[Libdlo] Ubuntu 9.10

[Bernie Thompson]

It's not clear to me what KMS means to fbdev drivers.

I'm sure there's more detailed info out there on this.  If someone
would be willing to take on the task of looking into this and report
back here with some info/recommendations, it'd be a great help --
either figure out the obvious answer, or dig in and ask some questions
on the appropriate (linux-fbdev-devel or dri-devel?) lists.

Here's some very old info from Jessie Barnes
(http://kerneltrap.org/node/8242), but I'm sure things have moved on
from here:

<quote>

DRM/FB cooperation

Another major factor to consider when enhancing modesetting in the
kernel is DRM and FB cooperation.  Currently, FB isn't aware of DRM
drivers, and DRM is only minimally aware of FB (such that it can bind
to PCI devices even after FB drivers have already done so).  As a
result, any modesetting done by either layer results in memory
allocation that may not be honored by the other side (and/or the X
server, which has its own idea of how memory is being used).  To
properly address interoperability, both the FB and DRM layers need to
share a common memory manager, common suspend/resume code, and common
modesetting code.  In addition, applications must use these layers in
some way to avoid conflicts (e.g. X should call into the DRM or FB
layers to do memory allocation).

What about the FB layer?

Today, the FB layer is really only well aware of a single head, and
doesn't do full EDID parsing, therefore its knowledge of available
modes is limited.  On the plus side, it's able to fetch EDID data where
possible and generate modes using the VESA CVT specification.

</quote>

Thanks!
Bernie

On Sat, Nov 14, 2009 at 10:41 AM, Kal McFate <kmcfate at darkink.com> wrote:
> I mentioned this previously but KMS must be disabled on newer kernels so X
> actually controls the FB devices.
>
> Kal