Input lag after last update

[Kai Mast]

Seems some recent update in trusty introduced an input lag in xmir again :(

I am using an Intel Hashwell chipset, which has been working perfectly so far...

[Kai Mast (kai-mast)]

Oh and mouse movement works fine, so it is only keyboard input that lags behind.

[Daniel van Vugt (vanvugt)]

This sounds like bug 1291755, which should have been fixed with the latest update to Mir 0.1.7. But also...

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
   apport-collect 1295851
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Rick Harris (rickfharris)]

Bug is still present here in mir-0.1.8+14.04.20140411-0ubuntu1 so may be slightly different to bug 1291755 ?

Only other info I can offer is that with 0.1.7 I could Ctrl+Alt+<func> to a VT and back into the Xsession and that would work around the bug for some time (hour or two?) before I would have to do this again.

With 0.1.8 this work around no longer seems to work and I have to restart the Xsession to get keyboard input to function correctly.

Symptom starts as slow to respond to keyboard input (type a character and takes a few seconds for typed character to appear on screen).
Shortly after this first symptom, displayed keyboard input degrades to being one character behind (type a character and character does not appear on screen until another character is pressed, or mouse is moved).

[Daniel van Vugt (vanvugt)]

Can anyone reproduce this in Ubuntu 14.10 utopic?

[Daniel van Vugt (vanvugt)]

Actually I would not be surprised if we did still have a bug like this. The team would not have noticed it for several reasons:
  * We don't have any keyboard/typing-related demo clients.
  * We don't use XMir regularly
  * Touch input could be suffering similar lag and we would not notice because touch events are much more numerous and more likely to be flushed adequately to keep Ubuntu-touch moving.

Our MultithreadedCompositor's frame scheduling logic is still somewhat suspicious. It gets the number of frames to schedule from the BufferQueue, but that function of the buffer queue is apparently racy by design, and may not return a realistically high enough value adequate to schedule enough frames.

[Daniel van Vugt (vanvugt)]

I think I might have found an explanation --> bug 1379610

[Daniel van Vugt (vanvugt)]

Hmm, maybe not.

[Launchpad Janitor (janitor)]

[Expired for XMir because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for mir (Ubuntu) because there has been no activity for 60 days.]

[Daniel van Vugt (vanvugt)]

Won't Fix. XMir 1.0 is now deprecated.