[Spice-devel] Keyboard layout change on Xspice
Alon Levy
alevy at redhat.com
Sat Apr 7 03:21:54 PDT 2012
On Fri, Apr 06, 2012 at 09:11:11PM +0200, David Jaša wrote:
> Hi David,
>
> David Mansfield píše v Pá 06. 04. 2012 v 14:17 -0400:
> >
> > On 04/06/2012 03:05 AM, Alon Levy wrote:
> > > On Thu, Apr 05, 2012 at 12:52:53PM -0400, David Mansfield wrote:
> > >>
> > >>
> > >> On 04/05/2012 11:58 AM, Alon Levy wrote:
> > >>> On Thu, Apr 05, 2012 at 01:24:54PM +0200, Michael Niehren wrote:
> > >>>> Hi together,
> > >>>>
> > >>>> i successfully installed and connected to Xspice und FC16, great work, i was very pleased
> > >>>> to see, what's possible with spice.
> > >>>>
> > >>>> 1 thing left to use it as an Server to connect from my thin client is the keyboard layout.
> > >>>> As i live in Germany i want to have the german keyboard layout. If i connect with the
> > >>>> spice-client i only got the english one. Is there a way to change that (i didn's find one)
> > >>>> ?
> > >>> (Continuing my previous reply). OK - tried a non english keyboard
> > >>> (hebrew), and it works fine. The thing to understand is that changing
> > >>> the keyboard mapping on the client doesn't affect the server - only
> > >>> changes on the server side affect it. So to get a german keyboard, you'd
> > >>> need to change the keyboard on the remote side, the server, for instance
> > >>> I just used "setxkbmap il" to change the keymap to the hebrew one on the
> > >>> remote side.
> > >>>
> > >>
> > >> I've been troubled by this too, because I use DVORAK mapping. Is
> > >> there anything in the pipeline for the spice-agent to address this?
> > >
> > > I don't think there is anything to fix, unless I misunderstand - the way
> > > it works is that the keyboard map is determined by the Xspice Xserver
> > > entirely, and not by the spice client. That's the way spice keyboard
> > > works, and it avoids having to encode anything about the keyboard map at
> > > the spice level. The spice keyboard protocol is the same an AT keyboard
> > > talks to the pc.
> > >
> > > A spice agent would help other things, like copy paste support, and
> > > better mouse performance for latency laden networks, but has nothing to
> > > offer for keyboard - I don't see what there is to fix here, maybe you
> > > can explain.
> > >
> >
> > I didn't read that this discussion was specific to Xspice, which while
> > I've tried, I was referring to spice access to a VM. Nevertheless, the
> > agent could perhaps be used to automatically set the server-side
> > keyboard mapping to that of the client, both in the Xspice and VM case,
> > I suppose.
> >
> > In a perfect-world scenario, the keyboard mapping setting would be
> > magically adjusted the client side mapping upon connect.
>
> It's not that easy:
> * there must be exactly same keymaps in client & guest. This is a
> _big_ problem since even console & X keymaps of the same name in
> linux are not the same
> * you have to take layout switching into account:
> * when not focused, watch for layout state in client and
> change it in guest accordingly
> * find out what shortcut client desktop uses for layout
> switching, trap it, pass it always to the client
> regardless of keyboard grab and switch layout in the
> guest
> * watch for layout changes in guest (e.g. when linux
> client uses shift+capslock and windows guest L_alt
> +shift) and propagate them back to the client
> * you should not break magic like mutter's one for alt
> +key-above-tab:
> http://git.gnome.org/browse/mutter/tree/src/core/above-tab-keycode.c
>
> I'd love to see it too but it seems so hard to get it right that it's
> not worth it - unless you'll find somebody to step up and write the
> actual code. :)
The thing is, for virtual machines where you work in full screen all of
this is not very interesting. The keypresses that trigger language
changes (i.e. keymap changes) get passes just to the vm and it does
whatever it does to change the keymap, and it just works, without all of
the above. No coordination is required. I like the detailed description
- and from looking at it it's obvious this is not trivial to implement
and easy to get almost working but not 100%. Maybe worth writing this
down on the wiki.
But for Xspice it's actually really required. And it's an easier case -
just an X "guest", not multi platform (still multiple platforms on the
client side though).
>
> David
>
> > I'm not saying
> > it's the highest priority problem in the world, but it is a bit
> > surprising at first when it doesn't work.
> >
> > Or maybe it's supposed to work in the VM setting and just isn't for me.
> >
> > Anayway, don't worry about it.
> >
> > Thanks,
> > David
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> --
>
> David Jaša, RHCE
>
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
More information about the Spice-devel
mailing list