Changing an app to use linux framebuffer

Changing an app to use linux framebuffer

[Simon Bridger]

Hi,

I am trying to get Autotrax working. It is an excellent, now free, PCB design 
package. (also a schematic package)
It uses VESA drivers. It works fine using DOSEMU under Xwindows. Unfortunately 
it is 
1) too slow being a cad app
2) autotrax pans when the mouse hits the edge of the screen. This totally 
conflicts with the whole gui thing where the mouse can move anywhere off 
screen.

I want to use it in a console window. Unfortunately I get a message telling me 
there is no vesa driver.

Autotrax uses plug-in graphic drivers, and we have the source for these, and 
can easily change them.

Is there any way of  changing them to write directly into the linux kernel 
frame buffer? 
Or indirectly through some calls in the  DOSEMU system?
Or to get the VESA drivers working?

Thanks for your attention

Simon Bridger

Re: Changing an app to use linux framebuffer

[Stas Sergeev]

Hello.

Simon Bridger wrote:
> I want to use it in a console window. Unfortunately I get a message 
> telling me there is no vesa driver.
Known problem:(
This largely depends on your video
card however.
Get a card where the extended registers
are accessable via the VGA registers -
and you have VESA. Old S3 and SiS cards
will do.
With a modern cards you are in troubles.

> Autotrax uses plug-in graphic drivers, and we have the source for 
> these, and can easily change them.
Will not help.

> Is there any way of  changing them to write directly into the linux 
> kernel frame buffer?
There was a patch somewhere in the net
which does this using SDL, but this patch
seems to be dropped by its author:(
This was also an emulation however, so,
while being full-screen, it is still slow.

> Or indirectly through some calls in the  DOSEMU system?
None currently available to deal with
a frame buffer AFAIK.

> Or to get the VESA drivers working?
That was my goal during the 4 month
recently. I've got VESA working, but,
as the kernel have only 128 bit for
the IO bitmap, you can't use an ioperm()
syscall to open all the necessary extended
registers of the card. So the
trap/iopl()/decode_instr technique was
used. This turned out to be even *much*
slower than an xdos:(
Fortunately the 2.5 kernels have a lazy
IO bitmap allocation scheme, so that the
size can be increased without any overhead.
I haven't played with 2.5 kernels yet.
If you really need to get VESA a go, you
have to enlarge an IO bitmap to 8K there
and I'll give you a code that enables
VESA under dosemu.
This work must be done sooner or later
by someone anyway. I don't have time to
play with a 2.5 kernel currently.

Re: Changing an app to use linux framebuffer

[Simon Bridger]

Hi Stas, thanks for the reply.

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.
Meanwhile the Xmouse is still at, or off, the edge of the Xwindow containing 
xdos

Would it be possible to make an xdos session run fullscreen?
- on a specific desktop (which we aren't using for anything else)
- without borders, widgets etc. (since we are full screen we don't need any of 
that)
- with the xwindows mouse disabled/hidden (since autotrax is doing all its own 
mouse display)

Assuming the mouse problem is solvable, is there a way to rewrite the autotrax 
driver to make it faster when using the xdos screen?

As I had another look at it I also notice that the vesa drivers for 1024x768 
and smaller work properly.
The 1280x? driver appears to have an address wrap around on screen, and the 
1400x1050 driver crashes

regards
Simon

Re: Changing an app to use linux framebuffer

[Stas Sergeev]

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.

Re: Changing an app to use linux framebuffer

[Bart Oldeman]

On Mon, 2 Dec 2002, Simon Bridger wrote:

> Would it be possible to make an xdos session run fullscreen?
> - on a specific desktop (which we aren't using for anything else)
> - without borders, widgets etc. (since we are full screen we don't need any of
> that)

ctrl-alt-f1 to switch to a console, login, type
xinit /path/to/xdosemu -- :1
replace /path/to with where xdosemu (or xdos) really is.

Match the resolution of the X server with the xdosemu box (use ctrl-alt-+
and ctrl-alt--, edit XF86Config, whatever).

Now dosemu is running in X session :1 which is normally reached by
Ctrl+Alt+F8.

> - with the xwindows mouse disabled/hidden (since autotrax is doing all its own
> mouse display)

Use Ctrl-Alt-Home to have the mouse trapped (and again to de-trap it).
Set
$_X_mgrab_key = "Home"
in dosemu.conf if ctrl-alt-home didn't work.


> Assuming the mouse problem is solvable, is there a way to rewrite the autotrax
> driver to make it faster when using the xdos screen?

The way xdos works is to update the contents of the video buffer (dirty
pages) periodically. So a video driver would play nice with DOSEMU if
it updates the video buffer in chunks localized in pages (4k in size),
rather than scatter stuff around more or less randomly. It will also help
to have the X server running at the same bpp as autotrax expects.
8bpp would be quickest.
xinit /path/to/xdosemu -- :1 -depth 8
There are various options in dosemu.conf you can play with, too.

Bart

Re: Changing an app to use linux framebuffer

[Simon Bridger]

Thanks Bart, 
the xinit .... gets it up on its own terminal nicely.

Does xdos accept vesa mode 0x140 (1400x1050)?
I can't get seem to get this mode going. (or any mode greater than 1024x768)
I tried increasing the xframebuffer size from 2048K, but that had no effect. 
Does the x_framebuffer size affect speed at all? (ie having it unnecesarily 
big)

> Use Ctrl-Alt-Home to have the mouse trapped (and again to de-trap it).
> Set
> $_X_mgrab_key = "Home"
> in dosemu.conf if ctrl-alt-home didn't work.
>
I haven't been able to get it to trap the mouse at all.
dosemu.conf does contain the line  $_X_mgrab_key = "Home"
I am using a laptop, does this affect the key mapping?
Can I just force mouse trapping when I start, rather than by using the 
keyboard? 

> The way xdos works is to update the contents of the video buffer (dirty
> pages) periodically. So a video driver would play nice with DOSEMU if
> it updates the video buffer in chunks localized in pages (4k in size),

It currently writes in 32k windows of course, and the drivers try to minimise 
page changes. This could be changed to 32 blocks perhaps.
Perhaps the autotrax driver should be changed to explicitly tell dosemu when a 
page should be updated?

> There are various options in dosemu.conf you can play with, too.
I'm game


Simon

Re: Changing an app to use linux framebuffer

[Bart Oldeman]

On Tue, 3 Dec 2002, Simon Bridger wrote:

> Does xdos accept vesa mode 0x140 (1400x1050)?

try
$_X_vesamode = "1400,1050"
not sure which mode number it will be but that can be figured out.

> I can't get seem to get this mode going. (or any mode greater than 1024x768)
> I tried increasing the xframebuffer size from 2048K, but that had no effect.
> Does the x_framebuffer size affect speed at all? (ie having it unnecesarily
> big)

maybe. I'm not sure.

> I haven't been able to get it to trap the mouse at all.
> dosemu.conf does contain the line  $_X_mgrab_key = "Home"
> I am using a laptop, does this affect the key mapping?
> Can I just force mouse trapping when I start, rather than by using the
> keyboard?

try to run xdos -D+X -O and see what it says about mouse grabbing.

> It currently writes in 32k windows of course, and the drivers try to minimise
> page changes. This could be changed to 32 blocks perhaps.
> Perhaps the autotrax driver should be changed to explicitly tell dosemu when a
> page should be updated?

It cannot. A page is dirty or not, 386+ hardware can take care of that. It
is just that the update function updates the xdos window n times per
second and takes only dirty pages into account.

Bart