----- Original Message ----- > > > Note: you cannot translate a scancode to utf8 (because you do not know > > > the keymap of the client). > > > > Or perhaps you could, that would allow to sync client and guest with the > > same > > keymap. > > 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. > > > > 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. > > 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... > > 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 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. > > > 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). _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel