--- Egbert Eich <[EMAIL PROTECTED]> wrote:
> Jon Smirl writes:
> > I'm putting together a document for Kernel Summit that describes
> the issues
> > around graphics device drivers. The kernel developers are
> currently making first
> > pass comments on it. As soon as I fold their comments in I'll
> post it to
> > fb-dev, dri-dev and wherever else is appropriate for the next
> round of comments.
> > Nobody is proposing final solutions yet, I'm just trying to
> collect everyone's
> > opinion.
>
> I fear that we will get a very Linux-centric view on device drivers.
>
> This will leave us with device drivers for Linux and a different ones
> (or none!) for the rest of the world. From an X developers point of
> view this is a support nightmare as he is the first one users will
> turn to if things don't work as expected.
We also have to consider the trade off between the interfaces a modern
graphics driver needs verses maintianing multi-platform availability.
If linux merges the FB/DRM drivers and moves certain things to the
kernel, there is nothing stopping other OS kernel developers from
adding similar features to their kernels, potentially even re-using the
linux fb/drm model (pending licenses). If X standardizes on an
interface to hardware, we can leave it up to the kernel people to
implement that interface. X develpers won't have to worry about
re-implementing support for various buses and quirks that the OS
already handles. OSes that choose not to support the new interfaces
can always fall back on the older releases of X. Future chipsets may
not even be useable down the road in the current model.
> Furthermore I'd argue that as little as necessary should live in the
> kernel space. One thing that - in my opinion - should *not* live in
> there is mode detection and initialization.
> First of all, we will not be able to do generic VESA mode
> initialization
> in the kernel (unless we decide to stick a complete x86 emulator into
> the
> kernel).
> Then many driver developers often take a very naive apporach at
> things
> and produce code that I know I don't want to see in my kernel.
> One can try to educate them which may not always be possible -
> especailly
> in the case of closed source drivers.
>
> Egbert.
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
-------------------------------------------------------
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
