[Qemu-devel] Keyboard patch for windows

[Qemu-devel] Keyboard patch for windows

[Erik Karlsson]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Keyboard input via SDL on windows it not working well. It is for example
impossible to distinguish between left and rihgt alt and control and
between the arrow keys and the numpad arrow keys.

I have fixed this problem by using windows low level keyboadrd hooks
 (SetWindowsHookEx, WH_KEYBOARD_LL) instead of SDL for keyboard input.

Low level keybord hooks should work on windows NT 4.0 SP3 or later, eg.
windows 2000 and windows XP but not on windows 9x. For this reason I use
another method if low level keyboard hooks are unsupported. Tihis method
involves hooking up the winidow procedure and using some ugly fixes and
there is still problems when you press the two shift keys simultaneously.
I have however not tested this method on win9x because i have no win9x
machine to test it on.

Erik

[-- Attachment #2: qemu-0.6.0-kbdfix.patch.gz --]
[-- Type: application/octet-stream, Size: 2799 bytes --]

Re: [Qemu-devel] Keyboard patch for windows

[Fabrice Bellard]

Strange since Windows should send the raw keycodes directly to SDL. I 
think your patch is too complicated to be integrated in an SDL target. 
Can you find a simpler solution ?

Fabrice.

Erik Karlsson wrote:
> Keyboard input via SDL on windows it not working well. It is for example
> impossible to distinguish between left and rihgt alt and control and
> between the arrow keys and the numpad arrow keys.
> 
> I have fixed this problem by using windows low level keyboadrd hooks
>  (SetWindowsHookEx, WH_KEYBOARD_LL) instead of SDL for keyboard input.
> 
> Low level keybord hooks should work on windows NT 4.0 SP3 or later, eg.
> windows 2000 and windows XP but not on windows 9x. For this reason I use
> another method if low level keyboard hooks are unsupported. Tihis method
> involves hooking up the winidow procedure and using some ugly fixes and
> there is still problems when you press the two shift keys simultaneously.
> I have however not tested this method on win9x because i have no win9x
> machine to test it on.
> 
> Erik
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Keyboard patch for windows

[Erik Karlsson]

The problem is that some of the keycodes are prefixed with an e0 prefix.

Examples:
Numpad right arrow/6: 4d	Right arrow:   e0,4d
Numpad left arrow/4:  4b	Left arrow:    e0,4b
Left alt:	      38	Right alt:     e0,38
Left control:	      1d	Right control: e0,1d

The problem withs SDL is that SDL strips off the e0 prefix. The result
is that it is impossible to distinguish between e.g. the arrow keys and
the arrow on the numeric keypad and between left and right alt and
contol keys.

Another advantage with low level keyboard hooks is that you can capture
system key combinations such as Alt-Tab and Ctrl-Esc. sdl_grab_start()
does not do that on windows.

I agree that it is unclean to have native windows code in an SDL driver.
It would of course be better to have a separate keyboard driver for
windows. The problem is that the qemu architecture does not allow
separate drivers for keyboard, mouse and display. This makes a windows
driver just for the keybord impossible. A windows driver would then need
to implement keyboard, mouse and display natively on windows.

Erik

> Strange since Windows should send the raw keycodes directly to SDL. I 
> think your patch is too complicated to be integrated in an SDL target. 
> Can you find a simpler solution ?
> 
> Fabrice.
> 
> Erik Karlsson wrote:
> > Keyboard input via SDL on windows it not working well. It is for example
> > impossible to distinguish between left and rihgt alt and control and
> > between the arrow keys and the numpad arrow keys.
> > 
> > I have fixed this problem by using windows low level keyboadrd hooks
> >  (SetWindowsHookEx, WH_KEYBOARD_LL) instead of SDL for keyboard input.
> > 
> > Low level keybord hooks should work on windows NT 4.0 SP3 or later, eg.
> > windows 2000 and windows XP but not on windows 9x. For this reason I use
> > another method if low level keyboard hooks are unsupported. Tihis method
> > involves hooking up the winidow procedure and using some ugly fixes and
> > there is still problems when you press the two shift keys simultaneously.
> > I have however not tested this method on win9x because i have no win9x
> > machine to test it on.
> > 
> > Erik

Re: [Qemu-devel] Keyboard patch for windows

[Laurent Amon]

Selon Erik Karlsson <erik.karlsson@bonetmail.com>:

> I agree that it is unclean to have native windows code in an SDL driver.
> It would of course be better to have a separate keyboard driver for
> windows. The problem is that the qemu architecture does not allow
> separate drivers for keyboard, mouse and display. This makes a windows
> driver just for the keybord impossible. A windows driver would then need
> to implement keyboard, mouse and display natively on windows.

There are a few things I'm not happy with with the SDL keyboard implementation
(as well as video, when it comes to Quartz). The mac keyboard is quite fubarred
(only letters and keypad numbers are correct). I posted on the list a patch (or
rather, a modified version of one somebody else posted), but I am still not
happy with it :
- I can't seem to map to a 104 keys windows keyboard (having Command as Windows
key, and I am missing the key next to the left shift (<> on my french keyboard)
but that seems rather a Windows problem as I am using a Win98 first edition.
- I cannot differentiate between left/right modifier keys, but to do so, one
would need to go through low level Carbon interfaces, if I understand
correctly).

