Page 1 of 1

How do X servers interface with graphics drivers (*nix)

Posted: Mon Oct 22, 2007 8:11 am
by JamesM
I couldn't fit everything I wanted to in the title :(

Filesystem and NIC drivers are mount()ed into the filesystem - what happens with gfx drivers? If an X server like XFree86 or XOrg wants to display a primitive, or draw a line, what happens? what functions does it call? Is there a generic interface library for these?

Cheers :)

James

Posted: Mon Oct 22, 2007 9:07 am
by Brynet-Inc
I'm not entirely sure if I'm experienced enough to answer this, but OpenBSD seems to take a lot of security precautions for X.

During installation it asks if X will be used, if so it enables the "Aperture driver". (via sysctl machdep.allowaperture=2)

The folloing fstat output shows which devices Xorg accesses..

Code: Select all

root   Xorg  14021 1 /  475244 crw-------  rw  xf86 /* X11 Aperture Device */
root   Xorg  14021 2 /  474837 crw-------  rw  ttyC0 /* Keyboard Console */
root   Xorg  14021 3 /  474841 crw-------  rw  ttyC4 /* X11 Console */
brynet Xorg   2812 1 /  475244 crw-------  rw  xf86  /* .. */
brynet Xorg   2812 2 /  474837 crw-------  rw  ttyC0 /* .. */
brynet Xorg   2812 3 /  474841 crw-------  rw  ttyC4 /* .. */
brynet Xorg   2812 8 /  474970 crw-r--r--   r  apm /* Power management.. */
brynet Xorg   2812 10 / 474849 crw-------  rw  pci0 /* PCI Character device */
brynet Xorg   2812 11 / 474834 crw-------  rw  wsmouse /* PS/2 Mouse */
.........
brynet xinit 20929 0 /  474837 crw-------  rw  ttyC0
brynet xinit 20929 1 /  474837 crw-------  rw  ttyC0
brynet xinit 20929 2 /  474837 crw-------  rw  ttyC0
There were also several network connections, Unix domain sockets/TCP etc..

How does it work on Linux? I have no idea.... :P I barely understand how OpenBSD manages it..

Posted: Mon Oct 22, 2007 10:40 am
by mystran
I only know about Linux. Mostly the display driver exists within the X server. That's true for 2D anyway. For 3D, no idea, I can't even code any OpenGL, much less 3D drivers, but even there, I'm under the impression that mostly a kernel module is only needed for AGP trickery. :)

Any normal process running with sufficient capabilities (often that means simply root) can get hardware access by asking, so there isn't much special that X has to do. Basicly you ask for the IO ports and memory areas you need and then you have fun with 'em.

I remember hearing some talk about interrupt issues and how those do not work unless you have a special kernel module, so I'd guess most 2D drivers are written to run without any interrupts, which as far as I know has it's own problems.

But .. I'm saying all this on top of my head without knowing much of anything about the subject, so don't trust me. :)

Posted: Mon Oct 22, 2007 10:46 am
by Brynet-Inc
mystran wrote:...But .. I'm saying all this on top of my head without knowing much of anything about the subject, so don't trust me. :)
Exactly, don't trust me neither.. I know very little about this subject, I expect it works different depending on the OS and Architecture.

My understanding is...
* 2D graphics are handled via Xorg.. It includes it's own drivers..
* AGP/PCI-E drivers may require extra work, when compared to ISA/PCI cards? (I'm not sure..)
* 3D is typically handled by the "DRM" and "DRI" modules, DRM being a kernel module.. (Which isn't ported to OpenBSD.. :()

DRM/DRI is a separate project it seems though: http://dri.freedesktop.org/wiki/

Perhaps you should look at the source code? X is modular now as well... 8)

Posted: Mon Oct 22, 2007 10:54 am
by mystran
Brynet-Inc wrote: Perhaps you should look at the source code? X is modular now... 8)
Does that mean that when you change one line of code, it doesn't involve waiting two hours while the build scripts run to discover that you forgot the semicolon anymore? :roll:

Posted: Mon Oct 22, 2007 10:59 am
by Brynet-Inc
mystran wrote:Does that mean that when you change one line of code, it doesn't involve waiting two hours while the build scripts run to discover that you forgot the semicolon anymore? :roll:
Everything has been "individually wrapped" so to speak, they also started using the GNU autoconf/automake system.. ;)

So now you can recompile a specific driver without... waiting 2 hours ;)

http://www.x.org/wiki/ModularDevelopersGuide
http://xorg.freedesktop.org/releases/X11R7.3/src/ -- Purty? 8)

Posted: Mon Oct 22, 2007 3:20 pm
by niteice

Code: Select all

