Bug 409791

This bug still exists in the F9 Beta.  I've heard grumblings from others I know
running various distributions that this bug exists for them, so it's likely an
upstream issue and not Fedora specific.

I can't find any bugs in the fd.o or gnome.org bugzillas for this.

Now logged upstream on freedesktop.org.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Seems to be fixed in

xorg-x11-server-Xorg-1.4.99.906-5.fc10.i386

Sigh, broken again in

xorg-x11-server-Xorg-1.5.0-6.fc10.x86_64

Just tried with 1.5.0-6 and 1.5.1-4 and both work fine for me.

Please run xkbcomp -xkb :0 out.xkb and attach the out.xkb file to this bugreport.
Also, please attach the output of xev when hitting caps, ctrl and alt (in a sequence, not all at the same time). Thanks.

The key marked Caps Lock (which is mapped to Control, but is still incorrectly
toggling the LED) gives

KeyPress event, serial 27, synthetic NO, window 0x6e00001,
    root 0x7a, subw 0x0, time 184966155, (121,44), root:(251,117),
    state 0x0, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False


The key marked Ctrl (which is mapped to CapsLock but does not toggle the LED)
gives

KeyPress event, serial 27, synthetic NO, window 0x6e00001,
    root 0x7a, subw 0x0, time 185018186, (80,117), root:(210,190),
    state 0x0, keycode 37 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False


The ALT key gives:

KeyPress event, serial 27, synthetic NO, window 0x6e00001,
    root 0x7a, subw 0x0, time 185051458, (155,132), root:(285,205),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Created attachment 318171 [details]
Output of xkbcomp -xkb :0 out.xkb as requested


Incidently, I've recently switched from i386 to x86-64, will check to see if
that is what has caused the regressio

Two reboots later, i386 v. x86-64 is indeed making the difference.

xorg-x11-server-Xorg-1.5.0-6.fc10.x86_64 on 2.6.27-0.352.rc7.git1.fc10.x86_64 does have the problem.

xorg-x11-server-Xorg-1.5.0-6.fc10.i386 on 2.6.27-0.352.rc7.git1.fc10.i686 does not have the problem.

Has it ever worked on x86-64? Just so we can narrow down the search-range.

I've only just switched to x86-64, so I don't know if it has ever worked there.

Now it's working for me on x86-64 also, with xorg-x11-server-Xorg-1.5.1-4.fc10.x86_64 ...

So either it's been fixed or it's something wierd environmental thingie.

Marking as closed.

Broken again.

Symptoms are slightly different now; both keys are attempting to set the caps-lock state.

I added a minimal patch to evdev to print what is actually handed to the driver. Can you please install this file and attach the Xorg.log after hitting caps lock.

http://koji.fedoraproject.org/scratch/whot/task_889822/

That should give us a hint for the LED issue at least.

Peter, I suspect current breakage is just another symptom of 467539 / 467636 so I'll wait for those fixes to come through and see if they resolve this too.

For the time until the update trickles down, both bugs can be avoided by having a config file, even an empty one should do. I'll leave the NEEDINFO flag until you get a chance to test the evdev patch.

Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

Sorry for not replying earlier.

Current X is just fine again.

Cheers,
Ralph.