On the video side, SDL plays rather liberally with fade-in fade-out when
switching video modes, and since it always goes back to native mode in-between,
and seems to double the changes when using 2 screens, I can just type
Ctrl-Shift-f and go get a coffee. Add to that host 16-bit mode gives wrong
colors (SDL 1.2.7, macos X.3.4) and that it is very easy to crash in windowed
mode, I'd say getting off the SDL code might be considered at some point unless
we want to patch it (there is a Carbon interface for Bochs we might try to
reuse, for instance).

Anyway, one can live with it for now.

Lga.

Re: [Qemu-devel] Keyboard patch for windows

[Pierre d'Herbemont]

On 4 août 04, at 12:05, Laurent Amon wrote:

> On the video side, SDL plays rather liberally with fade-in fade-out 
> when
> switching video modes

That is why I think we should develop our own interface, using directly 
carbon or cocoa, unless someone wants to debug SDL. SDL/Mac OS X is 
very buggy, and I don't see much activity on it.

Pierre

Re: [Qemu-devel] Keyboard patch for windows

[Laurent Amon]

Selon Pierre d'Herbemont <stegefin@free.fr>:

>
> On 4 août 04, at 12:05, Laurent Amon wrote:
>
> > On the video side, SDL plays rather liberally with fade-in fade-out
> > when
> > switching video modes
>
> That is why I think we should develop our own interface, using directly
> carbon or cocoa, unless someone wants to debug SDL. SDL/Mac OS X is
> very buggy, and I don't see much activity on it.

Well, the patch for the fades looks like 2 lines to comment out in SDL. Maybe we
should send a patch to them for a dependance on an environment variable or some
such. Or directly lift the SDL Quartz driver (and debug). Or use/port
gui/carbon.cc from bochs, but then, I don't know if the performances won't take
a hit.

Re: [Qemu-devel] Keyboard patch for windows

[Pierre d'Herbemont]

On 4 août 04, at 13:55, Laurent Amon wrote:

> Selon Pierre d'Herbemont <stegefin@free.fr>:
>> That is why I think we should develop our own interface, using 
>> directly
>> carbon or cocoa, unless someone wants to debug SDL. SDL/Mac OS X is
>> very buggy, and I don't see much activity on it.
>
> Well, the patch for the fades looks like 2 lines to comment out in 
> SDL. Maybe we
> should send a patch to them for a dependance on an environment 
> variable or some
> such.

There is not only the fade trouble, there is also the window buffer 
bug. I sent a patch to the sdl-devel mailing list (it was CC-ed to the 
qemu-devel) for this issue, but I didn't get any reply.

Pierre

Re: [Qemu-devel] Keyboard patch for windows

[Jim C. Brown]

While SDL works for qemu, I think we really need native support for different
OSes. Keep SDL around as a way to port qemu easily to new OSes of course, but
as development matures we should appoint maintainers for the OS-specific
drivers.

Touchpad emulation is not possible via SDL. I'm looking into using the X11
replacement (this will take a while as I have never done Xlib programming before
:) SDL may end up holding qemu back ... at the very least, use a custom version
of SDL that supports what we need (e.g. the custom SDL version should have
patches so the e0 is preserved when returning keypresses).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Keyboard patch for windows

[Lionel Ulmer]

On Wed, Aug 04, 2004 at 11:24:25AM -0400, Jim C. Brown wrote:
> While SDL works for qemu, I think we really need native support for different
> OSes. Keep SDL around as a way to port qemu easily to new OSes of course, but
> as development matures we should appoint maintainers for the OS-specific
> drivers.

I already sent a mail some times ago about this subject... People motivated
to do a task like this should write an 'interface' document describing the
proposed API for this driver layer (ie how QEMU would interface with this
layer).

Then, have it approved by Fabrice and port the SDL driver to this API.
People should be then free to add their own 'native' APIs with SDL being
always the 'default to run on new system' version.

Basically, this is how it works in ScummVM and it seems to work fine for
them (with, for example, native PocketPC and DreamCast ports).

       Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Keyboard patch for windows

[Fabrice Bellard]

I agree that native GUIs are better than an SDL one. If such patches are 
submitted (for Win32, Carbon or GTK), I will integrate them provided 
they are simple enough.

Fabrice.

Jim C. Brown wrote:
> While SDL works for qemu, I think we really need native support for different
> OSes. Keep SDL around as a way to port qemu easily to new OSes of course, but
> as development matures we should appoint maintainers for the OS-specific
> drivers.
> 
> Touchpad emulation is not possible via SDL. I'm looking into using the X11
> replacement (this will take a while as I have never done Xlib programming before
> :) SDL may end up holding qemu back ... at the very least, use a custom version
> of SDL that supports what we need (e.g. the custom SDL version should have
> patches so the e0 is preserved when returning keypresses).
> 

Re: [Qemu-devel] Keyboard patch for windows

[Fabrice Bellard]

 From the windows API it seems that the bit 24 of lParam in the message 
WM_KEYDOWN contains what you want. From the SDL source code, it seems to 
be passed in the scancode field...

Fabrice.

Erik Karlsson wrote:
> The problem is that some of the keycodes are prefixed with an e0 prefix.
> 
> Examples:
> Numpad right arrow/6: 4d	Right arrow:   e0,4d
> Numpad left arrow/4:  4b	Left arrow:    e0,4b
> Left alt:	      38	Right alt:     e0,38
> Left control:	      1d	Right control: e0,1d
> 
> The problem withs SDL is that SDL strips off the e0 prefix. The result
> is that it is impossible to distinguish between e.g. the arrow keys and
> the arrow on the numeric keypad and between left and right alt and
> contol keys.
> 
> Another advantage with low level keyboard hooks is that you can capture
> system key combinations such as Alt-Tab and Ctrl-Esc. sdl_grab_start()
> does not do that on windows.
> 
> I agree that it is unclean to have native windows code in an SDL driver.
> It would of course be better to have a separate keyboard driver for
> windows. The problem is that the qemu architecture does not allow
> separate drivers for keyboard, mouse and display. This makes a windows
> driver just for the keybord impossible. A windows driver would then need
> to implement keyboard, mouse and display natively on windows.
> 
> Erik
> 
> 
>>Strange since Windows should send the raw keycodes directly to SDL. I 
>>think your patch is too complicated to be integrated in an SDL target. 
>>Can you find a simpler solution ?
>>
>>Fabrice.
>>
>>Erik Karlsson wrote:
>>
>>>Keyboard input via SDL on windows it not working well. It is for example
>>>impossible to distinguish between left and rihgt alt and control and
>>>between the arrow keys and the numpad arrow keys.
>>>
>>>I have fixed this problem by using windows low level keyboadrd hooks
>>> (SetWindowsHookEx, WH_KEYBOARD_LL) instead of SDL for keyboard input.
>>>
>>>Low level keybord hooks should work on windows NT 4.0 SP3 or later, eg.
>>>windows 2000 and windows XP but not on windows 9x. For this reason I use
>>>another method if low level keyboard hooks are unsupported. Tihis method
>>>involves hooking up the winidow procedure and using some ugly fixes and
>>>there is still problems when you press the two shift keys simultaneously.
>>>I have however not tested this method on win9x because i have no win9x
>>>machine to test it on.
>>>
>>>Erik
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Keyboard patch for windows

[Erik Karlsson]

No, is does not work because the scancode in SDL is 8 bits. So when SDL sets
the scancode to HIWORD(lParam) only bits 16-23 goes into the scancode.

And there is still two more problems with using SDL that i have not
mentioned yet. These problems are not caused directly by SDL. They are
cauesd by some weird semantics of windows keyboard messges.

1) The shift up problem
When both left and right shift keys are down and you release one of the
shift keys no WM_KEYUP message is sent.

For example:
press left shift    -> WM_KEYDOWN left shift
press right shift   -> WM_KEYDOWN right shift
release left shift  -> no message
release right shift -> WM_KEYUP reight shift

The result is that shift keys get stuck down in the guest OS when you
are pressing both shift keys simultaneously.

2) The Alt-Gr problem
When you press Alt-Gr windows atomatially generates a left control
message befor sending the right alt message. These automatically ctrl
presses must not be forwarded to the guest os.

