On Tue, Jun 25, 2013 at 01:26:46PM +0200, Marc-André Lureau wrote: > Hi > > On Mon, Jun 24, 2013 at 8:08 AM, i iordanov <iiordanov@xxxxxxxxx> 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. The problem with passing around anything that isn't scancodes is that ultimately when QEMU injects the key events to the virtual machine, it needs to turn them into hardware scancodes. This is an inherantly lossy conversion. Perhaps a way around this problem is to take QEMU & virtual keyboard hardware out of the loop, and use the spice guest agent to inject the key event input directly to the windowing system as unicode characters or key symbols ? IOW, passing scancodes to QEMU would only be needed during bootup, once spice agent was running it would take over injecting key events ? Not sure how this would work if the user had started Xorg and spice agent, and then switched to a linux virtual console. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel