[linuxkernelnewbies] Grammer on my Terms: Linux Video Subsystem Revisited

[Peter Teoh]

http://thrawn01.blogspot.com/2005/03/while-i-was-out-of-town-dave-airlie.html Linux Video Subsystem Revisited While I was out of town, Dave Airlie posted to the Xorg list that he has Xgl running on top of Mesa solo!!! This really kicked off several threads about Xgl and the future linux video subsystem. The Disscusion quickly turned to MiniGLX. Mini GLX is a hack. It filled a specific need when it was created but I'm not sure it's an appropriate base for large projects. EGL was suggested as a replacement. Brian Paul wrote - An enhanced EGL interface could be a nice clean foundation. Xgl could layer upon it and other people could use it as-is for projects where X isn't wanted. Hopefully, other IHVs would adopt/implement it too. As the thread continued Adam Jackson mentioned that he already had some EGL interface code, and suggested they should get togeather and collaborate. This all led up to my favorite post to the list yet. Benjamin Herrenschmidt writes - That leads to one missing piece to ultimately merge the fb layer (mode setting) and the kernel DRM (command processing), which is a video memory manager that is independant from the client (X server). John Smirl Responds - Now you know why I have been making all those posts about merging DRM/fbdev for the last year while everyone was calling me crazy. mesa-solo has to join DRM/fbdev together to get the foundation that it needs. Some more disscuion insued, suggesting that if we are going to redo the video subsystem "mergedfb" was a nice hack, but not the way to go. But a video memory manager is really needed. Further down the list a thread about Monitor detection with HAL for Xgl started the whole drivers in kernel land vs User land bit again. Then Jon Smirl masterfuly steps in with this post. 1) Manipulating the PCI bus from user space has to stop on Linux. X is changing things in PCI config space without letting the kernel know. For example a kernel variable bridge_ctl shadows the hardware bridge control, the kernel can store bridge_ctl into the hardware wiping out changes X made. X can also make things like PCI ROMs appear in the PCI address space. The kernel does not know X did this. Now a new hotplug device comes along and the kernel assigns it an address on top of X's ROM. Good chance you need to reboot your machine. 2) X is not the only client of video. We have things like framebuffer, DirectFB, etc. Using device drivers for mode setting make this code common to all users. X is often conflicting with these other users. 3) Moving hardware access into the device drivers removes the need for X to run as root. 4) We are fixing the radeonfb driver to generate an interupt on monitor change for things like KVM switches. This interrupt will turn into a hotplug event that can be passed on to dbus. 5) In the XGL model card memory management is handled by the DRM device driver. When the device drivers are finished all of the info you are looking for will be easily accessible from sysfs. For example to enumerate the video cards in the system use: 'ls /sys/class/graphics' To see what modes the card supports 'cat /sys/class/graphics/fb0/modes' It will be easy to write dbus functions that build the lists from the data in sysfs. Ely Levi Responds - I just don't see why that code needs to be in the kernel, after all you don't need to be in kernel mode to access that information, and with linux moving device handling to user level with hotplug and udev it only makes sense to get the info in that way. as for pci info libpci is done by kernel people and probebly already knows how to find all that informaiton, I think kernel drivers should be kept as simple as possible as they are very not portable and a lot harder to debug. Jon Smirl Shoots, then scores - Doing these things in user space requires root priv. The XGL server is being designed to run without needing to be root. The basic idea is to minimize the code that needs to be inspected for security holes. It is much easier to inspect device drivers than the entire X server. [SNIP] Parallel arguements exist for why X should not enumerate the PCI bus from user space. The kernel instead provides a hotplug safe way to find devices via sysfs that doesn't need root priv. The Thread then trailed off on how HAL can support muliple OS's. Bottom line, the ground work for a new X server that depends on the OS to provide a video subsystem is at hand. Xgl now has a Web Page from where we may track it's progress. Eh, Long Post. But good stuff!