Switching on backlight

[pssc]

[ 165.533763] rpi-backlight rpi_backlight: Backlight change failed
[ 167.085803] rpi-backlight rpi_backlight: Backlight change failed
[ 168.281433] rpi-backlight rpi_backlight: Backlight change failed
[ 169.628353] rpi-backlight rpi_backlight: Backlight change failed
[ 169.742678] rpi-backlight rpi_backlight: Backlight change failed

Linux screenpi 4.1.12-v7+ #824 SMP PREEMPT Wed Oct 28 16:46:35 GMT 2015 armv7l GNU/Linux

I have an application controling the backlight via the

/sys/class/backlight/rpi_backlight/bl_power

Powering off writing 4 into the file seems reliable however power on fails.

I can sometime prod it into life via echoing more stuff into the file manually but its not reliable.

       val = level == 0 and "4" or "0"
        if self:getSettings()["backlight"] and (not only or only == "backlight") then
                dirNodeSetValue("/sys/class/backlight","bl_power",val,skipbacklight)
        end
end

function dirNodeSetValue(dir,node,val,skip)
        for entry in lfs.dir(dir) do repeat
                local entrydir = dir.."/"..entry

                if skip and skip[entry] then
                        break
                end
                local entrymode = lfs.attributes(entrydir, "mode")
                log:debug("dirNodeSetValue: ",entrydir," is ", entrymode)
                if entry:match("^%.") or (entrymode ~= "directory") then
                        break
                end

                local fblank = entrydir.."/"..node
                local mode = lfs.attributes(fblank,"mode")
                log:debug("dirNodeSetValue: ",fblank," mode is ", mode)
                if mode == "file" then
                        local fh = io.open(fblank,"w")
                        if fh then
                                log:info("dirNodeSetValue: ",fblank," to ",val)
                                fh:write(val)
                                fh:flush()
                                fh:close()
                        end
                end
                break -- oddness as we are in a double loop
        until true end
end

Code works on gpio_backlight for fbtft displays (adafruit28rt).

[P33M]

There's a known bug with the firmware glue switching the DSI backlight. A fix is in the patch queue.

[pssc]

Ok thanks, will retest then as soon as its pushed out...

[popcornmix]

Firmware is pushed. Please test after running rpi-update.

[pssc]

@popcornmix one on off cycle then off and back to:-

[   94.898890] rpi-backlight rpi_backlight: Backlight change failed
[   95.883632] rpi-backlight rpi_backlight: Backlight change failed
[   98.683035] rpi-backlight rpi_backlight: Backlight change failed
[  102.183071] rpi-backlight rpi_backlight: Backlight change failed
[  102.465310] rpi-backlight rpi_backlight: Backlight change failed
[  104.654344] rpi-backlight rpi_backlight: Backlight change failed
[  114.677035] rpi-backlight rpi_backlight: Backlight change failed

And if i leave it a while it seems to toggle again sometimes

[P33M]

You're switching the backlight at a fast interval. I can see two entries in the log that are less than 500ms apart.

Switching the backlight on and off that quickly will hit the ratelimit built into the firmware.

Is the issue still present if your do .. until loop incorporates a ~1 second delay?

[pssc]

@P33M I am triggering on a key press (activating soft off), I left the install overnight and tired triggering again no joy, I am also toggling the frame buffer blanking? at the same time. Even if it skips a setting it should fix after a pause and timer reset, is that rate limit there for any real reason? and as said this code path works fine for backlights provided via gpio_backlight and fbtft,

I will go back and generate an a application log and corresponding kernel log a am fairly sure that I only wrote once in a second to the sysfs bl power file but i didn't save the logs.

Phill.

[P33M]

Setting framebuffer blanking as well as backlight power is unnecessary - blanking the fb will turn off the backlight.

[pssc]

@P33M ok yes that's probably whats causing the backlight setting in rapid succession though it really should recover gracefully as left overnight and just switching on failed? i am not sure if toggling the blanking on a fbtft frame buffer toggles the bl(and not all display have bl control) which is why the codes in there for the blanking and of course blanking the HDMI output before calling vcgencmd display_power to cause HDMI screen power saving.

