Keyboard issues with asus rog

kronkar

New Member
Credits
44
(sorry about my english)
Hi,

After installing Ubuntu 21.04 on an asus rog laptop (ryzen 7 5800h, nvidia rtx 3070) and the proprietary nvidia drivers, when I type with the built-in keyboard the power off pop-up appears.

alguien ha conseguido solucionarlo? i tried kernel from 5.10 to 5.12
 


KGIII

Super Moderator
Staff member
Gold Supporter
Credits
29,146
That's definitely new to me. I've never seen that before.

Unless someone has a better idea, let's start with broad strokes to troubleshoot.

Does this behavior happen when you're booted to a live USB of the same version of Ubuntu?
 

kronkar

New Member
Credits
44
With ubuntu (live usb and installed) 20.04, 20.10, 21.04, linuxmint, and solus :(
if I start in safe mode it restarts in command line when typing
 

KGIII

Super Moderator
Staff member
Gold Supporter
Credits
29,146
Do the keys you press have any secondary/tertiary function - say with Fn, Fn + Shift, or similar?

Again, I've never seen this before. I wonder if it's a wonky keyboard that requires special drivers or something like that.

What's the exact name and model number? Maybe that will yield some search results.
 

kronkar

New Member
Credits
44
i have installed now the 21.04 version
i need the newest kernel for the compatibility with the graphics cards (CPU + GPU)
 

Beh

New Member
Credits
7
Hi, I am facing the same issue also on Ubuntu 20.04 with kernel 5.12.

Someone fix it via the following dkms module but it don't work for my G15 2021 .

 

braxma

New Member
Credits
13
I had same issue. Laptop Asus ROG-STRING G513QM.
I tried to install different ubuntu version (18.04, 20.01) but only 21.04 works. But when you press any key power-off pop up appears.
 

Fanboi

Active Member
Credits
3,751
Your problem is hopefully something simple (notebook firmware, kernel problem, Xinput driver compatibility issue, whatever) causing those keys to be "perceived" as "soft" power off key signals (XF86PowerOff) or "hard" power off signals (virtual POWR key).

Try these fixes:

Based of XF86PowerOff:
Code:
$ xmodmap -e "keysym XF86PowerOff = <fill in the key it should be>"
// You can find standard keysyms and codes listed on the internet.
Based on POWR virtual key:
Code:
$ xinput
// From the list, find "Power Button" and get the id, eg: id=X
$ xinput disable <power button's id>
*Note: It could be a reset button, too. Just it's most commonly the power key.

If the keys causing the Power Off dialogue are now not typing anything, first check that they are returning a value:
Code:
$ xev
// Type on those keys, see if the console outputs anything.
Now try changing your keymap, since this can be caused by regional disparity (I see you're not English):
Code:
# dpkg-reconfigure keyboard-configuration
Set it to the region that the notebook came from. This is important! I really hope that works for you.

The last resort is to try mapping your entire keyboard with Xmodmap which should be easy, but very ardious. You'll have to map your keyboard yourself :( and that'll require some reading, starting here: Xmodmap (from Arch Wiki, best place for answers, no matter your distro).

If the keys still don't do anything:

Looks like you have a serious problem. I had this with my mum's notebook. Luckily a backported kernel fixed everything. That's all I can think of. I really hope for your sake that it isn't this serious, and if it is, that the next kernel fixes it. Otherwise you'll be stuck with a USB keyboard and mouse and have to blacklist your laptop's one with a modprobe rule.
 

braxma

New Member
Credits
13
there is result of xinput
Code:
WARNING: running xinput against an Xwayland server. See the xinput man page for details.
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ xwayland-pointer:18                         id=6    [slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:18                id=7    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ xwayland-keyboard:18                        id=8    [slave  keyboard (3)]

there the different when xev
this d button result from remote keyboard
Code:
KeyRelease event, serial 37, synthetic NO, window 0x1800001,
    root 0x24f, subw 0x0, time 304424, (1389,463), root:(1439,577),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False
this d button result from keyboard on laptop
Code:
KeyPress event, serial 37, synthetic NO, window 0x1800001,
    root 0x24f, subw 0x0, time 307171, (1389,463), root:(1439,577),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False
 
  • Like
Reactions: Beh

Sundodo

New Member
Credits
6
Same problem with the same pc here.

I tried
Code:
dpkg-reconfigure keyboard-configuration
but I can't find my keyboard model because I don't know it

I don't understand your first solution
 

Fanboi

Active Member
Credits
3,751
there the different when xev
this d button result from remote keyboard
Code:
KeyRelease event, serial 37, synthetic NO, window 0x1800001,
    root 0x24f, subw 0x0, time 304424, (1389,463), root:(1439,577),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False
this d button result from keyboard on laptop
Code:
KeyPress event, serial 37, synthetic NO, window 0x1800001,
    root 0x24f, subw 0x0, time 307171, (1389,463), root:(1439,577),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False
So, good news: Your "d" key works fine. This means you don't have to worry about reconfiguring your keyboard/layout entirely.
As for the below output, looks like your system's default is Wayland (this explains nVidia bugs in your linked post). IDK much about Wayland, I've never had a system running Wayland (and probably won't until it's forced on me, much like systemd, at which point, I'll look into what I have to, purely to keep the system working). Apparently Wayland uses xwayland as means to keep a little X compatibility.

there is result of xinput
Code:
WARNING: running xinput against an Xwayland server. See the xinput man page for details.
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ xwayland-pointer:18                         id=6    [slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:18                id=7    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ xwayland-keyboard:18                        id=8    [slave  keyboard (3)]

Last "soft" attempt before moving onto desperate measures:
Okay, please not the following is guesswork, so close and save anything, just in case. It should restore anything broken, but always be cautious. Run the below. You'll have 1 minute to open ANY app (like gedit, mousepad, etc.) and try typing "d" and any other keys causing the POWR button signal. Do not close the terminal until it says you can:
Code:
xinput disable 8 && sleep 60 && xinput enable 8 && echo "Bruh, you can close the console"
If this works, albeit for a minute, you can stop here. Although I still don't exactly the cause (it still could be a number of things, including a libinput bug) of your error, at least we have a solution (albeit hacky). Let me know how it goes. If it doesn't do anything...


Final act of desperation:
Before we do this, you need to know:
1) Your power buttons (power/suspend/hibernate/etc) will no longer work as "soft" poweroff buttons. They will still work as "hard" buttons. Extra info:
- You'll need to click "Power Off" or whatever to power down.
- You'll still be able to use the "hard" Power button. That's when you press and hold the power button for 10-15 seconds and it shuts down your PC by force. This is done by the BIOS, so OS configs won't affect it.
- The "Suspend" function might, and I stress, only _might_ be affected as far as waking. But IIRC, the WAKE function is handled at BIOS level (the power button sends a signal to the BIOS, the BIOS checks if suspend mode is active and then, executes the WAKE protocol -- including necessary signals to the OS
2) Your laptop lid may not work to suspend, poweroff, etc. your PC (which is fine). Everything in the first point applies to the lid unless the BIOS handles it completely independently (the lid is a button, too).
"Yeah, yeah, cool, get to the point"... Okay.

As root, open /etc/systemd/logind.conf (always backup first) and you'll notice it's full of commented-out lines (most of the time. If it is not, please post the contents here before proceeding. Okay, assuming it is as it should be, there may/may not already be these lines. If they are, umcomment and modify their values, otherwise just add them:
Code:
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
Then reboot and pray.
If it works (it should), while it may be inconvenient, at least you can use your machine. If you're still at a loss, we'll try other things, although it may be a bug without a workaround.
 

Fanboi

Active Member
Credits
3,751
Same problem with the same pc here.
I tried
Code:
dpkg-reconfigure keyboard-configuration
but I can't find my keyboard model because I don't know it
You'll have to either use the generic/default, or try similar models. Example, the keyboards of the Inspiron 3000 series will probably work with the "Dell 6000 series" layout.


I don't understand your first solution
My first fix was to use xmodmap to remap the keyboard's power button which the X11 input driver refers to symbolically as "XF86PowerOff". Remapping it to another button or "d" would mean when XF86PowerOff was pressed, it would send a different keycode. You can reassign many keys you don't use this way (it may even be useful to customize your keyboard).
 
$100 Digital Ocean Credit
Get a free VM to test out Linux!

Staff online


Top