[lkml]   [2002]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: atyfb in 2.5.51

    > I've always stated that the whole fbdev model was flawed, it makes
    > basic assumptions about how a video card's memory and registers are
    > accessed (ie. the programming model) and many popular cards absolutely
    > do not fit into that model.

    I agree that the design of the /dev/fbX interface is not the best.
    Unfortunely we are stuck with it. Changing it would break userland apps.

    > > I will have to go threw the X code to fix that :-(
    > There is nothing to fix. You simply must restore the video state when
    > the last mmap() client goes away. The __sparc__ code does exactly that.

    I should of worded that better. Meaning I have to see what X is doing so
    the fbdev driver sets the state itself better. Hm. I'm thinking about the
    mmap approach versus the fb_open approach being used now.

    > I think relying on an application that mmap's a card to perfectly
    > restore the state would work in a perfect world, one we do not live
    > in. Furthermore, fixing up the state like I am suggesting makes life
    > much simpler for people actually working on things like X servers and
    > other programs directly programming the ATI chip.

    :-( True. We should always assume X or any userland app could be broken.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:31    [W:0.019 / U:4.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site