[P33M]

Part of the problem is that it appears the linux-side expects a backlight change to never fail - the backlight update function can return a value, but this value is ignored by the framebuffer update.
c.f. http://lxr.free-electrons.com/source/drivers/video/backlight/backlight.c#L40
Therefore there's the possibility that the backlight state and framebuffer blank/unblank could get out of sync until the next time the backlight is set.

I'll think about this a bit more.

[pssc]

@P33M something doesn't smell right in my case I am setting blank and power off then unblank and poweron, so it shouldn't matter that the second op failed as it would be set to the same state by either call...
I am doing a complete open close for each file toggle and not keeping the descriptor open.

[P33M]

Hm. That's right actually - even with the limit you should still be seeing the backlight actually switch state.

Can you post the full script you use so I can replicate the behaviour?

[pssc]

@P33M is available but theirs quite an overhead as this is an applet embedded in a build of squeeze play of the Pi debs in https://github.com/pssc/squeezeplay-dist its alpha and if you have don't have a Logitech music server you will have to abort the setup to connect to server by pressing home (q) toggles soft power. Probably best if I try and document my tests tonight with dmesg and application log output, I cant test from here and I can disable blank and/or backlight control will a simple option to test how thats affecting the interaction....

In summary before firmware update:-
Backlight powered off and I could sometimes prod back into life having cated several random values into the bl sysfs file possibly with several attempts at this.
After update:-
Backlight on / off ok then off and suck off but again just sometimes some toggling would bring it back on.

Re toggled off last night wouldn't switch on left for 7hrs tried to power on again in the morning no joy

[pssc]

@P33M ok disabling the back light control and just toggling the backlight in the app works so its some artefact of setting both bl and blaking

[pssc]

@P33M also first toggle blanks screen but doesnt toggle the backlight...

[P33M]

I've installed squeezeplay and can see the issue.

[pssc]

@P33M oh good its not just not me, by default it will toggle both (bl and blanking), there should be a menu option under setup advanced SqueezePi to toggle Bl control/ Blanking also add applet.Linux to info in the logging config so see what’s going on and sqeezeplay.ui to warn to reduce noise. Feed back appreciated as your probably about the 3rd user of that package...

[P33M]

For some reason, pressing Q (or waiting for a backlight wakeup) causes two writes to the mailbox interface in quick succession. The first always has a bl value of 0, the second is what the backlight is supposed to be, which is why switch-off works but not switch-on.

There is an obvious fix to make to the firmware - don't bother ratelimiting unless the backlight actually changes. This solves this particular case.

[P33M]

Can you test the start.elf from this link? Replace start.elf in /boot.

https://www.dropbox.com/s/jvyfhqij1vyb9ll/start.elf?dl=0

[pssc]

@P33M ware you still getting two writes event with one of the two options disabled? and did you see on the first toggle after reboot to blanking only that it didn't switch off? , say if the values the same not to bother with the rate limiting would seem to me reasonable.

[pssc]

@P33M start.elf will do, have to wait till about 11 this eve as the PI here at work doesn’t have a Official Pi LCD screen ;-)

[pssc]

@P33M ok seems to be good with both blanking and bl control enabled, however still seeing first toggle with blanking only not affecting the back light. initial sate odd somewhere?

[P33M]

If I reset the Pi when SqueezePi is running and the backlight is off, on the next boot I either get an infinite loop of backlight calls to the firmware or a call to turn the backlight on, but the framebuffer remains blanked.

The internal state of the driver and firmware remains consistent.

[pssc]

ok that’s different to the issue I am seeing which is when i reboot the pi the back-light on and console is unblanked and squeezepi is on (console blanks bl remains on and I only have blanking control enabled). I will try replicate that at home.

You could see if the what the application issues by enabling logging(Settings->Advanced->logging) at info of the applet.Linux module stuff should appear is syslog.

Are you running with bl and blanking control? (Settings->Advanced->SqueezePi) and is your instance connected to a server?

[pssc]

