Open ossman opened 5 years ago
The workaround I've done is to remove the mceusb
module during suspend so that it cannot generate input events directly after resume:
$ cat /usr/lib/systemd/system-sleep/mceusb
#!/bin/bash
[ "$1" = "post" ] && exec /usr/sbin/modprobe mceusb
[ "$1" = "pre" ] && exec /usr/sbin/rmmod mceusb
exit 0
@ossman : This is a known issue, I had to work around this issue with a simular hack. Currently there's no easy way to fix this inside Kodi afaik.
This issue is now marked stale because it has been open over a year without activity. Remove the stale label or add a comment to reset the stale state.
Bug report
Describe the bug
I've set up a new standalone Kodi system and decided to try out a simpler setup by using lirc in devinput mode for my mceusb remote (as not all keys work when going via X11).
Mostly works great. Except for one thing!
Suspending the machine by pressing the power button on the remote works fine. But it is almost impossible to resume the machine by pressing the power button on the remote again. I think I've managed to get it working just once.
Expected Behavior
Machine resumes, Kodi is back up and working.
Actual Behavior
Machine resumes, then quickly suspends again.
Possible Fix
The power key should probably be ignored for a while after resume.
To Reproduce
Steps to reproduce the behavior:
KEY_SLEEP
to yourLircmap.xml
(should probably open another issue for this)Debuglog
This is an idle system that gets one power key press to suspend, followed by a slight wait and then another press in an attempt to wake the system.
Note that the log shows the second
KEY_SLEEP
right after the system wakes up. Way before Kodi has begun doing it's internal resume process.Your Environment
Used Operating system:
[ ] Android
[ ] iOS
[x] Linux
[ ] OSX
[ ] Raspberry-Pi
[ ] Windows
[ ] Windows UWP
Operating system version/name: Fedora 30
Kodi version: 18.2