Re: [i3] binding the same key to revert the command?

[Ingo Bürk]

Hi,

one possible solution: save the following as /some/path/stopcont.sh and bind

bindsym $mod+p exec --no-startup-id /some/path/stopcont.sh 

Script:
===
#!/usr/bin/env bash
PROCESS=${1}
FILE="/tmp/${PROCESS}.signal"

if [[ -f "${FILE}" ]]; then
  rm ${FILE}
  pkill -SIGCONT ${PROCESS}
else
  touch ${FILE}
  pkill -SIGSTOP ${PROCESS}
fi
===

This will, of course, assume that the process isn't paused by anything
else as that would make it go out of sync. A better and more robust way
would be to write the script such that it instead uses the information
of /proc//stat to check whether the process is currently paused. If
you use a higher-level language such as Python, you can do this nicely
instead of manually parsing the output. See [1] for some more information.

[1]
http://stackoverflow.com/questions/6021771/is-there-a-way-to-determine-if-a-linux-pid-is-paused-or-not


Ingo

On 11/08/2015 04:16 AM, Zenny wrote:
> Hi,
>
> I am trying to use a keybinding to pause a process temporily,
>
> bindsym $mod+p exec pkill -SIGSTOP 
>
> But I could not figure out how to make pressing to same keybinding to
> restart the process?
>
> Currenlty I am using,
>
> bindsym $mod+c exec pkill -SIGCONT 
>
> Instead, I want something like re-pressing $mod+p executes pkill
> -SIGCONT .
>
> Thanks!
>
> /z

Re: [i3] binding the same key to revert the command?

[Ingo Bürk]

Hi,

sorry, my last email didn't go to the mailing list which I diidn't even
notice until this email. Below is my previous email as a quote which
also has a script using /proc/../stat. Never hurts to have multiple
solutions :)
> Hi,
>
> here's a script using /proc/.../stat. The usage is as before. The only
> assumption now is that the process is running exactly once.
>
> 
> #!/usr/bin/env bash
> PROCESS=${1}
> STATE=$(cat /proc/$(pgrep ${PROCESS})/stat | awk -F' ' '{print $3}')
>
> [[ "${STATE}" = "T" ]] && pkill -SIGCONT ${PROCESS} || pkill -SIGSTOP
> ${PROCESS}
> =



On 11/08/2015 05:22 PM, Joep van Delft wrote:
> Elaborating on Ingo's hints: Something like this could be used to not
> to have
> to maintain the state somewhere on disk:
>
> ===
> #!/usr/bin/env bash
> process_name=$1
> for pid in $(pgrep --exact $process_name); do
> # Assumes there is no space in the command name
> if   awk '$3=="T"{exit 1}' /proc/$pid/stat 2>/dev/null
> then kill -SIGCONT $pid
> else kill -SIGKILL $pid
> fi
> done
> ===
>
>
> Kind regards,
>
> Joep
>
>
> Ingo Bürk schreef op 2015-11-08 10:30:
>> Hi,
>>
>> one possible solution: save the following as /some/path/stopcont.sh
>> and bind
>>
>> bindsym $mod+p exec --no-startup-id /some/path/stopcont.sh
>> 
>>
>> Script:
>> ===
>> #!/usr/bin/env bash
>> PROCESS=${1}
>> FILE="/tmp/${PROCESS}.signal"
>>
>> if [[ -f "${FILE}" ]]; then
>>   rm ${FILE}
>>   pkill -SIGCONT ${PROCESS}
>> else
>>   touch ${FILE}
>>   pkill -SIGSTOP ${PROCESS}
>> fi
>> ===
>>
>> This will, of course, assume that the process isn't paused by anything
>> else as that would make it go out of sync. A better and more robust way
>> would be to write the script such that it instead uses the information
>> of /proc//stat to check whether the process is currently paused. If
>> you use a higher-level language such as Python, you can do this nicely
>> instead of manually parsing the output. See [1] for some more
>> information.
>>
>> [1]
>> http://stackoverflow.com/questions/6021771/is-there-a-way-to-determine-if-a-linux-pid-is-paused-or-not
>>
>>
>>
>> Ingo
>>
>> On 11/08/2015 04:16 AM, Zenny wrote:
>>> Hi,
>>>
>>> I am trying to use a keybinding to pause a process temporily,
>>>
>>> bindsym $mod+p exec pkill -SIGSTOP 
>>>
>>> But I could not figure out how to make pressing to same keybinding to
>>> restart the process?
>>>
>>> Currenlty I am using,
>>>
>>> bindsym $mod+c exec pkill -SIGCONT 
>>>
>>> Instead, I want something like re-pressing $mod+p executes pkill
>>> -SIGCONT .
>>>
>>> Thanks!
>>>
>>> /z

