Messages in this thread | | | Date | Mon, 29 May 2006 12:23:39 +0200 | From | Pavel Machek <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
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/
| |