Red Hat Bugzilla – Bug 488976
Keystrokes appear to be delayed and repeatable.
Last modified: 2009-03-27 10:53:46 EDT
Description of problem: While in a WINE Game, keystrokes seem to be buffering. What's really happening though is, if I were to type text in-game. I get problems. ex. If I type the word "Anyone" no text shows up until I type the 'y' and then the 'A' shows up, and when I type the 'o' the first 'n' shows up. Another problem is when I go to turn my character in game by pressing 'd' to turn right, nothing happens, but once I press 'd' again it starts to turn, but when I let go of 'd' it continues to turn and never stops as if the key depress is never registered. Also, 'esc' is supposed to bring up the menu, but doesn't unless pressed twice. But it's even worse if I have already become stuck turning in a direction. I have to press 'esc' multiple times to get it to register. This happens in World of Warcraft, as well as in Counter-strike. And it only happens in games. notepad emulated in WINE works fine. As well as all Fedora applications such as xterm. So far it only seems to happen in WINE Games. I have tried 3 different WINE versions, (1.1.14, 1.1.15, 1.1.16) and I have deleted my .wine directory to start fresh. It always happens. WINE devs think it has to do with libgxim. I yum updated yesterday 03-05-2009. This is when the problem started.
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1.Load up Game via command 'wine /home/<user>/Games/World\ of\ Warcraft/Wow.exe'
2.Log into character.
3.Start to play, keystrokes are delayed and causing errors.
Actual results: See description
Expected results: For there to have no delays in keystrokes.
I wish to confirm this bug.
It appears related to fixes from Bug 488223.
Hmm, I don't have that. is there any applications that I can try here? that's a bit hard to fix a kind of this issue without reproducible way on local box.
Probably I got an idea to solve this issue. try to implement that now.
*** Bug 489121 has been marked as a duplicate of this bug. ***
Unfortunately I've only been able to replicate this with World Of Warcraft operating under wine. I've attempted to replicate it with notepad under wine but have not yet had it occur :(.
To clarify the issue, can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=1230892 and do:
% gconftool-2 -t bool -s /apps/imsettings-applet/sync_on_forward true
If this works, I think the root cause would be same. please note that this workaround might affects a performance of input. I'm taking another way to fix a kind of this issue now. keep in mind you may need to turn it off once fixed package is available and install it on your box.
This is a pre-testing package. I need some volunteers before pushing this to updates. please try two cases:
1. install the package from the above URL. and see if your problem is gone.
2. turn off a sync_on_forward workaround. i.g. gconftool-2 -t bool -s /apps/imsettings-applet/sync_on_forward false
and restart your application to make sure and see if your problem is still gone.
3. give me your feedback of both cases, how's responsiveness say.
Please note that you need to restart your desktop after installing packages.
I am reporting about the emacs crashes in vnc which have grouped with this bugs: unfortunately the pre-testing package doesn't solve the issue. Emacs no longer crashes under heavy scrolling with lost connection to the X server, but rather it freezes and hangs forever and only kill -9 the process gets out of it...
(In reply to comment #9)
> I am reporting about the emacs crashes in vnc which have grouped with this
> bugs: unfortunately the pre-testing package doesn't solve the issue. Emacs no
> longer crashes under heavy scrolling with lost connection to the X server, but
> rather it freezes and hangs forever and only kill -9 the process gets out of
Hmm, works for me. are you sure you've restarted your desktop and new instance of imsettings-applet is running? and which cases does it happen on, 1 or 2? or both?
and when it's hanging, does redrawing a window work?
Doh. I missed one backporting patch to fix an issue not working on case 1 unless you explicitly turn on with gconftool-2 after applet starting.
Sorry for your trouble.
thanks, crossing fingers it seems to work (at least on i386)... more testing to follow
Thanks. is there anyone else who can volunteers? :)
BTW if no difference on behavior and performance between turning sync_on_forward on and off, I'll turn on that by default since that will fixes accelerator key issue on X apps. so that would be appreciated if someone has any comments about it.
These last packages from comment #11 appear to have solved my issues. Either that or I got real lucky last night :)
That's on x86_64 by the way.
I was the original commenter. Sorry it took a bit to respond. I would like to test the new package, but i'm using the older 3.1. If I could have some instructions on how to install your build. I'd love to test it out on my system. As I'm the original reporter.
To note, once I reinstalled 3.1, the problems were gone. So it was 3.2-4.
Send step by step instructions and I'll test whatever.
I'm not sure if I did this right.
I went to http://koji.fedoraproject.org/koji/taskinfo?taskID=1236402
and installed imsettings-0.105.1-3.fc10.2.i386 packages. Restarted, then went into the game. It's a ton better but there's still issues. Typing in the games for instance seemed to work without delay. However turning and moving character depending on how long you hold 'a' to turn left, once let go of 'a' would determine how long it kept turning after 'a' was let go. So for example if I hit 'a' to turn left in game for 2 seconds, it would continue to turn left for 2 more seconds after 'a' was lifted. If I did it for 5 seconds, then let go, it would continue to turn for another 5 seconds.
I did not apply the following because it did not work completely.
gconftool-2 -t bool -s /apps/imsettings-applet/sync_on_forward false
I did just notice your version 3. I'm going to install it now and see if it fixes it completely or not. Version 2 seems to be tons better, but still annoying. I'll report back in a few mins.
reporting back. I just installed version 3 from
And it seems to have fixed the problem.
However, I hate to be picky, but i think it is a problem and key to the future of linux gaming. I barely noticed this, it is so subtle, I had to have my wife confirm it. If I hit auto run and move my mouse cursor, the frames are perfect, no change in frame rate. If I however am hitting 'w' to move forward or 'a' to turn left, the frame rate drops a few frames, and it is noticeable. So it seems to me like maybe the keyboard is taking too much of a priority over the game itself. and slowing it down. If set to auto run and no keys are being pressed, the game does not experience slow down.
I have not tried the gconf2 tool yet. I will try it and report my results. I do not know if this is entirely related or not.
Ok, with version 3, and with "gconftool-2 -t bool -s /apps/imsettings-applet/sync_on_forward false" in effect I get the same result as I did using version 2.(See Comment 16) It does not work with it on false. However, with sync_on_forward to false, even though the buttons become stuck. There is no slow down in frame rates when turning. with sync_on_forward set to true, the keys work perfectly, but there is slowdown in frame rates whenever any keyboard key is keyed.
I think there needs to be some work still if this is going to be the final solution. But with sync_on_forward set to true. I would say it can be released, but some will notice this frame rate slow down.
I don't know or understand what or how this was coded, but it may need some more code to better tie in the keyboard with the games (Streamline them together?) so that it does not slow down the game.
Another thing I noticed I forgot to mention, It seems like if I open up chat in-game, and hold down a letter, it appears as if I'm typing that letter like 4 letters at a time, like it prints it 4-5 character per keyboard stoke. Could be related to the slow down. Like maybe there's too many key strokes per official key stroke. dunno if that makes sense or not.
Also with it set to true. in this very comment window if I hold down 'd' I'm experiencing the same repeating for 5 seconds after i hold it for 5 seconds. Only in this comment window though, the in-game seems to work.
I hope all of this gives you an idea to narrow it down better. Cause it's not making sense to me why it isn't working....
After re-reading the last comment I need to clarify the paragraph about the 4-5 characters per keystroke. what i meant to convey is that it's not repeating smoothly like it should, 1 character at a time. Instead it seems to be printing out 4-5 characters per repeat.
Thank you for testing. I'm not sure if you've done the right thing to test, but let me clarify the steps to make sure.
1. make sure you've installed the latest version of libgxim package. i.e. libgxim-0.3.2-4.fc10. don't get it wrong. the root cause was in imsettings. not libgxim. you didn't just use it due to a bug in libgxim.
2. install the pre-testing package from koji at Comment #11.
Basically that's it.
(In reply to comment #18)
> I think there needs to be some work still if this is going to be the final
> solution. But with sync_on_forward set to true. I would say it can be
> released, but some will notice this frame rate slow down.
Right. this just ensures keyevents certainly delivers one-by-one. so it should perfectly works but slow down because of extra costs.
> Another thing I noticed I forgot to mention, It seems like if I open up chat
> in-game, and hold down a letter, it appears as if I'm typing that letter like 4
> letters at a time, like it prints it 4-5 character per keyboard stoke. Could
> be related to the slow down. Like maybe there's too many key strokes per
> official key stroke. dunno if that makes sense or not.
Hmm, when too much keyevents is delivered, I'm using a idle timer to process and send back them from queue. this would be one of reasons responses is slow down. let me try another way too.
> Also with it set to true. in this very comment window if I hold down 'd' I'm
> experiencing the same repeating for 5 seconds after i hold it for 5 seconds.
> Only in this comment window though, the in-game seems to work.
To make it clearer, does it happen only when you *hold* down right? but appears within a reasonable time when you just press and release a key?
guess it would be same reason the above then.
(In reply to comment #19)
> After re-reading the last comment I need to clarify the paragraph about the 4-5
> characters per keystroke. what i meant to convey is that it's not repeating
> smoothly like it should, 1 character at a time. Instead it seems to be
> printing out 4-5 characters per repeat.
guess because something is taking CPU load too much?
BTW confirmed that still getting stuck with sync_on_forward=false. I have an idea to fix that but may need to spend more time. to avoid further confusion on XIM, I'm pondering to push updates with sync_on_forward=true because current pre-testing package seems to be working well for most bugs I got.
To clarify what I did, I think i installed it correctly. I installed the following packages:
Then I rebooted and tried both sync_on_forward true and false. With true the game was playable, but it slowed down the frame rate. With false, I get the repeat error that isn't as bad. (The one where if I hold a key down for 3 seconds, it will continue to act like I'm holding it for another 3 seconds after I release the key.) This is not the same error as the first release of 3.2-4, where it would seem to multiply like if I held 'a' to turn for 2 seconds it would keep turning for like 6 seconds, or if I held 'a' for 4 seconds it would turn for 12, etc. So it's a lot better.
With some text windows I receive the same repeating error with it set to true, such as this text window. Although when I do the same process in say gnome-terminal, there is no repeating issue. It just works.
And to clarify, the keyboard response isn't delayed anymore. If I hit 'd' to turn right, it registers right away, All keys register right a way as it should, I just seem to be getting an application slowdown when these keypresses occur. I have nothing else running and I have a dual core cpu, 3.0 Ghz. I don't think there's too much load on the cpu. That and the application doesn't slow down with it set to false, or with the old 3.1 package.
I'm hoping this can be fixed. But it seems to me that keystrokes are supposed to be registered in real time, and it almost seems like with queueing, the application or game is having to slow down to wait for the key responses. Again I do not understand what is being done with imsettings, but I'm just trying to explain my situation as best as I can.
If you release, Linux gamers will notice the issue, but they may think that it's their game or some new version of WINE or something, and not relate it to imsettings. It was only a miracle that I was able to figure out that this was the issue.
Good luck, let me know if you wish me to test anything else. I'm always happy to help improve the Linux environment. :)
Thank you for your explanation.
(In reply to comment #22)
> With some text windows I receive the same repeating error with it set to true,
> such as this text window. Although when I do the same process in say
> gnome-terminal, there is no repeating issue. It just works.
So you got a repeating error on both of setting true or false?
> If you release, Linux gamers will notice the issue, but they may think that
> it's their game or some new version of WINE or something, and not relate it to
> imsettings. It was only a miracle that I was able to figure out that this was
> the issue.
Not exactly. current situation is worst enough. people who uses Fedora 10 should be aware of the original issue. though there are still regression after applying an update.
> Good luck, let me know if you wish me to test anything else. I'm always happy
> to help improve the Linux environment. :)
Trying to improve for this issue now. hopefully I'll have another testing package shortly.
Another pre-testing package. hopefully it will be somewhat improved.
In reply to questions in comment 23:
> So you got a repeating error on both of setting true or false?
In the game application I no longer noticed a repeating error when set to true, but when in a text field like here on the comments page and set to true, I got the repeating error.
When set to false, it happened in the game and in the text field here on the comment field.
In reply to Comment 24:
I installed version 4. It seems work better, I noticed it won't repeat unless I hold it down for longer than 4 seconds, but I have one of those Northgate Omnikey keyboards that can deliver keystrokes pretty rapidly. This applies the comment field only.
In game, I do not notice the repeating error, but there's still slowdown. I did a Frames per second test. As I put my character on auto run with no key presses, he walks and the frames are at 40 frames per second. But when I turn off autorun and hit 'w' to move forward and walk manually with a key press, the frames drop down to 15 fps. I have no other programs running. I have 4GB's of RAM, on a dual core. This did not happen before libgxim 3.2-4.
I did discover a new clue for you though. I did notice something interesting while in the gaming application. When running by keypress 'w' the frames would drop, but if I then hit 'a' to turn left at the same time while holding 'w' the frame slowdown ceased, and ran perfectly. So as soon as a second keystroke was entered at the same time the frames went back up to 40 fps. It only seemed to slow down when one keypress was held, but once a second is introduced, it works as intended.
This is with everything set to default, I will try it now set to false. and reply with any differences.
Results for version 4 set to false:
When I turn or move briefly by keystroke in the game applications, it doesn't repeat, it stops as intended and there isn't any slow down. If I hold the keystroke in long enough for the key repeating to start, then it gets stuck, but only for 2 to 2 and a half seconds. So if I hold 'w' in for 8 seconds, it only continues moving forward for 2 to 2 and a half seconds. Or if I hold 'a' to turn left, I get the same results.
Though being set to false it's not as bad as it was being set to false in the previous versions.
In a comment text field such as this one, the results are similar. Repeating keystroke 'd' for 1 and a half seconds repeats then stops when let go, but once I hold it in for 2 seconds it repeats for 2 more seconds after letting go.
These comments are results from setting to false.
The error ceases to exist in programs like xterm.
My final opinion on version 4. It seems to work well with sync set to true. Well enough to release anyway, I just don't know why the keyboard is taking up so much cpu usage for repeating. Seems like that shouldn't happen. Maybe it's just my keyboard. It's based off of the northgate omnikey 101, which is a heavy thing, with mechanical keys, and key repeating is a lot faster than on a normal keyboard.
I just wish that keying wouldn't slow down games in Linux. I know it doesn't happen in windows.
Well, because X throws key events as long as you keeps pressing and once released a key. imsettings-applet proceeds them through XIM protocol. it's impossible to take no CPU power to deal with them but possibly take less CPU power than it does now.
BTW can you file a bug for that separately? now original bug should be fixed in next push. I'll try to continue improving a performance with it.
imsettings-0.105.1-4.fc10 has been submitted as an update for Fedora 10.
imsettings-0.105.1-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update imsettings'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2843
imsettings-0.105.1-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.