Add support for ASRock Steel Legend 360 LCD - #10
Conversation
|
- Remove the Information log in SendJpegFrame; it fired on every frame for every panel model. - Sample the byte-3 timestamp once per frame so all chunks of a frame carry the same value. - Share the realtimeDisplay disable path, then suspend for Steel Legend. - Formatting cleanup; add the panel to the README device table.
|
Thanks for this, @Ulfy! It's merged and shipped in v0.3.4 (deb, rpm, tarball, and Before merging I pushed a small follow-up commit (5746974) onto your branch:
Apart from the removed log line, the bytes on the wire should match your version exactly. I don't have a Steel Legend here, though, so could you install 0.3.4 and confirm the panel still works? In particular:
Replug the panel once after installing so the udev rule applies. If anything's off, attach a log from |
|
Ok, great! So after starting fresh with v0.3.4 from the AUR, here is what I found:
I did find a separate suspend/resume issue. If the PC sleeps while InfoPanel is running, the LCD is black after wake. The kernel reports an xHCI resume error/reinit on the USB controller hosting the LCD. Toggling the stream off/on successfully lights up the panel, but the profile image/sensors are just static. Restarting the stream within InfoPanel or killing/launching InfoPanel doesn't fix it... only a full power cycle clears the issue. So the Steel Legend support itself looks good; sans the suspend/resume issue. I attached the relevant infopanel log & a snippet from journalctl during that timeframe. There are no InfoPanel log entries at the actual system resume time. Systemd-sleep froze user.slice at 00:11:16 and thawed it at 00:12:24, but InfoPanel did not log any resume/reinit activity. The next InfoPanel device activity was only when I manually toggled streaming at 00:16. Thanks! |
|
I narrowed the suspend issue down further. The USB behavior is identical between working and failing resumes: the HID instance is the same, and both working and failing resumes show the xHCI message. The suspend duration seems to matter: A short suspend (say 12s) resumes normally, while the AIO LCD remains lit. A suspend over a minute, during which the LCD eventually goes dark, resumes in a broken state. This reminded me that the Windows Polychrome capture sent POST timeout {"value":60} during the init. It may be that after ~60 seconds without traffic the panel exits realtime-display/power state? Maybe InfoPanel is frozen/thawed across the system suspend and never repeats the startup handshake. Does this mean we need to perform another |
The Windows app stops its panel tasks on SystemEvents.PowerModeChanged Suspend and starts them again on Resume. The Linux port had no equivalent: the process was simply frozen mid-stream and thawed later. Ulfy reported on PR #10 that the ASRock Steel Legend 360 comes back dark after a suspend longer than about a minute (its firmware leaves realtime display after that long without frames) and then ignores a fresh handshake until a full power cycle. Only a clean suspend before the system sleeps avoids that state. Adds a SleepMonitor that subscribes to logind's PrepareForSleep on the system bus through Tmds.DBus.Protocol (already shipped with Avalonia) and holds a 'sleep' delay inhibitor. Before sleep it stops all eight panel tasks, which sends each panel its sleep or close command, then releases the inhibitor so the suspend proceeds. After resume it re-takes the inhibitor and restarts the panel tasks a second later. The state machine is unit-tested; the logind side was verified here: systemd-inhibit lists InfoPanel with a 'sleep' delay lock while the app runs. Without a system bus the app logs once and behaves as before.
|
Thanks for the confirmation on 0.3.4, and for narrowing the suspend issue down. Your reading matches what I found. The Windows app stops its panels on the suspend event and restarts them on resume. The Linux port never had that: the process was frozen mid-stream and thawed later, so nothing was sent to the panel for the whole suspend. That is consistent with your timing: a short suspend stays within the panel's idle window, a long one does not, and once the firmware has left realtime display on its own it evidently no longer accepts a handshake until power is cut. It also explains why nothing shows in the InfoPanel log at resume time. 0.3.6 adds the missing piece. InfoPanel now listens to logind's I verified here that the app takes the delay lock and that |
|
That did the trick. Did a few rounds of testing and it resumed perfectly. Here is the logging I see as well... Going to sleep: 9月 19 22:44:31 org_kde_powerdevil[2402]: [ 2447][1854.021156] (ldbus_handle_message)Received dbus signal PrepareForSleep(true=prepare) Waking up: 2026-09-20 00:34:02.241 +09:00 [INF] System resumed from sleep: restarting panel devices Thank you! proof.mp4 |
2 participants
Adds ASRock Steel Legend 360 LCD support using the existing Thermaltake/ASRock HID backend.
Changelog:
The protocol behavior was verified by comparing USB captures from ASRock Polychrome Display on Windows with the Linux USB traffic.
Existing Thermaltake/ASRock Phantom Gaming behavior is preserved through product-specific handling. I know it's not very DRY to reproduce the Build/Send Packet commands, but I didn't want to alter that method handling for the pre-existing code.