Integrated keyboard behaves strange in Qubes OS

Hi, I have been working for around a week with Qubes OS on a laptop, before I ran into the this problem. I restarted the laptop because the keyboard was behaving strange. Since then the following happened when starting the laptop:
I could enter my password for disk decryption. No problem so far.
Entering the credentials for login didn’t work on my integrated keyboard. In particular whenever I pressed the keys ‘4’, ‘5’, ‘r’, ‘t’, ‘f’, ‘g’, ‘c’ or ‘v’ something strange happened, e.g. pressing ‘f’ at one point resulted in 27#ölkj being written. Sometimes a seemingly infinite number of letters were written until I stopped it by pressing another letter, sometimes it tried to make a screenshot.
At that point in time logging in still worked by using Ctrl+Shift+u+Numbers to enter the broken keys.

I have no idea how it started, only theories:
• Software Upgrade?
• Wrong shortcut when trying to reduce the brightness of the screen?
• Leaving the laptop turned on or suspended for a day in the corner of the room?

I tried to fix it, but it seems I made it worse.
In addition to pressing random key combinations I changed the keyboard settings in the Qubes GUI. I removed a checkmark for the default keyboard there.
Now I cannot enter any letters in the login screen anymore.
If I press random digits on the number pad really fast, sometimes the digits ‘4’, ‘6’, ‘7’, ‘8’ and ‘9’ seem to register.
Other keys might result in the suspension of the laptop or the opening of the shutdown confirmation window.

Entering the password for disk decryption works fine.
In GRUB the keyboard works fine.
When starting Linux (e.g. Tails) from USB stick, the keyboard works fine.

Hence, I assume that it isn’t a hardware problem but solely related to Qubes OS.

OS: Qubes-R4.1.0-x86_64
Hardware: Lenovo T550
Keyboard: integrated
Keyboard Layout: German, qwertz

There is no risk of loss of personal data anymore since I was able to save everything.
I could just install an operating system from scratch. However, if I don’t understand how this happened and how I can repair it if it happens ever again, I’m probably not having enough trust in Qubes OS to make it my main operating system as I previously had planned.
I would be very glad if you could help me to understand this issue and how to fix it.

Do you remember what was happening before the keyboard started to behave strangely?
Was it right after boot or for some time after boot it worked fine?
Maybe you’ve updated Qubes right before this happened?
Is it USB keyboard?
If it’s USB keyboard then do you have it’s USB controller attached to dom0 or is it in sys-usb?

Maybe you have numeric keyboard in this place and it got turned on? Try NumLock, maybe with Fn, or other modifiers.

I am back to to the original strange behavior.
Shift and AltGr work as expected as does the numeric keypad. I can enter most of the letters and digits in the login screen including letters from the Germany keyboard layout (‘ä’, ‘ö’, ‘ü’ and ‘ß’), but if I press one of the eight “cursed keys” mentioned above, strange thing happen.
• multiple letters might be written to where the cursor is
• other keys may become disabled
• the touchpad may become disabled
• the shutdown confirmation dialog may appear

The Fn-Key also behaves a bit strange.
• Fn sometimes locks other keys on the keyboard.
• Fn sometimes triggers the shutdown confirmation dialog.
• Fn sometimes results in other keys behaving as if AltGr were pressed.

Do you remember what was happening before the keyboard started to behave strangely?
Was it right after boot or for some time after boot it worked fine?
Maybe you’ve updated Qubes right before this happened?

Sadly I cannot remember what I did right before it happened.
I was able to log in (or at least unlock the screen). It is possible that an upgrade was one of the last things that I did before logging off or locking the screen.
The screen was too bright for the dark location, so shortly after the login/unlock I tried to use Fn and the F1-F12 keys to make the screen darker. I might have pressed the wrong combination as well – it was dark. It took me a few moments to notice that something strange happened since instead of the screen becoming darker letters that I hadn’t pressed appeared in an open editor window.
Then I closed all the windows and restarted, hence, the current situation.
I don’t know if the problem appeared directly after login/unlock or after a failed attempt to reduce the brightness of the screen.

Is it USB keyboard?

