Re: OpenGL-based framebuffer concepts

On 5/28/06, Dave Airlie <airlied@xxxxxxxxx> wrote:
I've already pointed out to Jon the problems with this approach on
numerous occasions and to be honest do not have the time to do so
again,

I will not accept patches to make DRM drivers rely on fbdev drivers in
the kernel for many many many reasons, two quick ones :

Hence we will have no forward progress in kernel graphics for the next
few decades.


a) we don't always have a fully functional fbdev driver, see intel fb drivers.

Binding the drivers to each other does not cause any code to be called
in either driver. This is just the first step down a long path to
making the merged drivers work.

b) loading fbdev drivers breaks X in a lot of cases, we need to be a
bit more careful.

It is perfectly legal to load an fbdev driver with X today. If it
doesn't work it is a bug in X and should be fixed.

c) Lots of distros don't use fbdev drivers, forcing this on them to
use drm isn't an option.

Why isn't this an option? Will the distros that insist on continuing
to ship three conflicting video drivers fighting over a single piece
of hardware please stand up and be counted? Distros get new drivers
all the time, why will this be any different?

should I go on?

yes

You do realize that in a merged fbdev/DRM driver that if the mode
setting code is pushed into a user space library (I've said that would
be part of the path to a fully merged driver) that there really isn't
much left to a fbdev driver besides the binding and initialization
code.

I've made suggestions I've given you patches that start the work, I'm
going to finish that work, but I've no timeline, I'd hope at KS/OLS
this year to do it..

In your scheme the 60 existing fbdev drivers need to be edited to
remove their code that binds them to the hardware and make them use a
new low level driver. Are you signing up to edit all of these drivers?
I'll shut up when I see a tested patch that edits all 60 drivers and
make them use the new layer. My fear is that half the fbdev drivers
will get adjusted and no one will get around to fixing the rest,
effectively creating two fbdev architectures. A complete patch would
address that concern.

BTW, I've done patches that touched all of those drivers and it is a
very painful process. Be prepared to work on code for every
architecture supported by Linux.

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

Relevant Pages

  • Re: OpenGL-based framebuffer concepts
    ... does things in a strange manner, not even using the PCI bus mechanisms in the ... I don't know of any PCI based fbdev drivers not using the PCI ... Don't use the code in DRM CVS that loops over the PCI devices checking ...
    (Linux-Kernel)
  • Re: OpenGL-based framebuffer concepts
    ... > I will not accept patches to make DRM drivers rely on fbdev drivers in ... kernel politics are starting to sicken me. ... Jon is trying to force something into the kernel that no-one wanted ... and forcing the DRM on top of the fbdev drivers is not the way to do ...
    (Linux-Kernel)
  • Re: OpenGL-based framebuffer concepts
    ... >> are the best drivers we have. ... you forget everytime that the kernel ... >> fbdev drivers aren't even close, I mean not by a long long way ... it runs in the kernel or in user space. ...
    (Linux-Kernel)
  • Re: OpenGL-based framebuffer concepts
    ... Will the distros that insist on continuing ... > to ship three conflicting video drivers fighting over a single piece ... about binding the existing DRM and fbdev drivers together. ...
    (Linux-Kernel)
  • Re: pull request: wireless-next-2.6 2009-10-28
    ... The rt2x00 drivers include _all_ drivers in the ... If you are not willing to stand behind your own patches, ... the complainer and in that case I will explain to that person _why_ I disagree. ... I meant rt2800 support specifically, sorry if this was not clear. ...
    (Linux-Kernel)