*** This bug is a duplicate of bug 1895342 ***
https://bugs.launchpad.net/bugs/1895342
Thank you for taking the time to report this bug and helping to make
Ubuntu better. This particular bug has already been reported and is a
duplicate of bug 1895342, so it is being marked as such. Please look at
the other bug report to see if there is any missing information that you
can provide, or to see if there is a workaround for the bug.
Additionally, any further discussion regarding the bug should occur in
the other report. Feel free to continue to report any other bugs you may
find.
** Summary changed:
- 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
** Package changed: gdm3 (Ubuntu) => linux (Ubuntu)
** This bug has been marked a duplicate of bug 1895342
Acer Aspire E15 keyboard and trackpad non functional after update to
vmlinuz-5.4.0-47-generic
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gdm3 in Ubuntu.
https://bugs.launchpad.net/bugs/1908801
Title:
Acer Aspire E15 E5-511-POBM laptop internal keyboard & touchpad not
working in kernel 5.4.0-54, but 5.4.0-42 works
Status in linux package in Ubuntu:
Confirmed
Bug 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 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908801/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
