On Fri, 10 Jul 2026, Denis Benato wrote: > On 7/9/26 22:08, Salvatore Bonaccorso wrote: > > Control: forwarded -1 > > https://lore.kernel.org/regressions/[email protected] > > Control: tags -1 + upstream > > > > Hi, > > > > Ponali reported in Debian (https://bugs.debian.org/1141604) the > > following issue after updating from 6.12.90 to 6.12.94. First quoting > > the report: > > > > On Tue, Jul 07, 2026 at 07:37:24AM +0200, Ponali wrote: > >> Package: src:linux > >> Version: 6.12.94-1 > >> Severity: normal > >> Tags: upstream, regression > >> X-Debbugs-Cc: [email protected] > >> > >> Last known working kernel: 6.12.90-1 > >> First known broken kernel: 6.12.94-1 > >> > >> > >> Dear Maintainer, > >> > >> I upgraded all my packages through apt, which also upgraded the linux image > >> from 6.12.90 to 6.12.94. > >> > >> I expected the ScreenPad display to continue to be detected and exposed as > >> a > >> DRM output, like on 6.12.90. The ScreenPad being the trackpad with a > >> screen, > >> which came with my computer (ASUS VivoBook X532FA_S532FA). > >> > >> After upgrading and rebooting, the new kernel caused a regression where the > >> display of the ScreenPad fails to get recognized by the kernel. The > >> touchpad > >> functionality still works. Usually, the ScreenPad would appear as > >> "HDMI-A-1". > >> The DRM connector for it still exists (/sys/class/drm/card0-HDMI-A-1), but > >> "status" reports "disabled" > >> > >> I could not get the ScreenPad display to be recognized again on the new > >> kernel, > >> so I configured GRUB to automatically boot to the 6.12.90 kernel through > >> the > >> "Advanced Options". The ScreenPad is recognized on older kernel versions, > >> so I > >> am still able to use it (until a new LPE comes around). > >> > >> To replicate: > >> 1. Boot with 6.12.90. The ScreenPad display is detected as HDMI-A-1. > >> 2. Boot with 6.12.94 with the exact same hardware. > >> 3. The ScreenPad display is no longer usable. > >> > >> > >> My main display is eDP-1 (1920x1080), though it isn't essential. My GPU is > >> an > >> integrated Intel iGPU, and the driver used for both screens is i915. I have > >> booted to the new kernel for reportbug to get all the information > >> automatically, but i will continue to use the old one until the appropriate > >> time. > > Now, Ponali did bisect the changes between 6.12.90 and 6.12.94 and > > found that the backport of the commit 8d95d1f4aa5c ("platform/x86: > > asus-wmi: fix screenpad brightness range") changed the behaviour. > > Bisect log is at: https://bugs.debian.org/1141604#22 > > > > As this change was backported to other stable series as well I asked > > Ponali to please test 7.0.y and 7.1.y and confirmed that both 7.0.13 > > and as well 7.1.3 show the hehaviour. > > > > #regzbot introduced: 8d95d1f4aa5c76202b0833a70998769384612488 > > #regzbot link: https://bugs.debian.org/1141604 > > > > Is there anything Ponali can report back to further debug the issue? > Hi Salvatore, > > The commit incriminated is this one: > https://lore.kernel.org/all/[email protected]/ > > As you can see that commit changes min/max of the brightness range, but > does not touch the detection at all,
To be more precise, it DOES change read_screenpad_backlight_power() -> asus_wmi_get_devstate_simple() but AFAICT that cannot make things worse because asus_wmi_get_devstate_simple() used in both cases, so I was left to wonder the same thing as you. That being said, it's hard to see how bisect could point this to a wrong commit either because good/bad should be pretty obvious. Did reverting the suspect commit on top of 6.12.94 result in a working system? -- i. > while the user is complaining about "the display of the ScreenPad fails to > get recognised by the kernel" and I can only thing about two things: > - I got the range wrong and the kernel is rejecting the device due to wrong > min/max > - It's not true that the kernel fails to recognise the device and instead > it's userspace refusing to expose it (this happened recently with upower for > the battery so it can very well be a possibility) > > > From the dmesg logs I don't see kernel being angry and rejecting the > > screenpad so I am leaning on the second option: may I ask for the user > > to try identify the sysfs attribute responsible to control the > > brightness and get me the range of min/max? Also I would be curious to > > know if changing desktop like KDE or GNOME changes something.
