[Spice-devel] why getScanCode() will not work for keyboard input

[Marc-André Lureau]

Hi

On Mon, Jun 24, 2013 at 8:08 AM, i iordanov <iiordanov at gmail.com> wrote:
> Hi Marc-Andre,
>
> (And anybody else who wants to weigh in on this). After some research,
> reading and experimentation, here is what I've discovered.
>
> getScanCode() works only for physical devices (e.g. USB keyboards, bluetooth
> keyboards, or hardware device keyboards). The vast majority of input devices
> on Android are soft-keyboards which generate KeyEvents with invalid or
> missing scan codes.
>
> Such KeyEvents also don't even have a keycode. In such events, Android sets
> the keycode to KEYCODE_UNKNOWN. In addition, a KeyEvent is quite often a
> sequence of unicode characters rather than a single unicode character.

That makes sense. It would still be nice to handle physical devices
with their keycode.

> What *can* be obtained from every KeyEvent, however, is one or more unicode
> characters with the getUnicodeChar() and getCharacters() functions
> respectively.. For VNC purposes, what I do in bVNC is to convert these
> unicode characters to X11 keysym values, which are then passed to the VNC
> server. These keysyms are not just the ones that correspond to the XT
> keyboard keys, but a much larger set which maps pretty much every unicode
> character to a keysym.
>
> Do you guys see any way in which we can handle this situation where the
> input is not as straight forward as an XT keyboard?
>
> What would work is if mobile clients were able to either send unicode
> characters or X11 keysyms to the server.
>
> Does anybody else have any better ideas?

Probably Spice server and agents should learn to handle arbitrary
input in unicode (that would also help html5 client support)

However, this needs to be carefully designed, so that hw keycode are
still issued/interpreted to the guest when the remote doesn't handle
unicode directly.

I have not investigated further, but that looks interesting :)

--
Marc-André Lureau