Keith Packard writes: > > 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).
Right. There are other reasons that speak for leaving mode setting code out of the kernel: 1. Unlike most other code mode setting is not 'cheap'. Getting this code to work right on all falvors of cards using a specific chip is not an easy task. Keeping this independent of the OS as much as possible removes the need for duplication of this 'blood sweat' code. 2. Mode setting code is often times the result of trial and error trying to tiptoe around undocumented 'features' in the hardware. Although this code often does amazing things its quality is often not very good. It is usually not code one wants to have in the kernel. One may say: this can be fixed! Trust me, experience has show, this doesn't happen! 3. Faster deployment of new chipset support on a wider range of OSes. > > > 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. I'm sure this works well when COMPOSITE is enabled and OpenGL is used to accelerate COMPOSITE. I would like to see the performance of COMPOSITE + OpenGL vs. no COMPOSITE + XAA. > > 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. With XAA we already have an abstraction model for X that only requires to program the basic hardware dependent functionality in the chipset driver itself and to set bitmask telling the abstraction layer above which functionalities are supported. I'm sure this layer could be generalized. > > > 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. This doesn't really work well with 'TV' as this may require a specific resolution that's dependent on the underlying hardware. Your permitted resolutions are often tightly coupled to a lot of hardware dependent parameters. Only the chipset dependent driver can decide which modes it is capable of after it has knowledge about these other parameters. More so, these parameters may change during runtime when for example the output device is to be changed. Therefore any application on top of the driver should be prepared that video mode parameters it cares about (like fb location, fb stride, fb size, resolution, depth (?) may change underneath its feet. > > > 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. > On some platforms this is already done on the PIO level. Egbert. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
