Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook

On 7/11/26 18:46, Denis Benato wrote:
> On 7/10/26 20:45, Salvatore Bonaccorso wrote:
>> On Fri, Jul 10, 2026 at 03:31:08PM +0300, Ilpo Järvinen wrote:
>>> 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]
>>>>>
>>>>> 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
>>>>>>
>>>>>> 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?
>> Ponali did test, and reported back in the Debian bug at
>> https://bugs.debian.org/1141604#60, quoting:
>>
>>> 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.
>>>
> 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.
Ponali for some reason and afaics answered out-of-thread without you
among the recipients:
https://lore.kernel.org/all/[email protected]/

To quote:

"""
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
"""