lkml.org 
[lkml]   [2003]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
From
Date

> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.137 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site