What controls the LEDs?



  • My notification work just uses the /sys/class/leds files directly. Now that I've changed those files to be writable, things like missed calls now also change the LED state (with nasty 50ms flicker IMHO, but that's a different battle). Has anybody come across which module is dealing with the LEDs? I should figure out how to configure it, and then use a central API for my own notification LED effects.



  • Here you can control the LEDs /sys/class/leds/"colour", but I don't know so much about this.



  • If I am reading this correctly, does that mean that the ago old issue of the notification led not working for things like Deko and such like may be resolved soon?



  • @UKPhil said in What controls the LEDs?:

    If I am reading this correctly, does that mean that the ago old issue of the notification led not working for things like Deko and such like may be resolved soon?

    There are two things going on here. One is that the basic push notification service is going away, due to Ubuntu's phasing out of Touch as one of their projects. That's the one I'm working on. I have notifications working well (timely, efficient in both OTA data and battery), but it is an extra task to figure out which apps using old API's might be accomodated.

    And then there's the simple issue that it appears the /sys/fs LED files were too protected, so that existing code which knew how to light up LED's couldn't. I understand that will be fixed soon.



  • @vandys, thanks for the clarification. From what I am reading the two issues are heading in the right direction and notifications will have some level of fix soon. That is great news. Does that include Dekko? I know you said that an extra task is sorting out apps that use the old API’s, but with new email delivery from Dekko, that would be a vast improvement. Great work though so far. I know this is not a Dekko post, but wrapping it up in the overall notifications.



  • Dekko's just an email client, right? New mail notification is a server feature. For me, I have an imap watcher which watches for new mail using the IDLE extension and pushes an XMPP message:
    https://vsta.org/andy/pickup/xmpp_mail.py
    and I have a web interface to XMPP so I can read from a browser anywhere:
    https://github.com/vandys/webXMPP

    The final part is a daemon running on my phone, and its counterpart on that webXMPP server. When my phone's active, it just does a popup notification with sound. When the phone's off, it also gets the LED's blinking. They turn back off when you unlock the phone. The server remembers the client, and as soon as new messages arrive, it does a notification push.

    I guess I'm telling you that I don't see how an email client gives you push notifications. The best it can do is try to run in the background and poll an imap account. But Touch SIGSTOP's apps as soon as they lose focus (delta that UI tweak utility) which will fight you, and it's a waste of battery and data anyway. imap IDLE really isn't a great fit for a mobile platform.


Log in to reply
 

Looks like your connection to UBports Forum was lost, please wait while we try to reconnect.