| 2020-12-19 21:32:40 |
Joel Jakubovic |
bug |
|
|
added bug |
| 2020-12-19 21:32:40 |
Joel Jakubovic |
attachment added |
|
Results from running apport-cli -f -p gdm3 https://bugs.launchpad.net/bugs/1908801/+attachment/5445154/+files/BUGREPORT.apport |
|
| 2020-12-19 21:33:02 |
Joel Jakubovic |
summary |
internal keyboard touchpad not working |
Acer laptop internal keyboard & touchpad not working |
|
| 2020-12-19 23:46:38 |
Joel Jakubovic |
description |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to that old kernel version fix my problem if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... on top of an apparently working libinput??
Ideally I'd want to know the different stages in the lifecycle of a keystroke (post-libinput) and to find out at which stage the key event is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
Thank you for your consideration. |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
When I haven't had an external keyboard available I've used the on-screen keyboard to painstakingly run terminal commands by clicking each letter. However, sometimes the on-screen keyboard also stops sending keystrokes. The only concrete situation I can report is what I saw after resuming the system from sleep by opening the lid: at the login prompt on the lock screen, the onscreen keyboard came up, but didn't do anything when keys were clicked, forcing me to reboot.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to that old kernel version fix my problem if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... on top of an apparently working libinput??
Ideally I'd want to know the different stages in the lifecycle of a keystroke (post-libinput) and to find out at which stage the key event is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
Thank you for your consideration. |
|
| 2020-12-21 08:34:17 |
Launchpad Janitor |
gdm3 (Ubuntu): status |
New |
Confirmed |
|
| 2020-12-21 08:34:45 |
jlj |
bug |
|
|
added subscriber jlj |
| 2020-12-24 14:37:32 |
Joel Jakubovic |
description |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
When I haven't had an external keyboard available I've used the on-screen keyboard to painstakingly run terminal commands by clicking each letter. However, sometimes the on-screen keyboard also stops sending keystrokes. The only concrete situation I can report is what I saw after resuming the system from sleep by opening the lid: at the login prompt on the lock screen, the onscreen keyboard came up, but didn't do anything when keys were clicked, forcing me to reboot.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to that old kernel version fix my problem if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... on top of an apparently working libinput??
Ideally I'd want to know the different stages in the lifecycle of a keystroke (post-libinput) and to find out at which stage the key event is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
Thank you for your consideration. |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
When I haven't had an external keyboard available I've used the on-screen keyboard to painstakingly run terminal commands by clicking each letter. However, sometimes the on-screen keyboard also stops sending keystrokes. The only concrete situation I can report is what I saw after resuming the system from sleep by opening the lid: at the login prompt on the lock screen, the onscreen keyboard came up, but didn't do anything when keys were clicked, forcing me to reboot.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to that old kernel version fix my problem if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... on top of an apparently working libinput??
Ideally I'd want to know the different stages in the lifecycle of a keystroke (post-libinput) and to find out at which stage the key event is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
(As of 24 Dec 2020, I may now be OK to run 5.4.0-42. Before I reinstalled,
5.4.0-42 only fixed the keyboard and not the touchpad. After reinstalling,
and trying this kernel again, both seem to be working now. Next steps are
to compare things like the X logs. So while my Xmas wish has been granted,
it's still a bug and it would be good to narrow down its nature.)
Thank you for your consideration. |
|
| 2020-12-24 15:35:42 |
Joel Jakubovic |
description |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
When I haven't had an external keyboard available I've used the on-screen keyboard to painstakingly run terminal commands by clicking each letter. However, sometimes the on-screen keyboard also stops sending keystrokes. The only concrete situation I can report is what I saw after resuming the system from sleep by opening the lid: at the login prompt on the lock screen, the onscreen keyboard came up, but didn't do anything when keys were clicked, forcing me to reboot.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to that old kernel version fix my problem if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... on top of an apparently working libinput??
Ideally I'd want to know the different stages in the lifecycle of a keystroke (post-libinput) and to find out at which stage the key event is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
(As of 24 Dec 2020, I may now be OK to run 5.4.0-42. Before I reinstalled,
5.4.0-42 only fixed the keyboard and not the touchpad. After reinstalling,
and trying this kernel again, both seem to be working now. Next steps are
to compare things like the X logs. So while my Xmas wish has been granted,
it's still a bug and it would be good to narrow down its nature.)
Thank you for your consideration. |
A fresh install of 20.04 from the live USB doesn't see internal keyboard or touchpad input on my Acer Aspire E15 E5-511-POBM. After much private investigation to no avail (https://askubuntu.com/questions/1275809/ubuntu-20-04-lts-laptop-internal-keyboard-and-touchpad-no-longer-work), I am prepared to assert this as a bug. I'll restate the relevant info here, but see the link for a more chronological account. And I guess, for what it's worth, I would also assert that this is reproducible by installing 20.04 on my specific laptop model.
So, I boot up the laptop. I'm presented with GRUB boot menu. At this point the keyboard works, and if I choose advanced options and boot into a root shell I can type commands and do things that way as a last resort. However, all the problems seem to begin right from the start of the graphical session, even the login screen. This, in accordance with the instruction of https://wiki.ubuntu.com/Bugs/FindRightPackage#At_the_login_screen, is why I've filed this as a bug in gdm3. As I couldn't run the graphical bug program in Ubuntu, I ran the CLI in the root shell and attached the apport file here. I've tried to follow the relevant steps, but this is my first bug report so apologies if something is wrong.
I first noticed this problem a few weeks after upgrading 18.04 to 20.04. Yes, for the first few weeks of using 20.04, there were no problems. And then, one day, I booted up and the keyboard and touchpad spontaneously stopped working. This was mysterious because to my memory I hadn't done any major upgrade or change to any part of the system the previous day.
When the system is asleep / suspended, pressing a key or the touchpad easily wakes it up -- after which, they refuse to work again.
The brightness key combos (Fn+←/→) and one that turns off the screen (Fn+F6) do work, but others such as volume (Fn+↑/↓) do not work.
I see all expected key output when I run `sudo libinput debug-events --device /dev/input/event4 --show-keycodes` and type keys.
When I plug in an external USB keyboard and mouse, they work correctly while the internal keyboard and touchpad remain the same.
Outside of those specific situations, absolutely no internal keyboard input -- not even Ctrl+Alt+Del or Ctrl+Alt+F2 VT switching, let alone ordinary typing -- has any effect, and same with the touchpad.
When I haven't had an external keyboard available I've used the on-screen keyboard to painstakingly run terminal commands by clicking each letter. However, sometimes the on-screen keyboard also stops sending keystrokes. The only concrete situation I can report is what I saw after resuming the system from sleep by opening the lid: at the login prompt on the lock screen, the onscreen keyboard came up, but didn't do anything when keys were clicked, forcing me to reboot.
I had the following message in my `journalctl -b` logs:
```
The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Warning: Unsupported maximum keycode 569, clipping.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > X11 cannot support keycodes above 255.
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: > Internal error: Could not resolve keysym Invalid
Sep 17 11:36:20 joel-Aspire-E5-511 gnome-shell[1575]: Errors from xkbcomp are not fatal to the X server
```
This looks like it should have something to do with the keyboard issue. If it doesn't, then what is its significance?
When I first investigated, I was on kernel 5.0.47. When I selected 4.15.0-112 in the boot menu, everything was fine again; keyboard and touchpad working. I also found everything working fine on the install USB demo. Yet when I did a fresh reinstall of Ubuntu from the USB, the keyboard and touchpad did not work. This was now kernel 5.4.0-54.
Fortunately, switching down to 5.4.0-42 fixes my keyboard and touchpad problems, but I've no idea how long this will last (whether the problem is intermittent or can be relied upon to stay this way). Also, this was after my reinstall -- I did try this kernel on my previous install, and back then it only fixed the keyboard without the touchpad!
After installing lightdm alongside gdm, I see that lightdm actually sees my touchpad on 5.4.0-54, but still not my keyboard.
How can it be OK in the Live USB Demo but not the OS it installs? And why did switching down to those old kernel versions fix my problems if the problems only happened in the GUI and not the root console? What on earth is the connection between the kernel and GNOME's input handling ... downstream of an apparently working libinput??
Further, what is common between gdm and lightdm that, in some way related to the kernel, causes neither to recognise keyboard input? And what do they do differently such that lightdm sees touchpad input?
Ideally I'd want to know the different stages in the lifecycle of an event, say a keystroke -- post-libinput -- and to find out at which stage it is getting discarded. I literally went digging through the source code of various GNOME packages and programs, xkb tools, etc. I got as far as vaguely learning about Mutter or Clutter or something before deciding I had better things to do with my evenings. I am lost and I need someone who knows more about this.
One person on Ask Ubuntu gave some pessimistic sympathy, describing the issue as "just a thing we have to live with" on this particular laptop model. This is unacceptable, and I am able and willing to spend more time looking into this myself, if I can get just some pointers.
Thank you for your consideration. |
|
| 2021-01-04 08:28:54 |
Daniel van Vugt |
summary |
Acer laptop internal keyboard & touchpad not working |
Acer Aspire E15 E5-511-POBM laptop internal keyboard & touchpad not working in kernel 5.4.0-54, but 5.4.0-42 works |
|
| 2021-01-04 08:29:00 |
Daniel van Vugt |
affects |
gdm3 (Ubuntu) |
linux (Ubuntu) |
|
| 2021-01-04 08:30:32 |
Daniel van Vugt |
marked as duplicate |
|
1895342 |
|
| 2021-01-04 08:30:40 |
Daniel van Vugt |
bug |
|
|
added subscriber Daniel van Vugt |
