[Qemu-devel] QEMU keyboard issue with Gujin-2.2

[Qemu-devel] QEMU keyboard issue with Gujin-2.2

[Etienne Lorrain]

 Hello,

 I did more search on the keyboard problem, just posted on the forum
but here seems to be a better place:

 The GPL Gujin bootloader (http://gujin.org) is using the BIOS mouse
interface (INT 0x15/0xC2 interface) and as soon as the "set handler" service
is initialised (INT 0x15/0xC207) there is a problem with the keyboard:
uninterrupted "key present" (INT 0x16/0x01) with dummy keys are reported
to be pressed.
 This never happens with a real PC, and this even happens when the
"mouse handler" is only pointing to a "ret far", but does not happens
when this assembly service (to set the handler) is patched out of Gujin code.
 It seems that there is a problem in which handler (IRQ1/IRQ12 i.e. INT 0x9/INT 0x74)
is called out of the PS2 controller, when mouse bytes are present. 
I am using the qemu part of Fedora 7. 

Someone has an idea of what may happens? 

I tried to patch/regenerate bochs-2.3/bios/rombios.c because I noted 
that comment: 
// TODO : 
// 
// int74 
// - needs to be reworked. Uses direct [bp] offsets. (?) 
but I am really unfamiliar with this codebase, and my patch (to read all
the mouse data at once on the first call) did not fix the problem. 

Thanks for any information, 
Etienne.


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2

[WaxDragon]

On 10/11/07, Etienne Lorrain <etienne_lorrain@yahoo.fr> wrote:
>  Hello,
>
>  I did more search on the keyboard problem, just posted on the forum
> but here seems to be a better place:
>

  This may not be the same issue, but I've seen strange behaviour
also.  ReactOS has a built in kernel debugger that seems to have a
problem with the mouse input.  If the mouse is "grabbed" by the QEMU
SDL window, and you are in the kernel debugger, moving the mouse will
generate "garbage" charaters, usually rendering the debugger useless.
Real hardware, VMWare, and QEMU *without* the mouse grabbed do not
exhibit this behaviour.
  QEMU has acted this way for quite some time, seems forever.  I've
mentioned it on #qemu to little interest, but since it's not a huge
issue for me, I've not looked into a great deal. Thought I would
mention it.

WaxDragon

-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

[Qemu-devel] QEMU keyboard issue with Gujin-2.2

[Alexander E. Patrakov]

Hello,

if one attempts to use the Gujin bootloader inside qemu (even today's 
snapshot), one gets a message about unknown key being pressed.

The easiest way to reproduce the issue is to download install-2.2.tar.gz 
from http://sourceforge.net/project/showfiles.php?group_id=15465, unpack 
the tarball, and run "qemu -fda boot.144". The bottom of the screen will 
flash with the message about unknown command. This message does not show 
up in Bochs and on real hardware.

I also recompiled Gujin from source (gujin-2.2.tar.gz) and added code to 
print information about each call to the 0x16 BIOS interrupt to the 
parallel port. According to this log, Gujin does the following:

# prints:
Debug active!
sizeof MOUSE: 512, sizeof UI: 384, Initial VESA name check: Video card 
changed, reset VGA parameter.

# Get shift flags
AH=0x02 => result: AL=0x00 (i.e., no shift flags)

# keyb.com keyboard capabilities check
AH=0x92 => AH=0x80 (i.e., enhanced keyboard functions are supported)

# keyb.com keyboard capabilities check
AH=0xa2 => AH=0xa2 (i.e., 122-key keyboard functions are not supported)

# prints:
sizeof struct UTIL_str 640, sizeof struct memalloc_str 408.
max_IDE_found 10, max_freelist 64, max_disk 15, max_partition 64
sizeof struct diskparam_str 256, sizeof struct partition_str 64, sizeof 
struct freelist_str 16, sizeof struct IDE_found_str 8.

Reset all BIOS disks for BIOS to acknowledge changes:returns 0x0, status 
0x0
sizeof struct desc_str: 64, sizeof struct BOOTWAY_str: 16
{FAT12 on disk 0 part 5 with type 0x4!} {strange: PhysicaldriveNb = 0x0 
instead of 0x80}  {FAT12 on disk 2 part 5 with type 0x4!}

# check for enhanced keystroke
AH=0x11 => AH=0x11, AL set to 0 by the setnz instruction (i.e., no key)

# Then the check is repeated many times with the same "no key" result 
(because I press no keys). So far so good.
# .....

# Then, for some strange reason, the same call returns that a key is 
pressed:

# check for enhanced keystroke
AH=0x11 => AH=0x43, AL set to 1 by the setnz instruction that 
immediately follows int 0x16 in the Gujin source

# get enhanced keycode
AH=0x10 => AH=0x43, AL=0x00 (here is a problem - I pressed nothing!)

# goes to graphical mode
# prints:
best_max_width: found mode index 3 (maxwidth 640) out of UI.nbmode = 16
[get_refresh_freq: timeout after 49999]

# Then it begins to loop the following two calls:

# check for enhanced keystroke
AH=0x11 => AH=0x43, AL set to 1 by the setnz instruction that 
immediately follows int 0x16 in the Gujin source

# get enhanced keycode
AH=0x10 => AH=0x43, AL=0x00 (here is a problem - I pressed nothing!)

I.e., this looks like a "garbage in, garbage out" problem, not a Gujin 
bug - BIOS reports non-existing keypress to Gujin in qemu. Could you 
please fix qemu, or at least tell me how to debug further?

-- 
Alexander E. Patrakov

Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2

[Stefan Weil]

Hello,

could you try this file (when Berlios servers are online again):
http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/ps2.c?op=file

I had a similar problem, and the patched version of ps2.c helped...

Stefan

Alexander E. Patrakov schrieb:
> Hello,
>
> if one attempts to use the Gujin bootloader inside qemu (even today's
> snapshot), one gets a message about unknown key being pressed.
>