desarrollo-web-br-bd.com

¿Cómo funciona una GUI de Linux en el nivel más bajo?

Básicamente, estoy tratando de averiguar cómo se podría hacer una GUI desde cero con nada más que el kernel de Linux y la programación en C.

No estoy buscando crear un entorno de escritorio GUI desde cero, pero me gustaría crear algunas aplicaciones de escritorio y, en mi búsqueda de conocimiento, toda la información que he podido encontrar está en API GUI y kits de herramientas. Me gustaría saber, al menos para mi comprensión de los fundamentos de cómo se hace la interfaz gráfica de usuario de Linux, cómo se podría hacer un entorno de GUI o una aplicación de GUI sin utilizar ninguna API o kit de herramientas.

Me pregunto si, por ejemplo:

  1. las API y kits de herramientas existentes funcionan a través de llamadas del sistema al núcleo (y el núcleo es responsable en el nivel más bajo de construir una imagen GUI en píxeles o algo así)

  2. estos kits de herramientas realizan llamadas al sistema que simplemente transmiten información a los controladores de pantalla (¿existe un formato estándar para enviar esta información que todos los controladores de pantalla acatan o las API de GUI deben poder emitir esta información en múltiples formatos dependiendo de la pantalla/controlador específico? ) y también si esto es más o menos cierto, ¿el kernel de Linux en bruto generalmente solo envía información a la pantalla en forma de caracteres de 8 bits?

Solo quiero entender lo que sucede entre el kernel de Linux y lo que veo en mi pantalla (control/flujo de información a través del software y el hardware, si sabe, qué formato toma la información, etc.). Apreciaría mucho una explicación detallada, entiendo que esto podría ser una dousie para explicar con suficiente detalle, pero creo que tal explicación sería un gran recurso para otros que son curiosos y están aprendiendo. Por contexto, soy un estudiante de ciencias de tercer año que recientemente comencé a programar en C para mi curso de Programación de Sistemas y tengo una comprensión intermedia (o eso describiría) de Linux y la programación. De nuevo, gracias a cualquiera que me ayude.

46
poopoopeepee123

Cómo funciona (Gnu/Linux + X11)

Visión general

Se parece a esto (no se dibuja a escala)

┌───────────────────────────────────────────────┐
│                       User                    │
│     ┌─────────────────────────────────────────┤
│     │             Application                 │
│     │            ┌──────────┬─────┬─────┬─────┤
│     │            │      ... │ SDL │ GTK │ QT  │
│     │            ├──────────┴─────┴─────┴─────┤
│     │            │            xLib            │
│     │            ├────────────────────────────┤
├─────┴───┬────────┴──┐         X11             │
│   Gnu   │ Libraries │        Server           │
│   Tools │           │                         │
├─────────┘           │                         │ 
├─────────────────────┤                         │
│   Linux (kernel)    │                         │
├─────────────────────┴─────────────────────────┤
│                    Hardware                   │
└───────────────────────────────────────────────┘

En el diagrama vemos que X11 habla principalmente con el hardware. Sin embargo, necesita hablar a través del kernel para obtener acceso inicialmente a este hardware.

Estoy un poco confuso en el detalle (y creo que cambió desde la última vez que lo examiné). Hay un dispositivo /dev/mem que da acceso a toda la memoria (creo que la memoria física), ya que la mayoría del hardware de gráficos está mapeado en memoria, este archivo (ver todo es un archivo) puede usarse para acceder a él. X11 abriría el archivo (el núcleo usa los permisos de archivo para ver si puede hacer esto), luego X11 usa mmap para asignar el archivo a la memoria virtual (hacer que parezca memoria), ahora la memoria se parece a la memoria. Después de mmap, el núcleo no está involucrado.

X11 necesita saber acerca de los distintos hardware de gráficos, ya que accede directamente a través de la memoria.

