~stacyharper 3 years ago

What do you think?

I completly agree with you. I also think leds while crust or off is useless.

I think you made good choices. Blinking while pressing is a really good idea as it create a good feedback.

I would love to see your patch on this. And if other god ideas about this rework, please share them :3

~edp17 3 years ago

I am happy to do that patch but I don't know how to do it. I can do it on github but never used sourcehub before.

~stacyharper 3 years ago

Have a look at: https://git-send-email.io/

Our devel mailing list is: https://lists.sr.ht/~mil/sxmo-devel (~mil/sxmo-devel@lists.sr.ht)

~edp17 3 years ago

I have sent the patch "Redesign of LED usage". Don't be too hard on this, please but any comments are welcome. :)

~edp17 3 years ago

Okay, it seems I've checked out the latest branch but my change was done on an older release. So, this is not relevant for the newer version anymore. (Example the I copied the sxmo_notificationmonitor.sh into the core folder rather than the notifications.) How can I fix this?

~stacyharper 3 years ago

You'll have to rebase and resolve conflicts I fear. What you can do is to save your works somewhere else and start again from the latest master commit. It may be easier this way

~edp17 3 years ago

I have hard reset back to before my changes, then reapplied the changes into the files and sent a new patch. Is this correct? ('Redesign of LED usage - fixed for latest')

~stacyharper 3 years ago

It looks better ya :D

~edp17 3 years ago

Sorry for the previous. :D

~murks 3 years ago

Good idea! One thing that I think could be better is a way to distinguish between screen off and crust. I guess that would mean some LED for screen off.

~edp17 3 years ago

I have reworked my original idea. (Also created functions for blinking LED rather than repeating the "echo 0" and "echo 1" lines. :)) The new idea is this: 1.

• From menu - Lock & screen on: Green LED blinking, then Yellow LED is on
• Unlock screen (hold power button): Yellow LED blinking

• From menu - Lock & screen off: Yellow LED blinking, then No LED
• Waking up the screen (short press power button): Green LED blinking, then No LED when the screen is off again
• Unlock screen (hold power button): Yellow LED blinking

• From menu - Suspend: Green LED blinking, then No LED
• Waking up the screen (short press power button): Green LED blinking, then No LED when the screen is off again
• Unlock screen (hold power button): Yellow LED blinking

• Swipe - Suspend: Green LED blinking, then No LED
• Waking up the screen (short press power button): Green LED blinking, then No LED when the screen is off again
• Unlock screen (hold power button): Yellow LED blinking

I've made the changes on the device and they do mainly work fine but at some stages, some unexpected LED shown. Once I debugged/fixed, will push a patch over.

~murks 3 years ago

If I understand it correctly that still does not let you differentiate between screen off and crust, as both show no LED, correct?

~edp17 3 years ago

Yes, that is correct. Maybe it is just me, but I don't like to keep LED on when the screen is off. That is disrupting and consumes energy (yes, I know a small amount but still). When the screen is on and locked, that is different because in that case, the LED gives me an indication of why the screen is not responding.

~l5_plaintextsk 3 years ago

I like current led meaning, but I also like "no led in sleep". I have stopped using crust, as I have not received some calls (other party heard ringing and nothing on my side). So currently I use only lock + screen off. It is bit long to "hold up volume and than hold down volume" to lock and turn off screen. I would like to turn off screen after first vol up long press. Would it be reasonable for your usecases?

Reserving red led for errors seems not valid for me, because no errors are being proposed to be shown right now. Is it easy to detect modem lost problem in red, or at least something other meaningful?

PS: on mine pinephone I clearly see that there are three leds (red, blue and green). I would probably have hard time to see/remember that some state means yeallow and how it looks like. I would prefer/vote to use given three bits of information separated.

PS2: I like idea using leds to distinguish between missed calls/sms. But count on that there can be also other notification (perhaps user defined). For me it will be enough to see that I have something missed from "modem" part or other notification. Difference between sms and call would be bonus.

~edp17 3 years ago

Yeah, I think everyone has a different view on how and what LED to use and it depends on our taste what we like or don't. :)

Regarding the red LED how I meant was, it could be used to show if the system was busy to respond or when it was shutting down. (I am from Sailfish OS where the red LED is used for those events.)

I also got the problem of not receiving SMS in deep sleep and not getting any notifications either. (Interestingly after a reboot, all messages arrived. Could it be just the modem or something restarted when the screen is unlocked by the power button? I am not sure whether that is possible and/or that could solve this issue though.)

The reason I created my own LED setup (and suggested a redesign) was, I found the original setup is more developer rather than user friendly.

Fortunately, it is possible to amend those scripts on my device, so I can get the LED setup I prefer. :)

~murks 3 years ago

My argument for some LED on when the screen is locked is that I want to know that the phone is in that state because:

1. Screen off draws more power than crust.
2. Network is up (accessible via SSH).
3. You also want to know that when something is not working as expected during crust.

The LED is the only easily accessible way to distinguish between screen off and crust, that's why I would really suggest to keep a LED on during screen off or blinking every few seconds.

~proycon 3 years ago

I'm a bit late to this discussion and might have missed things, but I completely agree with what murks wrote:

On 21-09-29 11:36, ~murks wrote:

My argument for some LED on when the screen is locked is that I want to know that the phone is in that state because:

1. Screen off draws more power than crust.
2. Network is up (accessible via SSH).
3. You also want to know that when something is not working as expected during crust.

The LED is the only easily accessible way to distinguish between screen off and crust, that's why I would really suggest to keep a LED on during screen off or blinking every few seconds.

