kernel-packages team mailing list archive

[matteo sisti sette <1250186@xxxxxxxxxxxxxxxxxx>]

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

** Tags added: kernel-unable-to-test-upstream

-- 
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:
  "caps lock" state feedback is not sent to keyboard led when plugged
  (NumLock IS, which is ok). Neither CapsLock nor NumLock feedback is
  sent to led when state changes (e.g. by other keyboard)

Status in “linux” package in Ubuntu:
  Incomplete

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