Could not switch uppercase/lowercase by using keyboard of laptop

Bug #1988023 reported by shangsong
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

1. Fresh install ubuntu server 22.04.1 on Lenovo server.
2. Install console-data package
3. Get locale status:
# localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: n/a
      X11 Layout: us
       X11 Model: pc105
4. Fail to ist and set keymap with command "localectl", but the kmap file can be found in the /usr/share./keymaps/
#localectl list-keymaps
Failed to read list of keymaps: No such file or directory
# localectl set-keymap us
Failed to set keymap: Keymap us is not installed.
# find /usr/ -name us.kmap.gz
/usr/share/keymaps/i386/qwerty/us.kmap.gz
5. It need type "CapsLock" twice when want to switch uppercase/lowercase by using keyboard of laptop, not once, the other keyboard has no issue about it.
# dumpkeys | grep -E "keymaps|58"
keymaps 0-127
keycode 58 = CtrlL_Lock
6. It can switch uppercase/lowercase normally after run command "loadkeys us".

Please help check why need type twice "CapsLock" for switching uppercase/lowercase and how to fix it.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: pass
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2022-08-29 (0 days ago)
InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809)
MachineType: Lenovo ThinkSystem SR630 V2
Package: systemd 249.11-0ubuntu3.4
PackageArchitecture: amd64
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.15.0-43-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
ProcVersionSignature: Ubuntu 5.15.0-43.46-generic 5.15.39
SystemdFailedUnits:
 Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?).
 Unit \xe2\x97\x8f.service could not be found.
Tags: jammy uec-images
Uname: Linux 5.15.0-43-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 04/21/2022
dmi.bios.release: 1.30
dmi.bios.vendor: Lenovo
dmi.bios.version: AFE118I-1.30
dmi.board.asset.tag: none
dmi.board.name: 7Z70CTO1WW
dmi.board.vendor: Lenovo
dmi.board.version: 05
dmi.chassis.asset.tag: none
dmi.chassis.type: 23
dmi.chassis.vendor: Lenovo
dmi.chassis.version: none
dmi.ec.firmware.release: 1.80
dmi.modalias: dmi:bvnLenovo:bvrAFE118I-1.30:bd04/21/2022:br1.30:efr1.80:svnLenovo:pnThinkSystemSR630V2:pvr05:rvnLenovo:rn7Z70CTO1WW:rvr05:cvnLenovo:ct23:cvrnone:sku7Z70CTO1WW:
dmi.product.family: ThinkSystem
dmi.product.name: ThinkSystem SR630 V2
dmi.product.sku: 7Z70CTO1WW
dmi.product.version: 05
dmi.sys.vendor: Lenovo

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1988023

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
shangsong (shangsong2)
affects: linux (Ubuntu) → systemd (Ubuntu)
Changed in systemd (Ubuntu):
status: Incomplete → New
Revision history for this message
shangsong (shangsong2) wrote : CurrentDmesg.txt

apport information

tags: added: apport-collected jammy uec-images
description: updated
Revision history for this message
shangsong (shangsong2) wrote : Dependencies.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : Lspci.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : Lspci-vt.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : Lsusb.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : Lsusb-t.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : Lsusb-v.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : ProcInterrupts.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : ProcModules.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : SystemdDelta.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : UdevDb.txt

apport information

Revision history for this message
shangsong (shangsong2) wrote : acpidump.txt

apport information

Revision history for this message
Jeff Lane  (bladernr) wrote :

Questions/Comments:
What does "remotely" mean here? The bug report speaks of using the laptop
keyboard, not remote access; and a remote connection would mean just passing
a data stream - the local keymap setting has no effect on the keys sent by a
remote connection.

localectl is not how we manage keyboard settings in Ubuntu, and console-data
is a package in universe that we don't use at all. If you need to change
the keymap, this should be done with `sudo dpkg-reconfigure
keyboard-configuration`. localectl may or may not do the right thing, it's
basically untested. Regardless, capslock or shift not working correctly
should not be a question of keymap, there are no keymaps we ship by default
that don't handle these keys in the normal way. Perhaps this is a kernel or
issue or a bug with their ACPI tables?

Revision history for this message
shangsong (shangsong2) wrote :

