[Spice-devel] [patch 0/2] vdagent KEYVAL extension

[Marc-André Lureau]

----- 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).