Keyboard input missing after today's Fedora (ver .10) update

[jannom]

Hello

I applied all today's patches (18 of them) and Fedora asked me to log out/log on after the completion of update.
But after logon, in 2 programs (KeePassX and Oracles Sql Developer) there is not possible to use keyboard! Mouse is still functioning within them, but not keyboard. No ENTER, no arrow keys, no characters.

Has anyone else encountered same problems with todays updates and how to fix it?

Janno

[jannom]

Seems like thing called SCIM has appeared (with today's update?) in my system and now trying to manage keyboard input-system.
After I disabled it

System → Preferences → Personal → Input Method to enable or disable SCIM

then KeepassX resumed its normal work, I mean, I can use keyboard with it now. But in SQL Developer, only characyter keys function (at least that is better then previously, when nothing accepted input), but not ENTER or arrow-keys.

Should I completle uninstall SCIM to resume normal work with keyboard?

[kldixon]

You are not alone. xemacs has completely lost keyboard focus since a recent update. I am just now investigating your suggestions on SCIM.

[kldixon]

Well this is rather bizarre. The input method was not enabled so I tried enabling it but no joy. So I disabled it again and now xemacs seems to get keyboard focus, but not reliably. After working a bit everything seems to map to down.

[Muspellsson]

I have problem with keyboard in SDL apps

[kldixon]

Ok, that seems to be because the keyboard buffer is not being flushed when it should be.

[jmvidal]

I figured out one way to get xemacs working (for me)

1- System->preferences->personal->input method
there click on "enable input method feature" and
"Show the status icon"
then click OK
2- An icon will show up in the task bar. Click on this icon to "disconnect from the SCIM"

now xemacs works.

[kldixon]

Looking though my yum log nothing with scim has been updated for a while. Personally I suspect xorg-x11-drv-evdev-2.1.3-1.fc10.i386 or xorg-x11-drv-vmmouse-12.6.3-3.fc10.i386

[kldixon]

jmvidal, have you tried filling the keyboard buffer? Just keep your finger on the down arrow key until the cursor reaches the bottom of the buffer and then hold it for a few seconds longer.

[jmvidal]

jmvidal, have you tried filling the keyboard buffer? Just keep your finger on the down arrow key until the cursor reaches the bottom of the buffer and then hold it for a few seconds longer.

Not sure what you mean by this.

I turned clicked on the icon to "connect to input method". If I then go to a terminal window and press the down key I just get beeping from the computer. If I go to the xemacs window and press and hold the down key, nothing happens.

[kldixon]

Do your cursor keys still work in the xemacs window?

[jmvidal]

Do your cursor keys still work in the xemacs window?

Yes, the arrow keys still work.

Also, something just happened (I think I tried to maximize xemacs) where the IM chooser died (the icon is gone) and I had to kill xemacs because it disappeared. I restarted xemacs and it still gets keyboard input, but the IM chooser has "Enable input methos feature" NOT enabled.

[jannom]

I grepped through my log and found this :

# grep -i scim yum.log
Jan 13 11:21:04 Updated: scim-chewing-0.3.3-0.fc10.i386
Feb 03 12:37:56 Updated: scim-anthy-1.2.7-1.fc10.i386

so, today "scim-anthy-1.2.7-1.fc10.i386" got updated. Maybe that is the culprit.

And still my arrow keys and ENTER does not function in Sql Developer, although I tried several SCIM configurations.

Jmvidal, what do you mean by "disconnect from the SCIM"?

[jannom]

Sorry! today is not Feb 3, but already March.
So, that log-trace does not give us much.

[kldixon]

When I did what you suggested in post #7 and xemacs seemed to work I scrolled down to the bottom of a directory buffer in xemacs using the down arrow key and then tried to move back up with the up arrow but the cursor did not move. So I positioned the cursor with the mouse and thereafter any keystroke just moved the cursor down. My hypothesis in comment #6 was that the keyboard buffer was not flushed when the cursor hit the bottom of the xemacs buffer and so was full of down characters which were read whenever a keyboard event was seen by xemacs.