lkml.org 
[lkml]   [2006]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-05-29 12:30    [W:0.674 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site