Re: [Dri-devel] Re: DRM and pci_driver conversion

Face it, a good graphics driver needs more than just "set up the ROM". It
needs DMA access, and the ability to use interrupts. It needs a real
driver.

It basically needs something like what the DRI modules tend to do.

I'd be really happy to have real graphics drivers in the kernel, but quite
frankly, so far the abstractions I've seen have sucked dead donkeys
through a straw. "fbcon" does way too much (it's not a driver, it's more a
text delivery system and a mode switcher). And DRI is too complex and
fluid to be a good low-level driver.

Well... While I tend to agree, note that in 2.6 fbcon and the fbdev
itself _do_ have been separated. The fbdevs are moving toward that
low level driver thing.

Quite frankly, I'd much rather see a low-level graphics driver that does
_two_ things, and those things only:

 - basic hardware enumeration and setup (and no, "basic setup" does not
   mean "mode switching": it literally means things like doing the 
   pci_enable_device() stuff.

 - serialization and arbitrary command queuing from a _trusted_ party (ie
   it could take command lists from the X server, but not from untrusted
   clients). This part basically boils down to "DMA and interrupts". This 
   is the part that allows others to wait for command completion, "enough 
   space in the ring buffers" etc. But it does _not_ know or care what the 
   commands are.

IMHO, that low level driver should be ... the fbdev. The main reason for
that is the necessary locking & synchronisation between the command flow
and mode switching, palette control and cursor control (which aren't
things doable via the normal command path on moth cases).

Then, fbcon and DRI and X could all three use these basics - and they'd be
_so_ basic that the hardware layer could be really stable (unlike the DRI
code that tends to have to upgrade for each new type of command that DRI
adds - since it has to take care of untrusted clients. So DRI would
basically use the low-level driver as a separate module, the way it
already uses AGP).

I agree that fbcon itself should (and is now in 2.6) be a separate
module. The interface is still scary, the locking is almost absent,
which is a real problem even with current mode switching beeing racy
with printk & blanking, but at least we have something that works and
can evolve in the right direction.

Look how the fbdev interface was simplified in the 2.4 -> 2.6
transition, it's really a lot saner now, and I hope it will continue
to improve.

But I'm _not_ interested in some interfaces to let user mode just bypass 
the kernel. Because they will not solve any of the other problems that 
clearly _do_ need solving, and if the X server continues to believe that 
it can just access the hardware directly, it will never play well together 
with projects like fbcon/dri.

Fully agreed. My point is that this low-level driver and the fbdev should
be one thing.

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/