I am not sure if the integrated keyboard is attached via USB. lsusb (executed via Tails from USB stick) does not show anything that looks like a keyboard to me.

If it’s USB keyboard then do you have it’s USB controller attached to dom0 or is it in sys-usb?

During installation I did not diverge from the default settings very much. I selected some German localization options and selected Debian instead of some other distribution at some point.
I don’t remember doing anything special regarding USB during the installation or afterwards. Maybe I tried unsuccessfully to access an USB stick from within a qube but I don’t remember changing USB settings.

Maybe you have numeric keyboard in this place and it got turned on? Try NumLock, maybe with Fn, or other modifiers.

I tried different combinations of modifiers. In general they seem to make things worse.

Try watching the keys with xev or input test or evtest tool (you might need to install those), maybe it will give hints what is happening there…

xev was already installed in a Debian Qube.
Now it gets complicated. There is much strange behavior occurring.

For example, I pressed Fn multiple times.
The first times nothing happened, then xev closed with the following last words (partially copied by hand, please ignore mistakes):

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 83 (keysym 0xffb4, KP_4), same_screen YES,
XLookupString gives 1 bytes: (34) “4”
XmvLookupString gives 1 bytes: (34) “4”
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
XLookupString gives 0 bytes:
XmvLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 151 (keysym 0x1008ffb2, XF86WakeUp), same_screen YES,
XLookupString gives 0 bytes:
XmvLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmvLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x18, keycode 71 (keysym 0xffc2, F5), same_screen YES,
XLookupString gives 0 bytes:
XmvLookupString gives 0 bytes:
XFilterEvent returns: False

ClientMessage event, serial 32, synthetic YES, window 0x1600001
message_type 0xfc (WM_PROTOCOLS), format 32, message 0xfb (WM_DELETE_WINDOW)

When pressing ‘c’ multiple times, the first times nothing happened and then it resulted in a minute long loop of repeating:


KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 151 (keysym 0x1008ff2b, XF86WakeUp), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 151 (keysym 0x1008ff2b, XF86WakeUp), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

Pressing ‘v’ multiple times resulted in en endless loop of repeating:


KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
XLookupString gives 1 bytes: (0d) "
XmbLookupString gives 1 bytes: (0d) "
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES,
XLookupString gives 1 bytes: (0d) "
XFilterEvent returns: False

Other keys have a similar behavior: At some times I pressed the key nothing happened, at other times so many different entries were written that it filled my screen.

For comparison, pressing ‘a’ yields the following normal output:

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 38 (keysym 0x61, c), same_screen YES,
XLookupString gives 1 bytes: (61) “a”
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) “a”
XFilterEvent returns: False

Is there anything specific you want me to try?
Please be aware that copying by hand is a very tedious process.

Seems like a similar issue:
https://forums.gentoo.org/viewtopic-p-8152436.html
Maybe you’ve changed some power management settings?

I don’t think that it is related to the XF86WakeUp bug. It is just one of multiple different strange behaviors.
I also observed and endless loop of KeyPress and KeyRelease events for ‘j’ when I had pressed ‘f’ and vaguely remember that at some point I had a loop of ‘#’.

Here are some more observations.

Pressing ‘r’ multiple times:
At first nothing happened.
The last time I pressed the key the output of xev contained the following.

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x40, keycode 46 (keysym 0x6c, l), same_screen YES,
XLookupString gives 1 bytes: (6c) “l”
XmbLookupString gives 1 bytes: (6c) “l”
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x40, keycode 46 (keysym 0x6c, l), same_screen YES,
XLookupString gives 1 bytes: (6c) “l”
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Some time later pressing ‘r’ multiple times resulted in a similar loop of XF86WakeUp as I described in an earlier reply for the key ‘c’.
It seems that some key presses of normal letters are changing the meaning of other keys.

Pressing ‘f’ multiple times:
At first nothing happened.
The last time I pressed the key the output of xev was the following

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 88 (keysym 0xffb2, KP_2), same_screen YES,
XLookupString gives 1 bytes: (32) “2”
XmbLookupString gives 1 bytes: (32) “2”
XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x1600001,
root 0x530, subw 0x0 …
state 0x10, keycode 79 (keysym 0xffb7, KP_7), same_screen YES,
XLookupString gives 1 bytes: (37) “7”
XmbLookupString gives 1 bytes: (37) “7”
XFilterEvent returns: False

