Where to report heisenbug issues with Intel-based laptops backlights brightness sometimes set to minimum when reopening the screen lid?

Ask Fedora
, , , , , , , ,
1

TLDR: where do I report this so that chipsets & firmware folks see it?

Here is a short summary of the problem:

  • For years/decades, I (and others) have been experiencing a heisenbug where the laptop’s screen backlight brightness is sometimes set to the minimum when reopening the lid:
    • while docked on a docking station, or;
    • after undocking with the lid closed (i.e. with a suspend & resume cycle).
  • This has been observed on Lenovo, Framework and Dell laptops
  • It’s very hard to reproduce, even if you close & reopen your lid 60+ times. Usually it happens when you are not trying to reproduce it.
  • I am unsure whether the issue is related to docking stations only, or if it would also happen with regular external monitors + keyboard + mouse connections, or if it could happen even without any external display involved.

I tried reporting it upstream in upower here but am told that upower can’t possibly be the culprit, and to report it downstream and ask for your help.

I found a rare corresponding report in g-s-d here. I discussed (over chat) with one of the GNOME Shell + Mutter + G-S-D developers, but that person is telling me that it is highly unlikely to be caused by G-S-D.

I’m currently running dbus-monitor --system 'interface=org.freedesktop.login1.Session,member=SetBrightness' to see if it catches anything the next time the issue occurs, we’ll see if G-S-D is involved at all. I have a lot of other stuff written down in my notes but I’ll spare you those for now.

Meanwhile, upstream upower said, among other things:

The dock is a complicated device. When the system woke up from suspend, issues were usually found between EC, firmware, and kernel. These issues range from ACPI, video, and platform drivers to firmware.

I think the best way is to file a bug to Fedora bz with a dmesg log attached and get help from Lenovo support service.

From my experience, I know that filing a bug in the wrong component in RH Bugzilla is a long road to nowhere…
So my question for you is this: which component must I file this issue in there, for it to get properly investigated by the RH laptop HW enablement team and/or the Lenovo / Dell / Framework / Intel engineers?

2

This issue has been discussed at times here a few times.

It seems that several docking stations do not cause the system to poll the attached devices when waking from suspend so the are either not functional or improperly configured.

In many cases the solution was to wake the system up then disconnect and reconnect the docking station to the system. This forces a new poll of the attached devices and proper config.

3

Good news: after some more days of troubleshooting I figured out a way to consistently reproduce it, even without a docking station, and the issue has been identified here, with a proposed fix.

Hopefully this should fix the issue that you say had been discussed here previously (I was somehow unable to find existing threads about this), without resorting to workarounds like “unplug it and plug it again”, unless you folks were truly experiencing a bug in the docking stations (but it didn’t seem that way, in my case).