[Dell BIOSes dated 27 Mar 2019, XPS 9575, Precision 5530 2-in-1] laptop keyboard & touchpad not working at gdm screen after boot

> If I plug in a USB keyboard or activate my bluetooth mouse, I can use those to log in, and then after logging in the laptop touchpad and keyboard work again.

The login screen uses Wayland but the default user session uses Xorg. Can you please test both logging into "Ubuntu" and "Ubuntu on Wayland" and tell us if one works better than the other?

Please also run these commands after logging in:

  dpkg -l > allpackages.txt
  journalctl -b0 > journal.txt

and send us the resulting 'allpackages.txt' and 'journal.txt'.

will try the ubuntu sessions tomorrow. I normally run the gnome (wayland) session, but have keepass2 in startup applications. Believe that it is running via xwayland, and its approximately when keepass2 starts up and/or gains focus that my laptop touchpad/keyboard start working again.

In that case please also try (temporarily) uninstalling keepass2. Does that avoid the bug?

Actually, a big problem I can see is that your journal.txt (system log) is full of:

Mar 30 14:28:00 taplop gnome-shell[5876]: Failed to flip onscreen: Tried to flip inactive CRTC
Mar 30 14:28:01 taplop gnome-shell[5876]: Failed to flip onscreen: Tried to flip inactive CRTC
Mar 30 14:28:01 taplop gnome-shell[5876]: Failed to flip onscreen: Tried to flip inactive CRTC

That's a Wayland-specific issue so please do try logging into Xorg (just "Ubuntu").

Tests this morning seem to show that the internal devices get enabled right after any input from an external device on the gdm screen. So choice of session isn't influencing anything.

additionally, forcing gdm to use X11 via `WaylandEnable=false` in /etc/gdm3/custom.conf displays the same bug behavior.

Perhaps this is somehow related to the convertible lid hinge. Ordinarily when the laptop is in "tablet" mode (hinge open > 180 degrees), the keyboard and touchpad are disabled. Even more reliably than using an external device, switching into and then back out of tablet mode by opening/closing the hinge seems to restore keyboard/touchpad functionality. Not sure why they appear to work until the gdm screen though, or why sometimes using an external device causes them to work again.

I have the same issue, glad its not just me. The keyboard and touchpad only work once the hinge has been opened over 180degrees even after ive logged in so at least i have a work around till we get a proper fix.

Is there anything i can do to assist at this time?

Status changed to 'Confirmed' because the bug affects multiple users.

Same problem Precision 5530 2-in-1 with 1.4.8 bios. In my case touchpad is always working, keyboard will sometime came after 15-20 seconds. Closing and opening lid will fix problem. Also if you enter password with on screen keyboard (touchscreen) and get to gnome keyboard is working again. Ubuntu 18.04 kernel 4.18, 4.19, 4.20 and 5

Is is possible to downgrade the BIOS at all?

The bug description says:

> Did not see this behavior before upgrading from 1.2.0 bios to 1.4.0 bios

and the problematic BIOS versions are only a couple of weeks old:

https://www.dell.com/support/home/au/en/audhs1/drivers/driversdetails?driverid=p93yr
https://www.dell.com/support/home/au/en/audhs1/drivers/driversdetails?driverid=2rfmg

Unfortunately there's nothing newer yet either.

downgrading to the 1.2.0 bios on xps 9575 appears to be working properly (tested 3 reboots with no issues)

downgrading on precision to 1.0.5 (last available), keyboard will work again - so BIOS bug

I also run a Dell XPS 9575 2 in 1, with BIOS 1.40 and my system is *not* exhibiting this particular problem after a fresh 19.04 install. Keyboard and mouse work fine with GDM, but this is also after booting with the nomodeset kernel boot parameter.

Note: for other folks reading this thread wondering how I even got 19.04 installed, I had to install with nomodeset because of a kernel bug with the i915 module with certain laptop panels. I don't think the 4K panels are impacted by this bug...