(esto puede tener cambios, específicamente el modelo de seguridad, ya no puede dar acceso a [~ # ~] todos [~ # ~] de la memoria. )

Linux

En la parte inferior está Linux (el núcleo): una pequeña parte del sistema. Proporciona acceso al hardware e implementa seguridad.

Ñu

Luego Gnu (Bibliotecas; bash; herramientas: ls, etc.; compilador de C, etc.). La mayor parte del sistema operativo.

Servidor X11 (por ejemplo, x.org)

Luego X11 (o Wayland, o ...), el subsistema GUI base. Esto se ejecuta en tierra de usuario (fuera del núcleo): es solo otro proceso, con algunos privilegios. El kernel no se involucra, excepto para dar acceso al hardware. Y proporcionar comunicación entre procesos, para que otros procesos puedan comunicarse con el servidor X11.

Biblioteca X11

Una simple abstracción que le permite escribir código para X11.

Bibliotecas GUI

Las bibliotecas como qt, gtk, sdl, son las siguientes: facilitan el uso de X11 y funcionan en otros sistemas como wayland, Windows de Microsoft o MacOS.

Aplicaciones

Las aplicaciones se encuentran en la parte superior de las bibliotecas.

Algunos puntos de entrada de bajo nivel, para programar

xlib

Usar xlib es una buena forma de aprender sobre X11. Sin embargo, primero lee un poco sobre X11.

SDL

SDL le dará acceso de bajo nivel, directo a planos de bits para que pueda dibujar directamente.

Bajando

Si desea bajar, entonces no estoy seguro de cuáles son las buenas opciones actuales, pero aquí hay algunas ideas.

Enlaces

X11

https://en.wikipedia.org/wiki/X_Window_System

Formas modernas

Escribir esto atrajo mi interés, así que eché un vistazo a cuál es la forma rápida y moderna de hacerlo. Aquí hay algunos enlaces:

https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/

62
ctrl-alt-delor

la respuesta de ctrl-alt-delor le ofrece una buena visión general de la arquitectura general. Para un enfoque más práctico, le doy una respuesta con respecto a "nada más que el kernel de Linux y la programación en C".

Me gusta escribir en el frame-buffer directamente de vez en cuando. El controlador del dispositivo frame-buffer hará todo el tedioso acercamiento al hardware "cómo terminará esto eventualmente en una pantalla" para usted. Puede hacerlo de inmediato con un Shell raíz:

echo -n -e '\x00\x00\xFF' > /dev/fb0

Establece el primer píxel (arriba a la izquierda) en rojo en mi framebuffer de 32 bits:

Screenshot of the framebuffer with the top left pixel red

Puede hacerlo totalmente desde C abriendo/dev/fb0 y escribiendo bytes. El mapeo de memoria puede convertirse en tu amigo. Esto solo funciona sin un servidor X o en una consola virtual. Presione Ctrl + Alt + F1 para acceder a él.

PD: visualizar datos aleatorios como el movimiento del mouse también puede ser divertido:

cat /dev/input/mouse0 > /dev/fb0

PPS: tenga en cuenta también que prácticamente cualquier aplicación de escritorio del mundo real desea un acceso más directo al hardware para algunas cosas sofisticadas como la aceleración de hardware para el dibujo, 3D y renderizado de video. El simple dispositivo frame-buffer no hará nada de esto bien.

30
Hermann

Recomiendo comenzar con ncurses .

A diferencia de los sistemas gráficos más complejos, se basa únicamente en texto, por lo que no hay necesidad de atascarse en los detalles de los controladores de pantalla y las bibliotecas de gráficos. Sin embargo, los principios básicos de colocar ventanas en una pantalla, mover el foco entre ventanas, etc., siguen vigentes. Y aún puede hacer algunos dibujos, a nivel de bloques de caracteres únicos y ASCII art.

Por supuesto, todavía está construyendo esto sobre una biblioteca, pero es una biblioteca que puede entender fácilmente. Y más que eso, es una biblioteca donde el código fuente está disponible gratuitamente, está bastante bien documentado y no es demasiado impenetrable si quieres leerlo. Incluso puede modificarlo usted mismo si lo desea. O puede mirar todas las funciones de la biblioteca para encontrar lo que la API debe ser, y escribirla usted mismo desde cero en función de ese diseño.

6
Graham

SunOS 5 tenía la biblioteca DGA, que proporcionaba acceso independiente del dispositivo a los diferentes adaptadores gráficos cg [3,6,14], TCX o LEO, que también era lo que soportaba Doom en SPARC máquinas.

cg6 era de 8 bits, generalmente se usaba en X11 como un pseudocolor visual pero también podía proporcionar un color verdadero de 8 bits, mientras que tcx y leo es un búfer de marco de pantalla 3D acelerado de 24 bits (pseudocolor = un byte en videoram es un índice en un gran tabla que da un valor RGB de 3x8, el contenido de la tabla se puede cambiar fácilmente). El cg3 tenía aproximadamente la misma capacidad pero no se aceleró (los diseñadores de cg6 comenzaron luego otra firma ... nVidia).

Los dispositivos posteriores como el PGX, que se basaba en el chipset ATI Rage Pro, no podían admitir truecolor y pseudocolor al mismo tiempo, lo que hicieron los anteriores. Esto obligó a un usuario a elegir entre aplicaciones antiguas escritas para el modelo de pseudocolor (o actualizar el sw si es posible) y ejecutar solo aplicaciones orientadas a truecolor.

El pseudocolor existía básicamente porque lo que era videoram era terriblemente caro a mediados de los 80 hasta 1992 más o menos. Una pantalla en color que admitía una resolución de tipo de estación de trabajo utilizable también era bastante costosa (el Sun 2 en blanco y negro de 1984 tenía una resolución de 1152x864, mientras que un MG1 de 1989 tenía 1600x1280 pero blanco y negro).

Escribo esto porque quiero mostrar los diferentes requisitos que X11 tenía que soportar.

2
Stefan Skoglund