The only way I have found to avoid these two problems is using low level
keyboard hooks (maybe Direct Input will work too). Using windows
messages natively or pathing SDL's windows message handling will not
work.

The bottom line is that SDL is not an option if you want working
keyboard support on windows.

Erik

>  From the windows API it seems that the bit 24 of lParam in the message 
> WM_KEYDOWN contains what you want. From the SDL source code, it seems to 
> be passed in the scancode field...
> 
> Fabrice.
> 
> Erik Karlsson wrote:
> > The problem is that some of the keycodes are prefixed with an e0 prefix.
> > 
> > Examples:
> > Numpad right arrow/6: 4d	Right arrow:   e0,4d
> > Numpad left arrow/4:  4b	Left arrow:    e0,4b
> > Left alt:	      38	Right alt:     e0,38
> > Left control:	      1d	Right control: e0,1d
> > 
> > The problem withs SDL is that SDL strips off the e0 prefix. The result
> > is that it is impossible to distinguish between e.g. the arrow keys and
> > the arrow on the numeric keypad and between left and right alt and
> > contol keys.
> > 
> > Another advantage with low level keyboard hooks is that you can capture
> > system key combinations such as Alt-Tab and Ctrl-Esc. sdl_grab_start()
> > does not do that on windows.
> > 
> > I agree that it is unclean to have native windows code in an SDL driver.
> > It would of course be better to have a separate keyboard driver for
> > windows. The problem is that the qemu architecture does not allow
> > separate drivers for keyboard, mouse and display. This makes a windows
> > driver just for the keybord impossible. A windows driver would then need
> > to implement keyboard, mouse and display natively on windows.
> > 
> > Erik