Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #93259 > unrolled thread

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

Started byPonali <ponali2k@gmail.com>
First post2026-07-07 07:40 +0200
Last post2026-07-18 10:40 +0200
Articles 17 — 6 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-07 07:40 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Salvatore Bonaccorso <carnil@debian.org> - 2026-07-07 08:20 +0200
    Processed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does  not detect ScreenPad on ASUS VivoBook "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-07 08:20 +0200
    Processed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does  not detect ScreenPad on ASUS VivoBook "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-07 08:20 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-08 07:30 +0200
      Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Salvatore Bonaccorso <carnil@debian.org> - 2026-07-08 17:00 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-08 18:50 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Salvatore Bonaccorso <carnil@debian.org> - 2026-07-09 22:20 +0200
      Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Denis Benato <denis.benato@linux.dev> - 2026-07-10 14:30 +0200
        Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> - 2026-07-10 14:40 +0200
          Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Salvatore Bonaccorso <carnil@debian.org> - 2026-07-10 20:50 +0200
            Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Denis Benato <denis.benato@linux.dev> - 2026-07-11 18:50 +0200
              Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Thorsten Leemhuis <regressions@leemhuis.info> - 2026-07-21 16:10 +0200
    Processed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does  not detect ScreenPad on ASUS VivoBook "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-09 22:20 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-10 19:40 +0200
    Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-11 19:50 +0200
      Bug#1141604: Fwd: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook Ponali <ponali2k@gmail.com> - 2026-07-18 10:40 +0200

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

FromPonali <ponali2k@gmail.com>
Date2026-07-07 07:40 +0200
SubjectBug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Message-ID<Ne6Hf-3f8N-1@gated-at.bofh.it>
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.

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