Re: [i3] binding the same key to revert the command?

[Zenny]

Hi Sege,

On 11/8/15, Serge van Ginderachter  wrote:
> I have a script that does that, to pause dunst (whilst locking) and/or
> disabling the autolock screensaver (for a presentation mode).
>
> The trick is to be able to check for a state, which I do by using gtrayicon
> to visually show the current state, so the script can check whether to
> enable or disable the mode.
>
> See https://github.com/srvg/dotfiles/blob/master/bin/presentation-mode

Thanks for the input. Can you explain the usage in my case in particular.

Cheers,
/z

>
> On 8 November 2015 at 10:16, Zenny  wrote:
>
>> Hi,
>>
>> I am trying to use a keybinding to pause a process temporily,
>>
>> bindsym $mod+p exec pkill -SIGSTOP 
>>
>> But I could not figure out how to make pressing to same keybinding to
>> restart the process?
>>
>> Currenlty I am using,
>>
>> bindsym $mod+c exec pkill -SIGCONT 
>>
>> Instead, I want something like re-pressing $mod+p executes pkill
>> -SIGCONT .
>>
>> Thanks!
>>
>> /z
>>
>

Re: [i3] binding the same key to revert the command?

[Joep van Delft]

Elaborating on Ingo's hints: Something like this could be used to not to 
have

to maintain the state somewhere on disk:

===
#!/usr/bin/env bash
process_name=$1
for pid in $(pgrep --exact $process_name); do
# Assumes there is no space in the command name
if   awk '$3=="T"{exit 1}' /proc/$pid/stat 2>/dev/null
then kill -SIGCONT $pid
else kill -SIGKILL $pid
fi
done
===


Kind regards,

Joep


Ingo Bürk schreef op 2015-11-08 10:30:

Hi,

one possible solution: save the following as /some/path/stopcont.sh and 
bind


bindsym $mod+p exec --no-startup-id /some/path/stopcont.sh 



Script:
===
#!/usr/bin/env bash
PROCESS=${1}
FILE="/tmp/${PROCESS}.signal"

if [[ -f "${FILE}" ]]; then
  rm ${FILE}
  pkill -SIGCONT ${PROCESS}
else
  touch ${FILE}
  pkill -SIGSTOP ${PROCESS}
fi
===

This will, of course, assume that the process isn't paused by anything
else as that would make it go out of sync. A better and more robust way
would be to write the script such that it instead uses the information
of /proc//stat to check whether the process is currently paused. 
If

you use a higher-level language such as Python, you can do this nicely
instead of manually parsing the output. See [1] for some more 
information.


[1]
http://stackoverflow.com/questions/6021771/is-there-a-way-to-determine-if-a-linux-pid-is-paused-or-not


Ingo

On 11/08/2015 04:16 AM, Zenny wrote:

Hi,

I am trying to use a keybinding to pause a process temporily,

bindsym $mod+p exec pkill -SIGSTOP 

But I could not figure out how to make pressing to same keybinding to
restart the process?

Currenlty I am using,

bindsym $mod+c exec pkill -SIGCONT 

Instead, I want something like re-pressing $mod+p executes pkill
-SIGCONT .

Thanks!

/z

Re: [i3] Weird keybinding issue after suspend

[Michael Stapelberg]

On Sun, Nov 8, 2015 at 6:01 AM, Benjamin Kaiser 
wrote:

> So the issue popped up again, these were the steps I did to debug it:
>
> - jump to TTY3
> - run: `DISAPLY=:1 setxkbmap | tee /tmp/setxkbmap.out` (not sure if I
> should have been passing any arguments specifically)
>

I meant using e.g. “setxkbmap de” to set the keyboard layout. Also, I think
you meant DISPLAY.


