GPD Gyro woes after sleep
@justinweiss @Aru let's get a discussion going about the gyro sleep issue in gpd
Observed on GPD 4 2023, 2024, and Win Max (?) across all kernels and OSs (Nix, chimeraos, bazzite)
36 Replies
on my WM2 (6800u) the gyro doesn't work.
but for the GPD Win 4, the gyro workaround is required for the 6800u, 7840u, and 8840u models
what does that mean
I confirmed the issue on my 6800u, I helped a different user with a 7840u, and then there's the 8840u report
steam input doesn't show gyro working
what gyro does it have?
it never actually worked on my WM2, even with an updated bazzite
could have said something, although i think it might be a 160 and bazzite doesnt ship the patch
err, not sure. i had assumed it was the same as the win 4, but never investigated it
i don't really use my WM2 for gaming, so I never investigated
i just turned off gyro and ignored it
yeah gpd users are not my n1 customer
the gyro workaround worked fine on my Win 4, figured that it was a low-priority issue and wouldn't be investigated anytime soon
yeah but now we're getting a lot more gpd users it seems
i had brought up the idea of implementing the workaround as a ujust
lets fix the driver
make sure you can reproduce it on a fresh boot without hhd running
then we can move on from there
as you know from the suspend issue the ally/legion go had that workaround is dangerous
how would i test the gyro without hhd running?
start it after you suspend once or twice
it only matters its not running until after the suspend
ah gotcha, so disable, reboot, suspend a few times, then start hhd and see if it's broken
but bazzite restarts the hhd service on boot 🤔
disable it, does the setup reenable it every reboot?
this was the problem before with local hhd
bazzite always started the built-in hhd service, even when disabled
i thought it did it occasionally
for me it was every time
anyway its ok, just shut it down before suspend
please save me from dbus
usually hhd_local would kick in before the built-in hhd would take control, but if I ever disabled the hhd_local, the built-in would take over
which confused me a lot when i had previously been troubleshooting running off local hhd
- disabled hhd service, disabled workaround, did a reboot
- on reboot, as expected, hhd service was re-enabled. Disabled the service again, then did 2 suspend-resume cycles
- afterwards, turned hhd service back on. gyro was borked
- re-enabled the gyro workaround, then did a suspend-resume cycle
- after resume, gyro now working fine in steam input
gyro workaround is eh
lets see if we can stop relying on it
it's basically just a rmmod and modprobe on suspend-resume
so gyro just breaks after suspend
hopefully we could figure out the actual problem
pretty much
probably needs a reset after suspend
if i have hhd running, on fresh boot gyro works fine
it breaks after suspend
easiest way to see if gyro is sending data is
watch cat /sys/bus/iio/devices/iio\:device0/in_accel_x_raw (assuming device0 is right on the Win 4)There's a chance that only the buffer breaks but let's see
I might have a command for that too
I haven't been able to cause the problem on the Win Mini unfortunately, so there must be some difference. I was wondering if it was IRQ vs hrtimer triggers, but when I tried forcing hrtimer a while back I also don't remember seeing the problem. That's the first thing I'll try again once I have some time though.
What does dmesg say?
With hrtimer I wonder if it's trying to access the hardware / bus before it's ready. But that code isn't any different than the 160 IIRC so I'd expect the same problem there. Haven't heard of any problems with that one though.
Here's the thing
We shut down hhd before the tes6
And it removes the trigger
Unfortunately we can't make 100% sure it doesn't mess with something else
I guess we can disable gyro before roboot
160 hasn't been tested
Only 323
Unfortunately nobody ships the 160 patch
Dmesg complains if the hrtimer is on
But you've probably seen the error yoo
Well, if it's a crash in the module it would be best if the module could recover without forcing the software to handle it
That's this error? https://github.com/justinweiss/bmi260/blob/main/bmi260_core.c#L747
No there's an interruption stack trace
Due to the hrtimer
The 323 recovers and your device recovers too right?
As for irq, that is fixed with hrtimer
nothing needs to recover for me, I don't get a stack trace. But the mini is also using IRQ triggers.
Yes the stacktrace only happens with hrtimer
I knew about it from the beginning
But since the devices recovered I thought it was fine
I can botch a fix but I'd rather not
So I need to make sure its not hrtimer
yeah, I think that watch command with hhd disabled would help figure that out. If the gyro stops reporting data after a suspend when a trigger has never been set up, it's probably not related to hrtimer
if it's fine when you read the data raw, it's probably a buffer problem or hrtimer problem or a timing problem, something like that
On the mini, I tried a version of the driver that doesn't set up an IRQ. Reading the raw gyro data still works after a suspend, but I can't get hhd to start with that hacked up driver, just get this in a loop:
I'm still curious whether reading the raw data from sysfs will work on the win 4 after a suspend / resume