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.
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Hi,
As a first step, please verify if the problem persists in 6.12.95-1 as
released. If yes then proceed with the next paragraph.
Can you please bisect the changes between 6.12.90 and 6.12.94 upstream
please? Doing so will require to compile and testing a couple of
kernels:
git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.90
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.12.90 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 6.12.94 to ensure this is "bad"
git checkout v6.12.94
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem exists
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.12.90
git bisect bad v6.12.94
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Thanks already.
Regards,
Salvatore
Hi,
As a first step, please verify if the problem persists in 6.12.95-1 as
released. If yes then proceed with the next paragraph.
Can you please bisect the changes between 6.12.90 and 6.12.94 upstream
please? Doing so will require to compile and testing a couple of
kernels:
git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.90
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.12.90 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 6.12.94 to ensure this is "bad"
git checkout v6.12.94
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem exists
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.12.90
git bisect bad v6.12.94
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Thanks already.
Regards,
Salvatore
Hi, I have installed 6.12.95-1, and saw the problem still persisting on this kernel version. I bisected the changes between 6.12.90 and 6.12.94 upstream and retrieved this log: git bisect start # status: waiting for both good and bad commits # good: [2538fbeff8a94ee2b54eb09d92209e24a1e650d4] Linux 6.12.90 git bisect good 2538fbeff8a94ee2b54eb09d92209e24a1e650d4 # status: waiting for bad commit, 1 good commit known # bad: [0b8f247169e487eff2d4c2dd531bc43f7efda2cb] Linux 6.12.94 git bisect bad 0b8f247169e487eff2d4c2dd531bc43f7efda2cb # bad: [a244395d8c563ed1bb26c3ef708db6aeeaa08084] ixgbevf: fix use-after-free in VEPA multicast source pruning git bisect bad a244395d8c563ed1bb26c3ef708db6aeeaa08084 # good: [07d3611389ba7d78b80ea360a42ce32ab2521fbc] reset: replace boolean parameters with flags parameter git bisect good 07d3611389ba7d78b80ea360a42ce32ab2521fbc # bad: [8f7573f81132380c84261d88324d79dec182935a] netfilter: skip recording stale or retransmitted INIT git bisect bad 8f7573f81132380c84261d88324d79dec182935a # bad: [de42f86e2cf5028a97e74c25869d1a962b13c301] slip: reject VJ receive packets on instances with no rstate array git bisect bad de42f86e2cf5028a97e74c25869d1a962b13c301 # bad: [9640eceaae407dad09e5b745c29a62617626a28c] crypto: sa2ul - Fix AEAD fallback algorithm names git bisect bad 9640eceaae407dad09e5b745c29a62617626a28c # bad: [3493a2305548537a16bf449f97aa279bbe1fca5c] clk: qcom: dispcc-sm4450: Fix DSI byte clock rate setting git bisect bad 3493a2305548537a16bf449f97aa279bbe1fca5c # good: [e2491aa90fd951cd522765303724bbec889c4ccc] nfs/blocklayout: Fix compilation error (`make W=1`) in bl_write_pagelist() git bisect good e2491aa90fd951cd522765303724bbec889c4ccc # bad: [5a04f9a36930792f6d64e28d43609e158d09b665] platform/x86: dell-wmi-sysman: bound enumeration string aggregation git bisect bad 5a04f9a36930792f6d64e28d43609e158d09b665 # bad: [5fa55e5f9d2331c35b28bc47643e24ff623edbe7] tty: serial: ip22zilog: Fix section mispatch warning git bisect bad 5fa55e5f9d2331c35b28bc47643e24ff623edbe7 # bad: [9bd6ec11769bad4e430d0a583bb099c8a4d189e9] platform/x86: asus-wmi: fix screenpad brightness range git bisect bad 9bd6ec11769bad4e430d0a583bb099c8a4d189e9 # good: [1f3f5f945ad1643daeaa3a15585ebd25faec36f4] platform/x86: asus-wmi: adjust screenpad power/brightness handling git bisect good 1f3f5f945ad1643daeaa3a15585ebd25faec36f4 # first bad commit: [9bd6ec11769bad4e430d0a583bb099c8a4d189e9] platform/x86: asus-wmi: fix screenpad brightness range Regards, Ponali
Hi, Thanks for doing that, so at least the commit is very related to screenpad's. Now the commit was backported to not only 9.12.91 but as well 7.0.10 (from 7.1-rc1). Can you confirm if the issue is as well present with the kernel in testing and/or unstable (aka 7.0.13-1 or 7.1.3-1)? If the issue is present there as well then it's generic regression otherwise something might be missing in the 6.12.y series, in both cases we can report the issue upstream. But clarifying if 7.0.13 and in particular 7.1.3 is affected as well would be very helpful. Can you please test those? Regards, Salvatore
Hi, I have tested both the testing and unstable sources of the kernel, and I saw this issue is still present on each of these versions. Regards, Ponali
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:
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?
Regards,
Salvatore
Hi Salvatore, The commit incriminated is this one: https://lore.kernel.org/all/20260302174431.349816-3-denis.benato@linux.dev/ As you can see that commit changes min/max of the brightness range, but does not touch the detection at all, 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.
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?
Hi, I have found the sysfs attribute for brightness control to be in /sys/class/backlight/asus_screenpad, and it appears on both 6.12.90 and 6.12.94. On 6.12.90, max_brightness reports 235. On 6.12.94, max_brightness reports 255. I have checked out to v6.12.94, reverted the suspect commit, and found the ScreenPad to be working as intended. Regards, Ponali
Hi all, Ponali did test, and reported back in the Debian bug at https://bugs.debian.org/1141604#60, quoting: Regards, Salvatore
The only reason I see is the the minimum might be greater than the maximum or negative and the kernel is rejecting it. Can you also report back on the minimum? Also if you could print a few values that would be helpful since I am not really seeing much here.
Hi, I have made a list of everything that the sysfs attribute can return in 6.12.90: actual_brightness: 70 bl_power: 4 brightness: 70 max_brightness: 235 scale: unknown type: raw device/driver_override: (null) device/modalias: platform:asus-nb-wmi device/uevent: DRIVER=asus-nb-wmi MODALIAS=platform:asus-nb-wmi power/async: disabled power/control: auto power/runtime_active_kids: 0 power/runtime_active_time: 0 power/runtime_enabled: disabled power/runtime_status: unsupported power/runtime_suspended_time: 0 power/runtime_usage: 0 In 6.12.94, only these files change: bl_power: 0 max_brightness: 255 These files do not report any information: uevent: [Blank file] device/cpufv: [Permission denied] power/autosuspend_delay_ms: [Input/output error] For both kernels, setting the brightness to 0 has both brightness and actual_brightness report 0. I cannot check the minimum brightness through uevent because it shows up as blank. Regards, Ponali