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

[Marc-André Lureau]

----- Original Message -----
> > You said it yourself, unicode doesn't have representation for all keyboard
> > keys.
> > As you have seen in my previous reply, I am looking at the problem from an
> > "input-method" level. And I don't know if it's a good idea to depend on
> > X11/gdk
> > keysyms in general for Spice.
> 
> VNC use that for 20 years now, so I guess the idea is not so bad.
> 
> > > Else I need to listen on two different input channels, and mix them
> > > somehow.
> > > That does
> > > not make any sense to me.
> > 
> > Indeed, that might be a problem since input channel and vdagent/main
> > channel
> > are not synchronized.
> > 
> > Could we have the utf8 input message on the input channel, and multiplex it
> > with
> > the rest of vdagent messages, so at least the remote/guest receives event
> > in
> > order (assuming input channel waits for vdagent before processing key
> > event)?
> 
> Sorry, I do not really understand that. I already send a patch extending the
> input channel,
> but nobody answered. That is why I rewrote the whole thing to use vd_agent
> instead.

Well, you were not really explaining your particular case, or were you? bypassing all of server, x & qemu & kernel etc...

Arbitrary utf8 input can only be handled at user space / agent level (no way to pass a X11/gdk or utf8 through hw level)

And as of today, all agents messages go through the main channel. So it is quite normal to recommend to use the main channel. 

Now that I review your patch and look at spiceterm usage, I understand you are not just passing utf8 input, but you also want regular key events, thus the synchronization question arise.

> IMHO, extending the input channel keyboard message format would be the
> right thing to do. Simply send:
> 
> - scancode
> - keysym
> - modifier key state
> 
> inside a single message.

That might be a good option too, but that won't be that easy for the spice server / agent to deal with. And I also think it is useless to send a single message with all values when clearly only one of the 2 is being used.

I am still suggesting adding a utf8 input message (on input channel), synchronized with other existing XT key events (which don't have unicode representation). It is meant to be processed by the agent by in your case, it can be processed immediately.