Re: Re: atyfb in 2.5.51

* James Simmons [off-list ref] [021211 16:16]:

quoted

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.

One thing I was wondering: Is there a proper way to make sure that 
acceses to the framebuffer end up only on one specific virtual console?
I have an application that runs on one virtual console, but when
switching I do not want the screen to be trashed by writing just into
the framebuffer memory. My solution was to check whether the current
console is the console the application started on, but this looks a
bit bloated to me and I had some weird effects when switching to X and
back - like one frame still got painted into graphics memory while X was
already shown.
  
  Any ideas?
  Stefan

-- 
Laissez Faire Economics is the theory that if each acts like a vulture,
all will end as doves.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/