Opened 9 years ago

Closed 3 years ago

#10789 closed Bug Report - General (Won't Fix)

Keyboard-triggered system events and DPMS un-blanks triggered in indeterminate order

Reported by: Josh Triplett <josh@…> Owned by: stuartm
Priority: minor Milestone: 0.28.2
Component: MythTV - General Version: Unspecified
Severity: medium Keywords:
Cc: Ticket locked: no


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 9 years ago by Josh Triplett <josh@…>

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.

comment:2 Changed 8 years ago by stuartm

Milestone: unknown0.27
Owner: set to stuartm
Status: newaccepted

comment:3 Changed 8 years ago by stuartm

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 8 years ago by stuartm

Milestone: 0.270.28

comment:5 Changed 8 years ago by stuartm

See also #9494

comment:6 Changed 5 years ago by Stuart Auchterlonie


Moving unresolved tickets to next point release

comment:7 Changed 4 years ago by Stuart Auchterlonie


Moving remaining open 0.28.1 tickets to 0.28.2

comment:8 Changed 3 years ago by Stuart Auchterlonie

Resolution: Won't Fix
Status: acceptedclosed

Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master

Note: See TracTickets for help on using tickets.