I have Ubuntu 14.04 running on a Dell Latitude 13 laptop. When I launch Chromium and open several pages from stackexchange in different tabs. Any text I type in will frequently have characters showing up in a different order from how they were typed. For example, this paragraph actually showed up as:
I have Ubuntu 14.04 runnign on aDell Latitude 1 3laptop. Whne I alucnh Chormium na dopne several pages form tsackexchnag ei ndiffreent tabs. Any text I type in will ferwuqently have cahracters shwoing up in adifferent ofrdre form hwo htye weer ytped. For exmapel, thsi apragraph actually shwoed up as
As you can imagine having to manually fix that every time it happens can be very frustrating. The behavior looks as if some layer in the software stack is inserting key presses into a stack rather than a queue, and if they are not consumed as quickly as they arrive, they show up in the wrong order.
This only happens sporadically, and seems to happen more often when Chromium is swapping a lot. I have not been able to identify which layer of the software stack is causing the problem. Is there any additional debugging/logging I could enable to show me in which order characters show up at different layers in the software stack?
What I have tried so far
By sending alternating STOP and CONT signals to an xterm, I was able to slow down xterm just enough to reproduce the symptom. Since reordering of keyboard input is not supposed to happen even if xterm is frozen for a little bit, I think it is safe to conclude that the flaw is not in Chromium or stackexchange, but rather in some software being involved in both cases.
In order to rule out the possibility that it may be a flaw in the keyboard hardware, I tested with synthetic key presses.
sleep 10 ; for K in {a..z} ; do xdotool type "$K" ; sleep 0.2 ; done
With that command I was able to reproduce the problem. On one occasion the keys showed up in the order abcdefghlmkjpnioqrstuvwxyz. So when it also happens with keypresses generated by xdotool, it cannot be a flaw in the keyboard or keyboard controller.
If I speed up the input produced using xdotool even further, it causes the xterm to lock up.
Seeing an xterm lock up when keyboard input arrives quickly is something I have seen even without artificially slowing it down using STOP signals. When I do see xterm lock up like that, it usually keeps happening after I kill the xterm and start a new one. That problem persists until I run compiz --replace. After running that command everything runs faster and xterm no longer locks up at least for the first few days.
So there is some evidence suggesting that the two problems are related and somehow has something to do with compiz, but I don't have any solid evidence to back up that suspicion.
0 Answers