No touchscreen after sleeping on Acer Spin 512 R851TN (SPARKY360 Gemini lake)

[megacar1]

Hi, I already raised this on forum.chrultrabook.com but now I found this to be the preferred place for bugs. Issue happens under Fedora 39, Ubuntu 23.10 and most probably any other distribution.

I would try to use the workaround from https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Yoga_(Gen_3)#Fix_touchscreen_after_resume but I don't know how to find correct acpi-call for my raydium touchscreen..

log:

Feb 04 21:23:13 fedora kernel: ACPI: PM: Preparing to enter system sleep state S3
Feb 04 21:23:13 fedora kernel: ACPI: EC: event blocked
Feb 04 21:23:13 fedora kernel: ACPI: EC: EC stopped
Feb 04 21:23:13 fedora kernel: ACPI: PM: Saving platform NVS memory
Feb 04 21:23:13 fedora kernel: Disabling non-boot CPUs ...
Feb 04 21:23:13 fedora kernel: smpboot: CPU 1 is now offline
Feb 04 21:23:13 fedora kernel: smpboot: CPU 2 is now offline
Feb 04 21:23:13 fedora kernel: smpboot: CPU 3 is now offline
Feb 04 21:23:13 fedora kernel: ACPI: PM: Low-level resume complete
Feb 04 21:23:13 fedora kernel: ACPI: EC: EC started
Feb 04 21:23:13 fedora kernel: ACPI: PM: Restoring platform NVS memory
Feb 04 21:23:13 fedora kernel: Enabling non-boot CPUs ...
Feb 04 21:23:13 fedora kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Feb 04 21:23:13 fedora kernel: CPU1 is up
Feb 04 21:23:13 fedora kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4
Feb 04 21:23:13 fedora kernel: CPU2 is up
Feb 04 21:23:13 fedora kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6
Feb 04 21:23:13 fedora kernel: CPU3 is up
Feb 04 21:23:13 fedora kernel: ACPI: PM: Waking up from system sleep state S3
Feb 04 21:23:13 fedora kernel: ACPI: EC: interrupt unblocked
Feb 04 21:23:13 fedora kernel: ACPI: EC: event unblocked
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: report size changes, was: 82, new: 54
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x51f vs 0x00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x51f vs 0x00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x51f vs 0x00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x51f vs 0x00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x51f vs 0x00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x2a4c vs 0x10
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x9b4 vs 0x4126
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x611 vs 0x8800
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x956 vs 0x300
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x987 vs 0x104
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x67c vs 0xb00
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x962 vs 0x420
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0xad6 vs 0x211
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x527 vs 0x80
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0x9ce vs 0x411
Feb 04 21:23:13 fedora kernel: raydium_ts i2c-RAYD0001:00: raydium_i2c_irq: invalid packet crc 0xaf5 vs 0x100

[MrChromebox]

I'm not sure this is a firmware issue -- if the firmware correctly detects and sets up the touchscreen, the rest is on the OS

[megacar1]

ok, and what about the linked issue above? same issue, turned out to be bios issue... Is there any troubleshooting process that can nail it down? Whether its kernel, OS, bios etc... so you suspect it's the mainline kernel issue then? considering it happens on different distributions... would you be so kind and point me to the github or whatever place where linux kernel bugs can be raised? any advice in narrowing it down will be appreciated...do you think it can be gnome? is it worth a shot to try with KDE? like trying arch..

[MrChromebox]

the linked issue above doesn't give any info on what the bios issue is, just a few workarounds which are not applicable for your device. I don't have any resources for debugging touchscreens. The Arch forums are probably your best bet, IDK

[megacar1]

installed arch linux, same errors... ok, will head over to their forum

[megacar1]

Hi, i opened a bug on mainline linux kernel, since this happens across all distributions I tried https://bugzilla.kernel.org/show_bug.cgi?id=218497

However, the guys that maintain the kernel have a valid observation:

You mentioned in the forum post that the device in a converted Chromebook with a custom firmware. Given that the driver code for the Raydium controller is the same in the mainline kernel and the kernel used in Chromebooks, and works fine with the original firmware, I would suggest you to discuss this with MrChromebox folks.

Thanks.

Dmitry

So, if the same mainline kernel and same driver within ChromeOS works fine with original firmware, but fails with your firmware, its most probably the firmware's fault. Should I open a bug to coreboot maintainers? or they will not care about this hardware? If you don't mind me asking, how exaclty you produce these firmware images? you take the vanilla coreboot project, and then modify it to support the specifics of chromebook hardware?

[MrChromebox]

does booting a mainline kernel via AltFw on the stock firmware produce a working touchscreen? The ChromeOS and mainline kernels are not exactly alike

[megacar1]

Can you provide some link with steps how to do that, what is altfw ? I have another identical machine that is running stock chromeOS so I can test it out

[MrChromebox]

RW_LEGACY firmware. install via script, boot Linux USB via CTRL+L from the developer mode boot screen

[megacar1]

hi, I did something I wanted to avoid all this time, installed windows 11. good news for you, everything works, sleeping, touching... :) So I guess firmware is just fine, it's linux kernel.. Unfortunately I quit from linux on this machine and call it a day..

[megacar1]

unfortunately, further usage of windows shows the same issue. after subsequent sleep, touch unresponsive, and after touching the screen, crashed with blue screen

windows logs suggest to look for new firmware

error, event 137, kernel-power: The system firmware has changed the processor's memory type range registers (MTRRs) across a sleep state transition (S4). This can result in reduced resume performance.
error, event 34, kernel-processor-power: Idle power management features on processor 0 in group 0 are disabled due to a firmware problem. Check with the computer manufacturer for updated firmware.
error, event 34, kernel-processor-power: Idle power management features on processor 1 in group 0 are disabled due to a firmware problem. Check with the computer manufacturer for updated firmware.
error, event 34, kernel-processor-power: Idle power management features on processor 2 in group 0 are disabled due to a firmware problem. Check with the computer manufacturer for updated firmware.
error, event 34, kernel-processor-power: Idle power management features on processor 3 in group 0 are disabled due to a firmware problem. Check with the computer manufacturer for updated firmware.
warning, event 219, kernel-PnP: The driver \Driver\WudfRd failed to load for the device HID\GOOG0006\7&32a0ea0&0&0000.
warning, event 219, kernel-PnP: The driver \Driver\WUDFRd failed to load for the device ACPI\INT3400\0.

edit: it seems this a separate issue non related to touchscreen, i tried disabling the touchscreen, BSOD still happens. i will open a separate bug

[megacar1]

Regarding altFW, your documentation states my platform (sparky360) had some issues with legacyFW, something about payload not displayed. Thats the reason I avoided it in the first place and went with full uefi rom. If you have a reason to believe there is any chance legacyFW might behave better in sleep states, i might give it a go... Can i go directly from uefi rom to legacy using your script? Or I have to go back to stock? Also btw I dont have secure boot enabled, but I guess this has nothing to do with handling acpi events...