OK, after compiling 5.0.7 mainline + Ubuntu Patches + this patch from here (https://patchwork.freedesktop.org/patch/296411/) to fix the link training issue for my laptop panel, I am able to boot with modesetting.

Now I *am* noticing the problem. As others have suggested, bending back the laptop panel on it's hinge "resets" the keyboard and trackpad, then I can bend it back to a normal position and everything starts working.

One other thing worth mentioning is that the problem also exhibits itself in lightdm, not just gdm3.

^^^
FYI that would be bug 1824216.

I have the exact same issue on Fedora 30. Bios 1.5.1 came out today and has the same exact issue.

I have reported already problem to Dell, but apparently they are not doing anything about this. Only update for WD19. If more people report it, may be they will start to work. Will try to connect with notebookcheck to bring some fuss up. I am not using windows at all and this is big problem for me.

FWIW a few other messages pop up to me in the above logs as suspicious to the described symptoms, especially with keyboard working in cryptsetup.

Mar 31 10:34:45 taplop org.gnome.Shell.desktop[5876]: libinput error: client bug: timer event25 debounce: offset negative (-111ms)
Mar 31 10:34:45 taplop org.gnome.Shell.desktop[5876]: libinput error: client bug: timer event25 debounce: offset negative (-44ms)
Mar 31 10:34:45 taplop org.gnome.Shell.desktop[5876]: libinput error: client bug: timer event25 debounce short: offset negative (-57ms)

When libinput initialized if it failed to configure those input devices, that /might/ explain the behavior. Flipping the hinge will cause them to come on/off the bus and let libinput try again.

There is symptom that if you wait for 30 seconds, input devices will start to work again, without flipping hinge. Also closing lid to sleep laptop and wake it again will work also. System engineer from Dell reported that default kenrel 4.15 will not have this problem, every other higher version will have it, including latest main stream version.

Status changed to 'Confirmed' because the bug affects multiple users.

Hey everyone,

is there any update on the issue?
Does the bug still occur with BIOS v. 1.6.1 from 21 Jul 2019?

Thanks in advance for your help.

Regards,
Simon

Can you confirm linux kernel v4.15 doesn't have this issue?

This is information from Dell support team about 4.15 working and others don't

user report:

device - Dell XPS 15 9575 (2018) Intel Core i5-8305G
BIOS - version 1.2.0
OS - Fedora 30 (Gnome Version 3.32.2)

No bugs reported. Everything works fine.
Guess this is no surprise as I am running an older BIOS version.

I can confirm I have encountered this issue with BIOS v. 1.6.1 from 21 Jul 2019

Device - Dell XPS 15 9575 Intel Core i7-8705G
BIOS - version 1.6.1
OS - Fedora 30
Kernel - kernel-5.1.19-300

Additional info:
- I have an encrypted root partition. During boot, I am able to usethe keyboard for <1 second at the screen where I enter the password for the root partition. Then the keyboard is disabled.
- I tested this with a previously installed kernel 5.0.9-301 and I was able to use the keyboard to enter the password for the root partition, but once I arrive at the login screen for fedora the keyboard/touchpad is unusable (cannot even switch TTYs)
- Using the grub boot menu option "fedora rescue" which is installed by default with fedora, I am able to use the keyboard to login without issue.

I'm happy to share any additional information that is requested. I don't see any specific errors in dmesg that stand out here, but I've provided a dmesg from a boot when the keyboard would not function [0]. I will also upload a dmesg from a functional boot[1].

[0] boot_k509_keyable_unusable_dmesg.log
[1] boot_rescue_keyboard_usable_dmesg.log

I believe I have a workaround provided by a kernel engineer I was discussing the issue with.

Adding the following to the kernel boot options resulted in the keyboard and touchpad working without issue:

  i8042.nomux=1 i8042.reset

It appears that Dell uses i8042 to emulate a ps/2 interface rather than using USB for the built-in keyboard and touchpad.

The following stackexchange link provided more info: https://unix.stackexchange.com/questions/28736/what-does-the-i8042-nomux-1-kernel-option-do-during-booting-of-ubuntu

I've attached a new dmesg output from a successful boot using these boot options[0]

[0] boot_i8042_options_keyboard_usable_dmesg.log

That's interesting to me. Yes the EC will emulate an PS2 mouse until the OS brings up the I2C controller. I would think you can accomplish a similar result by blacklisting psmouse potentially.

Is this discussion in IRC or a mailing list?

Apologies, comment #32 is incorrect, this worked a couple times but the problem is still present intermittently. I have since downgraded to BIOS v1.2.0 to avoid the issue.

#32 is not working for Precision

It's worth mentioning that even with the downgraded bios the mouse cursor frequently gets stuck requiring a screen flex to fix.

In addition the downgraded bios exposes similar sticking on Windows. So I can only imagine that resolving this was the purpose of the bios update in the first place.

Once updated to the latest bios cursor behaviour is good on Windows.

Is there any hope that this will ever be fixed because as Bryn points out at #36 the temporary "fix" of downgrading the BIOS is far from satisfying.

I can only imagine that it must be a small proportion of Dell systems affected. Otherwise we would see more bug reports and interest here...

Mario?

XPS 9575 isn't (currently) available for purchase with Ubuntu. So yes, it's below the radar for something that is typically tested, tracked, or fixed from a BIOS or validation team perspective.

Yeah it sounds like the XPS 9575 is the main model affected. Also Precision 5530 (comment #14).

5530 2-in-1 also isn't available for purchase with Ubuntu, so same boat.

It's (confusingly) a very different system than 5530 which /is/ available with Ubuntu.

The thing is I am really afraid of upgrading the BIOS just to give it a shot because of this:

"Just update XPS 9575 Bios on the week of Sept 9, now the laptop is totally unresponsive, not able to power on, totally black screen, no light comes on, fans won't kick on, no Dell logo shows. Tried many ways, many times to enter the bios recovery mode suggested by Dell and other websites, but nothing works. The computer is dead now. Very, very frustrated."

###

Apparently the track pad issue affects Windows as well:

"I'm a Dell xps 9575 user running windows 10 fam 64. I can report that the track pads works absolutely inconsistantly: Mouse icon gets immobile at random moments wich is accompanied by unresponsible click. I'm running on bios 1.7.1 since one hour with no change compared to 1.5.1 and the previous bios didn't work either. I wish I could install ubuntu mate but the laptop belongs to my son. Windows update, intel driver and dell driver detects no upgrade to be done. The frozen trackpad issue seem to come from excessive chest pressure that bends the bottom of the trackpad and it also seems that the mouse gets back to life when bending the other way:both thumbs under track pad with fingers under palmrests..."

###

Does anyone have an "effective" workaround at the moment (and with which BIOS?), like pointed out earlier here?:

"This is still a problem on the newly released 1.6.1 BIOS. Workaround for all versions with this issue - hit FN+END to enter sleep (or close the lid, by default this will enter sleep mode), then wake it back up. Input will work properly after that."

###

All comments from: https://www.notebookchat.com/index.php/topic,96952.0.html?language=english-utf8

I have a workaround on linux(its not ideal).

On linux if i disable "disable while typing" and then disable "tap to click" it works. It would seem that the act of disabling and enabling the touchpad over and over causes it to not enable once and awhile. Its not ideal to not be able to tap to click, but I no longer have mouse issues.

@ryder-tim Thanks for letting us know. As far as I understand your workaround is meant for people running the old 1.2.0 BIOS (in order to avoid the more serious bug of no registered input at login) and your workaround only fixes the trackpad issues associated with BIOS v. 1.2.0. Is that correct?

@Peter_Lustig

Yes unfortunately that is correct. It makes the laptop more then usable, but does not fix the later bios issues.

#43 does not work for me (latest v. of Fedora 31) but appeared to be working for a short time before upgrading from Fedora 30 to Fedora 31 (most likely it never worked though and it was a placebo effect).

#46 Still working for me, have not had the issue since I made that change. I'm on Fedora 31 as well, fully up to date. Maybe I have just been lucky so far.

On a new XPS 15 9575 2-in-1 with BIOS 1.8.1, the symptoms are similar to comment #24. At the gdm login screen, the keyboard doesn't work at first but is OK after 20-30 seconds. The touchpad is not affected. The Linux 4.15 kernel is not affected but later ones are. I tried it with 4.18, 5.0 and 5.3 kernels. I am running Mint 19.2, which uses the Ubuntu kernels.

If I boot in recovery mode, the keyboard works on the recovery mode menu. If I then exit to normal boot, the unresponsive keyboard recurs. However, the elapsed time until it starts working
again is from the initial boot. That is, if I wait 30 seconds in recovery mode before exiting to normal boot, the keyboard will then be working at the gdm screen.

Mark,

If possible, please do a kernel bisect.

Dell released yesterday BIOS version 1.9.1 for the affected XPS 9575:

https://www.dell.com/support/Home/us/en/19/Drivers/DriversDetails?driverId=MDP34&lwp=rt

There is nothing clear in the release notes on the issue, but affected users may want to try the update.

The BIOS 1.9.1 from prev. comment #50 apparently was pulled by Dell, there is no reason given at the link.

I have a 9575 from September/October 2019 and BIOS 1.7.1 (from Aug 7, 2019, which is currently the latest one available on the Dell site (and, side note, fixes the annoying fans-always-on-in-tent-mode issue)), and I have the same behavior as described in comment #48, i.e. it is unresponsive for 30 secs at the login screen, then works fine. Still same problem in Focal Fossa with kernel 5.4.

I am pretty sure I did not have this in previous BIOSes ( but not 100% sure. As someone asked, yes it is possible to downgrade BIOS, I went through them all bewteen 1.1.6 and 1.7.1 up and down to narrow down the known tent-fan and touchpad-lower-half-randomly-failing issues).

Not sure if it matters, but I just rebooted and the wait time at the login screen is actually approx. 13 secs, not 30

On bios 1.10.0 that was released yesterday with kernel 5.4(fedora) I no longer have this issue. The keyboard and mouse work on boot for me.

I am still experiencing the issue after updating the BIOS firmware to version 1.10.0, on Ubuntu 19.10 (kernel 5.3.0-26).

Firmware info and download page: https://www.dell.com/support/Home/us/en/frdhs1/Drivers/DriversDetails?driverId=0KJ0

I also see no change with BIOS 1.10.0 on Eoan (though with kernel 5.3 due to an unrelated issue; I ran 5.4 and 5.5 before with the 1.7.1 BIOS and had the problem with all three kernels).

I also noticed that though I have the problem just for ca 13 secs most of the time, occasionally it never seems to start working (I waited more than a minute).

However, a few times recently I sent the laptop to sleep with the power button while the problem was occurring. The power button works even when the keyboard does not, and on wake-up the problem was gone. It is possible that I happened to press the button exactly when the keyboard would have worked anyway, but as the procedure helped every time this seems unlikely. Can anyone confirm?

I am running BIOS 1.10.0, Kernel 5.5, Ubuntu 20.04 (development) and am getting the same issue. The duration appears to vary for the keyboard and track pad to activate, sometimes it is longer or shorter than 13seconds stated above.
I am also running 9575.

Just checked, issue persists in 5.6.0 RC1 Kernel, Bios 1.10.0, Ubuntu 20.04.
Closing laptop lid while at login until suspend occurs and then immediately resuming from suspend appears to enable the keyboard and touchpad.

Running into this issue on XPS 9575 with Ubuntu 18.04. My solution so far is to flip the screen into tablet mode then back into laptop mode to get the keyboard working.

Booting with acpi=off fixes this, so I am thinking a workaround could be to ignore the tablet ACPI events ex "video/tabletmode TBLT 0000008A 00000000". Not sure if it is possible to selectively disable ACPI event handling just yet though.

Can you check if you have intel-vbtn or intel-hid driver loaded? I would think intel-vbtn.

Whichever it is a good experiment with the above comment is to blacklist the module, rebuild initramfs and reboot. See if this helps.

If it does then it's likely a situation of this driver starting in wrong state.

Looking at the dmesg from #30, it's actually intel-hid. Here is how to blacklist: https://askubuntu.com/questions/110341/how-to-blacklist-kernel-modules

@Mario Limonciello Sorry, I am a bit out of the loop. Does #61 solve the issue? And if so, are there negative aspects of blacklisting intel-hid?

Same problem here with a Dell XPS 15 2 in 1 9575. BIOS version 1.11. Problem fixed with blacklisting intel_vbtn in /etc/modprobe.d/

Just commenting to say I have the same problem with Dell XPS 15 2-in-1 9575, BIOS version 1.12.1. The problem was indeed fixed with blacklisting intel_vbtn. Using Fedora 32.

Same here. Thank you guys for finding a fix ;)

I wonder if this commit helps:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfae58ed681c5fe0185db843013ecc71cd265ebf

Recently installed Arch Linux and I am no longer encountering this issue at all.

Kernel version: 5.8.8
SystemD version: 246.4
BIOS version: 1.12.1
libinput version: 1.16.1-1
xf86-input-libinput version: 0.30.0-1

Not sure if there are any other relevant packages.

A very similar bug has started affecting me since I upgraded to Ubuntu 20.04.

On my laptop (Dell XPS 15 9560) I am unable to decrypt my harddrive because the keyboard is unresponsive so I can't enter the password.

I have found a workaround for that issue, which is to boot in recovery mode (the keyboard works in the grub menu), then drop to a root shell and run `reboot`. Upon reboot the keyboard works and lets me decrypt the drive and log in.

It does not work to enter the grub menu and choose normal boot, nor does it work if I do a hard reboot after booting in recovery mode.

During a Gnome session the keyboard and touchpad will occasionally become unresponsive as well. The workaround here is to press the power button - this brings up the logout dialog, which causes the touchpad and keyboard to work again.

To anyone who has been affected - there is a discussion going on the kernel mailing lists regarding this issue and it would be helpful if you can provide an acpidump. You can attach it to this bug (or file a kernel bugzilla and attach it there).

Desired would be the 1.2.0 firmware (which some people have downgraded to workaround this issue) as well as a current affected firmware.

1.2.0 firmware acpidump attached

Thanks Joe! By chance can you upgrade to current BIOS too and get that dump again? There is that workaround now (blacklist intel-vbtn) which you should be able to use now if you have no other problems with current firmware.

acpidump on latest (1.13.0) firmware.

Thanks so much!

I did some distro hopping with my XPS 15 9575 (BIOS 1.13.0)

Ubuntu 20.04.1 system had the same problem, but I found that the latest Pop!_OS (20.10) and Manjaro (20.2.1) did not have the issue. This leads me to believe that the issue was fixed on systems using updated kernels, such as kernel 5.8.8, but is still present on kernel version 5.8.0-36 that ships with the most up-to-date Ubuntu 20.04.1.

On Ubuntu 20.04.1, I was able to use the workaround found above, by adding "blacklist intel_vbtn" to /etc/modprobe.d/blacklist.conf and rebooting

Will possibly looks into whether Ubuntu 20.10 ships with a kernel that still has this problem

Hello Saturday 20 march 2021
running Ubuntu Mate "20.04.2 LTS (Focal Fossa)" (will stick to LTS)
so this is mate desktop here and architecture is of course 64 bits.
On my dell XPS 9575 the issue is present: either need to close and open screen hinge or wait 10 seconds to get to mousepad to life.
Did not try any unoficial patch.
I just updated from 1.12.1 bios to 1.14.1 with no change.
Thanks for reading.