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

[Dietmar Maurer]

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

Some SPICE applications want to use the keymap from the client side, and 
works directly with UTF input characters (for example a terminal emulator - spiceterm). 
The current scancode values cannot be used for those applications.

Note: you cannot translate a scancode to utf8 (because you do not know the keymap of the client).

Hope that is clear now?

> > > 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 thought we cannot modify existing message formats - or is that possible?
 
> > > 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/01434
> > 2.html
> > http://lists.freedesktop.org/archives/spice-devel/2013-September/01433
> > 9.html
> > http://lists.freedesktop.org/archives/spice-devel/2013-September/01434
> > 1.html
> > http://lists.freedesktop.org/archives/spice-devel/2013-September/01434
> > 0.html
> 
> You didn't explain why you needed to add a new message, and a new DOWN/UP
> flag. 

I want to send keysyms. The DOWN/UP flag is required because keysyms does not
include that information. 

Note: The Input channel use 3 different message type to indicate UP/DOWN/DOWN_AND_UP for scancodes.
I thought it is easier to use a flag instead.

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

Not sure what you talk about - My patch does not modify the behavior for scancodes.
It just send an additional message for the keysym (there is no scancode included).

     message {
       uint32 keyval;
       keyboard_keyval_flags flags; # DOWN/UP/DOWN_AND_UP
    } @ctype(SpiceMsgcKeyKeyval) key_keyval;

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

yes, we need to add that.

> In your server patch, you are not using the scancode. 

yes, I only need the keysyms.

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

You want to suppress normal scancode messages to avoid traffic?
  
> Shouldn't be all renamed from "keyval" to "gdk_keyval"?

I will name it whatever you like.

It is still not clear to me what patch do you prefer - vdagent protocol extension or the input channel extension?