FocusOut event, serial 32, synthetic NO, window 0x1600001,
mode NotifyNormal, detail NotifyNonlinear

and then the “[Dom0] Screenshot” dialog opened.

Does this sound familiar to anyone? Is it some known keyboard layout?

What’s the output of this command in dom0?
setxkbmap -verbose 10

The output of “setxkbmap -verbose 10” is the following:

Setting verbose level to 10
locale is C
Trying to load rules files ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105
layout:     de
variant:    nodeadkeys
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwertz)
types:      complete
compat:     complete
symbols:    pc+de(nodeadkeys)+inet(evdev)
geometry:   pc(pc105)

By replacing “rhgb quiet rd.qubes.hide_all_usb” with “rhgb quiet qubes.skip_autostart” in the startup settings I was able to get an external USB keyboard to work. There is no problem with the USB keyboard while the integrated keyboard behaves erratic.

Integrated keyboard:
Sometimes pressing an key does nothing at all, sometimes it works correctly and sometimes it creates multiple characters of input or even a seemingly endless stream of input.
Currently all the keys are affected, not just the keys that I mentioned in my initial post.

Cause?
We had already ruled out a hardware issue because the integrated keyboard works in grub and when starting another Linux distribution from USB stick.
Now the test with the external USB keyboard showed that it is not a general problem with the keyboard settings or keyboard layout.

It seems to me that the integrated keyboard or parts of it are considered by Qubes OS not as an keyboard but as some other device.
Sadly I have no idea how to fix it short of reinstalling the operating system and I have no idea how the problem started and how I could prevent the problem from reappearing with a new installation of Qubes OS.

Any ideas?

Maybe try to search for clues with xinput in dom0:

xinput list --long
xinput list-props <device-id>
xinput test <device-id>
xinput query-state <device-id>
xinput test-xi2 <device-id>

Ok, I can spend a little more time debugging before I have to reset the laptop.
I am not sure how to filter the output for the relevant stuff and hope the following output can help one of you to understand the issue.

$ xinput list --long
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
	Reporting 7 classes:
		Class originated from: 15. Type: XIButtonClass
		Buttons supported: 10
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" None None None
		Button state:
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Rel Vert Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 15.000000
		  flags: 0x0
		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 3
		  type: 1 (vertical)
		  increment: 15.000000
		  flags: 0x0

⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
	Reporting 3 classes:
		Class originated from: 4. Type: XIButtonClass
		Buttons supported: 10
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" None None None
		Button state:
		Class originated from: 4. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 4. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative

⎜   ↳ CHICONY USB Keyboard Consumer Control   	id=11	[slave  pointer  (2)]
	Reporting 7 classes:
		Class originated from: 11. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Rel Vert Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 15.000000
		  flags: 0x0
		Class originated from: 11. Type: XIScrollClass
		Scroll info for Valuator 3
		  type: 1 (vertical)
		  increment: 15.000000
		  flags: 0x0

⎜   ↳ Synaptics TM3053-003                    	id=15	[slave  pointer  (2)]
	Reporting 7 classes:
		Class originated from: 15. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Rel Vert Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 15.000000
		  flags: 0x0
		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 3
		  type: 1 (vertical)
		  increment: 15.000000
		  flags: 0x0

⎜   ↳ TPPS/2 IBM TrackPoint                   	id=16	[slave  pointer  (2)]
	Reporting 7 classes:
		Class originated from: 16. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 16. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 16. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 16. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 16. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Rel Vert Scroll
		  Range: -1.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 16. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 15.000000
		  flags: 0x0
		Class originated from: 16. Type: XIScrollClass
		Scroll info for Valuator 3
		  type: 1 (vertical)
		  increment: 15.000000
		  flags: 0x0

⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
	Reporting 1 classes:
		Class originated from: 9. Type: XIKeyClass
		Keycodes supported: 248

    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 5. Type: XIKeyClass
		Keycodes supported: 248

    ↳ Power Button                            	id=6	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 6. Type: XIKeyClass
		Keycodes supported: 248

    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 7. Type: XIKeyClass
		Keycodes supported: 248

    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 8. Type: XIKeyClass
		Keycodes supported: 248

    ↳ CHICONY USB Keyboard                    	id=9	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 9. Type: XIKeyClass
		Keycodes supported: 248

    ↳ CHICONY USB Keyboard System Control     	id=10	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 10. Type: XIKeyClass
		Keycodes supported: 248

    ↳ Integrated Camera: Integrated C         	id=12	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 12. Type: XIKeyClass
		Keycodes supported: 248

    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 13. Type: XIKeyClass
		Keycodes supported: 248

    ↳ ThinkPad Extra Buttons                  	id=14	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 14. Type: XIKeyClass
		Keycodes supported: 248

    ↳ CHICONY USB Keyboard Consumer Control   	id=17	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 17. Type: XIKeyClass
		Keycodes supported: 248

xinput test-xi2 3 reacts to both, keys from the integrated keyboard and USB keyboard.

xinput test-xi2 9 reacts to the external USB keyboard.

xinput test-xi2 13 reacts to the integrated keyboard and the touchpad.
Later it reacted to the integrated keyboard but not the touchpad. (?!?) It feels like I try to describe a behavior, which is constantly changing.

xinput test-xi2 15 reacts to touchpad clicks.

xinput test-xi2 16 reacts to touchpad movement.

Clicking on the integrated keyboard somehow temporary broke the external USB keyboard.
Arrow up returned ‘A’, arrow left returned ‘D’, arrow down returned ‘B’ and arrow right returned ‘C’. I was able to fix it by clicking even more on the integrated keyboard.

Here are more details about the device with id 13:

$ xinput list-props 13
Device 'AT Translated Set 2 keyboard':
	Device Enabled (179):	1
	Coordinate Transformation Matrix (181):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Send Events Modes Available (302):	1, 0
	libinput Send Events Mode Enabled (303):	0, 0
	libinput Send Events Mode Enabled Default (304):	0, 0
	Device Node (305):	"/dev/input/event3"
	Device Product ID (306):	1, 1
