Hi Bonnie :-)
> I run the dosemu/freedos package in a window on ubuntu
> linux (8.10 Intrepid). I use Gnome desktop.
>
> Basically it does what I need it to do except for one thing.
>
> When ever I type in the dosemu window the window darkens for a
> moment. This does not keep the window from accepting the keyboard entry
> however.
>
> This happens wether the terminal launching dosemu/Freedos is gnome
> terminal or terminator.
I experience the same, but am not sure what causes it.
Seems to be related to the "visual bell" and the fact
that dosemu can use terminal ESC sequences for sound
output whenever the emulated "internal PC speaker" is
touched. If you do xdosemu -C -D+i and look at your
log in .dosemu/boot.log you will see that for each
key you type, the log will show FOUR "SPEAKER: sound OFF"
log lines. You also get TWO such lines each time when
dosemu loses focus - in my case: when I move the mouse
pointer from inside the dosemu window to another window.
This made me try other logging options in Dosemu. Now
the "leave window" thing can give me for example, with
xdosemu -C -D+Qkrhuwi this while I am in DEBUG:
8042: scheduling IRQ1
8042: read port 0x60 = 0x9c
8042: read port 0x60 read=0x9c
INT15 0x4f CARRY=1 AX=869c
What does the AH=86 mean in this context? And why does
Linux send dosemu the event "somebody STOPPED pressing
ENTER" whenever my mouse leaves the dosemu window...?
KBD: compute_keynum(9c, 0, dos) called
HELPER: get_bios_key() returned 0000
8042: IRQ ACK, 0
SPEAKER: sound OFF!
SPEAKER: sound OFF!
At the command prompt I get the same as in DEBUG, so
FreeCOM does not seem to have an effect on this problem.
Probably any DOS/app running in Dosemu has this problem.
Interestingly, while it does NOT give flickering, I do
get an effect when the mouse ENTERS a dosemu window, too:
move_key: keynum=0001
put_keynum_r(break) called with invalid keynum 01:00
move_key: keynum=0002
put_keynum_r(break) called with invalid keynum 02:00
...
this goes on for ALL keynums up to 58 and then also
for c7, c8, c9, cb, cd, cf to d3, 9c 9d, c6, 54, b5,
b8, c6, db, dc, dd and then the whole story again!
I have no idea what causes this big number of bad
put_keynum_r(break) calls, maybe Gnome / Compiz is
telling dosemu that ALL keys are NOT pressed here?
When I simply type the "a" inside dosemu, the log is:
KBD:Xev: keycode = 38 type = 2
move_key: keynum=001e
put_keynum_r: old_make:0 make:1 key:1e
translate_key: make=1, key=001e, input
KBD: translate(old_shiftstate=0002, shiftstate=0002, key=001e)
KBD: translated key = 0061
KBD: writing to queue: scan=0000001e
KBD: queuelevel=1
KBD: read queue: raw=1e, queuelevel=0
8042: scheduling IRQ1
8042: read port 0x60 = 0x1e
8042: read port 0x60 read=0x1e
INT15 0x4f CARRY=1 AX=861e
KBD: compute_keynum(1e, 0, dos) called
translate_key: make=1, key=001e, dos
KBD: translate(old_shiftstate=0002, shiftstate=0002, key=001e)
KBD: translated key = 0061
HELPER: get_bios_key() returned 1e61
8042: IRQ ACK, 0
SPEAKER: sound OFF!
SPEAKER: sound OFF!
KBD:Xev: keycode = 38 type = 3
move_key: keynum=001e
put_keynum_r: old_make:1 make:0 key:1e
translate_key: make=0, key=001e, input
KBD: translate(old_shiftstate=0002, shiftstate=0002, key=001e)
KBD: translated key = 0061
KBD: writing to queue: scan=0000009e
KBD: queuelevel=1
KBD: read queue: raw=9e, queuelevel=0
8042: scheduling IRQ1
8042: read port 0x60 = 0x9e
8042: read port 0x60 read=0x9e
INT15 0x4f CARRY=1 AX=869e
KBD: compute_keynum(9e, 0, dos) called
translate_key: make=0, key=001e, dos
KBD: translate(old_shiftstate=0002, shiftstate=0002, key=001e)
KBD: translated key = 0061
HELPER: get_bios_key() returned 0000
8042: IRQ ACK, 0
SPEAKER: sound OFF!
SPEAKER: sound OFF!
This looks as if get_bios_key returns 1e/a for pressing
and 00/00 for releasing the key. Probably okay so far.
The other stuff looks okay, too. What is not okay is the
fact that both pressing and releasing a key each give TWO
"SPEAKER: sound OFF!" messages and every "sound off" seems
to make Compiz "ring the visual black flicker bell" :-p.
Maybe there is something wrong in how DOSEMU handles the
keyboard controller I/O, as ports 0x60 and 0x64 are for
the 8042 keyboard controller while port 0x61 controls,
among other things, the speaker gate? Ports 0x62 and 0x63
only existed on PC-XT, in case you were wondering :-).
Looking at dosemu source code, speaker_off() of speaker.c
is called... Places which call this are:
timers.c do_sound - this can switch off sound even if
it already was off, but I think IF you want to avoid
this THEN you would put extra checks in speaker.c and
NOT in timers.c ...
I assume 2 more speaker_off calls in emu.c / X.c are only
used when you close dosemu, so they should be no problem?
So what calls do_sound? Two places: spkr_io_write and
speaker_resume. The latter is in unfreeze_dosemu and
the former is in keyb_io_write... The unfortunate part
here is that the high bit of port 0x61 is used to tell
the keyboard controller that you ack a keyboard IRQ.
Suggested one line PATCH for plugin kbd_unicode serv_8042.c:
case 0x61:
if (value & 0x80) {
k_printf("8042: IRQ ACK, %i\n", port60_ready);
port60_ready = 0;
int_check_queue(); /* reschedule irq1 if appropriate */
}
+ else
spkr_io_write(port, value);
break;
Of course this will break cases where IRQ ACK and speaker
gate manipulations are done in the same port access, so a
more elegant patch would modify do_sound to make operation
of the speaker gate "lazy". In other words, to make it only
switch the speaker on / off if the speaker was not already
in the same state at that moment :-).
Eric
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
