Description of problem: Hitting the 'Print Screen' key on my keyboard results in a Metacity popup box that says "No command 33 has been defined." Version-Release number of selected component (if applicable): metacity-2.25.34-1.fc11 also occurs in metacity-2.25.8-4.fc11 How reproducible: every time Actual results: pop up box with warning Expected results: should take me to the screen shot window
Annoyingly, I also get this with the "up" arrow on my Lenovo T60. metacity-2.25.55-1.fc11.x86_64
(In reply to comment #1) > Annoyingly, I also get this with the "up" arrow on my Lenovo T60. > > metacity-2.25.55-1.fc11.x86_64 Reverting to metacity-2.25.34-1.fc11 fixes it.
Reverting to metacity-2.25.34-1.fc11.x86_64 didn't work for me. All my "inverted T" arrow keys are broken, but just "Up" opens the "No command 33 ..." message.
(In reply to comment #3) > Reverting to metacity-2.25.34-1.fc11.x86_64 didn't work for me. > > > All my "inverted T" arrow keys are broken, but just "Up" opens the "No command > 33 ..." message. I had to kill the running metacity process after doing the rpm downgrade, to start the old one.
Weird. I tried again: After downgrading the rpm and leaving X I looked for any running metacity processes, there weren't any. To be sure, I rebooted, but metacity-2.25.34-1.fc11.x86_64 still gives me "No command 33...." for "Up" arrow. As does metacity-2.25.55-1.fc11.x86_64. I have a Logitech USB keyboard which is being recognized as a "BTC USB Multimedia Keyboard" Does that sound right? (II) XINPUT: Adding extended input device "BTC USB Multimedia Keyboard" (type: K EYBOARD) (**) Option "xkb_rules" "evdev" (**) BTC USB Multimedia Keyboard: xkb_rules: "evdev" (**) Option "xkb_model" "pc105+inet"
My arrow keys are being recognized normally by bash in a ctrl-alt-2 console.
Seems to be fixed today!?! Still using metacity-2.25.55-1.fc11.x86_64 Perhaps this was fixed by the Xorg-x11-server updates?
Created attachment 327820 [details] Re-add some missing defaults The xorg update would have fixed the up arrow problem. I don't think the command 33 issue here is related. I think this patch will fix it, at least temporarily until upstream figures what to do about it.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The missing defaults bug that was the problem here was fixed sometime between 2.25.55 and 2.25.89. that is before the Fedora 11 release which has 2.26.0. Closing.