Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Hi, So a spice client must somehow figure how to translate the input it gets into scancodes. And IMO this should best be done on the client side so the client can use all information it has to do it. For gtk this is easy as the key events carry not only the character but the keycode too. For android/html5 clients this is alot trickier ... AFAIK, neither java nor javascript have access to scancodes. If you solve the problem on the server side (spice server library), you need to solve it only once. Else you need to implement that clumsy code on each client. If I remember correctly, qemu already has some code to convert VNC input to scancodes? It tries to translate the keysyms back to scancodes, using a keymap (specified via -k). Which doesn't work perfectly and also has the drawback that the server side needs to know which keymap the client is using. At least the later can be fixed by doing it on the client side. It will be clumpsy no matter what, but maybe that can't be avoided for html5/android. But, when the server side wants a utf8 stream this is a completely different issue. Maybe the easiest is to send the utf8 stream over a SpiceCharDeviceInterface (if present). Sorry, I am quite new to spice - please can you elaborate a bit more? I can see how to create a SpiceCharDeviceInterface at server side, but AFAIK that is used for other things? It is basically a transparent bytestream with a name tag, the name being a reverse fqdn to avoid name clashes (see docs/spice-port-fqdn.txt). The spice client then can do something sensible for names it recognises. For example it could wind up org.qemu.console.serial.0 to a vte widget. This way the guests serial console can be redirected over spice. And this would btw also be a possible approach to implement spiceterm. You can define your own channel for utf8 keyboard input, then make spiceterm and spice client use it to pass keyboard input. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Seems the keyboard interface only return scancodes? Is there a way to get the corresponding utf8 character (using client side keyboard mapping)? Scancodes are great for use in qemu/X11, but other applications needs utf8. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Seems the keyboard interface only return scancodes? Is there a way to get the corresponding utf8 character (using client side keyboard mapping)? Scancodes are great for use in qemu/X11, but other applications needs utf8. Which? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Scancodes are great for use in qemu/X11, but other applications needs utf8. Which? I want to write a terminal emulator, exporting the vt100 display over spice. Example: # spiceterm -c /bin/bash That way you can run any terminal based command over spice. We already have that for VNC. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Scancodes are great for use in qemu/X11, but other applications needs utf8. Which? I want to write a terminal emulator, exporting the vt100 display over spice. Example: # spiceterm -c /bin/bash That way you can run any terminal based command over spice. We already have that for VNC. So you want to have a terminal emulator using spice-server directly? in that case maybe we need to extend the protocol. I guess converting scan codes to utf-8 is impossible, without additional information, which currently we rely on the guest to decide on. I'm not sure what happens with Xspice, it might benefit from this too. This would entail adding a capability to the inputs channel and a new message. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
- Mensaje original - Scancodes are great for use in qemu/X11, but other applications needs utf8. Which? I want to write a terminal emulator, exporting the vt100 display over spice. Example: # spiceterm -c /bin/bash That way you can run any terminal based command over spice. We already have that for VNC. Having utf8 input was discussed a few weeks ago, it is needed for html and android clients for ex. Feel free to propose a solution. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Having utf8 input was discussed a few weeks ago, it is needed for html and android clients for ex. Feel free to propose a solution. Just extend the protocol to send both things (scancode and utf8)? Or add another channel for utf8 input? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
So you want to have a terminal emulator using spice-server directly? Yes. We have that for VNC, and it is quite convenient. For example, we can open a login shell to the host, or run maintenance command requiring user input like 'apt-get upgrade'. Or simply open a container console by running 'vzctl enter'. in that case maybe we need to extend the protocol. I guess converting scan codes to utf-8 is impossible, without additional information, which currently we rely on the guest to decide on. I'm not sure what happens with Xspice, it might benefit from this too. This would entail adding a capability to the inputs channel and a new message. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Hi, # spiceterm -c /bin/bash That way you can run any terminal based command over spice. We already have that for VNC. Having utf8 input was discussed a few weeks ago, it is needed for html and android clients for ex. Note that this is a completely different problem. When running a virtual machine you need the scancodes, so you can feed the guest with the correct virtual keystrokes. Translating those keystrokes into characters is the job of the guest operating system. There is no meaningful way to pass a utf-8 character stream into a virtual machine. So a spice client must somehow figure how to translate the input it gets into scancodes. And IMO this should best be done on the client side so the client can use all information it has to do it. For gtk this is easy as the key events carry not only the character but the keycode too. For android/html5 clients this is alot trickier ... But, when the server side wants a utf8 stream this is a completely different issue. Maybe the easiest is to send the utf8 stream over a SpiceCharDeviceInterface (if present). cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Having utf8 input was discussed a few weeks ago, it is needed for html and android clients for ex. Note that this is a completely different problem. When running a virtual machine you need the scancodes, so you can feed the guest with the correct virtual keystrokes. Translating those keystrokes into characters is the job of the guest operating system. There is no meaningful way to pass a utf-8 character stream into a virtual machine. So a spice client must somehow figure how to translate the input it gets into scancodes. And IMO this should best be done on the client side so the client can use all information it has to do it. For gtk this is easy as the key events carry not only the character but the keycode too. For android/html5 clients this is alot trickier ... AFAIK, neither java nor javascript have access to scancodes. If you solve the problem on the server side (spice server library), you need to solve it only once. Else you need to implement that clumsy code on each client. If I remember correctly, qemu already has some code to convert VNC input to scancodes? But, when the server side wants a utf8 stream this is a completely different issue. Maybe the easiest is to send the utf8 stream over a SpiceCharDeviceInterface (if present). Sorry, I am quite new to spice - please can you elaborate a bit more? I can see how to create a SpiceCharDeviceInterface at server side, but AFAIK that is used for other things? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
On Tue, Aug 06, 2013 at 03:42:29PM +, Dietmar Maurer wrote: Having utf8 input was discussed a few weeks ago, it is needed for html and android clients for ex. Note that this is a completely different problem. When running a virtual machine you need the scancodes, so you can feed the guest with the correct virtual keystrokes. Translating those keystrokes into characters is the job of the guest operating system. There is no meaningful way to pass a utf-8 character stream into a virtual machine. So a spice client must somehow figure how to translate the input it gets into scancodes. And IMO this should best be done on the client side so the client can use all information it has to do it. For gtk this is easy as the key events carry not only the character but the keycode too. For android/html5 clients this is alot trickier ... AFAIK, neither java nor javascript have access to scancodes. If you solve the problem on the server side (spice server library), you need to solve it only once. Else you need to implement that clumsy code on each client. If I remember correctly, qemu already has some code to convert VNC input to scancodes? Yes, but that code is broken by design, which is why we invented the raw scancode extension to VNC, and why SPICE uses scancodes from the start. It is not possible to round-trip from a character/key symbol, to a hw cancode back to a character/key symbol without irretrievably loosing information. eg the key sym you put in from the client will not match the one Xorg eventually gets in the guest. It also requires that you manually configure a keycode mapping table in the QEMU binary itself at startup, to match the keycode mapping in the guest and the mapping in the client. This obviously means that all clients must use the same keycode map that was chosen at the time QEMU started. I wrote a bit about this awfulness here https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ https://www.berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ Perhaps this brokenness is unavoidable with spice android/html5 clients, but you should be aware that if you go down that route, you are picking a solution which is unfixably broken. The only other option you'd have is to take QEMU's keyboard emulation out of the picture entirely. Define a spice guest agent extension that lets you pass key symbols straight to the guest agent, which can give them to the windowing system without any translation steps involved. Obviously this wouldn't be much help during intial VM bootup, but maybe that's an acceptable tradeoff ? 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8
Perhaps this brokenness is unavoidable with spice android/html5 clients, but you should be aware that if you go down that route, you are picking a solution which is unfixably broken. It is also broken if you implement it on the client side ;-) And we already have that code, so it would be a waste of time to re-implement that on the client side. The only other option you'd have is to take QEMU's keyboard emulation out of the picture entirely. Define a spice guest agent extension that lets you pass key symbols straight to the guest agent, which can give them to the windowing system without any translation steps involved. Obviously this wouldn't be much help during intial VM bootup, but maybe that's an acceptable tradeoff ? Well, this is not really the problem I want to solve. I want to write a terminal emulator, and I am interested in an utf8 input stream (scancodes are useless in this case). IMHO, the spice library should be flexible enough to provide that. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
