Re: Changing an app to use linux framebuffer

[Stas Sergeev <stssppnn@yahoo.com>]

Hello.

Simon Bridger wrote:
> Slow is a nuisance, but it isn't terminally slow.
> The showstopper is the mouse behaviour. What happens is this. When the 
> mouse reaches the edge of the autotrax screen, autotrax pans, and moves its 
> own mouse cursor back to the middle of the screen.
If only this is a problem, then surprise:
just press Ctrl+Alt+Home and the mouse
is trapped.
Note: there are generally more than one
"Home" button on the keyboard, but only
one will work for catching the mouse.

> Would it be possible to make an xdos session run fullscreen?
This is not always possible. Try the
xxx_aspect and xxxfact options of your
dosemu.conf (ie $_X_fixed_aspect etc).

> - with the xwindows mouse disabled/hidden (since autotrax is doing all 
> its own mouse display)
Yep, see above for the recipe.

> Assuming the mouse problem is solvable, is there a way to rewrite the 
> autotrax driver to make it faster when using the xdos screen?
No idea. xdos is always slow, as it have
to emulate all the hardware registers of
the VGA-compatible card.
It would be easier to enlarge an IO bitmap
in the 2.5 kernel after all.

> As I had another look at it I also notice that the vesa drivers for 
> 1024x768 and smaller work properly.
Just to avoid any confusion: what I told
you about VESA non-functionality and all the
underlaying problems, was under the quote
of your question regarding a direct video
card access (under console). xdos have its
own problems and limitations, but after all
it is hardware-independant, so the VESA is
(partially) supported there for any video
card that can run X.
xdos may work for you, but having the fast
full-screen direct VESA under console would
still be quite cool:) Unfortunately, currently
this is possible only on some absolete boards
like S3 Trio.