FYI I only issue bl/ blacking contol on soft power on/off events so struggling to figure how that loops occurring in the code unless your not connected to a server and thats causing the loop somehow.

[apjavel]

Hi, I have been struggling with the same issues as described by others here. I'm on pi3 and latest official image.
Did a sudo rpi-update as suggested above and The problems went away. Thanks for the fix!

[michalsc]

@popcornmix Can the firmware be updated, so that small changes in backlight (within few percent from actual value) are allowed at faster rate? 500ms seems to be awfully slow.

My aim is to provide soft backlight adaptions (change from one value to another within approximately 5 seconds) in case of longer screen inactivity. It worked with older versions of firmware pretty good, but with the newest one, where 500ms limit is indeed working, it looks really disgusting :(

[P33M]

Ah. I see an issue here - the ratelimit is always applied, whereas the original reason for applying it was to limit hard switching on v1.0 display boards that only support on or off switching. Other boards don't have this limitation so there's no reason not to allow arbitrary backlight change rates.

[michalsc]

@popcornmix Thank You. The last commits have fixed the issue, I can do slow and smooth backlight changes again :)

[roblan]

@popcornmix Do You know when this fix will be available in stable apt-get update?

[popcornmix]

@roblan apt-get firmware is dated March 3rd, so will include the latest backlight fix.

[GreenEyes2796]

I have been having the touch screen wake up problem since we upgraded to Jessie - Dec 7 2016. I did an update and dist-upgrade on March 9 2017 and it has had no effect on the wake up problem. Any idea when the proper fix will be available or a simple mod to the OS ?

[GreenEyes2796]

I should add that the sometimes the screen will not wake up on touch or keyboard, but then a few minutes later it seems to work fine.

[popcornmix]

@GreenEyes2796 what does vcgencmd version report for you?

[GreenEyes2796]

Nov 25 2016 16:03:50
Copyright (c) 2012 Broadcam
version (long hex string) (clean) (releases)

Do you need the hex string version number? Thanks

[popcornmix]

Your firmware is too old. The dist-upgrade version should be newer than that (with a March date).

[GreenEyes2796]

Hmm. Just ran update and upgrade again and the version did not change. Known working internet connection. Any idea why I'm stuck in Nov. 2016?

[popcornmix]

I assume you rebooted after updating?
Have you ever run rpi-update or otherwise manually updated firmware?
You could try:

sudo apt-get update && sudo apt-get upgrade --reinstall raspberrypi-bootloader

[GreenEyes2796]

Yes. Did reboot after update and dist-upgrade.
I'll try your reinstall.

[GreenEyes2796]

It failed. I think all the dist-upgrades are failing, Maybe I should just download a current distribution?

[popcornmix]

Yes, I think installing the latest raspbian jessie image is probably advisable.

Something is wrong on your image. It may be possible to fix it, but that will probably be harder than reinstalling, and you'll never know if you have fixed everything.

[GreenEyes2796]

Thanks!

…

On 3/13/2017 5:41 PM, popcornmix wrote: Yes, I think installing the latest raspbian jessie image is probably advisable. Something is wrong on your image. It may be possible to fix it, but that will probably be harder than reinstalling, and you'll never know if you have fixed everything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1179 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZKeWTFxG3omlFjmGX2CMeuDHCmn-2qDks5rlbgmgaJpZM4GZAVz>.

-- Vince Kelly Director - Green Eyes LLC +1 443 746 2175 [email protected] gescience.com

[GreenEyes2796]

Installed the March 3, 2017 raspian OS and the touch screen has woken up successfully five times in a row. I think it's fixed. Thanks!

…

On 3/13/2017 5:41 PM, popcornmix wrote: Yes, I think installing the latest raspbian jessie image is probably advisable. Something is wrong on your image. It may be possible to fix it, but that will probably be harder than reinstalling, and you'll never know if you have fixed everything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1179 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZKeWTFxG3omlFjmGX2CMeuDHCmn-2qDks5rlbgmgaJpZM4GZAVz>.

-- Vince Kelly Director - Green Eyes LLC +1 443 746 2175 [email protected] gescience.com