Linux console: All keyboard input is preceded by “^[â€
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
After coming back from laptop hibernation, my Fedora 27 has gone into a weird state whereby:
- On the graphical console, no input is accepted, even mouse activity
is disregarded - On the text console, any keyboard input is preceded
by '^[' (would that be CTRL+'1 character past Z'?). So when I want to
log in, I see^[r^[o^[o^[tand oncelogintimes out waiting for input,
it is game over: No more input. Capslock LED is inactive, Numlock LED is
active.
I remember seeing this on a boot screen of a Sun SPARCstation in the 90s...
What is going exactly and how can I fix it (except reboot the machine)?
Edit: This has been a "once-only" occurrence on the machine in question. After a reboot, the problem is gone. It might be due to a hardware glitch or any random bug. Although if it is due to an extra special mode of the terminal I/O, one would like to know more.
linux login
asked Mar 7 at 13:39
David Tonhofer
487415
add a comment |Â
up vote
1
down vote
favorite
After coming back from laptop hibernation, my Fedora 27 has gone into a weird state whereby:
- On the graphical console, no input is accepted, even mouse activity
is disregarded - On the text console, any keyboard input is preceded
by '^[' (would that be CTRL+'1 character past Z'?). So when I want to
log in, I see^[r^[o^[o^[tand oncelogintimes out waiting for input,
it is game over: No more input. Capslock LED is inactive, Numlock LED is
active.
I remember seeing this on a boot screen of a Sun SPARCstation in the 90s...
What is going exactly and how can I fix it (except reboot the machine)?
Edit: This has been a "once-only" occurrence on the machine in question. After a reboot, the problem is gone. It might be due to a hardware glitch or any random bug. Although if it is due to an extra special mode of the terminal I/O, one would like to know more.
linux login
asked Mar 7 at 13:39
David Tonhofer
487415
^[is the control code for the Esc key. I have seen similar posts, with^@(the null character), but both are hard to Google.
– muru
Mar 7 at 13:57
1
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
1
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
After coming back from laptop hibernation, my Fedora 27 has gone into a weird state whereby:
- On the graphical console, no input is accepted, even mouse activity
is disregarded - On the text console, any keyboard input is preceded
by '^[' (would that be CTRL+'1 character past Z'?). So when I want to
log in, I see^[r^[o^[o^[tand oncelogintimes out waiting for input,
it is game over: No more input. Capslock LED is inactive, Numlock LED is
active.
I remember seeing this on a boot screen of a Sun SPARCstation in the 90s...
What is going exactly and how can I fix it (except reboot the machine)?
Edit: This has been a "once-only" occurrence on the machine in question. After a reboot, the problem is gone. It might be due to a hardware glitch or any random bug. Although if it is due to an extra special mode of the terminal I/O, one would like to know more.
linux login
asked Mar 7 at 13:39
David Tonhofer
487415
After coming back from laptop hibernation, my Fedora 27 has gone into a weird state whereby:
- On the graphical console, no input is accepted, even mouse activity
is disregarded - On the text console, any keyboard input is preceded
by '^[' (would that be CTRL+'1 character past Z'?). So when I want to
log in, I see^[r^[o^[o^[tand oncelogintimes out waiting for input,
it is game over: No more input. Capslock LED is inactive, Numlock LED is
active.
I remember seeing this on a boot screen of a Sun SPARCstation in the 90s...
What is going exactly and how can I fix it (except reboot the machine)?
Edit: This has been a "once-only" occurrence on the machine in question. After a reboot, the problem is gone. It might be due to a hardware glitch or any random bug. Although if it is due to an extra special mode of the terminal I/O, one would like to know more.
linux login
asked Mar 7 at 13:39
David Tonhofer
487415
edited Mar 7 at 16:26
asked Mar 7 at 13:39
David Tonhofer
487415
asked Mar 7 at 13:39
David Tonhofer
487415
asked Mar 7 at 13:39
David Tonhofer
487415
487415
^[is the control code for the Esc key. I have seen similar posts, with^@(the null character), but both are hard to Google.
– muru
Mar 7 at 13:57
1
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
1
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50
add a comment |Â
^[is the control code for the Esc key. I have seen similar posts, with^@(the null character), but both are hard to Google.
– muru
Mar 7 at 13:57
1
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
1
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50
^[ is the control code for the Esc key. I have seen similar posts, with ^@ (the null character), but both are hard to Google.– muru
Mar 7 at 13:57
^[ is the control code for the Esc key. I have seen similar posts, with ^@ (the null character), but both are hard to Google.– muru
Mar 7 at 13:57
1
1
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
1
1
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.
A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)
A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.
Further reading
- https://unix.stackexchange.com/a/333922/5132
- https://superuser.com/a/723442/38062
- https://superuser.com/questions/428641/
- https://unix.stackexchange.com/a/391968/5132
- How to force release of a keyboard modifiers
- https://superuser.com/questions/956049/
answered Mar 7 at 21:37
JdeBP
28.3k459133
Very astute observation (although the terminal emulator is likely not in-kernel, isn't itagettywhat is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.
– David Tonhofer
Mar 8 at 18:39
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.
A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)
A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.
Further reading
- https://unix.stackexchange.com/a/333922/5132
- https://superuser.com/a/723442/38062
- https://superuser.com/questions/428641/
- https://unix.stackexchange.com/a/391968/5132
- How to force release of a keyboard modifiers
- https://superuser.com/questions/956049/
answered Mar 7 at 21:37
JdeBP
28.3k459133
Very astute observation (although the terminal emulator is likely not in-kernel, isn't itagettywhat is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.
– David Tonhofer
Mar 8 at 18:39
add a comment |Â
up vote
3
down vote
accepted
The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.
A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)
A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.
Further reading
- https://unix.stackexchange.com/a/333922/5132
- https://superuser.com/a/723442/38062
- https://superuser.com/questions/428641/
- https://unix.stackexchange.com/a/391968/5132
- How to force release of a keyboard modifiers
- https://superuser.com/questions/956049/
answered Mar 7 at 21:37
JdeBP
28.3k459133
Very astute observation (although the terminal emulator is likely not in-kernel, isn't itagettywhat is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.
– David Tonhofer
Mar 8 at 18:39
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.
A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)
A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.
Further reading
- https://unix.stackexchange.com/a/333922/5132
- https://superuser.com/a/723442/38062
- https://superuser.com/questions/428641/
- https://unix.stackexchange.com/a/391968/5132
- How to force release of a keyboard modifiers
- https://superuser.com/questions/956049/
answered Mar 7 at 21:37
JdeBP
28.3k459133
The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.
A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)
A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.
Further reading
- https://unix.stackexchange.com/a/333922/5132
- https://superuser.com/a/723442/38062
- https://superuser.com/questions/428641/
- https://unix.stackexchange.com/a/391968/5132
- How to force release of a keyboard modifiers
- https://superuser.com/questions/956049/
answered Mar 7 at 21:37
JdeBP
28.3k459133
edited Mar 8 at 20:33
answered Mar 7 at 21:37
JdeBP
28.3k459133
answered Mar 7 at 21:37
JdeBP
28.3k459133
answered Mar 7 at 21:37
JdeBP
28.3k459133
28.3k459133
Very astute observation (although the terminal emulator is likely not in-kernel, isn't itagettywhat is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.
– David Tonhofer
Mar 8 at 18:39
add a comment |Â
Very astute observation (although the terminal emulator is likely not in-kernel, isn't itagettywhat is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.
– David Tonhofer
Mar 8 at 18:39
Very astute observation (although the terminal emulator is likely not in-kernel, isn't it
agetty what is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.– David Tonhofer
Mar 8 at 18:39
Very astute observation (although the terminal emulator is likely not in-kernel, isn't it
agetty what is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get.– David Tonhofer
Mar 8 at 18:39
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f428752%2flinux-console-all-keyboard-input-is-preceded-by%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
^[is the control code for the Esc key. I have seen similar posts, with^@(the null character), but both are hard to Google.– muru
Mar 7 at 13:57
1
Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps
– muru
Mar 7 at 13:59
@muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things".
– David Tonhofer
Mar 7 at 16:21
1
This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer).
– Wouter Verhelst
Mar 8 at 15:50