Opened 12 years ago
Closed 6 years ago
#10789 closed Bug Report - General (Won't Fix)
Keyboard-triggered system events and DPMS un-blanks triggered in indeterminate order
Reported by: | Owned by: | stuartm | |
---|---|---|---|
Priority: | minor | Milestone: | 0.28.2 |
Component: | MythTV - General | Version: | Unspecified |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
With previous versions of mythtv and Linux, I used irexec to run a DPMS screen-blanking script when I hit my remote's power button; my script detects the current DPMS state of the monitor, and toggles that state. I now use a sufficiently new Linux kernel that handles the remote without LIRC, and I've tried to configure equivalent behavior using mythtv's keyboard-triggered system events ("Keystroke event #1", etc). I've configured the power button on my remote to trigger keystroke event #1, and configured that event to run my script. However, I discovered that this interacts badly with mythfrontend's own mechanisms to un-blank the screen on keypresses, in two different ways:
- When I hit the power button to blank the screen, my script runs "xset dpms force suspend" to blank the screen, but then mythfrontend immediately un-blanks the screen. I can work around that by sleeping for a moment before running xset, but I'd rather have a cleaner, race-free solution.
- When I hit the power button to un-blank the screen, mythfrontend immediately wakes the screen back up itself, which causes my script to detect the screen as un-blanked, and thus re-blank it.
I think a single simple change would address both problems: hitting a single key should either trigger a DPMS un-blank or trigger an action, but not both. With the screen un-blanked, mythfrontend should observe the un-blanked screen, and then trigger the event. With the screen blanked, mythfrontend should un-blank the screen but not trigger an event.
(Alternatively, mythfrontend could have a keyboard-triggerable "toggle DPMS" event and implement the necessary logic itself.)
Change History (8)
comment:1 Changed 12 years ago by
comment:2 Changed 11 years ago by
Milestone: | unknown → 0.27 |
---|---|
Owner: | set to stuartm |
Status: | new → accepted |
comment:3 Changed 11 years ago by
I can implement a solution for DPMS, but unfortunately not for screensavers because there isn't any way to query whether the screensaver is active. For this stupidity we have apparently have to thank the Gnome and KDE developers.
comment:4 Changed 11 years ago by
Milestone: | 0.27 → 0.28 |
---|
comment:6 Changed 8 years ago by
Milestone: | 0.28 → 0.28.1 |
---|
Moving unresolved tickets to next point release
comment:7 Changed 7 years ago by
Milestone: | 0.28.1 → 0.28.2 |
---|
Moving remaining open 0.28.1 tickets to 0.28.2
comment:8 Changed 6 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | accepted → closed |
Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master
Rationale for ignoring events with the screen blanked: if the user can't see the screen, then hitting a key to wake up the screen should not perform an action blindly. Otherwise, for instance, hitting the "OK" key on a remote to wake up the screen would potentially start playing whatever recording the user had selected.