Bug 447210 - Typing username after reboot causes a (related?) number to repeart-keypress
Typing username after reboot causes a (related?) number to repeart-keypress
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 16:23 EDT by Kevin R. Page
Modified: 2015-01-14 18:21 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 16:13:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin R. Page 2008-05-18 16:23:37 EDT
Description of problem:

An upgraded machine from F8 -> F9.

The users are used to typing their username rather than using the face chooser. 

When F9 has finished booting, I go to type a username - but the first keypress
doesn't display the letter pressed, instead it displays a number and then after
a short pause this number continues to autorepeat until a further key is pressed.

e.g. when 'a' is pressed, '2' is printed, then autorepeats. When 'k' is pressed,
'4' is printed and autorepeats.

When a second key is pressed is appears correctly, i.e. if you enter several
letters quickly only the first is replaced by a number - the second key is
pressed before the number autorepeats.

Keyboard is a PS/2 "Microsoft Internet".

LANG is en_GB.utf8

If I switch VT to a text login: when ctrl is pressed 'w' appears in GDM; alt and
F1 can be pressed and it'll still switch VT. At the text login keys appear as
pressed. On switching back to GDM it works fine.

So it seems like something is eating the first keypress and munging it?


Version-Release number of selected component (if applicable):
gdm-2.22.0-1.fc9

How reproducible:
Always
Comment 1 Ray Strode [halfline] 2008-05-18 18:05:47 EDT
So just to make sure that I understand one part of your problem, if you switch
to a text vt and press ctrl, then switch back to GDM's vt, a w appears?
Comment 2 Kevin R. Page 2008-05-19 03:16:40 EDT
(In reply to comment #1)
> So just to make sure that I understand one part of your problem, if you switch
> to a text vt and press ctrl, then switch back to GDM's vt, a w appears?

PC is freshly booted up.
Press and hold Ctrl: GDM's username textbox appears with a "w" in it
Also press and hold Alt, then add F1: switches to text vt as it should

The w appears before the vt switch. I guess because Ctrl is held down the
subsequent Ctrl repeat stops the weird auto-repeat of (in this case) w, and
means that a Ctrl is passed through to work with the Alt-F1.

i.e. the first keypress always seems to be incorrectly interpreted. Everything
after the first keypress seems ok, including when switching back to GDM's vt.

(I didn't try changing the default runlevel to 3 and checking the first keypress
is ok at text login; I can get access to the PC and try that later if it would
be informative)
Comment 3 Kevin R. Page 2008-05-19 09:22:45 EDT
> (I didn't try changing the default runlevel to 3 and checking the first keypress
> is ok at text login)

I changed inittab to boot to runlevel 3; the first (and subsequent) key press at
text login appears as it should (i.e. not munged into a number). Logging in on
this text console and issuing telinit 5 starts up GDM: this GDM also works fine.
It seems only GDM starting straight into runlevel 5 is affected.
Comment 4 Kevin R. Page 2008-05-19 16:13:51 EDT
I'm utterly perplexed: turning the PC on tonight and the problem isn't happening.

(There were numerous updates after install, but confirming this required reboots
after they'd installed; I gave everything a good wiggle/thump to check hardware;
I can't think of anything that would've been changed by my earlier runlevel
shenanigans or daily system cronjobs. I'm completely puzzled.)

Note You need to log in before you can comment on or make changes to this bug.