Alon Levy píše v Út 10. 04. 2012 v 13:41 +0300: > On Tue, Apr 10, 2012 at 12:08:31PM +0200, David Jaša wrote: > > Alon Levy píše v So 07. 04. 2012 v 13:21 +0300: > > > 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. > > > > There is just one annoying thing about it - when different shortcuts are > > used byt client and guest systems. I got used to shift+capslock at at my > > linux client where I spend most of time and when I have to work with > > windows guest, I keep swearing why I have the other keymap after I > > "switched" it and why I have the CapsLock turned on... > > > > > 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). > > > > > > > I see it. > > > > Actually, I'd like to see spice-based analogy of 'ssh -X' sometimes in > > the future and this would be one of prerequisites for it (the other are > > rootless Xspice, connection over unix socket etc.) > > I would appreciate if you created bugs for these.
I will when I'll have time for it (I consider it "nice to have" priority). Connection over a unix socket is already implemented by Dan McGee and Nahum IIRC. > The rootless case - we > are talking about Xspice being it's own window manager, so that you can > run a single X client? Exactly. Pretty extreme example would be something like: ssh --<spice_tunnel_option> user@host gimp - gimp's windows should be visible and manageable by client VM. I can imagine reusing multiple display support for this so that every new window spanned by the tunneled app is presented as a new hot-plugged display to the client. David > > > > > David > > > > > > > > > > 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@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@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 > > > > -- > > > > 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@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 -- 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
