support for led notifications

wdehoog · 29 Oct 2019, 16:49

[edit 2019/11/20] {
Sorry I give up. I have working code but the automated tests fail. Unfortunately the testing framework is even more complicated then unity itself and the things it tests are trivial. I see no use in crafting dbus messages and plugins just to automatically 'test' a led turning white or green.

Small advice: maintaining this test bed is too big a burden for a project this short of man power. I think you really should get rid of it.
}

I want to have the led on my phone show it is being charged or it's battery is full.
One of the core developers on telegram pointed out that this could be done by extending repowerd. So I tried to do that.

[edits] {
2019/11/09 made a PR for unity8
2019/11/07 I am now changing IndicatorsLight.qml. You can already try it. No need to build anything, just replace the qml file (keep a copy).
}

This is my first step in ubports and I have absolutely no clue of the architecture of ubports or the direction it is going into. So any development related reactions are welcome.

What I did:
Created a LightControl that does two things. Control the led (on/off/color etc) and manage the led. With managing I mean show a certain event charging, full, etc.
The battery state is monitored by UPowerPowerSource. I made it pass the BatteryInfo in its changed callback and have DefaultStateMachine pass it along.
Furthermore DefaultStateMachine also notifies display on/off.
Led styles are now hardcoded but could be made to use DeviceConfig.
Currently the led is off when the display is on. It can show charging (white pulsing) and full (solid lime green).

Choice to make

Currently the led shows dark green when a message is 'new'. This is handled by a qml file in Unity.
There cannot be two captains on this ship so either Unity must take care of managing the led or repowerd. I opt for repowerd.
Should the led be controllable through dbus?

Problems

I need information on how to know the state (or keep track of it) of pending new messages and missed calls.
I don't have sim card in my phone. How can I test 'pending new message'?

My work can be found in the add-light branch of repo https://github.com/wdehoog/repowerd
Development is done using cross-builder. I test it on my oneplus one.

When interested to test see: https://gist.github.com/wdehoog/c7c09a792799d03e6880e10dbc19ab33

PS.
I have very strong feelings about the testing framework of repowerd. The COC probably forbids me to express them.

flohack · 29 Oct 2019, 19:14

Hello and thanks for your motivation, it feels like you are highly motivated, so we want to get you onboard this train fast

Some high-level thoughts:

For a long time I was pondering the same idea roughly. I wanted to have information about bluetooth being on/discoverable so that you could remember to turn it off when not needed.
As you already found out, there is a use for the led as notifications indicator, this must not break! Its one of the core things that really works well
If you install a new authority for LED access, of course unity8 or whoever from that gang drives notifications LED now needs to backoff and we need to instead let him be a client for your component.
Your component does not need to track the state of messages, it should react on a request from Postal service to turn on or off this LED message class
Your component needs a hierarchy or alteration scheme for various LED message classes that have order of importance like:

(highest) Battery low
Unread notifications
Bluetooth enabled
(Lowest) Charging/Fully charged - those are exclusive and therefore in the same slot

OR:

Have a mechanism of rotation of LED states: Each slot will be visible for x seconds - But it could get irritating for the users, so I am not sure about it
You can even without SIM card trigger notifications - just install TELEports App, register a Telegram account on another device and let some messages arrive. OR use FluffyChat with a matrix account. Both will work without SIM card needed.

AppLee · 29 Oct 2019, 19:47

@Flohack said in support for led notifications:

You can even without SIM card trigger notifications - just install TELEports App, register a Telegram account on another device and let some messages arrive. OR use FluffyChat with a matrix account. Both will work without SIM card needed.

