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. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
