Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distinguish between "idle" reasons (keyboard, mouse, touchpad, ...) #42

Open
rpodgorny opened this issue Aug 29, 2019 · 7 comments
Open

Comments

@rpodgorny
Copy link

this will probably be rejected right away but still... ;-)
i currently use swayidle to do the session locking, dpms, etc... one of the actions is:

timeout 5 "light -s sysfs/leds/asus::kbd_backlight -r -S 0" resume "light -s sysfs/leds/asus::kbd_backlight -r -S 1"

...this lights up the keyboard anytime i press a key and turns off the light after 5s - this increases battery life a lot! (while preserving "where's that obscure key" kind of comfort).
the only downside is that this also fires when i move the cursor (which i sometimes do to prevent screen lock in middle of reading an article). :-(
would it be possible to add something like "timeout-keyboard" etc.?

...or any other suggestions how to achieve such behaviour?

thanks!

@vicencb
Copy link

vicencb commented Oct 18, 2019

Hi,
i am also interested in distinguishing idle reasons, but with a different purpose.
When the system is active, any event should keep the system active, as it is now.
But when the system is idle i would like to ignore cursor events. Only buttons or keys should be able to awake the system.

The use case is: the system may become idle (after a timeout or when i force it with SIGUSR1) and set the dpms state to off. Then the system should stay idle even if the mouse moves, either because of unrelated perturbances (like somebody hits the table) or because i need the desktop space where the mouse is.

Another possible way of doing this is setting a threshold: the cursor should move more than X pixels in one second to resume.

@kittydoor
Copy link

@vicencb that's a very good point! I would definitely appreciate being able to resume only on keyboard events and ignore mouse events.

@emersion
Copy link
Member

@kittydoor This has been added in swaywm/sway#4805

@vicencb
Copy link

vicencb commented Oct 5, 2020

Hi, i was trying to setup sway in order not to wake up on mouse move, but it does not work.
I can put it to sleep with Mod4+z and then it awakens with any input, including mouse moves.
What am i doing wrong?
This is the relevant part of the configuration:

exec swayidle -w timeout 500 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"'
bindsym Mod4+z exec /usr/bin/sh -c 'sleep 1 ; /usr/bin/kill -USR1 swayidle'
seat * idle_wake keyboard switch

@alex3kov
Copy link

alex3kov commented Nov 28, 2021

I start swayidle like this to not unlock on mouse movements, it works:

  swayidle -w \                                                                
      timeout 1800 'swaymsg input type:pointer events disabled ;
        swaymsg "output * dpms off"' \
      resume 'swaymsg input type:pointer events enabled ;
        swaymsg "output * dpms on"'

@josch
Copy link

josch commented Feb 21, 2023

This worked for me to only inhibit idle on keyboard actions and ignore mouse movements:

seat * idle_wake keyboard
seat * idle_inhibit keyboard

This issue can thus be closed, no?

@rpodgorny
Copy link
Author

This worked for me to only inhibit idle on keyboard actions and ignore mouse movements:

seat * idle_wake keyboard
seat * idle_inhibit keyboard

This issue can thus be closed, no?

well, i'd have to test it but at first glance it doesn't seem like it really solves my problem. the thing is i still want to make any keyboard or mouse event to be considered "activity" so the screen doesn't lock after a timeout... ...i just need a way to actively hook myself to a specific subset of inputs...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants