Please read all of this for a more complete X information ;-)
From Uwe Bonnes <firstname.lastname@example.org>:
xdos from dosemu version pre-0.60.4.2 with the patch from my last messages should now be more capable. In particular it should now understand the keys from the keypad-area (the keys the most right on a MF-Keyboard) and numlock and keyevents in the range of the latin characters, even when you run xdos from a remote X-terminal.
If it dosen't work for you as expected, please check out the following:
From Rainer Zimmermann <email@example.com>
Some basic information about dosemu's X support. Sometimes it's even sort of useable now.
What you should take care of:
important changes to previous version (pre53_17):
ToDo (in no special order)
We've made some major changes in X.c that enables X to run graphics modes. Unfortunately, this disables the cut-and-paste support, but we think the graphics stuff is much more fun (after things have established, we'll put the cut-and-paste stuff back). The graphics is done through vgaemu, the VGA emulator. Status of the work:
As stated before, this code was written for Linux (tested with 1.2.13 and 1.3.39) and we don't know if it works under NetBSD. The mmap() of /proc/self/mem and mprotect() magic in vgaemu are very (i386) Linux specific.
Steffen Winterfeldt Steffen Winterfeldt <firstname.lastname@example.org>
I've been working on the X code and the VGA emulation over the last few months. This is the outcome so far:
The current implementation supports 4 and 8 bit SVGA modes on all types of X display. Hi-color modes are supported only on displays matching the exact color depth (15 or 16); true color modes are supported only on true color X displays, but always both 24 bit and 32 bit SVGA modes.
In addition, the current hi- and true color support does not allow resizing of the graphics window and gamma correction is ignored.
As the typical graphics mode with 320x200x8 will be used often with large scalings and modern graphics boards are pretty fast, I added something to eat up your CPU time: you can turn on the bilinear interpolation. It greatly improves the display quality (but is rather slow as I haven't had time yet to implement an optimized version - it's plain C for now). If the bilinear filter is too slow, you might instead try the linear filter which interpolates only horizontally.
Note that (bi)linear filtering is not available on all VGA/X display combinations. The standard drawing routines are used instead in such cases.
If a VGA mode is not supported on your current X display, the graphics screen will just remain black. Note that this does not mean that xdos has crashed.
The VESA support is (or should be) nearly VBE 2.0 compatible. As a reference I used several documents including the unofficial VBE 2.0 specs made available by SciTech Software. I checked this against some actual implementations of the VBE 2.0 standard, including SciTech's Display Doctor (formerly known as UniVBE). Unfortunately implementations and specs disagree at some points. In such cases I assumed the actual implementation to be correct.
The only unsupported VBE function is VGA state save/restore. But this functionality is rarely used and its lack should not cause too much problems.
VBE allows you to use the horizontal and vertical scrolling function even in text modes. This feature is not implemented.
If you think it causes problems, the linear frame buffer (LFB) can be turned of via dosemu.conf as well as the protected mode interface. Note, however, that LFB modes are faster than banked modes, even in DOSEmu.
The default VBE mode list defines a lot of medium resolution modes suitable for games (like Duke3D). You can still create your own modes via dosemu.conf. Note that you cannot define the same mode twice; the second (and all subsequent) definitions will be ignored.
Modes that are defined but cannot be supported due to lack of video memory or because they cannot be displayed on your X display, are marked as unsupported in the VBE mode list (but are still in it). Note that there is currently no support of 4 bit VESA modes.
The current interface between VGAEmu and X will try to update all invalid video pages at a time. This may, particularly in hi-res VBE/SVGA modes, considerably disturb DOSEmu's signal handling. That cannot be helped for the moment, but will be addressed soon (by running an extra update thread).
If you really think that this is the cause of your problem, you might try to play with veut.max_max_len in env/video/n_X.c, near line 2005. This variable limits the amount of video memory that is updated during one timer interrupt. This way you can dramatically reduce the load of screen updates, but at the same rate reduce your display quality.
Gamma correction works in both 4 and 8 bit modes. As the dosemu.conf parser doesn't support float values, it must be specified as a percentage value: gamma 100 = gamma 1.0. Higher values give brighter graphics, lower make them darker. Reasonable values are within a range of 50 ... 200.
You can specify the video memory size that the VGA emulator should use in dosemu.conf. The value will be rounded up to the nearest 256 kbyte boundary. You should stick to typical values like 1024, 2048 or 4096 as not to confuse DOS applications. Note that whatever value you give, 4 bit modes are only supported up to a size of 800x600.
You can influence the initial size of the graphics window in various ways. Normally it will have the same size (in pixel) as the VGA graphics mode, except for mode 0x13 (320x200, 256 colors), which will be scaled by the value of mode13fact (defaults to 2). Alternatively, you can directly specify a window size in dosemu.conf via winsize. You can still resize the window later.
The config option fixed_aspect allows you to fix the aspect ratio of the graphics window while resizing it. Alternatively, aspect_43 ties the aspect ratio to a value of 4:3. The idea behind this is that, whatever the actual resolution of a graphics mode is in DOS, it is displayed on a 4:3 monitor. This way you won't run into problems with modes such as 640x200 (or even 320x200) which would look somewhat distorted otherwise.
Next Previous Contents
|The DOSEMU team|