Keeping the Screen Turned off While Getting Inputs

[Vladimir Dergachev]

On Sun, 27 Aug 2023, Ahmad Nouralizadeh wrote:

> Perhaps I didn't express my question precisely. I understand that you are talking about the mmap function in the kernel which is usually a function pointer in vm_operations...
> 
> My question is about the userspace structure of X11. IIUC, we have X11 clients, which are GUI apps.
> They have a portion of the X11 related libraries (those needed for clients) mapped into their address space. As the app and the X11 libraries (client code in X11) are in the same address space the
> graphical data are accessible by both. Xserver is a separate process (i.e., Xorg). How are the graphical data sent to the server? Does it use shared memory? Multiple shared memory regions to service
> each client?

First of all plain X11 does not use shared memory - the graphics requests 
are sent over a socket. Do as root "ls -l /proc/XXX/fd" where XXX is the 
pid of the Xorg. That socket is very fast !

Remember that originally X11 did only 2d graphics. POSIX shared memory 
support was added later via Xshm extension and was meant for transferring 
images.

The OpenGL is also an extension and how exactly it communicates is up to 
the driver. The driver is split into two parts - the part that sits in 
the kernel and the part that is in the Xserver.

The general trend is to make things faster you want to bypass as many 
layers as you can.

So you would setup your OpenGL window by talking to Xserver via a socket, 
and the Xserver will inform the kernel driver. Then you would send your 
data and rendering commands to the card via a kernel driver - preferably 
with as few kernel calls as you can get away with.

For example, running glxgears on my computer, with Xorg running on 
internal i915 Intel card, I see in /proc/XXX/fd:

lrwx------ 1 volodya volodya 64 Aug 27 13:03 0 -> /dev/pts/133
lrwx------ 1 volodya volodya 64 Aug 27 13:03 1 -> /dev/pts/133
lrwx------ 1 volodya volodya 64 Aug 27 13:03 2 -> /dev/pts/133
lrwx------ 1 volodya volodya 64 Aug 27 13:03 3 -> 'socket:[353776996]'
lrwx------ 1 volodya volodya 64 Aug 27 13:03 4 -> /dev/dri/card0
lrwx------ 1 volodya volodya 64 Aug 27 13:03 5 -> /dev/dri/card0
lrwx------ 1 volodya volodya 64 Aug 27 13:03 6 -> /dev/dri/card0
lrwx------ 1 volodya volodya 64 Aug 27 13:03 7 -> /dev/dri/card0
[...]

The file descriptors 0,1,2 are standard input, output and error. File 
descriptor 3 is the socket to talk to Xserver, and the rest is the device 
created by the kernel driver. I don't know why intel driver needs four of 
them.

Looking in /proc/xxx/maps there many entries, with lots of them looking 
like:

7fe9ac736000-7fe9ac836000 rw-s 203853000 00:0e 12497                     anon_inode:i915.gem
7fe9ac836000-7fe9ac83a000 rw-s 1109bc000 00:0e 12497                     anon_inode:i915.gem
7fe9ac83a000-7fe9ac84a000 rw-s 3267cc000 00:0e 12497                     anon_inode:i915.gem
7fe9ac90a000-7fe9ac91a000 rw-s 260574000 00:0e 12497                     anon_inode:i915.gem
7fe9ac91a000-7fe9ac92a000 rw-s 60d483000 00:0e 12497                     anon_inode:i915.gem

This has something to do with communicating with kernel driver. Looks like 
it needs a lot of buffers to do that. A few would make sense, but I got 21 
total which is too much.

On the other hand, on a different computer with an NVidia card, I see the 
following in /proc/XXX/fd for a plasmashell (KDE desktop):

lrwx------ 1 volodya volodya 64 Aug 27 13:13 11 -> /dev/nvidiactl
lrwx------ 1 volodya volodya 64 Aug 27 13:13 12 -> /dev/nvidia-modeset
lrwx------ 1 volodya volodya 64 Aug 27 13:13 13 -> /dev/nvidia0
lrwx------ 1 volodya volodya 64 Aug 27 13:13 14 -> /dev/nvidia0
lrwx------ 1 volodya volodya 64 Aug 27 13:13 15 -> /dev/nvidia-modeset
lrwx------ 1 volodya volodya 64 Aug 27 13:13 17 -> /dev/nvidia0
lrwx------ 1 volodya volodya 64 Aug 27 13:13 18 -> /dev/nvidia0
[...]

nvidiactl is unique - this is how things are triggerred, but there are 
many, many opened file descriptors to nvidia-modeset and, especially, 
nvidia0.

The contents of /prox/XXX/maps match in complexity:

7f0e6c00c000-7f0e6c00d000 rw-s 00000000 00:05 476                        /dev/nvidia0
7f0e6c00d000-7f0e6c00e000 rw-s 00000000 00:05 476                        /dev/nvidia0
7f0e6c00e000-7f0e6c00f000 rw-s 00000000 00:05 475                        /dev/nvidiactl
7f0e6c00f000-7f0e6c010000 rw-s 00000000 00:05 475                        /dev/nvidiactl
7f0e6c010000-7f0e6c011000 rw-s 00000000 00:05 475                        /dev/nvidiactl
7f0e6c011000-7f0e6c012000 rw-s 00044000 00:01 4096                       /memfd:/.nvidia_drv.XXXXXX (deleted)
7f0e6c021000-7f0e6c024000 rw-s 00000000 00:05 475                        /dev/nvidiactl
7f0e6c0d0000-7f0e6c0e3000 rw-s 00000000 00:05 475                        /dev/nvidiactl

and many more similar entries.

However, in both cases the focus is on communication with the kernel 
driver and the hardware, not the Xserver.

best

Vladimir Dergachev





> 
> Is Opengl mapped only into the server portion?
> 
>