https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #23 from Mike FABIAN mfabian@redhat.com --- (In reply to Stas Sergeev from comment #22)
(In reply to Mike FABIAN from comment #21)
Why doesn’t xine do that on my system?
There are a few ways to get an answer to this:
- You can suggest me how to enable more logging
and/or I'll do some debugging on my own.
I have some more debug prints which I did not permanently put into the source yet:
https://github.com/mike-fabian/ibus-table/commits/miketmp https://github.com/mike-fabian/ibus-table/commit/9f4218ca58bbca1eb020579ee98...
This patch should apply to your version of ibus-table.
- I give you an ssh. Hopefully with "ssh -X"
the thing is reproduceable.
I don’t see your gnome-panel then and will probably not be able to switch input methods.
This gave me a weird idea though.
I tried this:
1) Run xine somevideo.mp4 in gnome-terminal number 1. 2) Open another gnome-terminal, number 2, in that terminal run: “ssh -X localhost” 3) Switch input method to rusle, focus terminal number 2, press a key there and hold it. After a while it switches from “ф” to “a” *permanently*. The property menu (in the menu which opens when clicking on the input mode indicator in the gnome-panel) has switched to "Direct Input (Left Shift). I the debug.log I find: _table_mode_process_key_event() repr(key)=Shift_L 0x00000000
This does *not* occur without step 1), i.e. without running xine!
(I also tried mplayer but the problem did not occur when using mplayer instead of xine).
Looks like I can reproduce your problem now when I do the input in a terminal after doing “ssh -X localhost” in that terminal.
When xine is running, the autorepeat typing is noticeably lagging, there are a "huccups". But this is not because of the CPU load, it just somehow affects only ibus. :)
I don’t see that, it still appears fast to me in the terminal after “ssh -X localhost”.