Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-17 Thread Bart Oldeman
On Tue, 16 Nov 2004, jegunn wrote:

 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?

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
-
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


Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-17 Thread jegunn
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

 On Tue, 16 Nov 2004, jegunn wrote:
 
  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?
 
 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
 
-
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


Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-17 Thread jegunn
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



On Wed, 17 Nov 2004, jegunn wrote:

 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
-
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


Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-17 Thread Bart Oldeman
On Wed, 17 Nov 2004, jegunn wrote:

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

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
-
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


Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-17 Thread Bart Oldeman
 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.

Ok, that's fine, it just overrides the builtin one then.

 quilla:SDSSPrettypicsxdosemu 
 [1] 3541
 quilla:SDSSPrettypicsERROR: 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.

$_layout=auto does not work if you don't have any read
permissions
to the Linux console. Nothing to do with global.conf I see.

This is a known problem (apart from the fact that for remote
X sessions it is wrong to query the console on the remote
machine): in the next version (it's in CVS now)
$_layout=auto will query the X server about the keyboard
layout so in many cases it will no longer be necessary to
explicitly specify $_layout=us etc.

Bart
-
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


Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-16 Thread jegunn

I may have missed messages on this issue on the mailing list, and if so
apologies. I have used dosemu 1.0.2.1 for a couple of years under RH7.3 on
a dual 1.6GHz Athlon machine, running Generic CADD 6.0 under xdosemu with
wonderful results. I recently upgraded to FC2, (2.6.8) and discovered that
1.0.2.1 would no longer run, so I upgraded dosemu to 1.2.2.0.  This works
fine, but the cadd program now generates its screen a full factor of 50
more slowly than it did before. All of the X and memory settings are
unchanged as far as I can see. The speed change is reminiscent of 
the difference between BIOS graphics and writing directly to screen memory
in the bad old days. Am I likely missing something, or has something 
really changed in the code? The performance is, as I vaguely remember,
more-or-less like it was on an 8 MHz 80286.

Another smaller problem is that setting special VESA modes under X
no longer seems to work--I have used a 1024x740 mode to allow both the 
CADD menubar at the bottom and the window titlebar to exist on a 1024x768
screen, and would like very much now to use a 1280x1024 window on a new
larger display. Neither seems to be recognized by the same vesa listing
code which worked before, at least with the 1024x740 setting. I
upped the vga memory to 2048kB to accomodate the larger setting, but
still with no results.

Thanks in advance for any advice; I would be happy to attach all of
or clippings from my .dosemurc if that would help.

--jim gunn


-
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


Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

2004-11-16 Thread jegunn

On Tue, 16 Nov 2004, Stas Sergeev wrote:

 Hello.
 
 jegunn wrote:
  fine, but the cadd program now generates its screen a full factor of 50
  more slowly than it did before.
 Set $_hogthreshold=(0) in your dosemu.conf.

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?
 
  Another smaller problem is that setting special VESA modes under X
  no longer seems to work
 I suggest you to open the bugreport for
 that problem and attach the -D9+v log to
 it.

I will do that.

 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
 
-
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