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

[Dietmar Maurer]

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