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:2.747 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site