~mil/sxmo-user

9 3

Re: Ask for PIN on lock screen

Bosco Vallejo-Nágera <bosco@vallejonagera.xyz>
Details
Message ID
<CJNKCJBTZ61S.3I800M208HD7J@MacBook-Pro-de-Bosco.local>
DKIM signature
missing
Download raw message
I do have a pinephone, and I’ve been wondering the same. Would this patch/setting be at the display manager level, locker level (be that swaylock for Wayland and slock for Xorg) or something else? The tricky bit might be getting the on screen keyboard to work for password/PIN entry. Will monitor this thread.

Re: Ask for PIN on lock screen

Details
Message ID
<9ee1a91f-d651-d47d-4cf1-c2c8baa1d9b0@disroot.org>
In-Reply-To
<CJNKCJBTZ61S.3I800M208HD7J@MacBook-Pro-de-Bosco.local> (view parent)
DKIM signature
pass
Download raw message
On 30.04.22 14:12, Bosco Vallejo-Nágera wrote:
> I do have a pinephone, and I’ve been wondering the same. Would this patch/setting be at the display manager level, locker level (be that swaylock for Wayland and slock for Xorg) or something else? The tricky bit might be getting the on screen keyboard to work for password/PIN entry. Will monitor this thread.

I already have done some work in this direction and am currently waiting 
for sxmo-utils 1.9 to arrive in PmOS edge.

My approach was to patch swaylock (currently pretty ugly) with a keypad 
for entering numeric pins (a bit like phosh on the early days): 
https://codeberg.org/slatian/swaylock-mobile some background-information 
lives over at: https://slatecave.net/creations/swaylock-mobile/

There is also shlock https://github.com/telent/schlock which is 
documented in its readme.

Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<2ea1886c-5d73-8c4f-c2a2-eff6a609a5da@disroot.org>
In-Reply-To
<9ee1a91f-d651-d47d-4cf1-c2c8baa1d9b0@disroot.org> (view parent)
DKIM signature
pass
Download raw message
On 30.04.22 17:23, Baschdel wrote:
> I already have done some work in this direction and am currently 
> waiting for sxmo-utils 1.9 to arrive in PmOS edge.

I have not been lazy last week and have come up with a screenlocker 
integration for the sway version of sxmo + writeup:

https://slatecave.net/blog/2022-05-07_integrating-my-screenlocker-with-sxmo-part-2/

A little expectation management about swaylock-mobile:

It currently is just a screenlocker, you won't be able to 
accept/reject/silence calls on the lockscreen nor will you be able to 
get other notifications (I have not even built a clock yet). However, 
you should be able to use a different screenlocker by just changing the 
command that gets called in the run-screenlocker script.

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<87k0axce16.fsf@momi.ca>
In-Reply-To
<2ea1886c-5d73-8c4f-c2a2-eff6a609a5da@disroot.org> (view parent)
DKIM signature
pass
Download raw message
Great work! Im really happy to see progress on this issue since it's
been a common complaint. Just a word of warning, please work with
upstream (in this case swaylock) to get your code upstream. I would
advise doing this asap so we arent left with a lot of work that will
never be accepted upstream.

Here is the reasoning:

1. Improving upstream helps everyone. There's people with tablets
running sway that may not want to use Sxmo but automatically install
swaylock. Lets support that!

2. It's easier to maintain one project long term rather than duplicating
the maintenance effort.

3. We really cant have another fork of "sway utilities" in Sxmo. Last
time, we put "sxmo-sway" in sxmo ui, it broke installs when all the
patches were eventually grabbed by upstream and we reverted the package
dependency back to upstream "sway" in sxmo-common. Moreover, with sxmo
maturing, I want to move to a upstream-first approach to retain
stability.

4. More code review usually improves code quality.

