Neither CapsLock nor NumLock feedback is sent to led when state changes (e.g. by other keyboard)

[Teo]

Steps to reproduce:
- plug a usb keyboard
- Lock caps. Type something in uppercase. The keyboard caps lock led is on
- unplug keyboard
- replug keyboard
- type something
- then hit the caps lock key again and type

Expected: any of these would be correct:
- either A) the keyboard caps lock led turns on when plugging the keyboard, and what you type is uppercase
- or B) the keyboard led is systematically off after replugging the keyboard and what you type is lowercase
Then, after hitting Caps Lock again, the status of the led should keep consistent with the actual status, that is, if the led is on, you type uppercase, and if it's off, you type lowercase.

Observed:
After replugging, The keyboard led is off but what you type is uppercase.
Then, after hitting Caps Lock, the led turns on (indicating caps lock is on) but what you type is lowercase. The status stays inverted.

That is, the system remembers caps lock status after unplugging and replugging a keyboard, though no feedback is sent to the keyboard; the keyboard's led status is reset but the system's caps lock status is preserved, so it becomes inconsistent. Every stroke of the Caps Lock key just toggles both the led and the real typing status, which remain inconsistent.

Additionally, if the computer is a laptop, both keyboards share the same caps lock actual status (meaning hitting Caps lock in one of them will affect typing on both) but the external keyboard's led is only toggled when the external keyboard's own caps lock key is hit - that is, if you use both keyboards' caps lock keys, you get inconsistency between what is shown on the led and what is the real status.

Demonstration that this is an issue in the OS and not in the keyboard:
NUM LOCK BEHAVES DIFFERENTLY, AND ALMOST AS EXPECTED, and I strongly doubt Caps Lock and NumLock are different at low level.

Num lock status is remembered AND sent back to the keyboard led when reconnected (so feedback IS possible for NumLock and is done correctly on replugging).
However, numlock status feedback is not sent to external keyboard (not correctly at least) when changing numlock status. It is only sent when connecting. So, consistency can be lost if using multiple keyboards, and it does not get fixed the next time you strike numlock.

That is:
- boot and plug the keyboard (or boot with the keyboard plugged; result is the same)
- try numeric keyboard
=> result: numlock status is remembered from the last boot and is displayed consistently on led.
- hit numlock on external keyboard
=> result: status is toggled and consistently shown on led
- hit the numlock key as many times as needed on external keyboard to turn num lock on
- unplug keyboard
- replug keyboard
- try numeric keys
=> behaves as ON; displayed as ON on led
- turn it off
- unplug/replug keyboard
=> behaves as OFF, displayed as OFF. Everything's fine
- hit the numlock key on the built-in keyboard
- try numeric keys on external keyboard
=> behaves as OFF; still displayed as ON. FAIL!
- unplug/replug external keyboard
=> still behaves as OFF, now displayed as OFF. Consistency recovered!

So, NumLock behavior is better than CapsLock behavior, but still not completely correct.
It demosntrates that the OS CAN do what is needed to maintain consistency between led status and internal status, so the OS SHOULD do that.

Unless numlock and capslock work differently at the hardware level, this should be fixed for Caps Lock too

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-32-generic 3.8.0-32.47
ProcVersionSignature: Ubuntu 3.8.0-32.47-generic 3.8.13.10
Uname: Linux 3.8.0-32-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: teo 2191 F.... pulseaudio
Date: Mon Nov 11 19:18:12 2013
HibernationDevice: RESUME=UUID=ff7e702a-a05a-47fd-8c14-551e81f9e9e3
InstallationDate: Installed on 2013-10-11 (31 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Acer Aspire V3-571G
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-32-generic root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-32-generic N/A
 linux-backports-modules-3.8.0-32-generic N/A
 linux-firmware 1.106
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/15/2012
dmi.bios.vendor: Acer
dmi.bios.version: V2.07
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: VA50_HC_CR
dmi.board.vendor: Acer
dmi.board.version: Type2 - Board Version
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: V2.07
dmi.modalias: dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07:
dmi.product.name: Aspire V3-571G
dmi.product.version: V2.07
dmi.sys.vendor: Acer

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.12 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/

[Teo (teo1978)]

No, sorry, it would not be possible for me to test the latest upstream kernel.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Teo (teo1978)]

The "caps lock state feedback is not sent to keyboard led when plugged." part is now fixed on 13.10.

But now NumLock, which used to work, is screwed up. Great.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284342

The "Neither CapsLock nor NumLock feedback is sent to led when state changes (e.g. by other keyboard)" part remains. Which actually provides a workaround for 1284342 right now.

Bug 1284342 tracks the NumLock regression.
If this one is going to track the missing-feadback-for-both-capslock-and-numlock issue, then here's the expected behavior:
EITHER numlock and capslock status feedback should propagate to ALL connected keyboards when it changes,
OR each keyboard should have its individual numlock and capslock state, independent of other keyboards, so that, even if the feedback does not propagate to other keyboards, the status shown on the led would always be consistent with the actual behavior.

[Brad Figg (brad-figg)]

This change was made by a bot.

[TRToC (trtoc)]

This behavior appears for me using XUbuntu 16.04 after unlocking the screen with Intel graphics.
Like the recently fixed bug where the mouse cursor disappears after unlocking, I observed a similar behavior to the num lock and caps lock key leds described in this bug report.
After unlocking you have to press the num lock OR(!) caps lock key twice to get the leds back in the correct state.
related bug:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604