I have some question about linux desktop environment.
How linux shows its desktop environment on a screen. I mean where and how its GUI frames generates and send to lcd driver? is it at kernel level? does it have any relation to frame buffer (such fb0)?
Is it possible to access the Desktop GUI of linux and write it on frame buffer to show the window environment of linux?
I have searched a lot but did not find my main answer that how linux Desktop Environment is created and shown by monitor that have been known by drivers on linux.
thank you for your attention.
In Linux there's no internal desktop or anything like that. desktop environments are just regular applications just like other applications. almost all desktop environments at their lowest level interact with another GUI library (e.g Qt, GTK, ...). then all these GUI libraries interact with lower-level software called windowing system or display server or window server.
In Unix systems most used window system is X window system ( simply called as X or X11). almost any GUI library which supports Linux, it works with X.
Wayland is another windowing system which is growing and is supposed to be a good replacement for X, because X window system is too old and have many issues. but X is used almost everywhere in Linux and other Unix based operating systems.
So if you really want to know what's going on down there, you should know linux graphics stack. as i said desktop environments are just high level applications. from windowing system (like X) to lower-level libraries and modules (KMS, DRM, ...), are what you really looking for.
KMS (kernel mode setting) works with display controller and DRM (direct rendering manager) works with graphics card and GPU. (however it's really not as simple as i explained)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I'm studying Operating Systems. I read Window have lots of system calls for manage windows and GUI components. I have read you can change the GUI manager of your Linux Operating System. Then does Linux have system calls for GUI managements? How GUI works in Linux?
I'll take x86 as an example as I am more aware of x86 stuff than ARM stuff. Also, I may get some information wrong as I've been doing some research on this question while answering. Feel free to correct me if I am wrong.
System booting
Some time ago, Linux used to boot with a legacy bootloader (GRUB legacy version). The GRUB bootloader would be started by the BIOS at 0x7c00 in RAM and then would read the kernel from the hard-disk. It would follow the multiboot specification. The multiboot specification mentions the state that the computer needs to be in before jumping to the kernel's entry point. The kernel would then launch a first process (init) that every process would be a child of.
Today, most Linux distributions boot with UEFI (with the option of legacy booting also available). A UEFI app is placed on the boot partition partionned as a GPT ESP (EFI System Partition). This EFI app is launched and then follows the Linux Boot Protocol to launch Linux. The init process was also replaced by systemd. Linux will thus launch systemd as the first process of the computer. Actually, as stated on the manpage for systemd:
systemd is usually not invoked directly by the user, but is
installed as the /sbin/init symlink and started during early
boot.
The process that will be started is thus /sbin/init but it is a symlink to systemd. The systemd process will then read several configuration files on the hard-disk called units. These units are often targets which specify several units to read. Targets are thus units which specify several units to read. At first systemd will read default.target which specifies several other units. Some of these other units will start some processes among which is the Display Manager (fancy terminology which means login prompt). Recently, Ubuntu starts the Gnome Display Manager (GDM) as the first displaying program (gdm.service unit). This program will start the X server before presenting the user login screen (https://en.wikipedia.org/wiki/X_display_manager).
When the display manager runs on the user's computer, it starts the X server before presenting the user the login screen, optionally repeating when the user logs out.
Once logged in, GDM will start several other binaries responsible to let you interact with the system (the actual desktop, a binary to gather input for this desktop, etc). All of these components depend on the X server to work properly.
The DRM
The X server is a user program which makes extensive use of the Direct Rendering Manager (DRM) of the Linux kernel. The DRM is a system call interface which is used to interact with graphics cards. When the DRM detects a graphics card, it exposes a file like /dev/dri/card0 which is a character device (http://manpages.ubuntu.com/manpages/bionic/man7/drm.7.html).
In earlier days, the kernel framework was solely used to provide raw hardware access to
priviledged user-space processes which implement all the hardware abstraction layers. But
more and more tasks were moved into the kernel. All these interfaces are based on ioctl(2)
commands on the DRM character device. The libdrm library provides wrappers for these
system-calls and many helpers to simplify the API.
When a GPU is detected, the DRM system loads a driver for the detected hardware type. Each
connected GPU is then presented to user-space via a character-device that is usually
available as /dev/dri/card0 and can be accessed with open(2) and close(2). However, it
still depends on the grapics driver which interfaces are available on these devices. If an
interface is not available, the syscalls will fail with EINVAL.
The ioctl call allows to have any number of operations on the /dev/dri/card0 file since it is a general call which includes a request argument which is simply an unsigned long. It also takes a variable amount of arguments (see https://man7.org/linux/man-pages/man2/ioctl.2.html).
The ioctl call thus allows hardware vendors (like NVIDIA, AMD, etc) to provide drivers for their cards with the general ioctl call used as a general interface between user mode and kernel mode.
OpenGL
There exists several 3D rendering APIs available (OpenGL, Direct3D). OpenGL is mostly a set of C headers and a convention. The convention says what a certain call should do. It is up to the hardware vendor to implement the convention for their own card. Mesa3D has been an attempt to create an open source implementation of OpenGL for certain graphics cards. It worked quite well for integrated Intel HD Graphics (since documentation is open) and AMD (since they cooperated and offered some insight into the workings of their cards), but not for NVIDIA (the Nouveau driver is mostly not working or slow).
When you program some OpenGL, you include the OpenGL headers and link with libraries provided by hardware vendors which provide the definitions of the functions in the headers. These definitions make use of the DRM and cooperate with the X server to show content on the screen.
I'm studying Operating Systems. I read Window have lots of system calls for manage windows and GUI components. I have read you can change the GUI manager of your Linux Operating System. Then does Linux have system calls for GUI managements? How GUI works in Linux?
System calls (provided by the kernel) are often buried (e.g. in some cases deliberately undocumented and proprietary) and should not be used. Almost everything you see are actually normal functions in dynamically linked libraries/shared libraries. This allows the kernel's system calls to be radically changed without breaking everything (because everything only depends on the dynamically linked libraries/shared libraries); and reduces the functionality needed in the kernel itself.
For an example; most of the "system calls for managing windows and GUI components" you think Windows has could (internally, inside the relevant DLL) just end up using a single "send_message()" system call (to tell a different process, the GUI, that you want to create a window or change its position or ...).
For Linux it's roughly similar. The kernel's system calls (which actually are documented, for no sane reason - it goes against the spirit of SYS-V specs and means badly written "linux executables" aren't compatible with other Unix clones like FreeBSD or Solaris or OSX) exist to use things like low level memory management and raw file IO and sockets; but (like Windows) the kernel's system calls are buried under layers of shared libraries, and those shared libraries (e.g. like Xlib, GLib, KWindowSystem, Qt, ...) just use "something" (file IO, pipes, sockets, ...) provided by kernel to talk to another process (display server, GUI, ..).
Linux and Windows fall under separate categories; Linux is just a kernel, i.e. the piece under the hood that gives us the basic functionality we expect to run programs, like threads, memory and process management, etc. Windows is a full operating system, including the user facing components and numerous system libraries. An apter comparison would be a specific Linux distro and Windows.
On that note, distros, as independent operating systems, obviously can have different implementations of any OS component. Some distros, like Arch, don't come with a GUI by default at all. That said, essentially the entire Linux ecosystem uses Xorg and/or Wayland; I would recommend looking into the implementation details of those two.
A Linux GUI has quite a few differences compared to Windows GUI. For example, the GUI is not considered to be a part of the operating system, but rather an external part of it; that means no syscalls (not embedded whatsoever in the OS). After all, like the previous answer says, Linux is a kernel, that means it's only something really basic (allows execution of programs, memory/threads management, processes management, but not really much more). Whatever comes next (GUI, for example) are added features using packages.
This allows, for example, installing a GUI on top of a minimal installation of any Linux distro (CentOS, for example), and that GUI can be the one you want (Gnome, KDE...).
I'm trying to make a keyboard driver for windows & linux as a project, I was looking to simulate the actual process of writing a key (meaning not using anything such as windows messages), and after move on to the waiting for input from keyboard which I found alot of tutorials for.
Anyone know hot to do this for Windows & Linux? (running intel proc win10 64bit & kali linux amd proc 64bit)
You cannot have the same driver on Windows and on Linux. You'll need to make two different, unrelated, programs and you have to design them differently (because Windows and Linux have different architectures for drivers).
BTW, on Linux, with a graphical desktop, a display server (such as Xorg or Wayland) is running. That server is the only program handling the physical keyboard. You might consider working with it.
The actual notion of keyboard driver is too broad to make a concrete sense. On Linux, you could patch the kernel, patch the display server, improve the window manager, etc... There is no need, and not much interest, in coding that stuff in assembler.
Notice that on Linux, with a graphical desktop, the keyboard layout is handled in the display server, not in kernel code (so the kernel is sending key events with keycodes close to scancodes, not characters; the Xorg server sends keyboard events with similar keycodes to e.g. the window manager). Read more about the X Window System protocols and architecture and e.g. EWMH. The graphical layers are very complex (both on Linux and on Windows), many millions of lines of code.
I'm working on a GUI application with Qt on Linux. The operating system only provides the X Server and the prerequisites to run a Qt application. There is no desktop environment like GNOME, KDE, etc. installed yet. There's no window manager neither.
So my question is: does Qt require a preinstalled window manager (like KWin, Compiz, Metacity, etc.) or is it possible to write a Qt application that communicates with the X Server directly? I'm aware of the fact that the latter one possibly drives me crazy due to the effort I'd have. However, due to limitation of resources it could be an option.
Thanks in advance for your help!
No, Qt doesn't require a window manager when running under X11. You will have to manage your own windows, though! That means that you'll have to manage the Z order of windows, dragging windows on the screen, minimization/maximization if you need such, etc.
I've got the idea that in old days, XFree86 used /dev/fb* framebuffer devices. But now looks like the GUI system uses OpenGL, which is an open standard. So is OpenGL the lowest level open API? By 'open', I mean no obscure private ioctl or closed-source stuff.
Update:
I've got what I need after discussions with #datenwolf, who also provides a great answers.
In case anyone wants more coding detail: The X server driver is the lowest common level for the X system on top of any GPUs. To know what kind of interface an X server driver must implement: refer to DDX Design, it is a detailed doc for the latest X.org that tells you how to write an X driver.
In Linux there is no "lowest level API" exposed by the kernel that does graphics operations. All graphics drivers are actually implemented in the user space by so called "state trackers", which use special kernel functions to talk directly with the graphics hardware¹. The open source drivers implemented as part of the Mesa project use the Linux specific DRM API to talk to the hardware. The proprietary drivers from NVidia and AMD each use their very specific kernel module instead.
Now when it comes to end program usability Mesa and the proprietary drivers differ a bit:
NVidia's and AMD/ATI's proprietary drivers offer no API at all to end user programs to use for. Instead they're implemented as modules to load by the X server; the X server expects the driver modules to follow a specific scheme, which usually changes with major changes in the X server, so each X server major version bump usually required to update the driver modules as well.
The X server in turn provides a well known command stream based graphics API. Graphics commands sent over this API are scheduled by the X server and dispatched into called to the right functions of the driver module. The driver module in turn contains the whole intelligence for talking with the GPU and turns the commands coming from the X server into commands toward the GPU.
So to speak the X server is the lowest level universal graphics API currently available to Linux programs (except for programs that would go the length to implement everything to use the X driver modules directly).
When it comes to X11, the drivers that are part of the Mesa project are no different than the proprietary drivers. However because Mesa is open source its developers began implementing ways that programs could use Mesa and its drivers directly without having talk to it through the X server. For that they choose to expose an API conformant with the EGL specification. Unfortunately EGL is rather useless on its own because it requires an external display system to be present (or you can do only off-screen rendering).
This is where Wayland enters the picture. Wayland is not a display system. It is however a protocol that allows the building blocks of a display system to talk with each other. One central component of a Wayland based display system is the compositor which actually takes hold of the so called "seat" (= display device and associated input devices). Programs that want to display something on the screen use Wayland to open a connection with the compositor, which gives them a display to use EGL on. That they then can use to create actual drawing surfaces to do their graphics on.
[1]: Actually for some drivers (of legacy hardware) the X server must be started with root privileges, so that it can use the special function ioperm(…) to gain direct access to the hardware using the out*(…) and in*(…) functions and open /dev/mem for memory access. In this case there is zero support by the kernel regarding the communication with the graphics hardware. But for security and performance reasons nobody does (program) that anymore.
DRM and KMS, at least for the open-source driver stacks.
You need to build your own GPU-accelerated renderer, or use GLX
The lowest level access to the GPU is via X renderering backends.
The lowest level backend available to X is GLX.
GLX renders X directly to the GPU-accelerated OpenGL pipeline.
The default framebuffered xrender backend is unaccelerated.
Compton is an opensource compositor for X that uses the GLX backend.
It is a good example of using OpenGL to accelerate X.
GLX should be getting bindings for Vulkan, providing multiple OpenGL pipelines.
GLX only accelerates X in 2D, because X is a 2D app.
For 3D apps, a custom renderer is required.
The DRM GPU driver.
is the open...
I recently started using Linux (where I work is a Microsoft shop, so I only code in C#, work with MS products etc).
I'm trying to understand at a high level how some basic things in Linux hang together.
I've been reading www.linfo.org
Anyway I've never quite got what X is.
From reading this article it seems to me that X is layer that sits on top of the operating system (one X server sitting on top of the OS??) and X client applications make requests to the X server.
I think KDE, Xfce and Gnome are display managers, are they X server clients then?
I'm quite confused where everything sits.
Any explanation would be really appreciated!
It's all very modular and flexible; however this leads to complexity.
The "X Server" drives the display device. It provides graphics services to clients, and those services are pretty simple - such as:
"Give me a window frame to draw in"
"Put this bitmap here"
"Draw a horizontal black line 100px wide"
"Render the text 'hello' at (100,100)"
"Tell me if any mouse clicks or key presses have been aimed at my window frame"
There is a library called Xlib, provided by X, that has a standard interface for all these simple services. Any program that wants to use the X server's display eventually uses this client library and is called an X Client. Xlib knows how to connect to an arbitrary X server - on the local machine, or via TCP/IP across the LAN, or across the world - to call these services.
The Window Manager, which is just another X client program, is in charge of the "look and feel" of the desktop - how you move and arrange windows, etc. Because the window manager draws all the window decorations, it can make the desktop look like WindowsXP, or a Mac, or NeXTSTEP.
Part of the philosophy of X was to define "mechanism and not policy" - meaning, they give you tools to do it, but don't tell you how to use those tools. One such tool is the window manager, which can be replaced at will.
Many modern X applications are written to use a desktop enviroment such as Gnome or KDE. This offers these programs a consistent set of buttons and controls to draw, and a consistent interface for some things not traditionally included in X, but often considered part of a desktop - such as how to respond to drag-and-drop or how to present a standard file chooser dialog box.
The desktop environment usually provides an object model or programmatic interface that takes care of making all the simple X client requests and lets the program handle more important things. Removing these low-level calls yields another important benefit - platform independence.
Many desktop environments include a window manager, so that the look and feel of window controls and buttons is consistent and works with the desktop metaphor provided by the environment. However, it can usually still be switched out.
The separation of the X Server (running the display) and the X Client (wanting to use the display) has a few implications:
The graphics system is separate from the GUI programs, and they are separated about as completely as a web browser and web server are.
So the GUI program might not be displaying on the local machine - just like a web browser doesn't have to point at a web server on the local machine.
A machine can run JUST the client, with the X server elsewhere.
The machine with the display doesn't have to run the client - it can run JUST the X server, and all the clients can run on a dedicated machine. This is the original thin client: big programs running on big central server - with graphical user interaction handled by dedicated hardware on the desk in front of the user.
You need to know what your X server's network address is so you can tell GUI programs where to display their GUI. (this is usually done by setting the DISPLAY environment variable)
You can display many programs, from many different machines, all on the same desktop at the same time. It is all handled seamlessly, including cut-and-paste.
X11 is a network protocol, currently at release 7 (hence X11R7). It encapsulates graphics and input information, and connects an X client (application or window manager) running on a local or remote machine to the X server currently driving the local screen and input devices.
Gnome, KDE, XFCE, and LXDE are desktop environments; they contain pieces that talk to/with the X server (metacity, kwin, etc.), but also consist of specifications that applications must follow and libraries that are available in order for an application to "belong" to the DE.
In addition, it's worth remembering that the X server is just another program that gets run under linux. There's nothing special about it, it just happens to know how to grab onto the graphics card and take over the monitor using video drivers.
You can (theoretically) run linux very happily without ever running an X server - although of course, you would be limited to the command line programs.
That's how linux organises itself - kernel at the base, then a set of programs that provide functionality to higher level programs, which themselves provide functionality to higher level programs, all building up into a complete stack of software oriented to whatever the job of the machine is (say, general desktop, software development, web server, etc).
Beyond the kernel and it's modules, nothing is 'special'.
Wikipedia has some info about it.