From: Jon S. <jon...@ya...> - 2004-07-28 18:53:59
|
After talking to many people at OLS this seems to be the consensus for rearchitecting fbdev/DRM. It has been proposed that this design be a five year goal but there is still disagreement about the exact path to get there. This is a first pass for the fbdev/DRM people. I will incorporate comments and repost to lkml for the final pass. I'm sure everyone will let me know if I've misinterpreted some of the design points. First a basic definition. There are two consoles, the kernel one (printk, kdbg, OOPs, etc) and user one (normal console logins). There is no requirement that these consoles be handled with the same code even though they are today. 1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to track the boot video device and expose the contents of C000:0 for that special case. 2) VGA control - there needs to be a device for coordinating this. It would ensure that only a single VGA device gets enabled at a time. It would also adjust PCI bus routing as needed. It needs commands for disabling all VGA devices and then enabling a selected one. This device may need to coordinate with VGA console. You have to use this device even if you aren't using VGA console since it ensures that only a single VGA device gets enabled. 3) Secondary card reset - Handled by an initial hotplug event. We need a volunteer to write clean vm86 and emu86 apps for running the ROM initialization. Resetting needs #1 and #2 to work since resetting a card will enable it's VGA mode. I have an implementation of this but it needs a lot of clean up. 4) DRM code reorganization. There were several requests to reorganize DRM to more closely follow the Linux kernel guidelines. This reorganization should occur before new features are added. 5) Multihead cards will expose one device file per head. Many IOCTLs exposed by these devices will be common. Some, like mode setting, will be per head. 6) Mode setting before early user space - this was decided to be a platform specific problem. With minor adjustment the kernel can be made to boot without printing anything except errors before early user space starts. Platform specific code will need to handle these error messages if any. This includes INT10, Openfirmware, mainframe serial consoles, VGA mode. Suppressing informatory printing before early user space starts allows a clean boot straight into graphics mode. 7) Mode setting from normal user space - devices will have a standard IOCTL accepting a mode string like fbdev currently uses. This IOCTL will lock the device and optionally trigger a hotplug mode event. Mode setting for some fixed devices is simple enough to avoid the hotplug event. In the hotplug event the mode line will be decoded, DDC queried, etc. Some classes of devices (for example Intel 810,830,915) have to have their mode set using vm86 and the video BIOS. Others might use a small C app to query DDC and then use a device specific IOCTL to set the mode registers. Early boot and normal user space will use the same hotplug apps so they need to be as small as possible (good luck IA64 and emu86). 8) Merged fbmode - per head mode lists will include merged fb modes if the other heads aren't in use. Setting a merged fb mode will lock out the other head devices. It was decided that this was a better design than having a control device. 9) printk - setting the mode will also record the fb location, size, stride. Combining this info with the current fbconsole code will allow printk/oops to print in all modes. 10) a new system console UI is proposed. SysReq blanks the current screen and replaces it with the system console. System console will also support runing kdbg. Hit SysReq again and whatever you were doing is restored. This operation does not change the video mode. 11) OOPs will cause an immediate screen clear and painting of the system console including the OOPs data. It is not needed to change the video mode. Further drawing to the screen will be blocked until SysReq returns to normal operation if possible. 12) interrupt time printk - certain hardware implements non-interruptible operations. Most modern hardware does not do this. For older hardware these non-interruptible operations will need to be wrapped by the device driver. The complete data needed to finish the operation will be provided in the IOCTL. Doing this enables an interrupt time printk to call into the driver, make sure the hardware is free by completing the pending operation, and then write to the framebuffer. No older hardware currently implements this protection; without this protection there is potential for locking the machine. 13) all of the features being discussed are implemented by a single device driver plus a supporting set of library drivers. Multitasking of multiple controlling device drivers for a single piece of hardware is not allowed. 14) A new framebuffer memory manager is needed for mesa GL support. Ian is working on it. The memory manager will be part of the support library driver code. 15) Over time user space console will be moved to a model where VT's are implemented in user space. This allows user space console access to fully accelerated drawing libraries. This might allow removal of all of the tty/vc layer code avoiding the need to fix it for SMP. 16) accelerated, kernel based console drivers are not supported in this model. The only in kernel operations are simple ones like CR/scroll, clear, print text. It is possible to call existing DRM entry points from a kernel thread, but the code needed is complex. 17) A user space console implementation also makes supporting multiple users on multiple heads/card easier. The kernel will not need to be modified for multi-user VT support. User mode console allows pretty text and Asian scripts. 18) A coordinated system for grouping console devices needs to be designed. This will be bad if each distro does it differently. One proposal is to use udev to create: /console/1/mouse, /console/1/keyboard, /console/1/usb_hub, /console/2/mouse, /console/3/keyboard, /console/4/usb_hub, etc. 19) SAK - secure attention key. We forgot to talk about this so we need a design. 20) A PAM login would assign ownership of the console group devices to the logged in user. A mechanism needs to be designed for assigning ownership of secondary heads for the merged fb case. X should run as the logged in user and not require root if the hardware allows. 21) It was also discussed the X should stop implementing OS level features and instead use the features of the underlying OS. If the underlying OS is lacking support the support would be implemented in a library external to X. Examples of moving from X to OS support include: PCI bus, input, console groupings, etc. 22) A goal this design is to discourage user space video driver implementations when a kernel one exists. An example of this would be X's radeon XAA driver. X would instead use the DRM driver via mesa. 23) The old schemes are not going to be removed. If your ancient 2D card only has an fbdev and XAA driver it will still work. We're not going to remove old drivers if new ones don't exist. But don't expect the composting X server to turn your clunker 2D card in to a Radeon X800. ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |