|
From: Stefan R. <st...@su...> - 2002-12-15 11:45:33
|
* James Simmons <jsi...@in...> [021211 16:16]: > > > 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. |