ice@SirGalahad:~$ ls -l /dev/nv*
crw-rw-rw- 1 root root 195,   0 Oct 21 22:20 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Oct 21 22:20 /dev/nvidiactl
There are those character special files. The following is pure speculation, the open-source nv driver isn't very clear:

The driver opens those files, and the kernel recognizes that they should be handled by appropriate module. One is mmap()ed and used for register and data writes (see: ATI's published documentation (I assume nVidia works similarly) and open-source nv driver), the other for general hardware manipulation.

Posted: Mon Oct 22, 2007 10:22 pm
by Brynet-Inc
Those specific device nodes are created by the proprietary nvidia driver for Linux.. I don't think the "nv" driver uses them.

Posted: Tue Oct 23, 2007 1:30 am
by JamesM
Thanks guys, I got the answer to the question - "It's propriatry (sp?) as hell, just make it up". :)

Posted: Tue Oct 23, 2007 9:05 am
by Brynet-Inc
JamesM wrote:Thanks guys, I got the answer to the question - "It's propriatry (sp?) as hell, just make it up". :)
The 2D drivers aren't proprietary.. but 3D acceleration quite often is.. :(

Hopefully this will soon change.. With the specifications AMD/ATI "plan" to release (And the driver..), Who knows?

(Really, NVIDIA is one of the only big companies left.. lol..)

Posted: Tue Oct 23, 2007 10:21 pm
by iammisc
I think that you have to build some drivers into the kernel and then the x driver talks to that driver. For example on my old Intel i810 system I had to enable the Intel I810 kernel level driver under dri devices in the kernel config.

I think some drivers however, might talk to the device directly.

Posted: Wed Oct 24, 2007 1:23 am
by JamesM
The answer I gleaned from that is the drivers are built into the X server.

Ugh. Horrible. Not being replicated in my OS!

Posted: Wed Oct 24, 2007 1:53 am
by Brendan
Hi,

X is a standard for communication between a server and it's clients. The "back end" (or how X talks to video hardware) can be anything.

For normal OSs, X would use some (OS dependant) video driver interface to access the OSs existing video drivers.

For broken OSs, there is no video driver and no video driver interface for X to rely on. An example of this would be old versions of Linux, where "video support" meant text mode consoles and nothing else. In this case the only way to support X is to build video drivers into the X server.

For monolithic kernels (where device drivers are meant to be in the kernel) this can mean breaking the kernel's protection mechanisms to allow the video code in the X server to run. This causes protection/security problems, but also causes compatability problems between X and other processes that use video directly (e.g. any application that uses SVGAlib) and makes it extremely difficult if X crashes (leaving the video in an unknown state). For examples, see the old GGI/KGI FAQ.

IMHO (for Linux) it's a huge mess caused by original design flaws ("Oh, video is hard, let's ignore it" followed by "Oh, there's no video support, we'll have to hack it into the X server", followed by "the X server is crap because of video driver hacks, let's all do seperate/different things to fix it"). At the moment there's a mixture of different techniques used in Linux, where the X server might use kernel drivers/modules, VESA, or contain it's own video code for direct hardware access.

For a sane design you'd want layers - something like the OSI module (but for video, keyboard, mouse, sound, joystick, etc; rather than for networking). For an example, the bottom layer would be hardware, the next layer would be drivers, the next layer could be console, then the GUI layer, then the application layer at the top.


Cheers,

Brendan

Posted: Fri Oct 26, 2007 10:01 pm
by AndrewAPrice
mystran wrote:Does that mean that when you change one line of code, it doesn't involve waiting two hours while the build scripts run to discover that you forgot the semicolon anymore? :roll:
That gets annoying when you change one thing in a common header file included in 99% of your project. Which mean 99% of the project has to rebuild just for one small change.

Re: How do X servers interface with graphics drivers (*nix)

Posted: Fri Oct 26, 2007 10:27 pm
by AndrewAPrice
For 3D, I think (but not 100% certain), DRI is responsible for giving the final buffer to be drawn on the screen.

The OpenGL implementation acts as a middle-man between your program and the frame buffer, you send it requests (set device state, set texture, set vertex stream, render index batch), the OpenGL implementation translates these to hardware instructions (or emulates it). The image is stored in video card memory until Present (D3D) / Swap Buffer (OpenGL) is called, where it is copied back to the program's-window/full-screen-frame-buffer/etc.

If the final rendered image is to be displayed in a window, then there are two ways this can be done:
- The final image is rendered as a control in the program's window and it is up to the window manager to process this just like any other 2D control.
- Or, when initialising the OpenGL/Direct3D device a pointer to the full screen frame buffer is passed, but only told to render in a certain rectangle. This presents the problem that your OpenGL/D3D window must always be on top.