--- 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.
> 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.
>
> 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
> 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.
>
> 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.
>
> Note that there are side effect. Changing the mode on a head can trigger
> a mode change on another. That typically happen when doing things like
> mirroring in which case you may want to turn your mirrored screen into a
> mode whose aspect ration is compatible with the second screen.
> (Typically the case with non-4:3 LCD laptop screens mirroring to 4:3
> CRTs). In general, the thing should be designed so that clients can be
> notified at any time of configuration changes. That along with a lower
> level arbitration mecanism on actual hardware access.
>
> > There are numerous pros and cons for both a both schemes. The user space
> code is
> > swappable, easier to debug, and does not need to be run as root. Cons are
> that
> > these are more pieces to track. Device driver code is minimized. On the
> other
> > hand boot time mode setting forces the code back into the kernel. Early
> user
> > space should also be considered. It may be possible to use the BIOS for
> display
> > until early user space is there, then change the mode. There's only about a
> > screenful of display before early user space starts.
>
> If the userland code is in initramfs, it can be run very early, we can
> use a small text engine like pmac btext for early debugging if
> necessary.
>
> > A side effect of the whole mode setting issue is dual/tri head cards. Once
> there
> > are multiple heads with multiple framebuffers. FB is going to have to start
> mem
> > managing the VRAM which it does not currently do. DRI runs a memory manager
> over
> > the same VRAM and this is a conflict.
>
> Yes, that, access arbitration, and config change notifications are the
> main issues at this time.
>
> > Another conflict is that the OpenGL/xserver can move the display framebuffer
> > around in memory, for example when going full screen on video. It will be
> > complicated to coordinate the location of the current scan buffers between
> > xserver and fb. Currently Xfree can't do this so it isn't a problem.
>
> Ben.
>
>
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
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
