Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Sunday 28 May 2006 23:13, Dave Airlie wrote:
> > > For a specific DRM chip there are currently four modules:
> > > fbdev-core
> > > fbdev-chip depends on fbdev-core
> > > drm-core
> > > drm-chip depends on drm-core
> > > RIght now drm and fbdev can be loaded independently.
> > >
> > > I would always keep fbdev-core and drm-core as separate modules.  But
> > > drm-core may become dependent on fbdev-core.
>
> 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 :

So it's a personal thing? God, kernel politics are starting to sicken me.

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

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.

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.

Furthermore, having DRM rely on fbdev for device discovery and memory 
allocation means that the kernel, via the fbdev layer, will gain the capacity 
to flip the video mode to something sane on an oops or panic and display the 
information.

While I feel it isn't exactly necessary for an oops, having the kernel able to 
tell the user what's going on when it panics is a good thing. Doubly so for 
those panics that happen when X is running - currently that's a silent death. 
I've had to rebuild my system twice because of panics during X that killed 
various bits.

> 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.

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.

Yes, there should be an alternate probe method for systems where this won't 
work. I can't argue against that, but the current method used in most of the 
drivers should be the alternate, not the other way around.

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

what distro's? The only ones that don't are either the ones that hold the 
users hand or the ones where the user is meant to be able to quickly change 
and modify the system.

In the first case the user is likely not going to see much of the console. But 
having fbdev act as a low-level system for those DRM drivers that fbdev 
drivers exist for (sometimes doubled or tripled - like the case of DRM-CVS's 
nv driver and the nvidiafb and rivafb drivers and sometimes not) is a step 
towards fully modernizing the linux graphics system and bringing it back to a 
"one device, one driver" system that should exist.

> should I go on?
>
> 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..
>
> Dave.

I'm using those patches and a lot of sweat as a guide for turning the fbdev 
core layer for graphics drivers. This solves a lot of the complexity of a 
middle-layer because the fbdev core layer is going to do nothing more than 
handle device discovery, device DMA and such things. The fbdev chip drivers 
and the DRM system will use it as the backbone and a way of 
cross-communicating.

In such a case as where a DRM chip driver and an fbdev chip driver both exist 
for a piece of hardware, the DRM driver will use facilities exposed in the 
fbdev chip driver to function. Yes, binding the DRM chip driver like that 
will force distro's to support the fbdev system, but the conflicts you 
mention above will disappear because the systems now know the other exists 
and don't do things that the other doesn't know about.

I'm sure any patches I produce will get NACK'd by you because of some arcane 
kernel politics, but after witnessing this shitstorm and letting myself get 
talked into the work after just tossing out a few ideas I really could care 
less. Something needs to be done, has been needed to be done since the 
fbdev/DRM split appeared and nobody is doing it.

I've got a hell of a lot of free time right now, I'm so totally bored wityh my 
private projects it's not funny and this is something to keep me busy for a 
long time. You fdon't like it? Fine - but at least look at it for the code 
and it's merits - because I don't deal with people that will let their 
personal feelings get in the way of their judgement.

DRH
(and yes, I am a bit pissed off. Deal with it.)
-
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/