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

[Marc-André Lureau]

----- Original Message -----
> > > 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?
> > 
> > I don't remember. In the case of clipboard selection, it was certainly
> > easier since
> > we don't use the marshaller atm.
> > Perhaps have a second marshaller function version for this case would work?
> 
> how does that work (can't see it)?
> 
> Simply adding a new message solve the problem easily.

Yes, I think you should use a new message on input channel. In fact, your first protocol change made more sense for your needs, iirc.

>  
> > >> 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.
> > 
> > right, but it is assumed the server/vm have the keymap (or default).
> > It can convert to utf. That's what happen if i open gedit and type a key.
> > utf
> > conversion is irrelevant to your change. It's just a keysym you want to
> > send.
> > What you do with it, the protocol doesn't care.
> 
> Not everything is a VM (there is no server side keymap in spiceterm).

But even *userspace* x11 or weston spice server handle keymaps. You could too, using xkb common.

> 
> > The day the protocol send input strings, then it can be said it will be
> > utf8
> > encoded.
> > 
> > 
> > > I need utf8 and special/function keys. Using keysyms you get both.
> > 
> > I got that.
> > 
> > >> 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.
> > 
> > yeah, and scratch what I said, X11 makes more sense has it is a protocol,
> > regardless of the platform.
> > 
> > So you have enough to update your patches?
> 
> I still have no idea how to generate 2 marshallers for one protocol message?

That might be a marshaller limitation. Anyway, since you could add a new message, you can skip that.