UBports Robot Logo UBports Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    support for led notifications

    Scheduled Pinned Locked Moved OS
    36 Posts 9 Posters 6.9k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
      Reply
      • Reply as topic
      Log in to reply
      This topic has been deleted. Only users with topic management privileges can see it.
      • flohackF Offline
        flohack @dobey
        last edited by

        @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.

        My languages: πŸ‡¦πŸ‡Ή πŸ‡©πŸ‡ͺ πŸ‡¬πŸ‡§ πŸ‡ΊπŸ‡Έ

        dobeyD 1 Reply Last reply Reply Quote 0
        • dobeyD Offline
          dobey @flohack
          last edited by

          @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.

          1 Reply Last reply Reply Quote 1
          • W Offline
            wdehoog
            last edited by

            @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.

            dobeyD 1 Reply Last reply Reply Quote 0
            • dobeyD Offline
              dobey @wdehoog
              last edited by

              @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.

              W 1 Reply Last reply Reply Quote 0
              • W Offline
                wdehoog @dobey
                last edited by

                @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?
                M 1 Reply Last reply Reply Quote 1
                • M Offline
                  matteo @wdehoog
                  last edited by matteo

                  @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

                  W 1 Reply Last reply Reply Quote 0
                  • W Offline
                    wdehoog @matteo
                    last edited by wdehoog

                    @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

                    M 1 Reply Last reply Reply Quote 0
                    • U Offline
                      UniSuperBox
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • M Offline
                        matteo @wdehoog
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • HendriXXXH Offline
                          HendriXXX
                          last edited by

                          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! β˜ΊπŸ‘

                          1 Reply Last reply Reply Quote 0
                          • M Offline
                            matteo
                            last edited by matteo

                            Willem, here below the full unity8 report:

                            Unity8. log full report

                            Let me know if you need additional check.

                            Regards.

                            Matteo

                            W 1 Reply Last reply Reply Quote 1
                            • W Offline
                              wdehoog @matteo
                              last edited by wdehoog

                              @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

                              M 1 Reply Last reply Reply Quote 2
                              • M Offline
                                matteo @wdehoog
                                last edited by

                                @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
                                
                                
                                W 1 Reply Last reply Reply Quote 0
                                • M Offline
                                  matteo
                                  last edited by matteo

                                  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 πŸ‘

                                  W 1 Reply Last reply Reply Quote 0
                                  • W Offline
                                    wdehoog @matteo
                                    last edited by

                                    @matteo in this link they mention a problem with the led driver your phone has (I don't have one so I could be totally wrong). And this link mentions how you could get it to show something (if it works).

                                    So do you get any results with find /sys/bus/i2c -name select_engine or with find /sys/bus/i2c -name lp5562

                                    M 1 Reply Last reply Reply Quote 0
                                    • W Offline
                                      wdehoog @matteo
                                      last edited by

                                      @matteo If the led went off with sudo bash -c "echo 1 > /sys/...../brightness" then you are on to something. Try other values (64, 255).
                                      Also check what cat /sys/.../onoff says or cat /sys/.../enable.

                                      1 Reply Last reply Reply Quote 0
                                      • M Offline
                                        matteo @wdehoog
                                        last edited by

                                        @wdehoog Willem, I started looking around at the references you gave to me. According to an other post in this Forum, it seems the RGB leds are disabled on purpose; see here below the section of the kernel file leds-lp5562.c commented out for this reason:

                                        static struct lp55xx_led_config lp5562_led_config[] = {
                                        	/*{
                                        		.name 		= "R",
                                        		.chan_nr	= 0,
                                        		.led_current	= 20,
                                        		.max_current	= 40,
                                        	},
                                        	{
                                        		.name 		= "G",
                                        		.chan_nr	= 1,
                                        		.led_current	= 20,
                                        		.max_current	= 40,
                                        	},
                                        	{
                                        		.name 		= "B",
                                        		.chan_nr	= 2,
                                        		.led_current	= 20,
                                        		.max_current	= 40,
                                        	},*/
                                        	{
                                        		.name 		= "m86_led",
                                        		.chan_nr	= 0,
                                        		.led_current	= 80,
                                        		.max_current	= 80,
                                        	},
                                        };
                                        

                                        I think this is the major culprit for not having any other colors but the white for the RGB led installed on the Meizu Pro5. My question is: how can I flash only this part of the kernel, prior modifying that code to see if it helps to solving that issue?

                                        AlainW94A W 2 Replies Last reply Reply Quote 0
                                        • AlainW94A Offline
                                          AlainW94 @matteo
                                          last edited by

                                          @matteo I dind’t find Time to do it but I think the best way would be to download the kernel turbo from github, modify the driver, compil the kernel and simply copy paste the module on the device with a write fs activated. My plan was to do that like this.

                                          Meizu Pro 5, Meizu Pro 5, Meizu Pro 5, Meizu Pro 5 (Yes I have 4 of them)
                                          Never forget that they are much more ideas inside two heads than in one...

                                          1 Reply Last reply Reply Quote 1
                                          • W Offline
                                            wdehoog @matteo
                                            last edited by

                                            @matteo if the led support is build as a module then this module can be copied to the rootfs. If not I guess you can test a new kernel with fastboot boot which boots the kernel without installing it first.

                                            1 Reply Last reply Reply Quote 1
                                            • flohackF Offline
                                              flohack
                                              last edited by

                                              You do miss a point here: Channel 0 in this definition would then be used by red and white. So to me that sounds as if there is no RGB led installed, but just a white one. You will probably gain nothing from this experiment, maybe even damage your hardware. I would be very careful, this code was commented for a reason (and reminds me of deleting unused code, never leave commented code like this in a production driver.)

                                              My languages: πŸ‡¦πŸ‡Ή πŸ‡©πŸ‡ͺ πŸ‡¬πŸ‡§ πŸ‡ΊπŸ‡Έ

                                              AlainW94A 1 Reply Last reply Reply Quote 0
                                              • First post
                                                Last post