Ask / Submit

LED notifications stoped working. [released]

asked 2014-09-19 22:04:55 +0300

ApB gravatar image

As the title suggests. When i miss a call i don't get the green LED, when it charges it doesn't show the white LED (+doesn't blink when full). Also the blue LED when the screen is about to lock doesn't work.

I believe a reboot will fix it but i want to keep the uptime of 2+ months. :P

edit retag flag offensive reopen delete

The question has been closed for the following reason "released in a software update" by ApB
close date 2015-09-13 13:33:59.130140


So no LED notifications at all work? Try out CSD tool: --> Dial ##310## and CSD tools start. Chose "Individual test" and scroll down till u find LED test.

Sounds like you need to reboot though, check out this possible duplicate:

Btw 2+ months sounds pretty crazy - I turn my Jolla off almost every night ;-)

molan ( 2014-09-19 22:16:43 +0300 )edit

Oh yeah forgot to mention. The LEDs work fine with the CSD tool. After this long of an uptime only two things don't work. LEDs and clipboard.

And its not crazy. It's how it is supposed to work. ;) You should not reboot unless you get an update.

ApB ( 2014-09-19 22:25:31 +0300 )edit

Ok at least no HW defect. I meant crazy because you could keep it run that long :-D I simply turn it off because I don't need it when I sleep and at least every 2 weeks it happens that I run out of battery before I can charge it. So 2 months would be an incredible difficult challenge for me...

Make sure you keep some screenshots of the uptime :)

molan ( 2014-09-19 23:31:41 +0300 )edit

As i said this is how a phone is supposed to work. It should be a reliable tool that has minimal downtime (if any). And we should get a graphical way to restart services (systemctl restart) like these when they fail. Even thought they shouldn't fail in the first place.

ApB ( 2014-09-19 23:40:05 +0300 )edit

3 Answers

Sort by » oldest newest most voted

answered 2014-11-03 08:39:23 +0300

spiiroin gravatar image

There was a bug in the CSD itself.

The csd patterns are configured so that they work even if the normal led patterns are disabled. The intent was to disable normal led patterns during testing (so that only CSD led controls would apply). But instead of disabling led at test start and enabling afterwards, it was done the other way around.

The end result is: After the csd led test is used, the normal led patterns will not work until device is rebooted, mce restarted or led is enabled manually via mcetool --enable-led.

Should be fixed in update10.

edit flag offensive delete publish link more

answered 2014-09-20 09:20:56 +0300

spiiroin gravatar image

Led control is handled by mce service. Led pattern triggering happens both within mce (charging, startup/shutdown etc) and via d-bus interface (csd, emal, sms, etc). The fact that patterns activated by external entity (=csd) still work means the whole pipeline should be working and the problem is likely to be in led configuration or settings - both of which persist over mce restarts / device reboot.

In this case csd patterns work, others do not. The csd leds are by default configured as "type=5 / always show pattern, even if LED disabled". All the other patterns obey the "master" led switch.

Any chance that you would have at some point disabled the leds?

  • mcetool --disable-led

You could try enabling them again via:

  • mcetool --enable-led

If that does not fix the situation, it would be interesting to capture some debug logs before restarting anything....

edit flag offensive delete publish link more


I don't have dev mode enabled so i didn't mess with anything LED related. I noticed it yesterday when i plugged the phone in my PC usb port to charge it instead of the charger. White LED didn't came on.

ApB ( 2014-09-20 11:50:44 +0300 )edit

@ApB: If it goes to max 100mA mode it might not be considered as "charging" in some context. IIRC led logic does not care, but might be good to check if using actual charger / another port makes any difference. The master toggle mentioned above is not persistent. So reboot / mce restart will clear it - unless broken enough led config happens to be installed (possibly from some 3rd party sw). But since I've never seen something like this happen, it is a bit futile to try to figure out what might be wrong without access to normal / verbose journal logging from mce.

spiiroin ( 2014-09-20 13:52:12 +0300 )edit

Where are these logs??

ApB ( 2014-09-20 14:33:57 +0300 )edit

@ApB: You'll need devel mode and root, so you might as well try the "mcetool --enable-led" at some point too, but ..

Past logs can be obtained by:

  • journalctl -a _SYSTEMD_UNIT=mce.service

Or even better, start one ssh connection and start tracking mce logging:

  1. journalctl -f _SYSTEMD_UNIT=mce.service

And second one to tickle led functionality with full debugs enabled:

  1. mcetool -n # display off
  2. killall -USR1 mce # switch to debug verbosity
  3. mcetool -y PatternCommunication # start a led pattern
  4. mcetool -Y PatternCommunication # stop a led pattern
  5. killall -USR2 mce # back to normal verbosity
spiiroin ( 2014-09-20 16:46:45 +0300 )edit

Forgot that journalctl uses binary files. Anyway. I' ll update this after the next update.

ApB ( 2014-09-20 22:58:20 +0300 )edit

answered 2014-10-27 10:01:42 +0300

ApB gravatar image


To reproduce (not a common use case but anyway):

1) Connect the charger (White LED turn on/phone charges) 2) Go to the CSD tool > individual tests and run a LED test. 3) LED notifications stop working.

edit flag offensive delete publish link more


@ApB Whoa, and thanks a lot ;-)

The CSD enables led before the test (which is unnecessary) and disables led after test (which it definitely should not do) -> using csd to test led functionality breaks led functionality (until device and/or mce service is restarted) -> filed a bug.

spiiroin ( 2014-10-27 10:59:16 +0300 )edit

Question tools



Asked: 2014-09-19 22:04:55 +0300

Seen: 437 times

Last updated: Nov 03 '14