> - observe there was no output
> - jump back to TTY2, keyboard/keybindings still unresponsive in i3
> - jump back to TTY2
> - run `DISAPLY=:1 xev | tee /tmp/xev.out` (output starts spewing out, and
> also to the file)
> - jump back to TTY2, keyboard is now responsive to i3wm bindings
> - jump back to TTY3 and kill xev
>
> Output in `/tmp/xev.out`: http://p.nnev.de/7524
>
> Hope this helps with tracking down what could be causing this, as I still
> don't have much of a clue how to fix it.
>
> Cheers,
> Ben Kaiser
>
> On Mon, 2 Nov 2015 at 20:54 Benjamin Kaiser 
> wrote:
>
>> Thanks for the reply Michael,
>>
>> I had the issue happen again yesterday and ran `sudo
>> libinput-debug-events`, then changed back to i3, run a bunch of shortcuts
>> and pressed a bunch of keys (all of which did nothing) then changed back to
>> the tty only to see that it was registering those keys being pressed.
>>
>> I'll try running `setxkbmap` and `xev` from a TTY next time the issue
>> occurs to see if it fixes it / gives me any more information.
>>
>> Also another small thing I noticed. To get out of the situation I click
>> the workspaces, but the keyboard only works if I click a different
>> workspace the the one I am currently in, it doesn't do anything (keyboard
>> still won't register shortcuts) if I click the current workspace.
>>
>> modified my i3config to that (i3lock then systemctl suspend), I think it
>> was that at some point and the issue still occurred, but I'll try it out
>> let you know if the issue happens again.
>>
>> Cheers,
>> Ben Kaiser
>>
>> On Mon, 2 Nov 2015 at 19:00 Michael Stapelberg  wrote:
>>
>>> When this situation happens:
>>>
>>> 1. Does running xev(1) still show keyboard events?
>>>
>>> 2. Does using setxkbmap to set your layout make the problem go away?
>>> That should force i3 to re-grab all keys.
>>>
>>> On Fri, Oct 30, 2015 at 12:38 PM, Benjamin Kaiser <
>>> benjaminjkai...@gmail.com> wrote:
>>>
 Hello,

 I've got a really weird issue that's been bothering me for perhaps the
 last 6 months (before then it worked fine, perhaps could have been around
 when I switched to using my keyboard to suspend). Sometimes when I resume
 from suspend (I have i3lock launching at the same time as when I suspend) I
 can unlock my computer, but then no more keyboard events work. The keyboard
 remains active (lights on) and I can switch to a TTY, but none of the i3
 events fire. The only way I can fix it is to use the mouse (which is still
 working) to click on a workspace in the statusbar and then the keyboard
 responds again.

  As mentioned above, it only happens sometimes, and as a fellow dev it
 really annoys me to no end when something is unreproducible. Things I have
 tried to reproduce are just suspending, then detaching my keyboard and
 attaching it again before resuming from suspend, but that doesn't trigger
 the issue. Just about the only common thing I can find is time (after being
 suspended for a long time, 12hours+, it seems to happen more frequently).

 One idea I've had is that because I use a keyboard shortcut to suspend
 (`bindsym --release $mod+Control+Shift+s exec "systemctl suspend; i3lock"`
 in my config, the --

>>>
>>> nit: you should i3lock first, then suspend. That way, your screen is
>>> guaranteed to be locked in a race-free way when you resume. “i3lock &&
>>> systemctl” suspend should work.
>>>
>>>
 release was me weeks ago trying to rectify the issue, but it still
 persisted) i3wm is somehow holding onto the keyboard before flushing, but
 then post-suspend, i3lock takes the keyboards focus, i3wm holds onto an old
 un-flushed pointer to the keyboard (not sure if that is how that works) and
 doesn't refresh it upon i3lock giving up focus.
 From searching around in the i3 source code, seeing the line in
 main.c:main() with the comment annotation
 /* Grab the keyboard to get all input */
 xcb_flush(conn);
 And that function also occuring in click.c:route_click() (i.e. when I
 click the workspaces in the status bar)
 xcb_flush(conn);
 Maybe this is what is allowing the keyboard to work again. Is there
 some way this could be run upon i3lock giving up focus / i3wm resuming
 focus?

 Any help in solving this would be much appreciated!

 Here is some information about my system:
 Mouse: Razer Naga, (one with 12 buttons on side)
 Keyboard: ducky shine 3 with mini usb