$ xinput query-state 13
1 class :
KeyClass
	key[0]=up
	key[1]=up
	key[2]=up
	key[3]=up
	key[4]=up
	key[5]=up
	key[6]=up
	key[7]=up
	key[8]=up
	key[9]=up
	key[10]=up
	key[11]=up
	key[12]=up
	key[13]=up
	key[14]=up
	key[15]=up
	key[16]=up
	key[17]=up
	key[18]=up
	key[19]=up
	key[20]=up
	key[21]=up
	key[22]=up
	key[23]=up
	key[24]=up
	key[25]=up
	key[26]=up
	key[27]=up
	key[28]=up
	key[29]=up
	key[30]=up
	key[31]=up
	key[32]=up
	key[33]=up
	key[34]=up
	key[35]=up
	key[36]=down
	key[37]=up
	key[38]=up
	key[39]=up
	key[40]=up
	key[41]=down
	key[42]=up
	key[43]=down
	key[44]=up
	key[45]=down
	key[46]=up
	key[47]=up
	key[48]=down
	key[49]=up
	key[50]=down
	key[51]=down
	key[52]=down
	key[53]=up
	key[54]=up
	key[55]=down
	key[56]=up
	key[57]=up
	key[58]=down
	key[59]=down
	key[60]=down
	key[61]=up
	key[62]=up
	key[63]=up
	key[64]=up
	key[65]=up
	key[66]=up
	key[67]=up
	key[68]=up
	key[69]=up
	key[70]=up
	key[71]=up
	key[72]=up
	key[73]=up
	key[74]=up
	key[75]=up
	key[76]=up
	key[77]=up
	key[78]=up
	key[79]=up
	key[80]=up
	key[81]=up
	key[82]=up
	key[83]=up
	key[84]=up
	key[85]=up
	key[86]=up
	key[87]=up
	key[88]=up
	key[89]=up
	key[90]=up
	key[91]=up
	key[92]=up
	key[93]=up
	key[94]=up
	key[95]=up
	key[96]=up
	key[97]=up
	key[98]=up
	key[99]=up
	key[100]=down
	key[101]=up
	key[102]=up
	key[103]=up
	key[104]=up
	key[105]=up
	key[106]=up
	key[107]=up
	key[108]=up
	key[109]=up
	key[110]=up
	key[111]=up
	key[112]=up
	key[113]=up
	key[114]=up
	key[115]=up
	key[116]=up
	key[117]=up
	key[118]=up
	key[119]=up
	key[120]=up
	key[121]=up
	key[122]=up
	key[123]=up
	key[124]=up
	key[125]=up
	key[126]=up
	key[127]=up
	key[128]=up
	key[129]=up
	key[130]=up
	key[131]=up
	key[132]=up
	key[133]=up
	key[134]=up
	key[135]=up
	key[136]=up
	key[137]=up
	key[138]=up
	key[139]=up
	key[140]=up
	key[141]=up
	key[142]=up
	key[143]=up
	key[144]=up
	key[145]=up
	key[146]=up
	key[147]=up
	key[148]=up
	key[149]=up
	key[150]=up
	key[151]=down
	key[152]=up
	key[153]=up
	key[154]=up
	key[155]=up
	key[156]=up
	key[157]=up
	key[158]=up
	key[159]=up
	key[160]=up
	key[161]=up
	key[162]=up
	key[163]=up
	key[164]=up
	key[165]=up
	key[166]=up
	key[167]=up
	key[168]=up
	key[169]=up
	key[170]=up
	key[171]=up
	key[172]=up
	key[173]=up
	key[174]=up
	key[175]=up
	key[176]=up
	key[177]=up
	key[178]=up
	key[179]=up
	key[180]=up
	key[181]=up
	key[182]=up
	key[183]=up
	key[184]=up
	key[185]=up
	key[186]=up
	key[187]=up
	key[188]=up
	key[189]=up
	key[190]=up
	key[191]=up
	key[192]=up
	key[193]=up
	key[194]=up
	key[195]=up
	key[196]=up
	key[197]=up
	key[198]=up
	key[199]=up
	key[200]=up
	key[201]=up
	key[202]=up
	key[203]=up
	key[204]=up
	key[205]=up
	key[206]=up
	key[207]=up
	key[208]=up
	key[209]=up
	key[210]=up
	key[211]=up
	key[212]=up
	key[213]=up
	key[214]=up
	key[215]=up
	key[216]=up
	key[217]=up
	key[218]=up
	key[219]=up
	key[220]=up
	key[221]=up
	key[222]=up
	key[223]=up
	key[224]=up
	key[225]=up
	key[226]=up
	key[227]=up
	key[228]=up
	key[229]=up
	key[230]=up
	key[231]=up
	key[232]=up
	key[233]=up
	key[234]=up
	key[235]=up
	key[236]=up
	key[237]=up
	key[238]=up
	key[239]=up
	key[240]=up
	key[241]=up
	key[242]=up
	key[243]=up
	key[244]=up
	key[245]=up
	key[246]=up
	key[247]=up

For comparison: For query-state 9 the key[36] is the only key with value “down”.

The query-state looks suspicious. key 36 is Enter and it’s state is down because it’s pressed when you press enter to run command.
So for your integrated keyboard some of the keys are reported as pressed (down) and this may be the cause of this problem.
Can you boot from some Live USB and check whatever you’ll have these keys pressed there as well?

Also check if the keys that are reported as pressed have the same state all the time or it’s a random.

I started Tails from USB stick and installed xinput.
For xinput query-state 9 and xinput query-state 13 all keys are up (expect for key[36] if I used the respective keyboard to execute the command).

The state of the keys isn’t random, but it changes if I press keys.
I restarted Qubes OS. At first the touchpad worked and xinput query-state 13 showed “up” for all keys.
I pressed a few keys on the integrated keyboard. When I came to letters like ‘f’, ‘g’, ‘c’, ‘v’ etc. strange things started to happen. Afterwards xinput query-state 13 showed that key[44] and key[45] were “down” and the touchpad no longer worked. This happens often that the touchpad becomes disabled by clicking on the integrated keyboard. I still can use the pointing stick on the keyboard to move the mouse.