You can also use Dekko too for your emails... I have activated push imap and the notifications are fast (no need to wait 5-30 minutes for a test

wdehoog · 29 Oct 2019, 19:49

@Flohack Thanks for your warm welcome. Not sure if I will come onboard. I am more of a drive-by developer but lets see how it rolls.

Thanks for pointing me to the Postal service. If I understand you correctly you think that it is best if this Light thinghy can be notified by dbus of certain states/changes (pending messages, bluetooth discoverability, battery low)?

Wouldn't that cause modification of lots of services/stuff to become aware if this new led controller? I am trying to keep the changes more in one place.

Above all do you agree with the approach of having this 'led authority' as you call it, located in repowerd?

flohack · 29 Oct 2019, 22:53

@wdehoog Yeah lets see how this rolls ^^

Well no I am not concerned that this will cause many changes: LED is currently only used by notifications, and this is already centralized, so its one place to change. I agree on the DBus architecture as it is the most commonly used thing for IPC in UT.
I forgot one thing: All LED message classes should be configureable via system settings, so your addon to repowerd also needs to be able to remember what the user has turned on and what not. Otherwise I can hear already the many voices complaining that they cannot turn off x ^^

dobey · 30 Oct 2019, 19:02

@Flohack said in support for led notifications:

I forgot one thing: All LED message classes should be configureable via system settings, so your addon to repowerd also needs to be able to remember what the user has turned on and what not. Otherwise I can hear already the many voices complaining that they cannot turn off x ^^

This would be outside the scope of repowerd handling of the hardware itself, I think. Instead, for notifications level configuration, this would be handled by the code which handles notifications, and then requests the LED to be set to a color or whatever.

Anyway, I also think we shouldn't let any configuration possibilities get too out of hand. More configuration means more problems.

flohack · 1 Nov 2019, 14:35

@dobey Well we can put it into a separate component, but the entry barrier will be higher, it would be a standalone service, or would you put it into Postal or such? Anyways, if we want to have morethan one meaning for the LED we need something that holds this state of alternatives. Putting it into repowerd might be not the most elegant way but its a scope that a single dev can handle probably.

dobey · 1 Nov 2019, 14:35

@Flohack Well, as a comparison, the Power and Volume keys have multiple meanings, and all those meanings are not handled by repowerd. It only deals with the hardware, and unity8 decides whether the screen should be turned off, the reboot menu should be opened, volume should be changed, or a screenshot taken.

Likewise, repowerd should only handle the direct interaction with the LED hardware. It shouldn't manage itself what needs the LED is being used for; only handle the requests from above to set the state to on, off, blinking, pulsing, and what color it should be; and maybe deal with conflicts if multiple things want to set the state.

As for notifications, this is another area of the system that has long needed much refactoring and consolidation. Currently it's all spread across multiple components and is quite a mess. "Better LED handling for things" is as good a reason as any to start getting things cleaned up there as well. For an immediate solution, keeping the same LED usage and simply moving the core hardware interaction into repowerd with unity8 asking it to turn the LED on and off, rather than doing itself, is the way forward. Then a little more refactoring could be done to enable charging status along with the current generic notifications usage. And then more from there later on.

wdehoog · 1 Nov 2019, 15:46

@dobey @Flohack
repowerd seems to do more then handling hardware. It contains a class DefaultStateMachine that also keeps track of state and for example takes care of the display dimming and turing off.
It also knows about the battery state. For the proposed led states (charging/low/full/bt/notifications) repowerd seems like a good place for now.

unity currently detects unread notifications by checking if a dbus signal (Changed) contains a "message" part with an "icon" field with a string containing "indicator-messages-new". When the display is off it sets the led. I guess repowerd can also listen to this signal.

I'll gladly move the led stuff stuff somewhere else but the current unity place (qml\Panel\Indicators\IndicatorsLight.qml) feels like the wrong one. A friend of mine (owned a ut-phone) suggested the lockscreen should manage the led state.

If it is decided that the led indicator is usefull and should be part of ubports then indeed configurability should not be overdone. Some already existing config file would allow things to be disabled if really needed.

dobey · 1 Nov 2019, 21:12

@wdehoog said in support for led notifications:

It contains a class DefaultStateMachine that also keeps track of state and for example takes care of the display dimming and turing off.

Yes, repowerd is the thing which tells the hardware what to do here. It is the implementation for such pieces of hardware interaction. It is not where policy is decided though. It is simply told when the display should be dimmed or powered off, when an alarm event should be triggered, etc… It is itself not a full stack.

@wdehoog said in support for led notifications:

I guess repowerd can also listen to this signal.

No, repowerd should not implement any part of indicator rendering.

@wdehoog said in support for led notifications:

I'll gladly move the led stuff stuff somewhere else but the current unity place (qml\Panel\Indicators\IndicatorsLight.qml) feels like the wrong one

It may not be the right place, but it is a sufficient one for now. There's no need to move the "should the LED be enabled, and how" to somewhere else. The only part that should be moved to repowerd is the part that actually turns the LED on, off, blinks/pulses it, and such. It should not do more than that.

@wdehoog said in support for led notifications:

A friend of mine (owned a ut-phone) suggested the lockscreen should manage the led state.

Friends and users do not developers make. The lock screen is definitely the wrong place. The current location is fine for the level of refactoring which needs to be done now, to achieve what you want. There's no need to grow things beyond their need yet.

@wdehoog said in support for led notifications:

If it is decided that the led indicator is usefull and should be part of ubports then indeed configurability should not be overdone. Some already existing config file would allow things to be disabled if really needed.

There is no need to worry about this level of configuration yet, to achieve the immediate goal of charging/charged LED status.

wdehoog · 2 Nov 2019, 15:48

@dobey
So repowerd will listen on dbus to set the led on/off state, color and pulse rate.
Unity will decide if and how the led should shine.

Now the thing is repowerd already knows about the battery state and the display state.
So I think part of the policy could best be done in repowerd:

only show the led when the display is off
indicate battery low (or hot?)
if no other state for the led is set then show charging/full
unity will then set the led state regarding unread messages, bluetooth or whatever comes next

But I am new here so you I'll follow your advice.

The order would then be

move led hardware control to repowerd.
Allow the led state to be controlled through dbus.
Let unity use the led using dbus (extend Powerd plugin, remove Lights plugin).
Add led indication of battery state low/charging/full.
Question is where should this be done and how does it get the battery info?

matteo · 1 Jul 2020, 19:07

@wdehoog Willem, according to the discussion we've had on Telegram, only for convenience I'm reporting here the required output taken out from my Pro5, reviving the present thread:

Case from "Close to full charging" to "Fully charged": USB phone charging with black screen and white led blinking all the time - charged today from 77% to 100%-------> Full report - Pro5.

Thank you.

Matteo

wdehoog · 1 Jul 2020, 17:25

@matteo could you paste the whole unity8.log file?

weird stuff going on:

sometimes deviceState is charging/discharging and sometimes it is empty
battery level sometimes is 0
while discharging the level goes up

UniSuperBox · 7 Jan 2020, 17:40

I think what we've found is that the Meizu phones (MX4 and Pro 5) only have a single-color LED below the screen (where the Android home button would be), and for whatever reason Unity8 only knows how to make it blink, never solid.

matteo · 7 Jan 2020, 17:53

@wdehoog updated the previous post with the full report. I also saw that 0% charging level....weird indeed. Thank you for your help.

HendriXXX · 7 Jan 2020, 18:42

I was a bit suprised about shining led couple days ago, when I charged my Nexus 5. And even more when it turned different color after charged full. Good job, whoever made it work!

matteo · 1 Aug 2020, 09:25

Willem, here below the full unity8 report:

Unity8. log full report

Let me know if you need additional check.

Regards.

Matteo

wdehoog · 1 Jul 2020, 22:56

@matteo to test your leds. It is also interesting to see the permissions. For example on opo:

phablet@ubuntu-phablet:~$ find /sys -name brightness -ls
    13414      0 -rw-rw-r--   1 system   android_input     4096 Jan  5 20:48 /sys/devices/f9924000.i2c/i2c-2/2-0068/leds/red/brightness
    13442      0 -rw-rw-r--   1 system   android_input     4096 Jan  5 20:48 /sys/devices/f9924000.i2c/i2c-2/2-0068/leds/blue/brightness
    13428      0 -rw-rw-r--   1 system   android_input     4096 Jan  5 20:48 /sys/devices/f9924000.i2c/i2c-2/2-0068/leds/green/brightness
    11561      0 -rw-rw-r--   1 system   android_input     4096 Jan  5 20:48 /sys/devices/mdp.0/qcom,mdss_fb_primary.169/leds/lcd-backlight/brightness
    19339      0 -rwxrwxrwx   1 system   android_media     4096 Mar  3  1970 /sys/devices/leds-qpnp-f6287e00/leds/led:flash_torch/brightness
    19303      0 -rwxrwxrwx   1 system   android_media     4096 Mar  3  1970 /sys/devices/leds-qpnp-f6287e00/leds/led:flash_0/brightness
    19320      0 -rwxrwxrwx   1 system   android_media     4096 Mar  3  1970 /sys/devices/leds-qpnp-f6287e00/leds/led:flash_1/brightness
    17399      0 -rw-r--r--   1 root     root              4096 Jan  7 20:27 /sys/devices/leds-qpnp-f628c000/leds/kpdbl-pwm-2/brightness
    17421      0 -rw-r--r--   1 root     root              4096 Jan  7 20:27 /sys/devices/leds-qpnp-f628c000/leds/kpdbl-pwm-3/brightness
    17443      0 -rw-r--r--   1 root     root              4096 Jan  7 20:27 /sys/devices/leds-qpnp-f628c000/leds/kpdbl-pwm-4/brightness
    17377      0 -rw-rw-r--   1 system   android_input     4096 Jan  5 20:48 /sys/devices/leds-qpnp-f628c000/leds/button-backlight/brightness
    16275      0 -rw-rw-r--   1 system   android_input     4096 Mar  3  1970 /sys/devices/qcom,camera-led-flash.83/leds/torch-light/brightness
    17292      0 -rw-r--r--   1 root     root              4096 Jan  7 20:27 /sys/devices/msm_sdcc.1/leds/mmc0::/brightness
    17335      0 -rw-r--r--   1 root     root              4096 Jan  7 20:27 /sys/devices/msm_sdcc.2/leds/mmc1::/brightness

If 'phablet' is allowed you can try:

echo 1 > /sys/...../brightness

if not you must do it as root:

sudo bash -c "echo 1 > /sys/...../brightness"

(replace the dots with the full path) and try to echo different values (0,1,64,255)

Then it would also be interesting to show what other files reside in the same directories as the 'brightness' file. For example on opo:

phablet@ubuntu-phablet:~$ ls -l  /sys/devices/leds-qpnp-f6287e00/leds/led:flash_torch/
total 0
-rwxrwxrwx 1 system android_media 4096 Mar  3  1970 brightness
lrwxrwxrwx 1 root   root             0 Jan  7 20:33 device -> ../../../leds-qpnp-f6287e00
-rw-rw-r-- 1 root   root          4096 Jan  7 20:33 flash_blink
-rw-rw-r-- 1 root   root          4096 Jan  7 20:33 led_mode
-rw-r--r-- 1 root   root          4096 Jan  7 20:33 max_brightness
drwxr-xr-x 2 root   root             0 Mar  3  1970 power
-rw-rw-r-- 1 root   root          4096 Jan  7 20:33 strobe
lrwxrwxrwx 1 root   root             0 Jan  5 20:48 subsystem -> ../../../../class/leds
-rw-r--r-- 1 root   root          4096 Jan  7 20:33 trigger
-rw-r--r-- 1 root   root          4096 Mar  3  1970 uevent

And please post a dmesg log somewhere. Maybe this is related: https://e2e.ti.com/support/power-management/f/196/t/421131

matteo · 9 Jan 2020, 08:41

@wdehoog hi Willem, thank you for the suggestions. I searched on the internet and what @UniSuperBox said before about only the white color to be natively available on the Meizu phones seems correct: at least one app does exist on Flyme/Android side able to unleash all the other colors for the Pro5 as well, so maybe also for UT a work-around could be eventually feasible somehow ---------> RGB led notification Flyme

Now, here below the check I made.

phablet@ubuntu-phablet:~$ sudo find /sys -name brightness -ls
     8459      0 -rw-rw----   1 system   system       4096 gen  9 09:06 /sys/devices/virtual/backlight/pwm-backlight.0/brightness
    15318      0 -rw-rw-rw-   1 root     root         4096 gen  9 09:06 /sys/devices/gpioi2c0.14/i2c-12/12-0030/leds/m86_led/brightness
    15238      0 -rw-r--r--   1 root     root         4096 gen  9 09:23 /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/flash0/brightness
    15252      0 -rw-r--r--   1 root     root         4096 gen  9 09:23 /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/flash1/brightness
    15266      0 -rw-r--r--   1 root     root         4096 gen  9 09:23 /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/torch0/brightness
    15280      0 -rw-r--r--   1 root     root         4096 gen  9 09:23 /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/torch1/brightness

I typed sudo bash -c "echo 1 > /sys/...../brightness" for all of the items listed above but apparently it didn't work; actually, the only consequence I've seen is when I got the usb cable connected powering up the phone with the notification light blinking, just after sending one of those commands the light suddenly disappeared.
The following is what I have got in each of the folders above listed:

phablet@ubuntu-phablet:~$ ls -l /sys/devices/virtual/backlight/pwm-backlight.0/
total 0
-r--r--r-- 1 root   root   4096 gen  9 09:35 actual_brightness
-rw-r--r-- 1 root   root   4096 gen  9 09:35 bl_power
-rw-rw---- 1 system system 4096 gen  9 09:30 brightness
-r--r--r-- 1 root   root   4096 gen  9 09:35 max_brightness
drwxr-xr-x 2 root   root      0 gen  9 09:06 power
lrwxrwxrwx 1 root   root      0 gen  9 09:06 subsystem -> ../../../../class/backlight
-r--r--r-- 1 root   root   4096 gen  9 09:35 type
-rw-r--r-- 1 root   root   4096 gen  9 09:05 uevent

phablet@ubuntu-phablet:~$ ls -l /sys/devices/gpioi2c0.14/i2c-12/12-0030/leds/m86_led/
total 0
-rw-rw-rw- 1 root root 4096 gen  9 09:24 brightness
lrwxrwxrwx 1 root root    0 gen  9 09:37 device -> ../../../12-0030
-rw-r--r-- 1 root root 4096 gen  9 09:37 led_current
-r--r--r-- 1 root root 4096 gen  9 09:37 max_brightness
-r--r--r-- 1 root root 4096 gen  9 09:37 max_current
drwxr-xr-x 2 root root    0 gen  9 09:06 power
lrwxrwxrwx 1 root root    0 gen  9 09:06 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 gen  9 09:37 trigger
-rw-r--r-- 1 root root 4096 gen  9 09:05 uevent

phablet@ubuntu-phablet:~$ ls -l /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/flash0/
total 0
-rw-r--r-- 1 root root 4096 gen  9 09:29 brightness
lrwxrwxrwx 1 root root    0 gen  9 09:37 device -> ../../../13-0063
-rw-r--r-- 1 root root 4096 gen  9 09:37 enable
-r--r--r-- 1 root root 4096 gen  9 09:37 max_brightness
-rw-r--r-- 1 root root 4096 gen  9 09:37 onoff
drwxr-xr-x 2 root root    0 gen  9 09:06 power
-rw-r--r-- 1 root root 4096 gen  9 09:37 source
lrwxrwxrwx 1 root root    0 gen  9 09:06 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 gen  9 09:37 timeout
-rw-r--r-- 1 root root 4096 gen  9 09:37 trigger
-rw-r--r-- 1 root root 4096 gen  9 09:05 uevent

phablet@ubuntu-phablet:~$ ls -l /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/flash1/
total 0
-rw-r--r-- 1 root root 4096 gen  9 09:29 brightness
lrwxrwxrwx 1 root root    0 gen  9 09:39 device -> ../../../13-0063
-rw-r--r-- 1 root root 4096 gen  9 09:39 enable
-r--r--r-- 1 root root 4096 gen  9 09:39 max_brightness
-rw-r--r-- 1 root root 4096 gen  9 09:39 onoff
drwxr-xr-x 2 root root    0 gen  9 09:06 power
lrwxrwxrwx 1 root root    0 gen  9 09:06 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 gen  9 09:39 trigger
-rw-r--r-- 1 root root 4096 gen  9 09:05 uevent

phablet@ubuntu-phablet:~$ ls -l /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/torch0/
total 0
-rw-r--r-- 1 root root 4096 gen  9 09:30 brightness
--w--w---- 1 root root 4096 gen  9 09:40 chip_reg
lrwxrwxrwx 1 root root    0 gen  9 09:40 device -> ../../../13-0063
-rw-r--r-- 1 root root 4096 gen  9 09:40 enable
--w--w---- 1 root root 4096 gen  9 09:40 hwen
-r--r--r-- 1 root root 4096 gen  9 09:40 max_brightness
-rw-r--r-- 1 root root 4096 gen  9 09:40 onoff
drwxr-xr-x 2 root root    0 gen  9 09:06 power
-rw-r--r-- 1 root root 4096 gen  9 09:40 source
lrwxrwxrwx 1 root root    0 gen  9 09:06 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 gen  9 09:40 trigger
-rw-r--r-- 1 root root 4096 gen  9 09:05 uevent

phablet@ubuntu-phablet:~$ ls -l /sys/devices/gpioi2c1.15/i2c-13/13-0063/leds/torch1/
total 0
-rw-r--r-- 1 root root 4096 gen  9 09:30 brightness
lrwxrwxrwx 1 root root    0 gen  9 09:40 device -> ../../../13-0063
-rw-r--r-- 1 root root 4096 gen  9 09:40 enable
-r--r--r-- 1 root root 4096 gen  9 09:40 max_brightness
-rw-r--r-- 1 root root 4096 gen  9 09:40 onoff
drwxr-xr-x 2 root root    0 gen  9 09:06 power
lrwxrwxrwx 1 root root    0 gen  9 09:06 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 gen  9 09:40 trigger
-rw-r--r-- 1 root root 4096 gen  9 09:05 uevent

matteo · 9 Jan 2020, 08:52

In regard to the dmesg log, may I ask you what's that for? Only to understand the purpose, generally speaking. I looked for /var/log directory and I found several archived dmesg files but a bit outdated I'd say. However, I'd copied the most up to date dmesg file and in the following link you can find the details: dmesg.log

Please, tell me if you need something else from me. Needless to say, I really appreciate what you are doing