Best wishes,
Anjandev Momi
--
w:] www.momi.ca
pgp:] https://momi.ca/publickey.txt

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<6f3f27f3-ee45-98bc-6629-69310824bd4a@disroot.org>
In-Reply-To
<87k0axce16.fsf@momi.ca> (view parent)
DKIM signature
pass
Download raw message
On 07.05.22 21:43, Anjandev Momi wrote:
> Great work! Im really happy to see progress on this issue since it's
> been a common complaint. Just a word of warning, please work with
> upstream (in this case swaylock) to get your code upstream. I would
> advise doing this asap so we arent left with a lot of work that will
> never be accepted upstream.
> 
> Here is the reasoning:
I don't care about the reasoning, you are right.

The one problem I currently see with upstreaming is that when I do the 
integration work for calls, notifications and all those other shiny 
things people expect on their lock-screens, swaylock will gain a lot of 
complexity which I don't know if the developers/maintainers want (and I 
wouldn't disagree if they said no). I guess I have to write some messages.

Thanks for the advice!
Sebastian

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<2OWHVDHEJVMEG.2QS2AU4BP2U4W@yellow-orcess.my.domain>
In-Reply-To
<2ea1886c-5d73-8c4f-c2a2-eff6a609a5da@disroot.org> (view parent)
DKIM signature
pass
Download raw message
Hey there,

Firstly thanks a lot again for working on this. It is a difficult
project but it the last sxmo missing part we need.

As anjan said, we dont want to support a sxmo related sub-fork. Ideally
this would be an existing upstream project or a mobile dedicated
program (used by multiple mobile environments).

As you explained it, adding a virtual keyboard to swaylock may or
probably may not be on the emersion tastes. My opinnion is that having
an optional argument to display a virtual keyboard could be considered
in the swaylock scope. But this have to be discussed with them !

In the end, I dont think there is any non DE related wayland locker with
integrated virtual keyboard. Using swaylock to build the first one
could make sense to me.

So I tried to play a bit with your swaylock-mobile fork.

First thing to notice : Relying on pin passphrase is a hard no-go to
me. We must support every available character sets. I know it means
that we must add a fully functionnal virtual keyboard to swaylock but
this looks very important to me. (we dont need more advanced
features as we got with wvkbd).

Then I tried to integrate this in sxmo workflows. My solution seems way
more simple than yours. Let me know if I missed important things but the
simplest way seems :

https://paste.sr.ht/~stacyharper/7894d590bf68a4f533b5d28f6a4aa21484e09423

-> making hardware buttons to still works while locked
-> start waylockd on screenoff

The existing three states are usefull to manage screen state. I want to
dissociate those behaviors from the new security locker as much as
possible.

Swaylock offer a simple way to not having to manage swaylock.

- We can start multiple swaylockd instance, only the first one will be
usefull. Laters one will just say "another already exists". We then dont
need to remember or manage this.
- It add a security wrapper arround swaylock and prevent kills or
crashes.

My opinion is : We choose the perfect moment to start the locker. Once
it is started, the user HAVE to type it's passphrase !

I started swaylockd on screenoff. It make it possible to lock the screen
while watching a video by example without starting swaylock. When the
video will finish, 8 seconds later, swaylock will start with the
screenoff state transition. I'll try this for sometime to see if it fits
as perfectly as it looks.

Probably missing points / issues / to be discussed :

- On the incoming calls subject, I think there is two solutions :
  - still require the passphrase (opinionated but can make sense. Looks
    simplest and could be a temporary solution at least)
  - display bemenu above swaylock (look harder cause I think swaylock
    will just grab any focus. Need to be POCed)
- Proximity lock conflicts.
  Either make the proximity lock to not actually run state hooks.
  Or we could start swaylockd outside of those hooks (in a completly
    independent swayidle + on post-suspend hooks ?).
  Or we just require passphrase to gain access to DTMF tones ? We can
  then share the phone while on call to someone else without giving full
  access.

As you can see, none of those constraints looks horrible and can be
considered as features depending on your opinion.
Only the numeric compatible passphrase constraint looks wrong to me atm.

I'm waiting for you opinions on this !
Stacy

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<1fc802f9-9064-2337-ffde-7b261f63df8b@disroot.org>
In-Reply-To
<2OWHVDHEJVMEG.2QS2AU4BP2U4W@yellow-orcess.my.domain> (view parent)
DKIM signature
pass
Download raw message
On 09.05.22 16:33, Stacy Harper wrote:
> Hey there,

