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
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1250186 Title: Neither CapsLock nor NumLock feedback is sent to led when state changes (e.g. by other keyboard) Status in linux package in Ubuntu: Confirmed Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1250186/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
