Re: OpenGL-based framebuffer concepts

["Dave Airlie" <airlied@gmail.com>]

> > 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 :
>
> So it's a personal thing? God, kernel politics are starting to sicken me.

Dude, calm down, this isn't about any kernel politics, I see you've
been talking to Jon off-thread if I had to guess..

Jon is trying to force something into the kernel that no-one wanted
then, an no-one wants now, he is the one playing politics, we've
described a perfectly workable solution a number of times.

We all agree that "one driver for one piece of hardware" is the ideal,
unfortunately sometimes you have to take a view of the way things are,
and forcing the DRM on top of the fbdev drivers is not the way to do
it, not alone will I NACK the patches I'm pretty sure no other kernel
maintainer is going to try and put them in.

> Okay. That means the intel fbdev drivers will advance significantly through
> the process of having the DRM drivers rely on the fbdev driver as a lower
> layer. I've already started work on this and find that the current fbdev code
> does things in a strange manner, not even using the PCI bus mechanisms in the
> kernel to find the hardware.

No they won't. the intel fbdev drivers can only progress via
information from Intel on how their cards work, all the wishing the
world on your part won't help that. From my point of view I've already
done a lot of work on the intelfb drivers just to get them into a
state for EGL on i915.

> Yes, a few drivers do this, but by and large any system currently in use will
> have it's video card on the PCI or AGP bus, including all those cards now
> being manufactured for the PCI-E systems.

Lots of the world isn't a PCI device, and of the 60 fbdev drivers that
Jon relishes in mentioning (at least 5 times in this thread so far), a
lot of them are for arcane hw that needs an fbdev driver to show
anything.... these don't need to be worked on, they are old drivers,
if someone wants to pick them up they can, we just make sure they
still work. THERE IS NO NEED TO PORT 60 DRIVERS, Jon just likes saying
numbers to discourage one course of action over another....

> > b) loading fbdev drivers breaks X in a lot of cases, we need to be
> > a bit more careful.
>
> Unlike what Jon says about this being a problem with X, I happen to feel this
> is more likely a problem with the way only 2 (of 60 or so) fbdev drivers find
> and bind to the hardware.

no I'm sorry you've been listening to Jon, the kernel fbdev drivers on
x86 are generally very very difficult to get working in all situations
, and while you may claim that is fixable it would be a pretty major
regression over what we have so no-one will accept it.

> Yes, this is a strange thing to do, relying on finding the ROM of a card at a
> specific location and requiring said ROM to have certain signatures. An
> easier method is to use PCI bus discovery - pci_get_subsys() and
> pci_dev_get() - for locating the cards.

ISA? SBUS? NUBUS? should I go on? have you got a copy of Linux Device
Drivers v3 at least to read?

Look I don't care how pissed off or not you are, I've got a job to do
in the real world and maintaining this stuff is just part-time
work.... I'm telling you what is acceptable in the kernel from my
point of view and the point-of-view of a number of kernel developers
that I've discussed this with over the past 2 years, Jon's view isn't
acceptable otherwise we would have accepted his patches.

There is no reason for the DRM to live on top of fbdev and any
attempts to make it live there will not be accepted by me into the
DRM, for technical reasons not whatever reasons Jon wants to use
(licensing, political etc..). If you can convince Andrew or Linus or
Antonio (the fbdev maintainer) to accept your patches I'll work with
them, but we've been over this at Kernel Summit last year we all
agreed on the way forward, it hasn't moved due to manpower not due to
clarity of direction. Jon just further obscures the directional
clarity by getting involved at all and I'd thank him to please stop,
his world view is not correctly aligned with the actual world in this
area.

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