>> 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).
Exactly. I have no real concern on where "one place" is, as long as all the clients (And the kernel booting is a client) can access it. I would contend that it is perhaps just a long held fear that mode setting is too big and complex for the kernel. It will be big, complex, and highly privileged code no matter where it lives. At some point we will cross the line between what is "too complex". If we aren't there now we will be some day soon. Lots of OS designs have had mode setting kernel-side for a long time. The "driver" contains register level hardware knowledge and elevated privileges. The "client" does not have either. It knows only the driver's API. Same as DD OGL (client) and DRM (driver). >> 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 think you are straying into the area I wanted to stay away from. The driver model will have some chunk of device dependent code talking to the hardware that knows nothing of the high level API. It isn't X related, it isn't OGL related. It is hardware related only. Then there are corresponding DD parts for X, OGL or whatever that know this hardware specific API. As a vendor I want to write this low level component once no matter what the future design of the higher level clients. You cannot predict with any degree of accuracy what the future of graphics is going to be, but that doesn't preclude getting the driver model right. If you want to stack X on top of OGL... fine. I'm talking about the API between the DD parts of OGL and the hardware driver. >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. Exactly. The driver model interface (maybe call it a HAL) looks like the hardware. For older generation cards there would be very little here, just some 2d stuff. The DD portion of OGL or whatever would be doing it all in software (probably punting) >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. We have correctly moved most of the X world away from modelines and toward a symbolic name, however the DI->DD part is still broken. X tells the driver the set of timings but X knows nothing about the hardware so the more advanced drivers throw those timings away and use a "correct" set that most closely matches. It should be DD component telling DI component what is possible and DI component choosing from that list. >> 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'. Correct. Bag o bits is what I'd like to see removed from the fbdev. I think a command interface would be a good design. i.e. Write commands rather than ioctls. (or one ioctl that takes a command buffer) that way you can get one context switch (all privilege elevations will require this, even if it isn't a Ring3->Ring0 thing) for a lot of commands. Plus it is easy to version, and support multiple versions concurrently. Command0 == Set command interface to version 1.0 command1 == draw foo command2 == dispatch dma buffer xyz and another client... command == set command interface to version 1.2 command1 == draw foo (slightly different interface than 1.0) >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. I would actually hate to see this for the mode setting part. This is a complete over-simplification of modern hardware. You would end up defining a whole language of sleeps, wait_for_bits, and register writes to get the job done correctly. You cannot just blast register values to hardware. On Intel hardware you will need to wait for vsyncs, talk to external devices over i2c, etc. Trying to let user-space determine all the register values ahead of time is simply not going to work for mode setting, you will just end up encouraging drivers to have the same very limited set of mode setting capabilities that you have now. For rendering the driver API should be close to the hardware. Stack your OGL or whatever on top of that. Just like DRM does now. For mode setting the driver API is going to have to be somewhat self contained. "What modes can you do?", "ok set number 3". Just to be clear we've got two discussions going on now. 1 is the "What will the future graphics stack for Linux look like. X on OGL? OGL alone? Foo on Bar? I am making no statements related to that discussion. 2 is the what does the "driver model" look like. Mode + Render kernel side? Mode kernel side + privileged user library? Tiny kernel module + privileged user library for mode and render? That is the discussion that seems ripe for a final solution. ------------------------------------------------------- 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