Hi Jeff,
  We use lenovo XClarity Controller(XCC) web to access server/OS remotely. The lower/higher kernel version is reproduce, so this is not kernel issue. With the same environment, RedHat does not reproduce the issue, so this should also not be a ACPI bug.

  With the command "dumpkeys", RedHat return "Caps_Lock" for the keycode 58 by default, but ubuntu return "CtrlL_Lock", maybe this is the reason why RedHat cannot reproduce. Hope it is usable for debugging.

Revision history for this message
shangsong (shangsong2) wrote :

Hi Jeff,
  This should be relate to an kernel issue(https://bugzilla.kernel.org/show_bug.cgi?id=7746) which has been fixed. The other linux vendor has already solution for the Caps_Lock/CtrlL_Lock issue now:

https://git.powerel.org/powerel7/base/src/commit/2cda77266d4e43b958393a16f4ec0632daa1ac0c/SOURCES/us-map.patch
https://unix.stackexchange.com/questions/136817/caps-lock-led-not-working-on-linux-console
https://bugzilla.redhat.com/show_bug.cgi?id=1586149

Please help push the fix it, thanks.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

Re-assigning since it sounds like this is not a systemd issue.

affects: systemd (Ubuntu) → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Jeff Lane  (bladernr) wrote :

I was finally able to recreate this from a Jammy VM on my Macbook. Steps to recreate:

In Jammy open browser and connect to a Lenovo XCC (BMC)
Log in and launch the remote console.
type some characters (anywhere works, I did this in the login: prompt on the ubuntu install
** chars will be all lower case
tap the caps lock and type chars
** chars will be all lower case
double tap the caps lock key (you have to hit it twice) fairly quickly
** chars are now upper case when typed
single tap the caps lock key
** chars remain upper case when typed
double tap the caps lock key
** chars are once again lower case when typed.

It gets weirder because I can get to a point where the caps lock light is off, but the chars are all upper case, or where the caps lock light is on but the chars are all lower case.

I was also able to recreate this against a Dell iDRAC console, though in that case once I managed to get the letters in all caps, I could not get caps lock back off again.

Finally, I tried this against an HPE iLO5. I was not able to reproduce this issue against the iLO5 device.

So all in all I was able to reproduce this issue on 4 different servers (3 Lenovo, 1 Dell) and unable on 1 server (HPE)

I then tried this on my desktop and was also able to reproduce this (perhaps in hte past I was just failing to properly set it up? )

from my desktop, this is how it went:

open XCC remote console
Caps Lock Light Off: type some chars -- all lowercase
Hit Caps Lock Key
Caps Lock Light On: type some chars -- all lower case
Hit Caps Lock Key
Caps Lock Light Off: type some chars -- all upper case
Hit Caps Lock Key
Caps Lock Light On: type some chars -- all upper case
Hit Caps Lock Key
Caps Lock Light Off: type some chars -- all lower case again.

Revision history for this message
Jeff Lane  (bladernr) wrote :

so that said, I still don't know where the issue is... I suspect this will likely never be fixed...

When when you say:

# dumpkeys | grep -E "keymaps|58"
keymaps 0-127
keycode 58 = CtrlL_Lock
6. It can switch uppercase/lowercase normally after run command "loadkeys us".

where do you run that command? On the laptop, or on the remote machine via the xcc console? In other words, where are you changing the keymap?

Revision history for this message
shangsong (shangsong2) wrote :

6. It can switch uppercase/lowercase normally after run command "loadkeys us".

where do you run that command? On the laptop, or on the remote machine via the xcc console? In other words, where are you changing the keymap?

The detail steps is below:
1. Install package console-data(This is necessary);
2. Run the command "loadkeys us" at any console(No matter laptop, xcc console, or any shell console)
3. At this time, it can switch uppercase/lowercase normally via xcc console. You also can aware of the change via the output of command 'dumpkeys | grep -E "keymaps|58"', the previous keycode58 is from CtrlL_Lock to Caps_Lock.

You also can get the reproduce environment via command "loadkeys cz"

Revision history for this message
shangsong (shangsong2) wrote :

Hi Jeff,
  Any progress for this issue?

Revision history for this message
Jeff Lane  (bladernr) wrote :

Still no update, it's apparently a very low priority to be looked at.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.