-- Package-specific info:
** Version:
Linux version 6.12.94+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.94-1 (2026-06-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.12.94+deb13-amd64 root=UUID=15d9e214-fc96-4d66-8bb2-ca00debecd8d ro quiet splash

** Not tainted

** Kernel log:
[    5.353184] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18
[    5.353261] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input19
[    5.353347] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input20
[    5.353421] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input21
[    5.628512] iwlwifi 0000:01:00.0: base HW address: 90:78:41:6e:ad:bb, OTP minor version: 0x4
[    5.699026] audit: type=1400 audit(1783399488.618:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=999 comm="apparmor_parser"
[    5.699067] audit: type=1400 audit(1783399488.618:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="QtWebEngineProcess" pid=1001 comm="apparmor_parser"
[    5.699106] audit: type=1400 audit(1783399488.618:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name=4D6F6E676F444220436F6D70617373 pid=1000 comm="apparmor_parser"
[    5.699150] audit: type=1400 audit(1783399488.618:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=1004 comm="apparmor_parser"
[    5.699590] audit: type=1400 audit(1783399488.618:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="TETR.IO" pid=1002 comm="apparmor_parser"
[    5.699627] audit: type=1400 audit(1783399488.618:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="1password" pid=998 comm="apparmor_parser"
[    5.699921] audit: type=1400 audit(1783399488.618:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=1005 comm="apparmor_parser"
[    5.701839] audit: type=1400 audit(1783399488.622:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1008 comm="apparmor_parser"
[    5.701846] audit: type=1400 audit(1783399488.622:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1009 comm="apparmor_parser"
[    5.702309] audit: type=1400 audit(1783399488.622:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-checkns" pid=1011 comm="apparmor_parser"
[    5.740740] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[    5.748932] iwlwifi 0000:01:00.0 wlo1: renamed from wlan0
[    6.009897] sd 2:0:0:0: Attached scsi generic sg0 type 0
[    6.101555] mc: Linux media interface: v0.10
[    6.159077] videodev: Linux video capture interface: v2.00
[    6.209894] Bluetooth: Core ver 2.22
[    6.209921] NET: Registered PF_BLUETOOTH protocol family
[    6.209923] Bluetooth: HCI device and connection manager initialized
[    6.209928] Bluetooth: HCI socket layer initialized
[    6.209931] Bluetooth: L2CAP socket layer initialized
[    6.209934] Bluetooth: SCO socket layer initialized
[    6.368166] usbcore: registered new interface driver btusb
[    6.373023] Bluetooth: hci0: Firmware revision 0.1 build 19 week 44 2021
[    6.379009] Bluetooth: hci0: Reading supported features failed (-16)
[    6.379029] Bluetooth: hci0: Error reading debug features
[    6.379042] Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported.
[    6.379192] usb 1-5: Found UVC 1.50 device USB2.0 HD IR UVC WebCam (13d3:56cb)
[    6.403132] usb 1-5: Found UVC 1.50 device USB2.0 HD IR UVC WebCam (13d3:56cb)
[    6.408699] usbcore: registered new interface driver uvcvideo
[    6.565950] nvme nvme0: using unchecked data buffer
[    6.751593] EXT4-fs (sda4): mounted filesystem 23610926-8e3c-4792-a1c2-7769f43fc351 r/w with ordered data mode. Quota mode: none.
[    6.772485] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    6.772491] Bluetooth: BNEP filters: protocol multicast
[    6.772498] Bluetooth: BNEP socket layer initialized
[    6.778239] Bluetooth: MGMT ver 1.23
[    6.786716] RPC: Registered named UNIX socket transport module.
[    6.786722] RPC: Registered udp transport module.
[    6.786724] RPC: Registered tcp transport module.
[    6.786726] RPC: Registered tcp-with-tls transport module.
[    6.786728] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    6.801958] NET: Registered PF_ALG protocol family
[    6.825260] block nvme0n1: No UUID available providing old NGUID
[    6.869061] Bluetooth: RFCOMM TTY layer initialized
[    6.869072] Bluetooth: RFCOMM socket layer initialized
[    6.869079] Bluetooth: RFCOMM ver 1.11
[    7.058369] NET: Registered PF_QIPCRTR protocol family
[    7.250627] iwlwifi 0000:01:00.0: Registered PHC clock: iwlwifi-PTP, with index: 0
[    7.893483] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B01F.0002/input/input22
[    7.893692] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B01F.0002/input/input23
[    7.893964] hid-generic 0005:046D:B01F.0002: input,hidraw1: BLUETOOTH HID v0.03 Keyboard [MX Anywhere 2] on 90:78:41:6e:ad:bf
[   10.904998] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[   10.954728] kauditd_printk_skb: 118 callbacks suppressed
[   10.954731] audit: type=1400 audit(1783399493.874:130): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1603 comm="Xorg" capability=12  capname="net_admin"
[   11.476576] audit: type=1400 audit(1783399494.394:131): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1603 comm="Xorg" capability=12  capname="net_admin"
[   12.190975] audit: type=1400 audit(1783399495.110:132): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1603 comm="Xorg" capability=2  capname="dac_read_search"
[   16.438264] input: Microsoft Bluetooth Keyboard as /devices/virtual/misc/uhid/0005:045E:0830.0003/input/input25
[   16.528937] input: Microsoft Bluetooth Keyboard Mouse as /devices/virtual/misc/uhid/0005:045E:0830.0003/input/input26
[   16.529265] input: Microsoft Bluetooth Keyboard as /devices/virtual/misc/uhid/0005:045E:0830.0003/input/input27
[   16.529502] hid-generic 0005:045E:0830.0003: input,hidraw2: BLUETOOTH HID v1.17 Keyboard [Microsoft Bluetooth Keyboard] on 90:78:41:6e:ad:bf
[   24.553567] wlo1: authenticate with 3a:07:16:fe:26:54 (local address=90:78:41:6e:ad:bb)
[   24.555008] wlo1: send auth to 3a:07:16:fe:26:54 (try 1/3)
[   24.566782] wlo1: authenticate with 3a:07:16:fe:26:54 (local address=90:78:41:6e:ad:bb)
[   24.566793] wlo1: send auth to 3a:07:16:fe:26:54 (try 1/3)
[   24.569193] wlo1: authenticated
[   24.572583] wlo1: associate with 3a:07:16:fe:26:54 (try 1/3)
[   24.577144] wlo1: RX AssocResp from 3a:07:16:fe:26:54 (capab=0x1111 status=0 aid=9)
[   24.579329] wlo1: associated
[   24.662454] wlo1: Limiting TX power to 23 (23 - 0) dBm as advertised by 3a:07:16:fe:26:54
[   26.790207] warning: `kdeconnectd' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
[  114.470551] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[  159.657343] netfs: FS-Cache loaded
[  159.679941] Key type dns_resolver registered
[  159.998615] Key type cifs.spnego registered
[  159.998629] Key type cifs.idmap registered
[  159.999498] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  159.999503] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  159.999506] CIFS: Attempting to mount //192.168.1.40/Public
[  160.390210] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.390218] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.390221] CIFS: Attempting to mount //192.168.1.40/T\xc3\xa9l\xc3\xa9chargement
[  160.436588] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.436598] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.436602] CIFS: Attempting to mount //192.168.1.40/S\xc3\xa9rie
[  160.480613] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.480625] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.480631] CIFS: Attempting to mount //192.168.1.40/PC ASUS Ponali
[  160.527851] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.527867] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.527873] CIFS: Attempting to mount //192.168.1.40/homes
[  160.574078] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.574088] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.574092] CIFS: Attempting to mount //192.168.1.40/home
[  160.694311] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  160.694321] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  160.694325] CIFS: Attempting to mount //192.168.1.40/MacMiniM4Agnes

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: VivoBook_ASUSLaptop X532FA_S532FA
product_version: 1.0       
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0       
bios_vendor: American Megatrends Inc.
bios_version: X532FA.306
board_vendor: ASUSTeK COMPUTER INC.
board_name: X532FA
board_version: 1.0       

** Configuration for modprobe:
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
blacklist microcode
options snd_pcsp index=-2
options cx88_alsa index=-2
options snd_atiixp_modem index=-2
options snd_intel8x0m index=-2
options snd_via82xx_modem index=-2
options bonding max_bonds=0
options dummy numdummies=0
options ifb numifbs=0

** Loaded modules:
nls_utf8
cifs
cifs_arc4
nls_ucs2_utils
cifs_md4
dns_resolver
netfs
exfat
ccm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
xt_CHECKSUM
xt_MASQUERADE
xt_conntrack
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nft_compat
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
bridge
stp
llc
qrtr
uhid
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
bnep
sunrpc
uvcvideo
btusb
btrtl
btintel
videobuf2_vmalloc
btbcm
uvc
btmtk
videobuf2_memops
videobuf2_v4l2
bluetooth
videodev
videobuf2_common
mc
ecdh_generic
sg
intel_uncore_frequency
intel_uncore_frequency_common
snd_sof_pci_intel_cnl
snd_sof_intel_hda_generic
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda_common
x86_pkg_temp_thermal
snd_soc_hdac_hda
snd_sof_intel_hda_mlink
binfmt_misc
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
intel_powerclamp
snd_sof
nls_ascii
coretemp
nls_cp437
vfat
kvm_intel
fat
snd_sof_utils
snd_soc_acpi_intel_match
snd_soc_acpi
iwlmvm
soundwire_bus
kvm
snd_soc_avs
mac80211
snd_soc_hda_codec
snd_hda_ext_core
snd_hda_codec_hdmi
snd_soc_core
snd_hda_codec_generic
snd_compress
snd_pcm_dmaengine
irqbypass
libarc4
snd_hda_intel
crct10dif_pclmul
ghash_clmulni_intel
snd_intel_dspcfg
sha512_ssse3
snd_intel_sdw_acpi
sha256_ssse3
snd_hda_codec
sha1_ssse3
iwlwifi
aesni_intel
snd_hda_core
gf128mul
crypto_simd
processor_thermal_device_pci_legacy
cryptd
snd_hwdep
processor_thermal_device
mei_hdcp
mei_pxp
processor_thermal_wt_hint
intel_rapl_msr
snd_pcm
rapl
intel_cstate
cfg80211
asus_nb_wmi
snd_timer
processor_thermal_rfim
asus_wmi
intel_uncore
sparse_keymap
mei_me
processor_thermal_rapl
intel_rapl_common
snd
platform_profile
processor_thermal_wt_req
wmi_bmof
pcspkr
rfkill
mei
processor_thermal_power_floor
soundcore
processor_thermal_mbox
intel_soc_dts_iosf
intel_pch_thermal
intel_pmc_core
intel_vsec
int3403_thermal
int340x_thermal_zone
ac
joydev
pmt_telemetry
int3400_thermal
pmt_class
acpi_thermal_rel
acpi_pad
acpi_tad
evdev
msr
parport_pc
dm_mod
ppdev
lp
parport
configfs
efi_pstore
nfnetlink
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
xor
raid6_pq
libcrc32c
crc32c_generic
sd_mod
uas
usb_storage
i915
drm_buddy
i2c_algo_bit
drm_display_helper
cec
hid_multitouch
rc_core
hid_generic
ttm
i2c_hid_acpi
i2c_hid
drm_kms_helper
hid
ahci
iTCO_wdt
xhci_pci
libahci
intel_pmc_bxt
xhci_hcd
libata
iTCO_vendor_support
nvme
drm
watchdog
usbcore
nvme_core
scsi_mod
crc32_pclmul
intel_lpss_pci
crc32c_intel
serio_raw
intel_lpss
i2c_i801
nvme_auth
idma64
i2c_smbus
video
usb_common
scsi_common
battery
wmi
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Coffee Lake HOST and DRAM Controller [8086:3e34] (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	IOMMU group: 1
	Capabilities: <access denied>
	Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
	DeviceName: VGA
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 142
	IOMMU group: 0
	Region 0: Memory at b0000000 (64-bit, non-prefetchable) [size=16M]
	Region 2: Memory at a0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 3000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 2
	Region 0: Memory at b1310000 (64-bit, non-prefetchable) [size=32K]
	Capabilities: <access denied>
	Kernel driver in use: proc_thermal
	Kernel modules: processor_thermal_device_pci_legacy

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 255
	IOMMU group: 3
	Region 0: Memory at b1329000 (64-bit, non-prefetchable) [disabled] [size=4K]
	Capabilities: <access denied>

00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Point-LP Thermal Controller [8086:9df9] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 4
	Region 0: Memory at b1328000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: intel_pch_thermal
	Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller [8086:9ded] (rev 30) (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device [1043:201f]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 133
	IOMMU group: 5
	Region 0: Memory at b1300000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Cannon Point-LP Shared SRAM [8086:9def] (rev 30)
	Subsystem: Intel Corporation Device [8086:7270]
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	IOMMU group: 5
	Region 0: Memory at b131e000 (64-bit, non-prefetchable) [disabled] [size=8K]
	Region 2: Memory at b1327000 (64-bit, non-prefetchable) [disabled] [size=4K]
	Capabilities: <access denied>

00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 [8086:9de8] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 6
	Region 0: Memory at b1326000 (64-bit, non-prefetchable) [size=4K]
	Region 2: Memory at b1325000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: intel-lpss
	Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #1 [8086:9de9] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 17
	IOMMU group: 6
	Region 0: Memory at b1324000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: intel-lpss
	Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Cannon Point-LP MEI Controller #1 [8086:9de0] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 143
	IOMMU group: 7
	Region 0: Memory at b1323000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:17.0 RAID bus controller [0104]: Intel Corporation 82801 Mobile SATA Controller [RAID mode] [8086:282a] (rev 30) (prog-if 00 [Vendor specific])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 8
	Region 0: Memory at b131c000 (32-bit, non-prefetchable) [size=8K]
	Region 1: Memory at b1322000 (32-bit, non-prefetchable) [size=256]
	Region 2: I/O ports at 3090 [size=8]
	Region 3: I/O ports at 3080 [size=4]
	Region 4: I/O ports at 3060 [size=32]
	Region 5: Memory at b1321000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Point-LP PCI Express Root Port #10 [8086:9db1] (rev f0) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 122
	IOMMU group: 9
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: b1200000-b12fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.4 PCI bridge [0604]: Intel Corporation Cannon Point-LP PCI Express Root Port #13 [8086:9db4] (rev f0) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 123
	IOMMU group: 10
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: b1100000-b11fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1f.0 ISA bridge [0601]: Intel Corporation Cannon Point-LP LPC Controller [8086:9d84] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	IOMMU group: 11

00:1f.3 Audio device [0403]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 30) (prog-if 80 [HDA compatible with vendor specific extensions])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 145
	IOMMU group: 11
	Region 0: Memory at b1318000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at b1000000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_cnl

00:1f.4 SMBus [0c05]: Intel Corporation Cannon Point-LP SMBus Controller [8086:9da3] (rev 30)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1991]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 11
	Region 0: Memory at b1320000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at efa0 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller [8086:9da4] (rev 30)
	Subsystem: Intel Corporation Device [8086:7270]
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	IOMMU group: 11
	Region 0: Memory at fe010000 (32-bit, non-prefetchable) [size=4K]

01:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
	DeviceName: WLAN
	Subsystem: Intel Corporation Device [8086:0110]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 144
	IOMMU group: 12
	Region 0: Memory at b1200000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

02:00.0 Non-Volatile memory controller [0108]: Intel Corporation SSD 660P Series [8086:f1a8] (rev 03) (prog-if 02 [NVM Express])
	Subsystem: Intel Corporation Device [8086:390d]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 13
	Region 0: Memory at b1100000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: nvme
	Kernel modules: nvme


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 13d3:56cb IMC Networks USB2.0 HD IR UVC WebCam
Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bluetooth wireless interface
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0634:5607 Micron Technology, Inc. CT2000X10SSD9


-- System Information:
Debian Release: 13.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.94+deb13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.12.94+deb13-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.148.4
ii  kmod                                    34.2-2
ii  linux-base                              4.12.1

Versions of packages linux-image-6.12.94+deb13-amd64 recommends:
ii  apparmor  4.1.0-1

Versions of packages linux-image-6.12.94+deb13-amd64 suggests:
pn  debian-kernel-handbook  <none>
pn  firmware-linux-free     <none>
ii  grub-efi-amd64          2.12-9+deb13u2
pn  linux-doc-6.12          <none>

Versions of packages linux-image-6.12.94+deb13-amd64 is related to:
pn  firmware-amd-graphics      <none>
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
ii  firmware-intel-graphics    20250410-2
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
ii  firmware-iwlwifi           20250410-2
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
pn  firmware-misc-nonfree      <none>
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
ii  firmware-realtek           20250410-2
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

[toc] | [next] | [standalone]


#93260

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-07-07 08:20 +0200
Message-ID<Ne7jX-3fwc-3@gated-at.bofh.it>
In reply to#93259
Control: tags -1 + moreinfo

Hi,

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.

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

[toc] | [prev] | [next] | [standalone]


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

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2026-07-07 08:20 +0200
SubjectProcessed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Message-ID<Ne7jX-3fwc-5@gated-at.bofh.it>
In reply to#93259
Processing control commands:

> tags -1 + moreinfo
Bug #1141604 [src:linux] linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Added tag(s) moreinfo.

-- 
1141604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141604
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


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

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2026-07-07 08:20 +0200
SubjectProcessed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Message-ID<Ne7jX-3fwc-9@gated-at.bofh.it>
In reply to#93259
Processing control commands:

> tags -1 + moreinfo
Bug #1141604 [src:linux] linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Ignoring request to alter tags of bug #1141604 to the same tags previously set

-- 
1141604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141604
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#93268

FromPonali <ponali2k@gmail.com>
Date2026-07-08 07:30 +0200
Message-ID<Net18-3rJU-29@gated-at.bofh.it>
In reply to#93259
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

[toc] | [prev] | [next] | [standalone]


#93273

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-07-08 17:00 +0200
Message-ID<NeBUJ-3wwJ-1@gated-at.bofh.it>
In reply to#93268
Hi,

On Wed, Jul 08, 2026 at 07:20:09AM +0200, Ponali wrote:
> 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

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

[toc] | [prev] | [next] | [standalone]


#93274

FromPonali <ponali2k@gmail.com>
Date2026-07-08 18:50 +0200
Message-ID<NeDDb-3xtO-1@gated-at.bofh.it>
In reply to#93259
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

[toc] | [prev] | [next] | [standalone]


#93299

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-07-09 22:20 +0200
Message-ID<Nf3nX-3LnK-11@gated-at.bofh.it>
In reply to#93259
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

[toc] | [prev] | [next] | [standalone]


#93304

FromDenis Benato <denis.benato@linux.dev>
Date2026-07-10 14:30 +0200
Message-ID<NfiwF-3TQl-3@gated-at.bofh.it>
In reply to#93299
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

[toc] | [prev] | [next] | [standalone]


#93305

FromIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date2026-07-10 14:40 +0200
Message-ID<NfiGl-3TUd-9@gated-at.bofh.it>
In reply to#93304
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. 

[toc] | [prev] | [next] | [standalone]


#93308

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-07-10 20:50 +0200
Message-ID<Nfosp-3WXN-3@gated-at.bofh.it>
In reply to#93305
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

[toc] | [prev] | [next] | [standalone]


#93318

FromDenis Benato <denis.benato@linux.dev>
Date2026-07-11 18:50 +0200
Message-ID<NfJ3P-48dP-1@gated-at.bofh.it>
In reply to#93308
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

[toc] | [prev] | [next] | [standalone]


#93409

FromThorsten Leemhuis <regressions@leemhuis.info>
Date2026-07-21 16:10 +0200
Message-ID<Njjkt-66GI-7@gated-at.bofh.it>
In reply to#93318
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/178362762638.911488.8564892548331679884@eldamar.lan
>>>>>
>>>>> 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
>>>>>>
>>>>>> 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.
Ponali for some reason and afaics answered out-of-thread without you
among the recipients:
https://lore.kernel.org/all/5e456d33-7e8f-4e54-9149-ac3cff229445@gmail.com/

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

[toc] | [prev] | [next] | [standalone]


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

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2026-07-09 22:20 +0200
SubjectProcessed: Re: Bug#1141604: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Message-ID<Nf3nX-3LnK-13@gated-at.bofh.it>
In reply to#93259
Processing control commands:

> forwarded -1 https://lore.kernel.org/regressions/178362762638.911488.8564892548331679884@eldamar.lan
Bug #1141604 [src:linux] linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Set Bug forwarded-to-address to 'https://lore.kernel.org/regressions/178362762638.911488.8564892548331679884@eldamar.lan'.
> tags -1 + upstream
Bug #1141604 [src:linux] linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Ignoring request to alter tags of bug #1141604 to the same tags previously set

-- 
1141604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141604
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#93307

FromPonali <ponali2k@gmail.com>
Date2026-07-10 19:40 +0200
Message-ID<NfnmF-3Wpd-13@gated-at.bofh.it>
In reply to#93259
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

[toc] | [prev] | [next] | [standalone]


#93319

FromPonali <ponali2k@gmail.com>
Date2026-07-11 19:50 +0200
Message-ID<NfJZT-48Kl-3@gated-at.bofh.it>
In reply to#93259
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

[toc] | [prev] | [next] | [standalone]


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

FromPonali <ponali2k@gmail.com>
Date2026-07-18 10:40 +0200
SubjectBug#1141604: Fwd: linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook
Message-ID<Ni8Ku-5td2-13@gated-at.bofh.it>
In reply to#93319


-------- Forwarded Message --------
Subject: 	linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on 
ASUS VivoBook
Date: 	Sat, 11 Jul 2026 19:43:19 +0200
From: 	Ponali <ponali2k@gmail.com>
To: 	1141604@bugs.debian.org



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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web