Hi ----- Original Message ----- > > > > Hi > > > > ----- Original Message ----- > > > Hi > > > > > > ----- Original Message ----- > > > > > > > > > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > > > > > > > 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. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel