Moving xss-lock to community

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Moving xss-lock to community

tur-users mailing list

Seems fairly popular, plus it's useful to lock the screen on sleep
without systemd.

--
Pierre Neidhardt

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
On Tue, Jan 16, 2018 at 10:59:49AM +0100, Pierre Neidhardt via aur-general wrote:
>
> Seems fairly popular, plus it's useful to lock the screen on sleep
> without systemd.
I realize I'm somewhat late with this response, but upstream hasn't
updated their project in years and the release has several outstanding
issues, such as using 100% CPU [1] and broken features such as the
advertised IdleAction support. [2]

If you use polkit and acpid, a "simple" alternative is to use
systemd-inhibit, and run actions based on acpid events. Not sure there's
a ready implementation with X support in mind.

Or now that you've adopted it, perhaps you could look over the ~700
lines of C code and fix outstanding issues. :)

Alad

[1] https://bitbucket.org/raymonad/xss-lock/issues/6/hang-high-cpu-on-session-exit
[2] https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list

The 100%-cpu issue should be fixed upstream on master (and thus also in the -git package).
I've mentioned this on the wiki:

https://wiki.archlinux.org/index.php/Power_management#xss-lock


I'll ask the author if he's still maintaining it.
I might consider a fork otherwise.

--
Pierre Neidhardt

A real friend isn't someone you use once and then throw away.
A real friend is someone you can use over and over again.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
On Thu, Jan 18, 2018 at 07:26:33PM +0100, Pierre Neidhardt wrote:
>
> The 100%-cpu issue should be fixed upstream on master (and thus also in the -git package).
> I've mentioned this on the wiki:
>
> https://wiki.archlinux.org/index.php/Power_management#xss-lock
>
Since that's a fairly significant issue, why not include the commit that
fixes it in the community package? git cherry-pick should do the job.

Alad

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by tur-users mailing list
On January 18, 2018 7:26:33 PM GMT+01:00, Pierre Neidhardt via aur-general <[hidden email]> wrote:
>
>The 100%-cpu issue should be fixed upstream on master (and thus also in
>the -git package).
>I've mentioned this on the wiki:
>

Why not simply backporting it via a patch file then?

Cheers,
Levente
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by tur-users mailing list

Alad Wenter via aur-general <[hidden email]> writes:

> If you use polkit and acpid, a "simple" alternative is to use
> systemd-inhibit, and run actions based on acpid events. Not sure there's
> a ready implementation with X support in mind.

Could you detail this?  How do you set it up?  What is lacking in terms
of X support?

--
Pierre Neidhardt

Nobody said computers were going to be polite.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by tur-users mailing list

It's only 4 commits since 0.3.0, two of them being critical fixes.
I could backport those two commits (just tried: no conflict); it feels
needlessly pedantic however, compared to using "master" straight away.

I've contacted the developer, see if he replies within a few days.  If
not, I'll go ahead with the patches.

--
Pierre Neidhardt

Sodd's Second Law:
        Sooner or later, the worst possible set of circumstances is
        bound to occur.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
On 01/18/2018 03:02 PM, Pierre Neidhardt via aur-general wrote:
>
> It's only 4 commits since 0.3.0, two of them being critical fixes.
> I could backport those two commits (just tried: no conflict); it feels
> needlessly pedantic however, compared to using "master" straight away.
>
> I've contacted the developer, see if he replies within a few days.  If
> not, I'll go ahead with the patches.

If upstream has abandoned the project for years without tagging a stable
release, then I would feel totally okay about taking my own prerogative
to evaluate if master is stable, and if so, package the latest

source=("https://bitbucket.org/raymonad/xss-lock/get/${_commit}.tar.gz")

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by tur-users mailing list
On Thu, Jan 18, 2018 at 08:52:23PM +0100, Pierre Neidhardt wrote:

>
> Alad Wenter via aur-general <[hidden email]> writes:
>
> > If you use polkit and acpid, a "simple" alternative is to use
> > systemd-inhibit, and run actions based on acpid events. Not sure there's
> > a ready implementation with X support in mind.
>
> Could you detail this?  How do you set it up?  What is lacking in terms
> of X support?
>
As we know, logind by default does actions like suspend on closing the
lid or pressing the suspend button. Rather than modify these actions to
run some event (like locking the screen priorly) through services files,
you can temporarily disable them with systemd-inhibit. [1] Example:

  $ systemd-inhibit --what=handle-lid-switch --why=Locker screenlocker

The default mode is "block", which delays the set actions indefinitely.
To use it as a regular user, you rely on polkit. This is quite similar
what DE power managers à la xfce4-power-manager do.

"screenlocker" in its most basic form would look at ACPI events from
acpid, and run actions accordingly. Example: [2]

  #!/bin/bash
  coproc acpi_listen
  trap 'kill $COPROC_PID' EXIT

  while read -u "${COPROC[0]}" -a event; do
      handler.sh "${event[@]}"
  done

