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

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

[Salvatore Bonaccorso]

Control: forwarded -1 https://lore.kernel.org/regressions/178362762638.911488.8564892548331679884@eldamar.lan
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: ponali2k@gmail.com
> 
> 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?

Regards,
Salvatore

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

[Denis Benato]

On 7/9/26 22:08, Salvatore Bonaccorso wrote:
> Control: forwarded -1 https://lore.kernel.org/regressions/178362762638.911488.8564892548331679884@eldamar.lan
> 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: ponali2k@gmail.com
>>
>> 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/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.

> Regards,
> Salvatore

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

[Ilpo Järvinen]

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/178362762638.911488.8564892548331679884@eldamar.lan
> > 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: ponali2k@gmail.com
> >>
> >> 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/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, 

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. 

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

[Salvatore Bonaccorso]

Hi all,

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/178362762638.911488.8564892548331679884@eldamar.lan
> > > 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: ponali2k@gmail.com
> > >>
> > >> 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/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, 
> 
> 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.
> 
> 
> Regards,
> 
> Ponali

Regards,
Salvatore

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

[Denis Benato]

On 7/10/26 20:45, Salvatore Bonaccorso wrote:
> Hi all,
>
> 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/178362762638.911488.8564892548331679884@eldamar.lan
>>>> 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: ponali2k@gmail.com
>>>>>
>>>>> 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/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, 
>> 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.
>> Regards,
>>
>> Ponali
> Regards,
> Salvatore