Description of problem: NumLck default is re-set after logging in Version-Release number of selected component (if applicable): RHEL5 Beta2 CSB How reproducible: Every time Steps to Reproduce: 1. Log into T42 laptop 2. open any text based window (terminal, word processor, etc.) 3. type letters on the RHS of the keyboard - numerical values are displayed instead of characters Actual results: alphanumeric values are displayed instead letters Expected results: Letters! Additional info: T42 laptop. Snippet from IRC to describe the behavior. ronp_mtg Jeff: I'm getting a NumLk after logging into the platform - BZ or Trac? This is a T42 laptop jeff urm? jeff Not sure what you're saying. ronp_mtg After I log into my laptop, it appears that the NumLock key is all of a sudden set. For example: jeff That's a BIOS setting. ronp_mtg Hmm. Even after logging into the laptop? ronp_mtg I have the same Kerberos PW for the laptop and e-mail. jeff It's not set, then you log in and it gets set? ronp_mtg I can successfully log into the laptop. If I then try to access anything that requires the same, it gets garbled. ronp_mtg I tested this theory by logging into the laptop, opening a word processor, retype my password, and see the characters are replaced by numbers at the end of the PW. ronp_mtg If I hit a shift NumLock, then things are back to normal. jeff Well, the first thing I'd check is the BIOS numlock setting. ronp_mtg But shouldn't that also affect the initial login screen? jeff Hmm. Yeah. Now I see what you're saying.
Ray, Can you offer me a patch for this progressively annoying bug? If I use caps lock, I then need to use shift+numlck to unlock several keys. I then have to do the same *again* after taking caps lock off.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Since this bugzilla is in a component that is not approved for the current release, it has been closed with resolution deferred. You may reopen this bugzilla for consideration in the next release.
Uggghhh. This affects a wide array of ThinkPads: T41, T40, T60, etc. Someone should consider documenting the work-around so that people have a clue as to what is going on here and have 1/2 chance of staying productive with their laptops when they undock or re-dock a system, or when they boot un-docked. To be clear, this problem has nothing to do with docking stations themselves since this bug is clearly visible when booting without being docked, too.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
So which version of RHEl5, if any, do we plan on addressing this?
proposing for 5.3
Ronald, any reaction to comment 15?
I am still having this problem with Fedora 12 with an external USB Thinkpad keyboard.
Warren, please open a separate bug for the F12 issue. The X server input code between RHEL 5.4 and F12 has changed a lot.