The benefit of this (and xss-lock's) approach is that your screenlocker
program is run in the environment of the current user, so there's no
need for common hacks such as hardcoding DISPLAY. With systemd-inhibit
you also have some fallback in place should "screenlocker" fail for some
reason, at least assuming it exits on error.

Of course, you can extend the scope of "screenlocker" to react to any
arbitrary ACPI events, for example for volume controls - with latter you
get functional controls in full-screen applications as well.

One issue remains and that is how the program should react when you log
out from your X session, that is when the currently running X server
terminates. xss-lock would simply quit in this case, and if writing in C
you should be able to easily replace this behavior. Unsure about shell.

Another potential issue is on multi-user systems. If both listen to acpi
events in this way there may be conflicts.

Alad

[1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
[2] https://wiki.archlinux.org/index.php/Acpid#Connect_to_acpid_socket

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

Bennett Piater
This doesn't take care of locking on inactivity though, which is the other major feature of xss-lock.

Cheers,
Bennett
--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> This doesn't take care of locking on inactivity though, which is the other major feature of xss-lock.
>
Except, as noted, that "major feature" doesn't work at all...

Alad

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by Bennett Piater
On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> This doesn't take care of locking on inactivity though, which is the other major feature of xss-lock.
>
That said, a short implementation may look as follows:

https://github.com/grawity/hacks/blob/master/desktop/systemd-lock-handler

Alad

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

Bennett Piater
In reply to this post by tur-users mailing list


On 01/18/2018 09:25 PM, Alad Wenter via aur-general wrote:
> On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> Except, as noted, that "major feature" doesn't work at all...

Doesn't it?
It appeared to work when I tried it, and that was this morning...

Cheers,
Bennett

--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808


signature.asc (565 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
On Thu, Jan 18, 2018 at 09:32:46PM +0100, Bennett Piater wrote:
>
>
> On 01/18/2018 09:25 PM, Alad Wenter via aur-general wrote:
> > On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> > Except, as noted, that "major feature" doesn't work at all...
>
> Doesn't it?
> It appeared to work when I tried it, and that was this morning...
>
See the bug report I linked in the first reply.

https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind

Alad

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

Bennett Piater


On 01/18/2018 09:37 PM, Alad Wenter via aur-general wrote:
> See the bug report I linked in the first reply.
>
> https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind

Right, that is actually something else than what I did.
I used `xset s` to trigger on inactivity, and xss-lock correctly locks
the screen when that happens.

So it seems like it can still be used as a replacement for xautolock.

Cheers,
Bennett

--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808


signature.asc (565 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

David Runge
On January 19, 2018 9:42:26 AM GMT+01:00, Bennett Piater <[hidden email]> wrote:

>
>
>On 01/18/2018 09:37 PM, Alad Wenter via aur-general wrote:
>> See the bug report I linked in the first reply.
>>
>>
>https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind
>
>Right, that is actually something else than what I did.
>I used `xset s` to trigger on inactivity, and xss-lock correctly locks
>the screen when that happens.
>
>So it seems like it can still be used as a replacement for xautolock.
Fwitw (and sorry for hijacking), I recently tried xprintidle (with a forked upstream, different from the one in the AUR) and it seems to work.
This might still be used in a script to lock screens automatically under X, but it's clunky. I'd much prefer a more complete solution, as xautolock is aging (not so well) and at least in my case produces undesirable  defuncts from time to time.
xss-lock seemed too broken at that time, so I never used it.
Are there any other alternatives not mentioned in the wiki?

Best,
David

--
https://sleepmap.de
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list

-------- Original Message --------
 On January 19, 2018 11:52 AM, David Runge <[hidden email]> wrote:
>Fwitw (and sorry for hijacking), I recently tried xprintidle (with a forked upstream, different from the one in the AUR) and it seems to work.
> This might still be used in a script to lock screens automatically under X, but it's clunky. I'd much prefer a more complete solution, as xautolock is aging (not so well) and at least in my case produces undesirable  defuncts from time to time.
> xss-lock seemed too broken at that time, so I never used it.
> Are there any other alternatives not mentioned in the wiki?


I wrote xidle_dispatcher [0] myself, which I basically hook up to slock. Another tool I know of does basically the same thing, both being more or less what xssstate.c[1] does.

cheers!
mar77i

[0] https://github.com/mar77i/xidle_dispatcher
[1] https://git.suckless.org/xssstate/tree/xssstate.c


Sent with ProtonMail Secure Email.
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list
In reply to this post by tur-users mailing list

Eli Schwartz via aur-general <[hidden email]> writes:
> source=("https://bitbucket.org/raymonad/xss-lock/get/${_commit}.tar.gz")

No answer from the dev so far, so I've packaged the latest commit as Eli suggested.
Let me know if there is anything wrong.

--
Pierre Neidhardt

The time spent on any item of the agenda [of a finance committee] will be
in inverse proportion to the sum involved.
                -- C.N. Parkinson

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

David Runge
Hi Pierre,

On 2018-01-23 10:14:12 (+0100), Pierre Neidhardt via aur-general wrote:
> No answer from the dev so far, so I've packaged the latest commit as Eli suggested.
> Let me know if there is anything wrong.
nice to see this in [community]!

Could you also include a service file, that propagates the lock-sessions
command, in the vein of what was suggested upstream [1]?

IMHO that would be very useful!

Best,
David


[1] https://bitbucket.org/raymonad/xss-lock/issues/18/systemd-unit-for-locking-on-sleep

--
https://sleepmap.de

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving xss-lock to community

tur-users mailing list

David Runge <[hidden email]> writes:

> Could you also include a service file, that propagates the lock-sessions
> command, in the vein of what was suggested upstream [1]?

As far as I can tell, xss-lock is already run when I resume from a
suspend.

I'm no systemd expert: what is the intent of the suggest systemd unit?

--
Pierre Neidhardt

signature.asc (497 bytes) Download Attachment
12