[sjwright]

The requested feature: a setting for whether inputs that occur while the screensaver is running be swallowed (current behaviour) or executed.

Explanation: Currently when a Kodi screensaver is active, pressing any button on an infrared remote is hijacked by the screensaver to trigger it to end, and the original command request is swallowed/ignored. This is a sensible default when a screensaver completely covers the screen contents, such as with a black screen. But there are some instances where this may be undesirable:
 

• Using Kodi remote control to wake up your TV / AVR using HDMI-CEC.
  You end up having to press the "wake up" button twice—once to stop the screensaver and a second time to trigger the actual command you wanted. Because the TV is off, the concept of the screensaver being active isn't
  
  
• When using the "dim" screensaver.
  You can still see the screen contents when it is dimmed, so having the first input swallowed by the screensaver is unnecessary and feels like a bug.
  

For now I've disabled the screensaver but since my TV is prone to burn-in, this isn't good long term.
I hope this request makes sense?

[Klojum]

When using the "dim" screensaver.

It dims the screen, yes. If you want full black, use the Black screensaver.

I could imagine having the screensaver "copy" the key pressed into the Kodi GUI, it probably possible and certainly not a bug.
But usually people will press any key on a remote or keyboard to wake a device up. If that key would also be activated onto the Kodi GUI itself, undesired actions might follow and the "Back" key would be pressed quite as often.

So, it does sound like a "1st World problem" to me... Having to press a button twice only once.

[sjwright]

Thanks for replying, it's appreciated.

My primary observation is that perhaps some GUI-insensitive commands like CECActivateSource and RunScript ought not be pre-empted by any running screensaver—whether it's dim, black or otherwise. CECActivateSource is a command you call when the TV is switched off. RunScript is often used for actions which have no relation to the GUI state.

As a programmer myself I'm embarrassed to admit it but I've been confused for months about why I always have to press the power button (mapped to CECActivateSource) on my Kodi remote control twice in order for my TV to switch on. I feel stupid that I didn't twig that the Kodi screensaver was swallowing the first press. I offer this feature request because I suspect I'm not the only person who uses HDMI-CEC and is affected by this (admittedly very minor) frustration.
 

But usually people will press any key on a remote or keyboard to wake a device up. If that key would also be activated onto the Kodi GUI itself, undesired actions might follow and the "Back" key would be pressed quite as often.

That's exactly right—when the screen is blacked out or otherwise occluded, it is appropriate for the screensaver to swallow actions which are dependent on GUI state, like "Back" or "Enter". My point, which I apologise for not explaining well, is that a dimmed screen won't necessarily strike everyone as "asleep" and needing to be woken up. I'm sure there are many people who will see this differently, perhaps depending on things like how dark their room is (which affects how legible the dimmed picture is) and/or whether they see Kodi as seamless consumer electronics or a computer running software.

I can work around all of this by just disabling the screensaver. However I greatly value Kodi's dimming feature for the sake of my television screen's life. Hence my predicament and thus this feature request.

[sjwright]

I should also note that prior to filing this feature request I did try to read through the Kodi source, however I'm not well versed in C++ and I couldn't quite follow the logic. Best as I could tell it has something to do with CGUIWindowManager::SendMessage() and CGUIWindowScreensaver::OnMessage() but I'm really not sure as I don't know what Message means in Kodi parlance. Because I don't understand the code, I'm unable to propose a change that is easiest for you to implement given Kodi's architecture.

A few potential paths I envisage:

* Adding a setting/toggle to the Dim screensaver specifically or the screensaver module generally <— probably the easiest to code

* Changing the behaviour at the keymap (e.g. add XML property to flag specific keys to always bypass the screensaver) <— the most flexible for power users

* Changing the behaviour of specific commands (have a blacklist of commands which the screensaver doesn't swallow) <— probably the most seamless

Thanks for listening.

[joao.p.taveira]

• When using the "dim" screensaver.
  You can still see the screen contents when it is dimmed, so having the first input swallowed by the screensaver is unnecessary and feels like a bug.
  

Hi to all,

I also would like to have the option @sjwright mentioned. This issue is anoying me for years. I use several methods to control kodi, such as, remotes, gestures, voice commands, etc, and I'm forced to repeat the "input key", voice command, gesture.

In my opinion, this being a bug or not, depends on the state of player/program/script/activity when the screensaver "kicked in". There must be a consistency in the inputs that change the state machine of the running activity and the user expected result. This kind of (UI) bugs are extremelly common (and very annoing) but they were always related to skins code. One of the most common bug is the navigation on vertical menus, when the user hit "down" on the last item on bottom, the first (on top) is then selected. This is great until the user starting to navigating upwards, and after hit "up" on first item, the cursor is not on last item but somewhere on "top bar" or some on some button of a quickbar... this is not "intuitive".

I always found this UI issues on skins and I know (or I don't know) if the author of the skin is really a professional developer, or if she/he studied about the GUIs, ... but I'm positive that she/he enjoy it and shared, which is great.

The issue that @sjwright mentioned resides in kodi code, and I think that this inconsistency is a bug because it induces confusion on the user. When I launch a player, assuming the most basic use case, it's internal state is "started" (or ready, or initialized..); on "play" event, the player is expected to make transition to "playing" state; ... on "pause" event, it should make transition to "paused" state; ... in the "paused" state the "play" event should make transition to "playing" state, ... etc etc etc, ...

I think that (almost) everybody that contribute to kodi knows what "state machines" are and how they work, thus any component that changes the outputs of state machine "running" without explicit user changes in settings, it's a bug.

If I hit "play", I'm expecting to kodi to play. During "playout", if I input "pause", the player must be "paused". If I hit "play" after 1s of last "pause" or if I hit "play" after 1 hour since last input, the expected result must be exactly the same, unless I changed settings that I'm aware of changing the behavior.

One airplane manufacturer added nice features to theirs planes that would increase power on "taking of", preventing "stalls" if pilots reduse thrust. but they forget to mention that. Once, one of this planes was taking of and engines started to surge, thus pilots reduze thrust to idle but the airplane computer decided that it should increase thrust to clime... so both engines blow up. The plane crashed, but no body died.

Could you reconsider the feature request from @sjwright? Or could someone from team-kodi guide us to best way to get this done?

Thanks