Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Keyboard Caps Lock LED status is incorrect after rebooting to UEFI with Caps Lock LED ON #633

Closed
1 task done
wenbhou opened this issue Feb 18, 2025 · 0 comments · Fixed by #632
Closed
1 task done
Labels
state:needs-triage Needs to triaged to determine next steps type:bug Something isn't working urgency:high Significant with a critical impact

Comments

@wenbhou
Copy link
Contributor

wenbhou commented Feb 18, 2025

Is there an existing issue for this?

  • I have searched existing issues

Current Behavior

When the system is rebooted to UEFI with the Caps Lock LED turned on, the LED status does not reflect the actual state of the Caps Lock key. The Caps Lock LED remains on, but the keyboard input produces lower-case characters. This causes confusion for users who rely on the LED indicator to determine the state of the Caps Lock key.

Expected Behavior

The Caps Lock LED should accurately reflect the state of the Caps Lock key in UEFI.

Steps To Reproduce

  1. Turn on the Caps Lock key, ensuring the Caps Lock LED is illuminated.
  2. Reboot the system and enter UEFI.
  3. Observe that the Caps Lock LED remains on, but the keyboard input produces lower-case characters.

Build Environment

- OS(s):Windows 11
- Tool Chain(s):VS2022
- Targets Impacted:ALL

Version Information

eccbb05f3e4295a1b343b787f86b326c2df9d56c

Urgency

High

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

@wenbhou wenbhou added state:needs-triage Needs to triaged to determine next steps type:bug Something isn't working labels Feb 18, 2025
@github-actions github-actions bot added the urgency:high Significant with a critical impact label Feb 18, 2025
ProjectMuBot pushed a commit that referenced this issue Feb 18, 2025
## Description

Fixes #633

Reset the keyboard to default state during initialization in order to
make sure the LED status on keyboard is determined.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
- [x] Backport to release branch?

## How This Was Tested

Tested on Surface Laptop and Surface Pro, all keyboard LEDs are turned
off when booting to the UEFI front page.
No regressions observed.

## Integration Instructions

N/A
makubacki pushed a commit to makubacki/mu_plus that referenced this issue Feb 18, 2025
Fixes microsoft#633

Reset the keyboard to default state during initialization in order to
make sure the LED status on keyboard is determined.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
- [x] Backport to release branch?

Tested on Surface Laptop and Surface Pro, all keyboard LEDs are turned
off when booting to the UEFI front page.
No regressions observed.

N/A

(cherry picked from commit f55d046)
makubacki pushed a commit that referenced this issue Feb 18, 2025
Fixes #633

Reset the keyboard to default state during initialization in order to
make sure the LED status on keyboard is determined.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
- [x] Backport to release branch?

Tested on Surface Laptop and Surface Pro, all keyboard LEDs are turned
off when booting to the UEFI front page.
No regressions observed.

N/A

(cherry picked from commit f55d046)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state:needs-triage Needs to triaged to determine next steps type:bug Something isn't working urgency:high Significant with a critical impact
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant