[Spice-devel] [PATCH spice-gtk 3/3] widget: set keypress-delay to 0 on unix socket

[Marc-André Lureau]

Hi

----- Original Message -----
> > 
> > Hi
> > 
> > ----- Original Message -----
> > > Hi
> > > 
> > > ----- Original Message -----
> > > > > 
> > > > > From: Marc-André Lureau <marcandre.lureau at redhat.com>
> > > > > 
> > > > > There is no strong need for keypress-delay on local connection (not
> > > > > verified: unless the system is heavily loaded, in which case the VM
> > > > > will
> > > > > probably be stuck too and may or not repeat the key when running).
> > > > > 
> > > > > The benefit of removing keypress-delay is that games or interfaces
> > > > > that
> > > > > require "realtime" responses, such as FPS, are slightly better
> > > > > without
> > > > > the 100ms input delay.
> > > > > 
> > > > 
> > > > The same apply to tcp connection so I would just set this to 0,
> > > > not only for unix sockets.
> > > > Or perhaps set to a value (like 10?) that causes no problem.
> > > > Considering that if network is quite busy the kernel should collapse
> > > > tcp packets I would prefer to set this delay to 0.
> > > 
> > > The keypress-delay and SPICE_INPUTS_CAP_SCANCODE were introduced to fix
> > > key
> > > repeat that happen quite easily over the network.
> > > 
> > > We use TCP_NODELAY, not sure it's always a good idea then.
> > > 
> > > So we can't blindly remove the keypress-delay, and I don't have a better
> > > solution to avoid spurious key repeats over the network when typing atm.
> > 
> > Just to clarify, keypress-delay is not used to delay all key events, but
> > rather to wait for the next "key-release" event. As soon as it comes, the
> > input event "press-release" is sent.  (see keypress-delay documentation)
> > 
> 
> I know. The issue with real network is caused by latency, more precisely on
> latency variance and not average. This as if latency would be constant the
> press/release would be just skewed and key duration would be the same on both
> sides (guest and client).
> Delaying the press and sending press+release at the same time fix the
> different
> duration caused by latency change in the usually typing case where a key is
> released after being press without intermixed pressions/releases.
> However this post the press to the release event reducing the duration to
> 0.
> It appears some game (in my experience OpenArena) handle this 0 duration as
> no key (at least during the menu).

Interesting, I guess this could be worked around easily in server or qemu (I wonder if other input methods, such as qmp input-send-event would suffer the same problem).

> I'm not saying your patch does not fix the issue, just that it fixes it
> partially in the case of unix sockets where the latency and variance are
> near to 0.
> 
> However I think for game experience 100ms is a too big value for this delay,
> remote connection or not.

I think we could have two mode of operations, "typing" or "direct", in direct mode we would just send events as they come like before (or keypress-delay 0), while in typing mode we would filter/batch the press/release. Perhaps a better heuristic could switch between the two modes..?

Reducing the filtering delay is possible too, iirc, I took 100ms after doing some non-scientific measurements. But thb, I don't think that will really help.

> 
> About TCP_NODELAY this is a long story. It surely could help decreasing
> latency but without buffering or any other advice to sockets can increase
> quite a lot bandwidth usage. As long as kernel has space in the queue it
> keeps sending packets (even for a single byte) to the network stack.
> If queues are full it starts collapsing packets and optimizing them
> reducing number of packets.
> 
> With which game(s) you are experiencing this issue?
> Does reducing the default delay helps?

I was just playing some FPS with virgl, and there you want "direct" input, to avoid the 100ms input lag, because you keys pressed.