Hey!


> As you explained it, adding a virtual keyboard to swaylock may or
> probably may not be on the emersion tastes. My opinnion is that having
> an optional argument to display a virtual keyboard could be considered
> in the swaylock scope. But this have to be discussed with them !

This somehow smells like a libwvkbd … or embedding support on wayland …
I have not talked to emersion yet … (missed him on irc yesterday)

> So I tried to play a bit with your swaylock-mobile fork.

Thank you!

> First thing to notice : Relying on pin passphrase is a hard no-go to
> me. 

That's what was easy to build in two nights and I hope the code screams 
that its not meant to stay like this. TLDR: agreed!

> 
> Then I tried to integrate this in sxmo workflows. My solution seems way
> more simple than yours. Let me know if I missed important things but the
> simplest way seems :
> 
> https://paste.sr.ht/~stacyharper/7894d590bf68a4f533b5d28f6a4aa21484e09423
> 
> -> making hardware buttons to still works while locked
> -> start waylockd on screenoff
> 
> The existing three states are usefull to manage screen state. I want to
> dissociate those behaviors from the new security locker as much as
> possible.
> 
> Swaylock offer a simple way to not having to manage swaylock.
> 
> […]
> 
> My opinion is : We choose the perfect moment to start the locker. Once
> it is started, the user HAVE to type it's passphrase !
> 
> I started swaylockd on screenoff. It make it possible to lock the screen
> while watching a video by example without starting swaylock. When the
> video will finish, 8 seconds later, swaylock will start with the
> screenoff state transition. I'll try this for sometime to see if it fits
> as perfectly as it looks.

Thanks for bringing swaylockd and it's locking functionality to my 
attention! Also I didn't think the locked (touchscreen off) state was 
there to stay. Also I'm in favor of having working hardware-buttons on 
the lockscreen, but The inputhandler script needs a reliable way to know 
that the input came from a locked state! (maybe a command-line flag 
would be the easiest solution)

Also I tried the screenoff hook right after trying out he lock hook and 
realizing that the lock state is triggered AFTER the screen comes back 
on, that's a no-go for me!

There are multiple reasons I built my patch the way I did:

* It will get annoying you pretty quickly that you have to type your 
pin/password every time that darn sensor is covered for a second.

