This problem exists in all kernels I have tried newer than 5.7, including 5.11 HWE-Edge and several mainlines, including 5.12.x and 5.13.x (RC), as well as 5.10 OEM.
There was a problem identical to this reported at upower (https://gitlab.freedesktop.org/upower/upower/-/issues/126), but it was supposedly fixed with a kernel commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=992a60ed0d5e312ce9a485c9e12097ac82ae4b3e). I'm still seeing the bug, however. Everything in the description in the thread of comments at upower is what I am seeing to the letter. If the laptop finishes POST and loads GRUB with the power disconnected, upower will report the power supply state as offline from there forward, though then the desktop environment responds correctly to power state changes. If it finishes POST and loads GRUB with power connected, it reports the power online from there forward, and that does prevent the desktop environment from detecting power state changes. This issue was also present in a live session of Manjaro I tried with 5.10. ** Bug watch added: gitlab.freedesktop.org/upower/upower/-/issues #126 https://gitlab.freedesktop.org/upower/upower/-/issues/126 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.10 in Ubuntu. https://bugs.launchpad.net/bugs/1933028 Title: Power supply disconnection not recognized on Dell XPS 13 9310 w/5.10 OEM kernel Status in linux-oem-5.10 package in Ubuntu: New Bug description: I bought a Dell XPS 9310 "Developer edition" with Ubuntu 20.04 preinstalled. It came with 5.6 OEM kernel, and when I unplugged the AC power, it would properly recognize it and do the things like switch to a dimmer display (as configured) and sleep if the lid is closed (rather than just lock the session as it would do with AC power connected). Since the 5.6 kernel auto updated to 5.10, this has not worked, with exceptions (below). Unplugging the power supply generates the appropriate ACPI event as noted in acpi_listen (and TLP does properly recognize the on-battery status and apply the on-battery changes), and upower does report the power supply as being offline with 'upower --monitor-detail'. However, this portion of the details: [04:00:48.093] daemon changed: daemon-version: 0.99.11 on-battery: no lid-is-closed: no lid-is-present: yes critical-action: HybridSleep is not present when the command is executed while running 5.10 OEM. It is present when the 5.6 kernel is running. It seems to correspond 1:1 with the proper function when the power supply is removed... if the 'daemon changed section' exists, it works, otherwise not. If I am running KDE Plasma, when the issue is manifesting, the tooltip for the power management widget says "plugged in but discharging," claiming the power supply is attached but not producing enough power. It is definitely not connected, and is wholly on battery power when it says that. It's not just a KDE thing, though, as the same malfunction happens in GNOME in the bone-stock Dell install of Ubuntu 20.04 also. It just doesn't tell the bit about "plugged in but discharging," as far as I know. I am not very familiar with GNOME. Now, the exceptions. If I boot the laptop while on battery power, the connection and disconnection of the power supply will be properly recognized until the next boot. The 'daemon changed' bit from upower will be reported. If the next boot is on AC, it resumes working incorrectly, with or without a cold boot in between. I have tried various kernel parameters to get it to work, but while a couple of times I thought I finally "got it," the improvement proved ephemeral. When I added 'acpi_rev_override=1 acpi_osi=Linux' to the kernel parameters using GRUB, it would work properly for the next boot (on AC), but only for that boot. Afterward, it would malfunction like 5.10 OEM usually does when booting on AC. I had the same happen with other combinations of ACPI_* kernel parameters. None ever had its effect persist more than one boot. I tried telling it that it was Windows (which worked for one boot), or using two parameters to say it was Linux (acpi_osi and acpi_os_name), and it worked for one boot also. I don't recall it ever working without using the acpi_rev_override parameter, though I tried so many things that I may be in error about that. The same faulty behavior is noted when using the standard Ubuntu kernel 5.8 (HWE) or mainline 5.11+ kernels. I also tried Manjaro KDE from a live session (5.10 kernel), and it did the same as in Ubuntu 20.04 (since the live session had booted on AC, unplugging power did not register; it again said "plugged in but discharging" in the power widget tooltip). Whatever patch Dell must have checked in to 5.6 to make the power state changes work correctly, if there is one, apparently did not make it to 5.10, or else it is not compatible fully with 5.10. Machine specs are i5-1135G7, 16GB, Dell firmware 2.2.0 (latest, as of this writing). No touch, 1920x1200 display, NVMe SSD (1TB SK Hynix, but the same behavior is noted with the stock 256GB WD NVMe SSD). Thw power supply I am using is the factory Dell unit (USB-C connector) plugged directly into the unit with no intermediate hub. Nothing is plugged in other than the power. The faulty versions of the kernel include all of the 5.10 variants I tried, most recently 5.10.1029.30. It happens on Ubuntu 20.04 proper as well as the downstream variant, KDE Neon (20.04 base). What I expected to happen: When I boot with the AC power plugged in, then later unplug it, I expect the system to apply the settings I chose for on-battery operation: Dimmer LCD backlight, enter standby when lid is closed, and recognition of the on-battery status from the power applet in the tray. The "power unplugged" system sound is heard. What actually happens: The "on battery" settings are not applied, and the power applet reports "plugged in but discharging." No system sound is heard. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-5.10/+bug/1933028/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
