Around 16 o'clock on May 6, "Sottek, Matthew J" wrote: > 1) If the mode setting can be removed from the X server then we can > leverage that module for whatever graphics system is required. Some > times we need an X server, some times we need something more like a > framebuffer. Putting this in one place is a must.
'one place' appears to mean a common library API and not a common kernel API; some cards require extensive code to manage mode selection which can't be effectively implemented in kernel mode (like the current X i810 drivers). > 2) Providing one place for rendering code would be nice too. For cards which can support it, I'd like to suggest that the GL API seems a natural fit here. Retargeting the X server to GL appears possible, and I hope to have a proof of concept running by OLS to show people. For other cards, I suggest that there aren't a whole lot of useful accelerated operations; 2D only cards generally don't support general image compositing, so the only critical operations for "modern" applications are video->video blt and (optionally) solid fill. I've implemented rather a lot of X servers in this way to good effect. > 1) A small, device-independent, API that can be used to set modes and > do some very simple rendering. Yes, the lowest level graphics driver needs to be able to request a specific mode and find out how that affects the hardware. I would suggest that the 'mode' selected here be indirect -- a 'symbolic' mode which reflects a more sophisticated configuration as specified by some device-specific mechanism. For instance, it would be nice to start a graphics application in "TV" mode without that application needing to know about all of the underlying complexities. This is similar to how standard modes are specified in X today -- you request a resolution, which is really just a symbolic name for a list of modes. The driver then selects one of those modes which the monitor can support. > 2) A mechanism to make all the device dependent extensions your heart > desires. Absolutely -- both for driver writers and mode selection mechanisms. Of course, one thing here is to make sure the kernel API isn't just a 'bag of bits in an ioctl'. Perhaps the kernel API could accept a list of register name/value pairs for the desired mode; the kernel driver would then be responsible for setting the register values appropriately. -keith
pgp00000.pgp
Description: PGP signature
