On Fri, Jan 12, 2007 at 09:15:21AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >> I've tried to tackle the same issue by hacking the vnc client side to
> >> send us keysyms no matter what the local keyboard mapping is. So I can
> >> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
> >> nevertheless and passes the correct scancodes to the guest OS.
> >
> > You mean scan codes, don't you? Key symbols are the XK_a and so
> > forth.
>
> No, keysyms. This is what the vnc protocol uses, so there is no way
> around that, unfortunaly. It takes the X11 keycodes and translates
> these to us keymap keysyms using a buildin table, then sends them. So
> for the server side (from vnc protocol view, i.e. qemu-dm or vnc-fb) it
> looks like a vnc client with us keyboard.
>
> > Passing scan codes in addition to key symbols makes sense.
>
> Does the vnc protocol allow that? I don't think so :-(
No, but there's no reason we couldn't come up with an extension. Anthony
has already done similar to allow passing of relative mouse co-ords instead
of absolute co-ords. Extensions are opt-in, so unless the client has support
they'd carry on with normal keysyms, but a client that understood the new
extension could switch to scan codes. The important thing is talking to
upstream VNC mailing lists about any proposed extension to get buy-in so
some of the popular clients implement it. As far as i'm concerned, I'm more
than happy to extend the virt-manager VNC client if it could enable better
internationalized keyboard handling.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|