Re: keypress-delay issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Čt, 2015-06-25 at 00:28 -0700, Jared Kwek wrote:
> On Tue, Jun 23, 2015 at 4:14 PM, Marc-André Lureau <mlureau@xxxxxxxxxx> wrote:
> >
> >
> > It's interesting that I can barely notice the lag, and possibly most
> > people, judging by the amount of people complaining.
> 
> While true that the lag is barely noticeable, the fact is that it is
> there and more noticeable to some people than others.
> 
> >
> >
> > This was introduced to solve a real problem though, to avoid spurious
> > software key repeat on guest side. This is particularly annoying with
> > remote guest with a lag of several 100's of ms, but could also happen
> > locally if the VM get stuck due to scheduling.
> >
> 
> I also understand the problem you were trying to solve, as it is a
> common issue in remote desktop situations.  But instead of a
> one-size-fits-all solution, I'm advocating for a configurable value
> since different values make sense in different situations.  If my
> desktop is on a VM on my local machine, it would be a better user
> experience for me to turn down compression, keypress delays, etc.
> rather than use the same settings as if my desktop were streaming
> across a slow network connection.
> 
> >
> > I am not sure more tweaking should be advertised, as this is fairly
> > obscure and could reopen the issue I was trying to solve. Instead I
> > wish we would have a better/more clever solution to this issue.
> > Unfortunately, I don't have good one, adjusting the latency
> > based on local vs remote "measurements" would still let spurious
> > key repeats on slow scheduling, is this a better tradeoff?
> 
> 
> I don't think adjusting the latency based on measurements would be a
> good alternative unless it could be done with confidence in those
> measurements.  I think an easier method would be to set the
> keypress-delay to a sane value by default and allow it as a
> configuration item in case a person wants to tweak it.  Similar to how
> compression works now with the SPICE protocol...

IIRC the compression is set on connection initialization based on b/w
measurement so this analogy supports Marc-André's approach more. (I can
see that latency measurement is trickier than b/w).

David

> most people don't
> change the defaults but those that want to have the option to do so.
> 
> With the risk of generalizing too much, I value the fact that most
> open source software packages are more configurable than their
> commercial counterparts.  Having more options to tweak if I desire
> allows me to tailor the software to my specific use case.
> 
> Thanks for considering my suggestions.
> 
> Regards,
> Jared Kwek
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]