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

quoted

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.