I pressed some more keys. ‘c’ worked normal and pressing ‘f’, ‘g’, and ‘v’ didn’t do anything. When I pressed ‘c’ and ‘v’ in short order

bash: c: command not found
g^[[3;6~
':;
^C

was written to the terminal. (^C was my doing.)
Afterwards, key[44], key[45], key[51], key[54], key[55], key[58], key[59] and key[60] had the value “down”.

Revisiting the problem with the power management settings, for which you posted a link to the Gentoo forum:
/usr/libexec/upowerd and xfce4-power-manaer --restart --sm-client-od <...some-id...> are running. I am still not sure if/how the power management could affect the keyboard like this.
Killing both processes does not solve the problem.

Try to disable/enable integrated keyboard:
xinput disable 13; sleep 1; xinput enable 13
Maybe try to disable other input devices like touchpad except for integrated keyboard and USB keyboard.

You can run this command to see how the key press/release is affecting query-state:
watch -n 0.05 "xinput query-state 13 | tail -n +3 | column -c 100"

TLDR:
It seem to be the Fn key and the F4 key (toggle microphone), which seem to break everything.
I still have no idea which program is responsible or how to fix it permanently.

Long version:

I tried xinput disable 13; sleep 1; xinput enable 13.
In addition I disabled and enabled 15 and 16 (and maybe 11).
It didn’t help (at first. More on that later).
I wasn’t able to disable 2 or 3. It failed with the following message:

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  131 (XInputExtension)
  Minor opcode of failed request:  57 ()
  Serial number of failed request:  21
  Current serial number in output stream:  22

In the beginning I was not sure how useful it is to watch what keys are considered as “down”. Since it starts with all keys “up”, I think keys staying down is a result of the error, not its cause.
However, since xinput disable 13; sleep 1; xinput enable 13 allows me to reset all keys to “up”, I finally could map the behavior of the keys systematically.

Pressing the Fn key a few hundred times:

  • Sometimes it changes the state of key[64], key[77], key[83] and key[151] to “down”.
  • Sometimes it changes the state of key[64], key[71], key[77], key[83] and key[151] to “down”.
  • Sometimes it changes the state of key[64], key[70], key[71], key[72], key[77], key[83] and key[151] to “down”.

After releasing the Fn key, sometimes either key[64], key[70], key[71], key[72] or key[151], but only one of these keys, stays down.
In addition at one point the key[108] went down and stayed down for the rest of the test.

Furthermore, at some instances when I pressed Fn

  • either the terminal changed its appearance (toggle full screen),
  • the small window for showing and adapting the brightness of the screen appeared
  • a “Close all tabs?” window appeared,
  • a “Logout window” appeared or
  • the small window for changing the microphone appeared.

Most often it was one of the first two behaviors.

Pressing Alt:

key[64] and key[77] change their state to down, but only until you release the key.

What happened now?

At this point I wanted to continue with ‘4’, ‘5’, ‘r’, ‘t’, ‘f’, ‘g’, ‘c’ and ‘v’, but then I noticed that the keyboard was now working normally, besides the Fn key (and some of the the F1-F12 keys?). Sadly, my mouse/touchpad stopped working and I was no longer able to click.

Since the problem might have started when I was trying to reduce the brightness of the screen, I started to try F1-F12, sometimes in combination with the Fn key.
I was not sure what exactly was the cause, but the problem with the keys ‘4’, ‘5’, ‘r’, ‘t’, ‘f’, ‘g’, ‘c’ and ‘v’ reappeared. On the other hand my touchpad started to work again.
FYI: I was not able to end the watch command with Ctrl+c. I had to use the mouse.

I pressed Fn multiple times (and inbetween restarted device 13).
In addition to the strange behavior already descriped above,

  • at some point the LED of the key started to glow, but I was no longer able to click with the mouse
  • at some point I was able to click with the mouse again and
  • at some later point the keys ‘4’, ‘5’, ‘r’, ‘t’, ‘f’, ‘g’, ‘c’ and ‘v’ started to work normally again.

Systematically checking the F1-F12 keys:

The LED on the Fn key glowed while I was performing the following tests.

Pressing F1:
key[67] is down and a “Do you want to read the Xfce Terminal manual online?” window appears. The letters continue to work.
Pressing F2:
key[68] is down and nothing happens. The letters continue to work.
Pressing F3:
key[69] is down and nothing happens. The letters continue to work.
Pressing F4:
key[70] is down and nothing happens. The letters continue to work.
Pressing F5:
key[71] is down and nothing happens. The letters continue to work.
Pressing F6:
key[72] is down and nothing happens. The letters continue to work.
Pressing F7:
key[73] is down and nothing happens. The letters continue to work.
Pressing F8:
key[74] is down and nothing happens. The letters continue to work.
Pressing F9:
key[75] is down and nothing happens. The letters continue to work.
Pressing F10:
key[76] is down and File menu of the terminal is toggled. The letters continue to work.
Pressing F11:
key[95] is down and full screen is toggled. The letters continue to work.
Pressing F12:
key[96] is down and nothing happens. The letters continue to work.

Pressing Fn+F1:
key[64], key[77], key[83], key[151] + key[67] are down.
The LED of the Fn key stops to glow.
A huge amount of dom0 menues (more than hundred, probably less than two hundred) are opened. I have the following options: Open in New Window, Create Launcher…, Create URL Link…, Create Folger…, Create Document, Paste (grayed out), Open Terminal here, Arrange Desktop Icons, Desktop Settings…, Properties…, Applications
To get rid of the menues I click “Open Terminal here” more than a hundred times and then close the terminals.
The letters continue to work.

No that the Fn key does not glow, I repeat the test of the F1-F12 keys.

Pressing F1:
key[121] is down and the loud speaker is toggled. The letters continue to work.
Pressing F2:
key[122] is down and the volume of the loud speaker is reduced. The letters continue to work.
Pressing F3:
key[123] is down and the volume of the loud speaker is increased. The letters continue to work.
Pressing F4:
No key changes its state! The microphone is toggled. Whenever the microphone is off, the strange behavior reappears.
Pressing F5:
No key changes its state! The small window for the brightness of the screen appears, but the brightness does not change.
Pressing F6:
No key changes its state! The small window for the brightness of the screen appears, but the brightness does not change.
Pressing F7:
No key changes its state! The “[Dom0] Display” window appears. The letters continue to work.
FYI: The symbol of F7 in my keyboard shows a camera, not a display.
Pressing F8:
No key changes its state! Nothing happens. The letters continue to work.
FYI: The symbol of F8 in my keyboard shows a crossed-out Wifi symbol.
Pressing F9:
No key changes its state! Nothing happens. The letters continue to work.
FYI: The symbol of F9 in my keyboard shows a gear. Maybe it is a symbol for “settings”.
Pressing F10:
No key changes its state! Nothing happens. The letters continue to work.
FYI: The symbol of F10 in my keyboard shows a magnifying glass. Most likely it is a symbol for “search”.
Pressing F11:
No key changes its state! Nothing happens. The letters continue to work.
Pressing F12:
No key changes its state! Nothing happens. The letters continue to work.

Conclusion: As long as I press Fn key never again and press the F4 key only an even number of times, I have no problem.

Real conclusion:
There is some problem with the Fn key and at least some of the F1-F12 keys.
I still find the behavior of the Fn key the most worrying. Fn seems to not only toggle between two states but switch between an unknown number of states (touchpad enabled/disabled, Fn yes/no, Fn key glowing yes/no, various different keys down or not).

Thank you, tzwcfq, for bringing me and this analysis this far. :grinning:

Any ideas on how to continue from here?

1 Like

I just started Tails from USB stick and experimented with the F1-F12 keys and the Fn key.

While Tails has no problems to toggle WLAN (flight mode) and reducing and increasing the brightness of the screen, it shows the same strange behavior for the Fn key and the F4 key.

So, it could be a hardware problem. Please excuse that I assumed that it was related to Qubes OS. The main difference is that Qubes OS keeps its state with each restart while Tails starts each time without the problem.

Thank you marmarek and tzwcfq both for your patience and your help.