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

[Marc-André Lureau]

----- Original Message -----
> > Well, you were not really explaining your particular case, or were you?
> 
> Yes, I tried at least, and I even provided a complete, working example code
> (spiceterm).

It shouldn't be necessary to read your code to understand what you try to achieve and what are the problems you are facing. Especially if you want to modify the protocol.

I still have to answer myself the question "why is the current XT scancode input not enough"? Although I think I have guessed, it would be good to explain that, to motivate the reason for this change.

> > 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.
> 
> Ok (although I think such separation only makes thing unnecessarily complex).

For keyboard events generated at human speed, that's not important. I can agree to stick gdk/x11 keysyms in existing messages, when the server has SPICE_INPUTS_CAP_KEY_KEYVAL. But that's not what you proposed in your last patches.

> > 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).
> 
> I already sent such patch 2 weeks ago - please can you review?
> 
> http://lists.freedesktop.org/archives/spice-devel/2013-September/014342.html
> http://lists.freedesktop.org/archives/spice-devel/2013-September/014339.html
> http://lists.freedesktop.org/archives/spice-devel/2013-September/014341.html
> http://lists.freedesktop.org/archives/spice-devel/2013-September/014340.html

You didn't explain why you needed to add a new message, and a new DOWN/UP flag. How to interpret scancode with the flag? You can't stick 2 3-bytes scancodes for DOWN/UP, so is the server supposed to generate the UP scancode? (that would be different from existing scancode events)

The spice server can't advertize support for this message by default, it needs to be enabled only if the server make use of it. So there need to be an API to change server caps (perhaps there is one already). In your server patch, you are not using the scancode. So is the client supposed to send both KeyDown/Up and Keyval messages? Then why have scancode sent 2 times?

Perhaps you shouldn't add scancode in your message, and just have gdk/x11 keysyms then?

Shouldn't be all renamed from "keyval" to "gdk_keyval"?