> > That is clumsy, and also requires a protocol extension - so what is > > the advantage? > > "sync client and guest with the keymap" & avoid the need for new key event. I guess you over-simplify that. There are many different keymaps on the client side! So you do you correctly translate the scancode back? I assumes that is impossible to do accurately. > > > > Hope that is clear now? > > > > > > It's not about utf, you are not using utf encoding. It's about UI "keysyms" > > > or > > > "keyval" > > > > yes (see subject). > > So let's stop talking about utf altogether, which I would want to see at a higher > level, for arbitrary "string" inputs. > > > > > > I thought we cannot modify existing message formats - or is that > > > > possible? > > > > > > It's possible, just like the VD_AGENT_CAP_CLIPBOARD_SELECTION you > > > asked last time. > > > > Sorry, but this is already fully implemented for the vdagent protocol > > (see VD_AGENT_CAP_KEYVAL). > > So why do you ask? I am just answering your question. Oh, I get you wrong. So you really think we can modify existing message formats based on caps? That looks a bit confusing to me, and it is not clear how that should work because message marshallers are auto-generated? > > > It's not about what I like, it's about being correct. You call it > > > utf when it has very little to do with utf. > > > > first, I call it keyval. Second, keyval and utf8 are closely related, > > and you cans easily convert them. > > that's irrelevant for the protocol change. You can also convert most XT > scancode to utf... no, you can't do that (because you do not know the keymap)! You can do it for US keymap - but most of us do not use that keymap. > > > You don't explicitely give the keyval encoding, when elsewhere you > > > just assume it is gdk/x11. This cannot be left to the client to > > > decide. You must define it clearly. That's why I dislike just saying > > > gdk/x11, because I am not sure we can just assume they won't change > > > it for example. > > > > I guess the correct name is X11 keysyms. Although that is not > > statdardized, I guess that is used everywhere and really stable. > > > > > I would prefer if we stick to unicode (and utf8 representation) > > > > It is unlikely that UTF people add representations for functions keys > > in near future. > > But we can send both things - keysyms and UTF code if you like? > > I already detailed what I imagined could work for arbitrary utf8 string input. But > that's not what you want, so we have different needs. Although I believe your I need utf8 and special/function keys. Using keysyms you get both. > extension will not be relevant for typical client/vm usage (or even x11 & weston > server) that Spice is targetting, and I think you could use that arbitrary utf8 string > input approach instead. But I don't want to force you to do it. We can also > accept extensions to the protocol that are not relevant for VM. Great! > > > > It is still not clear to me what patch do you prefer - vdagent > > > > protocol extension or the input channel extension? > > > > > > In your case, a gdk_keyval message, the input channel. > > > > or better 'x11_keysym' message? > > You are using it with gdk constant in client and spiceterm, but gdk keysyms seems > to be exact mapping of x11. So either we decide to follow x11 or gdk. I would > tend to say Gdk, which is more cross-platform (even though it's in fact just x11 > atm). But the gdk docs simply references to the x11 docs, so I guess x11 is the source. The also mention that they keep that in sync with x11. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel