Jon Smirl writes:
 > --- Egbert Eich <[EMAIL PROTECTED]> wrote:
 > > 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
 > 
 > Tell me the right non-Linux lists and I will post there too. There have been
 > significant complaints from the Linux kernel developers over the current DRM
 > code. Most of it centers around the crossplatform support. Better division of
 > the platform specfic code from the generic code should address these.

Right. However I've got the impression that this has improved already.
As far as DRM is concerned only a few OSes/platforms matter.
mode setting and 2D accel is an issue on many more OSes. Many of
those don't have a vital community as Linux does. Idnividuals and
groups intereseted in X (until now XFree86) on these platforms usually
gather on the project related mailing lists.

 > 
 > > kernel space. One thing that - in my opinion - should *not* live in
 > > there is mode detection and initialization. 
 > 
 > I'm making some progress on this front. I think I've talked benh into it, and
 > he's started talking to Linus about it. If Linux goes this path then is someone
 > going to move the other platforms onto this path too? Support is starting to
 > grow for merging FB/DRM into a simgle driver.
 > 
 > --- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
 > > 
 > > > The proposal is for a user space library that does mode setting as well as
 > > other
 > > > common things like cursor support. This library would in turn load plug-in
 > > > libraries for each card. 
 > > 
 > > Ok, we have been discussing all of these points over and over again, and
 > > I will be at KS, so I didn't want to restart the whole thing on this
 > > list, but I wanted to note a few things though:
 > > 
 > > > For the mode setting case the library would read the DDC data for each head
 > > > using the existing I2C drivers or the driver plug-in lib for non-standard
 > > cases.
 > > > This data would then be combined with config files where the user can
 > > override
 > > > modelines and such. 

Most of this exists inside of X already. These pieces could easily be
separated out of the server.

 > > 
 > > I agree with the idea of moving the EDID decoding & mode selection to
 > > userland. In this regard, though, I beleive we should aim toward some

I don't only want to see mode selection in user land but also mode
programming.
I keep reiterating the reasons:

1. Mode programming for a number of chips needs to be done thru the BIOS.
   Unless one wants to stick a complete x86 emulator into the kernel
   this needs to be done from user land.
2. HW programming (especially programming around hw quirks) is a hard job,
   and you need the hardware - if possible every flavor if it.
   No need to duplicate this for different OSes - not speaking of the support
   nightmare that is involved.
3. Quality of video driver code is often not what we expect from kernel code.
   The focus of the developer is often clearly upon getting the hardware to
   work.
   Graphics driver programmers shouldn't be forced to have to deal with kernel
   interfaces.
4. Debugging mode setting code involves a lot of round trips (edit->build->
   test->edit...). This can be done more effectively from user space.
5. Having this code in user mode in a separate project allows deployment of
   support for new chipsets.


 > > simple library that sits with the kernel, eventually distributed with
 > > the kernel tree, to live in initramfs optionally since it may be
 > > required to even get a console at boot (which is fine, initramfs is
 > > available early). The video cards themselves have PCI drivers that can
 > > "trigger" detection by the library via hotplug, the library could manage
 > > things like persistant configuration, either separate desktops or
 > > geometry of a complex desktop, etc... and eventually notification of
 > > userland clients of mode changes.

There are competing requirements here:
Libs that wack the hardware should be OS/platform independent as possible.
This is also a license issue.
Yes, we will most likely need OS dependent non-chipset specific wrappers,
but those are cheap to do - a lot cheaper than code dealing directly
with chipset quirks.

 > > 
 > > One reason for that is lots of monitors lie about their capabilities in
 > > their EDID block, so we want "override" files.
 > > 
 > > The kernel driver in this case doesn't need to be that much different
 > > than the current fbdev's though, except that we want to move the HW
 > > access for graphics commands to the kernel too, which basically turns
 > > into merging the DRI driver and the fbdev. There is no need, I think, to
 > > re-invent the wheel from scratch here, it would be a lot more realistic
 > > to build on top of those existing pieces.
 > > 
 > > > The modelines would be passed into the plug-in libs which would turn them
 > > into
 > > > register values. Finally the plug-in lib would use a private IOCTL to set
 > > the
 > > > state into the video hardware. 

It's not that easy. Modelines are only one part of the picture and - with
the advent of different display output technologies there are a lot of other
things that play a role here.


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

Reply via email to