On Wed, Jun 28, 2006 at 02:16:56PM +0200, Rafa?? Cygnarowski wrote:
> So now I have to find out:
> - where those fake keycodes were dropped,

I'm not sure.

> - why after loading my test program those two 8s are displayed 
>   (there is some unneeded interrupt generated - am I right?).

8 is on the same key as "up" on the numeric keypad.

> Honestly, I don't know where I should start looking...

Have you tried toggling numlock?

The URL I posted might help -- especially the bit about fake shifts.

The output you're getting is:

    e0 e0 48 e0 e0 aa

but you should get:

    e0 2a e0 48 e0 c8 e0 aa

So you're losing 2a (which after e0 would fakes pressing shift) and then
c8 (which would release the up key itself).

(BTW, it'd be easier if you used hexadecimal in your output.)

It seems that having the MSB bit set in the output of
sdl_keyevent_to_keycode() means that it's one of the 'e0'-escaped keys
(mostly the 'grey' versions of the numeric keypad keys)... and the MSB
in the final keycode is set if the key is being released, otherwise
it's cleared.

I can't see anything wrong... but I'm not sure if you're adding code in
the wrong place.  QEMU uses PC keycodes internally but I'm not sure this
should go as far as including fake shifts -- either way, you'll probably
need to look at hw/ps2.c.

I don't know much about PS/2, unfortunately, but hw/ps2.c seems to
translate keycodes from set 1 to set 2, and they get converted back to
set 1 elsewhere.  Maybe that's where the bug is?
-- 
Stuart Brady


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Reply via email to