I'm even in favour of having a LED on in crust so you know the device is still on and hasn't run out of battery (which still happens regularly).

So basically I'm fairly happy with the current state of our LEDs, but perhaps we should make things more easily configurable so it can be tweaked to everyone's liking.

--

Maarten van Gompel (proycon) https://proycon.anaproy.nl

~stacyharper 3 years ago

Yeah basically I think our current usage of led is consistent with our screenlock behaviors and flows atm.

IMHO, In an ideal version of Sxmo:

• I dont care about off/suspend mode cause the phone will always be suspended if the screen is off and nothing is running (ssh session, music, sound) on the phone.

• Leaving screen off mode and crust will be the exact same thing. Ex, short press power to display a semi dark screenlock wallpaper with some basic information. Short press again to bring a keyboard and type passphrase to fully unlock the phone. Or wait and sxmo go back to suspended mode or stay off if music or wathever.

• Then, led will be used for more precise notifications :)

~edp17 3 years ago

Yeah, I see your points/reasons. As a developer, I absolutely agree: I would like to know whether the device is on and in crust or just screen off. As a user, I don't care. When the screen is off (even in crust) I expect all the basic functions (receiving SMS/calls) do work and the device won't switch off silently. :) I've found keeping the LED on especially during the night is disturbing. However, I agree that this is down to each individuals' taste. :)

~edp17 3 years ago

I agree with @stacyharper.

~murks 3 years ago

I doubt what Stacy sketched out there is even possible. As far as I can tell Crust is energy saving precisely because certain things are turned off. You can't have both, things turned off and working at the same time. Even if you try to be "smart" about it, that is a) error prone and b) some things are simply not possible. As an example you can inhibit crust if an SSH session is ongoing but you can't initiate a SSH session if the phone is in crust. This is something you can't just abstract away and in such cases I'm in favor of not abstracting it away but keeping users aware of it and leaving them control.

~proycon 3 years ago

On 21-10-01 08:47, ~murks wrote:

I doubt what Stacy sketched out there is even possible. As far as I can tell Crust is energy saving precisely because certain things are turned off. You can't have both, things turned off and working at the same time. Even if you try to be "smart" about it, that is a) error prone and b) some things are simply not possible. As an example you can inhibit crust if an SSH session is ongoing but you can't initiate a SSH session if the phone is in crust. This is something you can't just abstract away and in such cases I'm in favor of not abstracting it away but keeping users aware of it and leaving them control.

I agree with you yes. It's best to have the users be aware and leave them in control. I think features like automatic suspension and automatic screen-off should be opt-in rather than the system trying to be too smart by default. We may expect from our users to do the necessary configuration to tweak the system to their liking.

--

Maarten van Gompel (proycon) https://proycon.anaproy.nl

~edp17 3 years ago

I think the key point here is the ability to configure according to our needs. If I could configure the LED as I needed, I wouldn't want to start this topic. As currently the LED usage is encapsulated in a few scripts, I think, it would be a good start to separate them into one script. which then could be driven by a config file. Then, a maintenance option (if needed) could be developed to manipulate that config file. On my device, I'll try to do this.

~edp17 referenced this from #339 3 years ago

~the01player 3 years ago · edit

I agree. Everyone has different preferences for how they use LEDs and an easy way to configure them seems like the most reasonable way to fit everyone's use case.

~edp17 3 years ago

I've reworked my original idea and submitted a patch https://lists.sr.ht/~mil/sxmo-devel/patches/25546. In there I extracted the LED usage from scripts (sxmo_screenlock.sh, sxmo_rtcwake.sh, sxmo_postwake.sh and sxmo_notificationmonitor.sh) into one script (sxmo_leds.sh) and introduced a config file to control them. It is a very basic solution. In the config file that was included in the patch, I added the original LED settings. On my device, I have tested both the original and my custom settings and both worked well. What do you think?

~murks 3 years ago

I get a 404 for that patch url.

~edp17 3 years ago

Yeah, because for some reason the full stop at the end of sentence, became the part of the url. Please copy/paste the url and remove the dot at the end. I have no idea how to amend a comment, so cannot fix that. Sorry.

~edp17 3 years ago

I hope this will work: https://lists.sr.ht/~mil/sxmo-devel/patches/25546

~l5_plaintextsk 3 years ago

One wish: be able to "see" that phone is charging (or at least it have started charging). Using LED can provide permanent version of info. Some info on screen (perhaps with /sys/class/power_supply/axp20x-battery/current_now and /sys/class/power_supply/axp20x-usb/usb_type or /sys/class/power_supply/axp20x-usb/input_current_limit) for few seconds after connecting would be also handy.

~l5_plaintextsk 3 years ago

Another wish/idea. Making LED configurable using some language for FSM (finite state machine). Would it be reasonable?

For example using PlantUML it could be like this: https://www.planttext.com/?text=LP7DYa8n34RtUOgi1-uBk10HYnjrH146HYcbDrSBRIfjHbz_wiMVTfdqV3aXdMKnIVw21n0ddd3_i_x6hMFQNY8JhjG2UsVEoGJC9bmzmU_N2RjkYYZXgYNgHDnJqYRhCaj8Ft60dLheajUHH_vT3WDEq5vCEbCgmxEDp6I5UgYH9iBl18uB5nRcguFwq5Fyr0-QwOx1vKmzMkCzrAzTGu_hL2Xo53SuQyH5FlBWobKIXNXxI9SxfJQrjMgyj3baQDfTout20ZKYR3spSjJoA_y0

~phartman REPORTED FIXED 2 years ago