Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

Hello.

Set $_hogthreshold=(0) in your dosemu.conf.

I suggest you to open the bugreport for
that problem and attach the -D9+v log to
it.

Thanks. I tried this a little while before I got your reply; the performance is *very* sensitive to the setting; 3 is more-or-less OK, but better with zero. I was using 1 before with 1.0.2.1. Did the priority code change between these versions?

I will do that.

yes, certainly. You may even want to try 1.2.1 and see how that behaves, since there were a few changes between 1.2.1 and 1.2.2 that can be regressions in certain cases (we'll have to look at this more closely).

There's a big difference between hogthreshold 1 and 2, then to 3 4 5 etc it goes more gradually.

With "0" you pretty much have dosemu using 100% CPU all the time; with say "10" it will still sleep most of the time at the DOS prompt for instance.

Bart

On Wed, 17 Nov 2004, Bart Oldeman wrote:

Thanks, Bart.

The other problem I alluded to still remains. The following line in .dosemurc

$_X_vesamode = "1024,740"

elicits no response to a query which lists the available VESA modes. Changing the $_X_vgaemu_memsize has the expected result; going from one megabyte to 2 brings the 1280x1024 and 1600x1280 modes into existence, but the custom modes do not show up. This worked fine in 1.0.2.1. Stas suggested that I do some debugging and file a bug report, which I have not done yet, but there is no debugging output from either -D9+v or -D9+X.

thanks

--jim

Many apologies--I thought the debugging output came on stdout/stderr, but it is clearly put into boot.log. Running with -D9+c elicits the output

X_fullscreen 0
vgaemu_memsize 0x600
vesamode_list (nil)
X_lfb 1
X_pm_interface 1

when parsing the .dosemurc lines in the vicinity of

# size (in Kbytes) of the frame buffer for emulated vga. Default: 1024K

$_X_vgaemu_memsize = (1536)

# use linear frame buffer in VESA modes. Default: on

# $_X_lfb = (on)

# use protected mode interface for VESA modes. Default: on

# $_X_pm_interface = (on)

# KeySym name to activate mouse grab, ""=off. Default: "Home" (ctrl+alt+home)

# $_X_mgrab_key = "Home"

# List of vesamodes to add. The list has to contain SPACE separated # "xres,yres" pairs, as follows: "xres,yres ... xres,yres". Default: ""

# for 1024x768 screen use 1024,740 or thereabouts

$_X_vesamode = "1280,960"
# 1280,1024"

# pause xdosemu if it loses focus

# $_X_background_pause = (off)

in .dosemurc. So the memory size is recognized, but the vesamode line is not. Has the syntax changed? The documentation has not.

thanks

--jim

No, it's a typo.

in dosemu's etc/global.conf replace
foreach $yyy (" ", $X_vesamode)
by
foreach $yyy (" ", $_X_vesamode)
recompile and I hope you are all set then.

Bart

Thanks much, Bart. I am running from the binary distribution, so I took the chicken's way out and changed dosemu.users to read the fixed global.conf file. I will recompile sometime when I have my ducks in a little better order. Fixed the problem, but made a new one, or at least a new error message:

quilla:SDSSPrettypics>xdosemu &
[1] 3541
quilla:SDSSPrettypics>ERROR: Unable to open console to evaluate the keyboard map.
Please specify your keyboard map explicitly via the $_layout option
ERROR: Unable to open console to evaluate the keyboard map. Please specify your keyboard map explicitly via the $_layout option

I uncommented the $_layout = "auto"

in .dosemurc to no avail, but $_layout = "us" fixed it. Another error or version difference between the distributed global.conf and the compiled in version? There was no obvious problem with xdosemu (which started fine), but I thought I should bring it to you attention.

thanks again. This is a *wonderful* piece of code; the old dos cadd program is the one thing from my Windows/DOS past I simply cannot live without, and being able to run it under Linux has been a godsend.

--jim