[ 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).
pssc
All 77 comments
There's a known bug with the firmware glue switching the DSI backlight. A fix is in the patch queue.
P33M
on 31 Oct 2015
Ok thanks, will retest then as soon as its pushed out...
pssc
on 31 Oct 2015
Firmware is pushed. Please test after running rpi-update.
popcornmix
on 1 Nov 2015
@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
pssc
on 2 Nov 2015
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?
P33M
on 2 Nov 2015
@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.
pssc
on 2 Nov 2015
Setting framebuffer blanking as well as backlight power is unnecessary - blanking the fb will turn off the backlight.
P33M
on 2 Nov 2015
@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.
pssc
on 2 Nov 2015
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.
P33M
on 2 Nov 2015
@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.
pssc
on 2 Nov 2015
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?
P33M
on 2 Nov 2015
@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
on 2 Nov 2015
@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
on 3 Nov 2015
@P33M also first toggle blanks screen but doesnt toggle the backlight...
pssc
on 3 Nov 2015
I've installed squeezeplay and can see the issue.
P33M
on 5 Nov 2015
@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...
pssc
on 5 Nov 2015
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
on 5 Nov 2015
Can you test the start.elf from this link? Replace start.elf in /boot.
P33M
on 5 Nov 2015
@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
on 5 Nov 2015
@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
on 5 Nov 2015
@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?
pssc
on 5 Nov 2015
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.
P33M
on 6 Nov 2015
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
on 6 Nov 2015
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.
pssc
on 6 Nov 2015
@P33M's firmware fix in in latest rpi-update firmware.
popcornmix
on 7 Nov 2015
@P33M not been able to replicate your bug yet, and hints for your setup, my backlight always powers on on boot.
pssc
on 10 Nov 2015
ok Squeezplay play aside
latest fw/kernel power pi
pssc@lothlorien:255~$ ssh testwipi
pi@testwipi's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Nov 10 22:23:14 2015
pi@screenpi ~ $ sudo -s
root@screenpi:/home/pi# echo 1 >/sys/class/graphics/fb0/blank
Console blanks but bl remains on
Prod console so it unblanks.
root@screenpi:/home/pi# echo 1 >/sys/class/graphics/fb0/blank
Console blanks and bl goes off, this points to an initial state/set problem
pssc
on 10 Nov 2015
I have a similar backlight problem.
@pssc: Do you have a USB-DAC or Hifiberry Amp connected? If yes, is the problem still there when you disconnect the DAC and you are using the default ALSA output?
Snyder1977
on 27 Nov 2015
@Snyder1977 Nope no dac connected and experienced stability issues initially less so with more recent firmware via rpi-update, now have a pi2's with pi lcd screen with no dac and a Pi-DAC+
pssc
on 30 Nov 2015
I see the same issue as @pssc after an initial boot. If the framebuffer blanks the first time the backlight stays on. After the framebuffer turns on again, subsequent blanks of it also turn off the backlight. So it really is only the first blank which does not go through.
In my specific case I am autostarting a Kivy GUI in the console right after the boot. Since the backlight does not turn off the first time the console blanks the Kivy app continues to show. What I really want is that the screen blanks after 5 minutes. Currently the workaround for me is to blank and unblank the framebuffer one time during boot in rc.local. After that I see the expected behaviour. The backlight goes of after 5 minutes (the app being still active) and turns back on after I touch the screen. @popcornmix: Is there a way I can see whats happening with the backlight the first time the console blanks?
maru-sama
on 20 Jan 2016
Ok I played around with this some more this evening and found an easier workaround. Putting the following line in rc.local is enough for the screen to work the first time as well.
echo 0 > /sys/class/graphics/fb0/blank
So instead of turning it off and on again, we just tell it that it is indeed on. This seems to sync the fb and the touchscreen and blanking works.
maru-sama
on 21 Jan 2016
@pssc has your issue been resolved? If so, please close this issue. Thanks.
Ruffio
on 17 Aug 2016
This issue seems to have reappeared in the newest version of raspberrypi-bootloader or one of its dependencies. I use a Pi 2B with a v1.0 screen and writing to /sys/class/backlight/rpi_backlight/bl_power results in rpi-backlight rpi_backlight: Backlight change failed in the kernel log.
Neovy
on 29 Nov 2016
@P33M's firmware fix in in latest rpi-update firmware.
Have you run rpi-update?
pelwell
on 29 Nov 2016
Yes, I updated all packages and the firmware in a previous attempt, but it breaks as soon as I update raspberrypi-bootloader.
Neovy
on 29 Nov 2016
Confirmed: issue reappears after latest firmware update
z1c0
on 29 Nov 2016
There will be an update to the package going out today, but rpi-update should also fix the problem if it runs AFTER the raspberrypi-bootloader upgrade.
XECDesign
on 29 Nov 2016
Confirmed: issue reappears after latest firmware update
Updated how?
rpi-update is the leading edge of firmware updates - the raspberrypi-bootloader will lag behind that somewhat.
pelwell
on 29 Nov 2016
I can reproduce this with the latest version installed via rpi-update 4.4.35+. blanking the screen works but re-enabling it results in
[ 4439.433528] rpi-backlight rpi_backlight: Backlight change failed
This does not happen right after a reboot, but after running for a few hours. For testing purposes I reverted to 4.4.32+ to see if I can reproduce it there
maru-sama
on 29 Nov 2016
Ok 4.4.32 works for me while i get the Error after some time with the current Version.
maru-sama
on 30 Nov 2016
Can you test this firmware: https://www.dropbox.com/s/m8vvbpgx2x047ox/firmware_bl.zip?dl=0
and report if it solved the issue.
popcornmix
on 30 Nov 2016
I did an rpi-update to the latest version and then update the firmware files. So far I cannot reproduce the issue, but I will leave it running like that over night and will test it again tomorrow.
maru-sama
on 30 Nov 2016
Ok i Just tested it again. This Firmware fixes the issue for me.
maru-sama
on 1 Dec 2016
Hello @popcornmix. When while this Change make it into the Main Kernel or the One available via rpi-update?
maru-sama
on 3 Dec 2016
A few days ago, I received my original touchscreen (v1.1).
When I got everything setup (clean Raspbian installation with everything updated), I noticed the screen going blank and then after a while no longer waking back up when touching it. Having double-checked all connections, I knew it had to be something related to the software.
Then I noticed this issue, which seemed to be exactly the same problem I had.
Running rpi-update didn't fix it, but it does look like the files from the Dropbox link seem to fix it (fingers crossed).
I'll leave it on overnight and come back here to confirm whether or not it has really fixed the issue.
jorisvervuurt
on 3 Dec 2016
This fix should be in latest rpi-update firmware.
popcornmix
on 3 Dec 2016
@popcornmix - some time ago (beofre pixel?) I could change rpi_backlight/brightness very quickly.
Now when I try to change it frequently I get "rpi-backlight rpi_backlight: Backlight change failed".
I wanted to create smooth backlight transition, but now it seems to be impossible?
roblan
on 3 Dec 2016
@popcornmix I can confirm that the firmware downloaded from your Dropbox link has fixed the wake-after-blanking issue. I suggest getting this fix in an apt-get upgrade as soon as possible, to prevent people from returning 'defective' touchscreens. Thanks!
jorisvervuurt
on 4 Dec 2016
@roblan Backlight switching is rate limited to 500ms for hardware reasons.
@P33M may know the details but I believe something bad happens if you switch too quickly.
popcornmix
on 4 Dec 2016
@popcornmix do you know when was this change introduced? And where can I find info why?
roblan
on 4 Dec 2016
The original 500ms rate limit was added over a year ago.
But a bug to this code was introduced in last apt-get upgrade firmware.
You can run rpi-update to get a fix for the current bug, or wait for the fix to reach apt-get upgrade firmware.
popcornmix
on 4 Dec 2016
@popcornmix Do you know when it will reach apt-get?
gfxfr
on 6 Dec 2016
I have the same problem. It's really frustrating when you are trying to host a kiosk using this setup. Did not have this problem using Wheezy. It's rendered this 7" Raspberry Pi Touchscreen completely useless.
Raynman77
on 15 Dec 2016
@Raynman77 Try running sudo rpi-update and all should be fine. ;-)
Would be best if it was in the latest Raspbian image and in the latest sudo apt-get update && sudo apt-get upgrade though.
jorisvervuurt
on 16 Dec 2016
@jorisvervuurt Doesn't this update Raspbian to nightly and unstable updates?
Raynman77
on 17 Dec 2016
@Raynman77 It does indeed install the latest (development) firmware, which might be unstable. I haven't had any problems with it though. @popcornmix When can we expect the fix to be in the latest sudo apt-get upgrade?
jorisvervuurt
on 19 Dec 2016
That's up to @XECDesign
I did recommend a firmware bump to him
popcornmix
on 19 Dec 2016
@jorisvervuurt Yes this updated release does fix the issue. Thanks for the heads up. Hopefully there weren't too many bugs in this release.
Raynman77
on 19 Dec 2016
The apt firmware is being bumped as we speak.
It will be the same firmware as in current rpi-update so hopefully that is good.
popcornmix
on 19 Dec 2016
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!
apjavel
on 22 Jan 2017
@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 :(
michalsc
on 17 Feb 2017
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.
P33M
on 17 Feb 2017
@popcornmix Thank You. The last commits have fixed the issue, I can do slow and smooth backlight changes again :)
michalsc
on 2 Mar 2017
@popcornmix Do You know when this fix will be available in stable apt-get update?
roblan
on 4 Mar 2017
@roblan apt-get firmware is dated March 3rd, so will include the latest backlight fix.
popcornmix
on 4 Mar 2017
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
on 13 Mar 2017
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.
GreenEyes2796
on 13 Mar 2017
@GreenEyes2796 what does vcgencmd version report for you?
popcornmix
on 13 Mar 2017
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
GreenEyes2796
on 13 Mar 2017
Your firmware is too old. The dist-upgrade version should be newer than that (with a March date).
popcornmix
on 13 Mar 2017
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?
GreenEyes2796
on 13 Mar 2017
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
Yes. Did reboot after update and dist-upgrade.
I'll try your reinstall.
GreenEyes2796
on 13 Mar 2017
It failed. I think all the dist-upgrades are failing, Maybe I should just download a current distribution?
GreenEyes2796
on 13 Mar 2017
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.
popcornmix
on 13 Mar 2017
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
https://github.com/raspberrypi/linux/issues/1179#issuecomment-286252915,
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
on 13 Mar 2017
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
https://github.com/raspberrypi/linux/issues/1179#issuecomment-286252915,
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
on 14 Mar 2017
Related issues
pssc
·
9Comments
mohmedelwany
·
5Comments
steros76
·
3Comments
ncguk
·
4Comments
XECDesign
·
6Comments