Re: OpenGL-based framebuffer concepts

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >> 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 :
> 
> a) we don't always have a fully functional fbdev driver, see intel fb 
> drivers.

Well, we need to write those fbdev drivers, then.

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

Fix X and/or fbdev, then.

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

Let the distros catch up with current state of technology....

I mean, it is crazy. We have complex subsystem (graphics), that is
made even more complex because of crazy design (independend fbdev and
DRM, X handling PCI from userspace).

Now, lets take common hardware like radeon. You want these
combinations to be supported:

vgacon 
vesafb ( + unaccelerated X )
radeonfb ( + unaccelerated X )

vgacon + accelerated X
vesafb + accelerated X
radeonfb + accelerated X

vgacon + DRM + accelerated X
vesafb + DRM + accelerated X
radeonfb + DRM + accelerated X

...that's crazy! You claim that for various reasons (mostly bugs) we
need to keep that complexity. That's not the way forward, with
manpower we have I'm afraid.

I believe we can trim supported combinations to half... for hardware
that works anyway. For special cases like intel when some driver is
unavailable /broken, well we may need to do different choices, or
better write missing parts / fix broken cards. I believe that these
combinations make sense:

vgacon 
vesafb ( + unaccelerated X )
radeonfb ( + unaccelerated X )
radeonfb + accelerated X
radeonfb + DRM + accelerated X

That's half of combinations to care about! Plus first two are really
generic across x86...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/