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
    > > a) we don't always have a fully functional fbdev driver, see intel fb
    > > drivers.
    >
    > Well, we need to write those fbdev drivers, then.

    And you propose to get specs from hw vendors how? (please provide
    solutions for practical problems)

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

    we don't have the manpower to do even that...

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

    and you are not going to fix it with a big lot of code, you need to
    fix it one problem at a time,

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

    We have to support what we support now, regressions in what we support
    are not acceptable, we would spend all our time just having Linus
    backing out changes, I'm sorry Pavel I respect what you've done with
    input, but your list below cuts out a number of currently support
    configurations the main ones currently in use are:

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

    If you take a look at the stuff required to get r300 support in the
    drm and X into the kernel without breaking current systems you'll get
    an idea of what we have to do..

    Linus has so far reverted a number of patches from the DRM as they
    cause regressions, anything done in this area has to be careful to
    have a complete understanding of the area.

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

    Again this gets rid of the two most popular combinations in use today.
    I don't think this is acceptable, and you'll also break suspend/resume
    on every radeon based laptop in use today, but I'm sure you thought
    about all of that before posting :-)

    I'm not knocking solutions here for the fun of it, I've tried a lot of
    different combinations of things to find an answer, and until someone
    supplies some code that doesn't regress or works in an incremental
    manner to improve the situation....

    Here are the rules:
    1. No regressions.
    2. Doesn't require lockstep changes in X and kernel, i.e. a new kernel
    can't break old X, and new kernel can't require a new X, new config
    features in the kernel can require a new X of course but anything
    using and old config feature must still work.

    Dave.
    -
    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:39    [W:4.657 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site