* I also tried to fix the issue that when the proximity-lock is active 
and something in my pocket turns the phone on I want to go back to sleep 
pretty quickly otherwise it gets warm and when I realize the battery is 
drained (and my mom gets annoyed because I don't answer). Which works 
pretty well with the timeout.

* In case you rely on some trickery to decide whether to activate 
swaylock in the screenoff state its pretty easy to find combinations of 
proximity-lock + powerbutton + letting it go to sleep where the 
screen-locker comes up multiple times (would be solved by swaylockd), or 
worse the screen-locker doesn't come up.

* You don't want to end up on lock-screen you can't unlock because the 
touchscreen is still off (Managed to do that while testing on sxmo 1.8)

I also have a lot more cases where my approach fails, probably that 
includes your watching a video with just the touchscreen off, because 
that one locks the can_suspend which doesn't stop the lock-screen from 
coming up (and it shouldn't because ssh is a thing and I don't want to 
forget that my phone is unlocked while I'm looking at another screen), 
that includes many more, possibly because I made some silly mistakes 
somewhere.

Having swaylockd + sway keep track of the locked flag should work and it 
will definitely work better than my hacky approach.

> Probably missing points / issues / to be discussed :
> 
> - On the incoming calls subject, I think there is two solutions :
>    - still require the passphrase (opinionated but can make sense. Looks
>      simplest and could be a temporary solution at least)

I would at least want to know if it is wort unlocking …

>    - display bemenu above swaylock (look harder cause I think swaylock
>      will just grab any focus. Need to be POCed)

That's a hard no from me, nothing should be able to make its way on the 
lock-screen without some kind of permission of the screen-locker (There 
should be something that knows what exactly can show up and what can't, 
I'm not keen on this kind of surprise), also swaylock doesn't just grab 
all input but tells sway that it is a screen-locker that does 
screenlockery things.

> - Proximity lock conflicts.
>    Either make the proximity lock to not actually run state hooks.
>    Or we could start swaylockd outside of those hooks (in a completly
>      independent swayidle + on post-suspend hooks ?).

That's the whole reason behind splitting the state machine into two parts.

>    Or we just require passphrase to gain access to DTMF tones ? We can
>    then share the phone while on call to someone else without giving full
>    access.

I wouldn't pack a full call UI on the lock-screen either, hangup, mute, 
speaker, volume, done.

> As you can see, none of those constraints looks horrible and can be
> considered as features depending on your opinion.

I have to start somewhere :D
Suggestions for/and improvements are always welcome!

I'll update my blogpost based on your questions and my experience 
somewhere in the next few days. (or at least link to this conversation)

Greetings!
Slatian

(Signing with Sebastian results in even more name-clashes than Baschdel, 
surprise!)
--
web: https://slatecave.net

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<2RJLBFS6REMS2.2HHTWDFMYE2QY@yellow-orcess.my.domain>
In-Reply-To
<1fc802f9-9064-2337-ffde-7b261f63df8b@disroot.org> (view parent)
DKIM signature
pass
Download raw message
> Thanks for bringing swaylockd and it's locking functionality to my 
> attention! Also I didn't think the locked (touchscreen off) state was 
> there to stay.

Yap those three scripts will pretty much stay the same.

> Also I'm in favor of having working hardware-buttons on 
> the lockscreen, but The inputhandler script needs a reliable way to know 
> that the input came from a locked state! (maybe a command-line flag 
> would be the easiest solution)

Ah I see what you mean. My current solution allow me to start appmenu or
other inputhandler action while being locked out.

I think we could use two bindsym (one --locked and one without) to
distinguish both.
Or we could manage swaylockd a little bit using either sxmo_daemons.sh
or superd. It would then be easier to handle the security locked case on
different sxmo parts.

> Also I tried the screenoff hook right after trying out he lock hook and 
> realizing that the lock state is triggered AFTER the screen comes back 
> on, that's a no-go for me!

Mhh yes that's expected. To me the lock hooks cant be used to start the
security locker. And yes, ideally the locker should start early.

> There are multiple reasons I built my patch the way I did:
> 
> * It will get annoying you pretty quickly that you have to type your 
> pin/password every time that darn sensor is covered for a second.
> 
> * I also tried to fix the issue that when the proximity-lock is active 
> and something in my pocket turns the phone on I want to go back to sleep 
> pretty quickly otherwise it gets warm and when I realize the battery is 
> drained (and my mom gets annoyed because I don't answer). Which works 
> pretty well with the timeout.
> 
> * In case you rely on some trickery to decide whether to activate 
> swaylock in the screenoff state its pretty easy to find combinations of 
> proximity-lock + powerbutton + letting it go to sleep where the 
> screen-locker comes up multiple times (would be solved by swaylockd), or 
> worse the screen-locker doesn't come up.
> 
> * You don't want to end up on lock-screen you can't unlock because the 
> touchscreen is still off (Managed to do that while testing on sxmo 1.8)

For the last case it looks like if you start a bemenu behind swaylock
then the sway mode toggle to "menu" and you loose control over the
screen state. You can then be prisoner of the screenoff state.

One simple alternative I got in mind would be to add a manual trigger to
start swaylock. It would then be up to the user to choose when they lock
and when they dont.

To me it is either trying to be smart and do compromises, or be stupid
and reliable. Plus anyway, the user got a complete control over hooks to
implement their own automatisations.

> I also have a lot more cases where my approach fails, probably that 
> includes your watching a video with just the touchscreen off, because 
> that one locks the can_suspend which doesn't stop the lock-screen from 
> coming up (and it shouldn't because ssh is a thing and I don't want to 
> forget that my phone is unlocked while I'm looking at another screen), 
> that includes many more, possibly because I made some silly mistakes 
> somewhere.
> 
> Having swaylockd + sway keep track of the locked flag should work and it 
> will definitely work better than my hacky approach.
> 
> > Probably missing points / issues / to be discussed :
> > 
> > - On the incoming calls subject, I think there is two solutions :
> >    - still require the passphrase (opinionated but can make sense. Looks
> >      simplest and could be a temporary solution at least)
> 
> I would at least want to know if it is wort unlocking …
> 
> >    - display bemenu above swaylock (look harder cause I think swaylock
> >      will just grab any focus. Need to be POCed)
> 
> That's a hard no from me, nothing should be able to make its way on the 
> lock-screen without some kind of permission of the screen-locker (There 
> should be something that knows what exactly can show up and what can't, 
> I'm not keen on this kind of surprise), also swaylock doesn't just grab 
> all input but tells sway that it is a screen-locker that does 
> screenlockery things.

That's pretty much the kind of compromises we have to discuss. I also
understand that we dont want to display anything above swaylock but then
we have to unlock to pickup calls.

> > - Proximity lock conflicts.
> >    Either make the proximity lock to not actually run state hooks.
> >    Or we could start swaylockd outside of those hooks (in a completly
> >      independent swayidle + on post-suspend hooks ?).
> 
> That's the whole reason behind splitting the state machine into two parts.

Okay so that would mean we dont start swaylockd from any of the three
state hooks. We should then decide how/when we would start it.

Multiple ideas come :

- manually (as said before): lisgd gesture by example (long right edge
to bottom?)
- a new independent swayidle plus after/before suspension ?
- (both ?)

> >    Or we just require passphrase to gain access to DTMF tones ? We can
> >    then share the phone while on call to someone else without giving full
> >    access.
> 
> I wouldn't pack a full call UI on the lock-screen either, hangup, mute, 
> speaker, volume, done.
> 
> > As you can see, none of those constraints looks horrible and can be
> > considered as features depending on your opinion.
> 
> I have to start somewhere :D
> Suggestions for/and improvements are always welcome!

Yap basically the whole subject is completly up to debates. We have to
figure out the best and sane defaults for sxmo.

Stacee

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<279e321d-2767-c150-d63e-4a3ec00f6ad0@disroot.org>
In-Reply-To
<6f3f27f3-ee45-98bc-6629-69310824bd4a@disroot.org> (view parent)
DKIM signature
pass
Download raw message
On 07.05.22 23:36, Baschdel wrote:
> On 07.05.22 21:43, Anjandev Momi wrote:
>> Great work! Im really happy to see progress on this issue since it's
>> been a common complaint. Just a word of warning, please work with
>> upstream (in this case swaylock) to get your code upstream. 

> The one problem I currently see with upstreaming is that when I do the 
> integration work for calls, notifications and all those other shiny 
> things people expect on their lock-screens, swaylock will gain a lot of 
> complexity which I don't know if the developers/maintainers want (and I 
> wouldn't disagree if they said no). I guess I have to write some messages.

I exchanged some E-Mails with Simon (emersion) and nope I won't be able 
to get any of those features into upstream swaylock because of the 
complexity they introduce, swaylock is supposed to stay simple (which is 
an honorable goal). This means I'll start a proper fork at some point in 
the future.

Greetings,
Slatian

Re: Announce: working lockscreen integration for sxmo on wayland

Details
Message ID
<3GQWDQVJVNC8A.21K7P4H7SU5RN@yellow-orcess.my.domain>
In-Reply-To
<279e321d-2767-c150-d63e-4a3ec00f6ad0@disroot.org> (view parent)
DKIM signature
pass
Download raw message
> I exchanged some E-Mails with Simon (emersion) and nope I won't be able 
> to get any of those features into upstream swaylock because of the 
> complexity they introduce, swaylock is supposed to stay simple (which is 
> an honorable goal). This means I'll start a proper fork at some point in 
> the future.

Glab you figured it out directly with him. That an expected results.
Anyway there isnt that much available solution atm. Having more wayland
DE agnostic touchscreen lockers would be benefit for the whole
ecosystem.
Reply to thread Export thread (mbox)