> 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 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/
This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:21 EST