bcm2708_fb_blank not implemented (prevents DPMS from working in X) #487

Closed
AGWA opened this Issue Jan 8, 2014 · 47 comments

Comments

Projects
None yet
@AGWA

AGWA commented Jan 8, 2014

Are there any plans to implement bcm2708_fb_blank? This function is called when the FBIOBLANK ioctl is made on the frame buffer and is supposed to put the monitor into power saving mode. Since it has not been implemented, X on the Raspberry Pi is unable to put the monitor into power saving mode (aka DPMS).

You can see the problem by running xset dpms force off in X. The monitor blanks but does not enter power saving mode, and the message "(EE) FBTURBO(0): FBIOBLANK: Operation not permitted" is printed to the X log. (It says "Operation not permitted" because bcm2708_fb_blank always returns -1, and 1 == EPERM.)

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 8, 2014

Collaborator

What behaviour is needed to make monitor enter power saving mode:
outputting a black screen?
tvservice -o ?

I assume when the blank is removed, you want the previous contents of framebuffer preserved?
Or will it be updated by X?

Collaborator

popcornmix commented Jan 8, 2014

What behaviour is needed to make monitor enter power saving mode:
outputting a black screen?
tvservice -o ?

I assume when the blank is removed, you want the previous contents of framebuffer preserved?
Or will it be updated by X?

@P33M

This comment has been minimized.

Show comment
Hide comment
@P33M

P33M Jan 8, 2014

Contributor

In the olden days (and presumably would still be valid for RCA output) if you turned off Vsync or Hsync pulses (and blanked the screen) then the monitor would enter power save mode.

http://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling

I think for HDMI, CEC messages for suspend are required.

Contributor

P33M commented Jan 8, 2014

In the olden days (and presumably would still be valid for RCA output) if you turned off Vsync or Hsync pulses (and blanked the screen) then the monitor would enter power save mode.

http://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling

I think for HDMI, CEC messages for suspend are required.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 8, 2014

Collaborator

CEC won't help DVI monitors (and older HDMI TVs) nor composite.
And it's not simple. We only support CEC control from the ARM, so something like libCEC would be required, which wouldn't be good in a kernel module.

With my current LG TV, running:

tvservice -o

Shows "LG No Signal" on screen after a few seconds.
This persists for some minutes and then TV goes to standby, so I think it is possible for the TV to detect a lack of output, but I don't know if this is widely implemented.

Collaborator

popcornmix commented Jan 8, 2014

CEC won't help DVI monitors (and older HDMI TVs) nor composite.
And it's not simple. We only support CEC control from the ARM, so something like libCEC would be required, which wouldn't be good in a kernel module.

With my current LG TV, running:

tvservice -o

Shows "LG No Signal" on screen after a few seconds.
This persists for some minutes and then TV goes to standby, so I think it is possible for the TV to detect a lack of output, but I don't know if this is widely implemented.

@P33M

This comment has been minimized.

Show comment
Hide comment
@P33M

P33M Jan 8, 2014

Contributor

I have a DVI monitor connected and doing tvservice -o, the Dell switches off and goes to standby pretty quick.

Unfortunately it doesn't seem to come back after a tvservice -p but I assume that is a separate issue.

Contributor

P33M commented Jan 8, 2014

I have a DVI monitor connected and doing tvservice -o, the Dell switches off and goes to standby pretty quick.

Unfortunately it doesn't seem to come back after a tvservice -p but I assume that is a separate issue.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 8, 2014

Collaborator

Yes, "fbset -depth 8 && fbset -depth 16" or xrefresh will bring back the framebuffer.

The problem is powering off a display frees any dispmanx elements, and someone has to put them back.
That makes FBIOBLANK more complicated.

I was thinking of an mailbox message to FBIOBLANK, which when unblanked puts the framebuffer back on the display. There could still be problems if additional dispmanx layers had been added by other applicatons.
(But only the same as if you had typed in "tvservice -o && tvservice -p").

Collaborator

popcornmix commented Jan 8, 2014

Yes, "fbset -depth 8 && fbset -depth 16" or xrefresh will bring back the framebuffer.

The problem is powering off a display frees any dispmanx elements, and someone has to put them back.
That makes FBIOBLANK more complicated.

I was thinking of an mailbox message to FBIOBLANK, which when unblanked puts the framebuffer back on the display. There could still be problems if additional dispmanx layers had been added by other applicatons.
(But only the same as if you had typed in "tvservice -o && tvservice -p").

@AGWA

This comment has been minimized.

Show comment
Hide comment
@AGWA

AGWA Jan 8, 2014

Thanks for the quick replies to this.

tvservice -o puts my IBM DVI monitor into standby mode (backlight off). tvservice -p brings it out of standby, though the screen remains blank until I switch VTs (neither fbset nor xrefresh work). This seems like the right approach, assuming you can get the framebuffer back on the display after it's unblanked. I'll also see if I can test with some other DVI monitors.

AGWA commented Jan 8, 2014

Thanks for the quick replies to this.

tvservice -o puts my IBM DVI monitor into standby mode (backlight off). tvservice -p brings it out of standby, though the screen remains blank until I switch VTs (neither fbset nor xrefresh work). This seems like the right approach, assuming you can get the framebuffer back on the display after it's unblanked. I'll also see if I can test with some other DVI monitors.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 8, 2014

Collaborator

fbset needs to change something or else it is no-op.
fbset -depth 8 && fbset -depth 16
should bring framebuffer back.

Collaborator

popcornmix commented Jan 8, 2014

fbset needs to change something or else it is no-op.
fbset -depth 8 && fbset -depth 16
should bring framebuffer back.

@AGWA

This comment has been minimized.

Show comment
Hide comment
@AGWA

AGWA Jan 8, 2014

I tested with a NEC DVI monitor, and tvservice -o and tvservice -p brings it into and out of power saving mode.

Also, section 2.4 of the DVI spec looks useful. It say that all DVI-compliant monitors must support the "active-off" power state, which is entered by disabling the T.M.D.S. link, and exited by re-activating the link. I think that means that tvservice -o/tvservice -p should be expected to work properly with any DVI monitor.

AGWA commented Jan 8, 2014

I tested with a NEC DVI monitor, and tvservice -o and tvservice -p brings it into and out of power saving mode.

Also, section 2.4 of the DVI spec looks useful. It say that all DVI-compliant monitors must support the "active-off" power state, which is entered by disabling the T.M.D.S. link, and exited by re-activating the link. I think that means that tvservice -o/tvservice -p should be expected to work properly with any DVI monitor.

jfasch pushed a commit to jfasch/linux that referenced this issue Jan 14, 2014

gpio-langwell: initialize lock before usage
Otherwise we will end up with traceback from LOCKDEP:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-next-20130521-00028-g09aa9fc #487
 00000000 00000000 f6c55c54 c1541fe4 f6040bf8 f6c55c8c c1069ef1 c1726bc1
 c1726cc8 c1726c9e 00000000 f6c584e0 f6c58000 f6c55ce8 00000000 f6040bf8
 f6040bf8 00000046 f6c58000 f6c55d00 c106a18d 00000a2b 00000003 00004f02
Call Trace:
 [<c1541fe4>] dump_stack+0x49/0x77
 [<c1069ef1>] register_lock_class+0x58/0x260
 [<c106a18d>] __lock_acquire+0x94/0xcff
 [<c106adc8>] ? __lock_acquire+0xccf/0xcff
 [<c106b2ad>] lock_acquire+0xcc/0x10d
 [<c1269c7c>] ? lnw_irq_type+0x63/0xe9
 [<c1545da0>] _raw_spin_lock_irqsave+0x32/0x42
 [<c1269c7c>] ? lnw_irq_type+0x63/0xe9
 [<c1269c7c>] lnw_irq_type+0x63/0xe9
 [<c108f454>] __irq_set_trigger+0x98/0x123
 [<c1090225>] irq_set_irq_type+0x2f/0x51
 [<c1090225>] ? irq_set_irq_type+0x2f/0x51
 [<c1269d02>] ? lnw_irq_type+0xe9/0xe9
 [<c1269d34>] lnw_gpio_irq_map+0x32/0x3b
 [<c10914f2>] irq_domain_add_legacy+0xe2/0x107
 [<c1091b53>] irq_domain_add_simple+0x47/0x60
 [<c1269f6e>] lnw_gpio_probe+0x119/0x217
 [<c1271018>] pci_device_probe+0x5a/0x92
...

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: David Cohen <david.a.cohen@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
@arionl

This comment has been minimized.

Show comment
Hide comment
@arionl

arionl Mar 30, 2014

I'm running the standard X server (part of Raspian distro) and have a Acer monitor hooked up to my Pi via DVI. From an SSH session tvservice -o will power the display down, but as others have mentioned tvservice -p powers it back on but nothing is displayed. If I issue fbset -depth 8 && fbset -depth 16 followed by xrefresh I get a corrupt version of what was on the screen before power down -- with artifacts that look like display-resizing problems, etc.

I'm using my Pi for a kiosk display and my intension is to hook up a motion detector via GPIO that I could monitor to issue display on/off commands. Any progress on this or other approaches to control display power?

arionl commented Mar 30, 2014

I'm running the standard X server (part of Raspian distro) and have a Acer monitor hooked up to my Pi via DVI. From an SSH session tvservice -o will power the display down, but as others have mentioned tvservice -p powers it back on but nothing is displayed. If I issue fbset -depth 8 && fbset -depth 16 followed by xrefresh I get a corrupt version of what was on the screen before power down -- with artifacts that look like display-resizing problems, etc.

I'm using my Pi for a kiosk display and my intension is to hook up a motion detector via GPIO that I could monitor to issue display on/off commands. Any progress on this or other approaches to control display power?

@AGWA

This comment has been minimized.

Show comment
Hide comment
@AGWA

AGWA Mar 30, 2014

@arionl, I've found the most reliable technique is to switch VTs and back after running tvservice -p. I use the following script to control the HDMI: https://gist.github.com/AGWA/9874925 - I'd be curious to know if this works for you.

AGWA commented Mar 30, 2014

@arionl, I've found the most reliable technique is to switch VTs and back after running tvservice -p. I use the following script to control the HDMI: https://gist.github.com/AGWA/9874925 - I'd be curious to know if this works for you.

@arionl

This comment has been minimized.

Show comment
Hide comment
@arionl

arionl Mar 30, 2014

@AGWA Thanks! I didn't realize you could switch VTs programmatically via chvt and get status with fgconsole. I'll comment further on your gist page. Still will be nice to get a formal solution implemented with standard DPMS calls, etc..

arionl commented Mar 30, 2014

@AGWA Thanks! I didn't realize you could switch VTs programmatically via chvt and get status with fgconsole. I'll comment further on your gist page. Still will be nice to get a formal solution implemented with standard DPMS calls, etc..

@trevd

This comment has been minimized.

Show comment
Hide comment
@trevd

trevd Aug 3, 2014

Hi Folks.

Here's my FBIOBLANK handling implementation using the mailbox interface like @popcornmix suggested. I know FB_BLANK_UNBLANK and FB_BLANK_NORMAL work, the others arguments but I've not tried them

static int bcm2708_fb_blank(int blank_mode, struct fb_info info)
{
int result;
struct vc_msg msg;
printk("bcm2708_fb_blank blank_mode=%d\n",blank_mode);
memset(&msg, 0, sizeof msg);
msg.tag.tag_id = VCMSG_SET_BLANK_SCREEN;
msg.msg_size = sizeof msg;
msg.tag.buffer_size = 4;
msg.tag.data_size = 4;
msg.tag.dev_id = blank_mode ;
/
send the message */
result = bcm_mailbox_property(&msg, sizeof msg);
printk("bcm2708_fb_blank result=%d\n",result);
return result;

}

I'm also adding FBIO_WAITFORVSYNC once I get head round the hows and the whys of it all :)

@popcornmix I'll submit a pull request if you want

trevd commented Aug 3, 2014

Hi Folks.

Here's my FBIOBLANK handling implementation using the mailbox interface like @popcornmix suggested. I know FB_BLANK_UNBLANK and FB_BLANK_NORMAL work, the others arguments but I've not tried them

static int bcm2708_fb_blank(int blank_mode, struct fb_info info)
{
int result;
struct vc_msg msg;
printk("bcm2708_fb_blank blank_mode=%d\n",blank_mode);
memset(&msg, 0, sizeof msg);
msg.tag.tag_id = VCMSG_SET_BLANK_SCREEN;
msg.msg_size = sizeof msg;
msg.tag.buffer_size = 4;
msg.tag.data_size = 4;
msg.tag.dev_id = blank_mode ;
/
send the message */
result = bcm_mailbox_property(&msg, sizeof msg);
printk("bcm2708_fb_blank result=%d\n",result);
return result;

}

I'm also adding FBIO_WAITFORVSYNC once I get head round the hows and the whys of it all :)

@popcornmix I'll submit a pull request if you want

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Aug 3, 2014

Collaborator

@trevd
Sure, a PR would be good. Also good to add FBIO_WAITFORVSYNC.

Collaborator

popcornmix commented Aug 3, 2014

@trevd
Sure, a PR would be good. Also good to add FBIO_WAITFORVSYNC.

trevd added a commit to trevd/android_kernel_broadcom_rpi that referenced this issue Aug 4, 2014

@trevd

This comment has been minimized.

Show comment
Hide comment
@trevd

trevd Aug 4, 2014

Apologises for the spam ... That'll teach me for not doing a proper fork .

trevd commented Aug 4, 2014

Apologises for the spam ... That'll teach me for not doing a proper fork .

@slu-010101

This comment has been minimized.

Show comment
Hide comment
@slu-010101

slu-010101 May 23, 2015

Same here, screen blank only but never power off.
This waste a lot of power in my case.

Same here, screen blank only but never power off.
This waste a lot of power in my case.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Jul 30, 2015

Are there any updates on this, recently got an RPi2 and running Ubuntu Mate (15.04) on it but am experiencing this issue

t3chguy commented Jul 30, 2015

Are there any updates on this, recently got an RPi2 and running Ubuntu Mate (15.04) on it but am experiencing this issue

@lealanko

This comment has been minimized.

Show comment
Hide comment
@lealanko

lealanko Aug 19, 2015

I wrote a simple tool to work around the problem. It simply polls the X server for the DPMS state and calls tvservice accordingly. It's available here: https://github.com/lealanko/vcdpmsd

I wrote a simple tool to work around the problem. It simply polls the X server for the DPMS state and calls tvservice accordingly. It's available here: https://github.com/lealanko/vcdpmsd

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 19, 2015

@lealanko I will install it when I next plug my Pi in and if it doesn't work for me will raise an Issue there, else will Star and Follow it; Thanks in Advance!!

Edit:
Works perfectly lealanko! Thank you very much
(Ubuntu Mate 15.04 on Raspberry Pi 2)

t3chguy commented Aug 19, 2015

@lealanko I will install it when I next plug my Pi in and if it doesn't work for me will raise an Issue there, else will Star and Follow it; Thanks in Advance!!

Edit:
Works perfectly lealanko! Thank you very much
(Ubuntu Mate 15.04 on Raspberry Pi 2)

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Aug 19, 2015

Collaborator

@lealanko you may be better off using vcgencmd display_power 0 to switch off and vcgencmd display_power 1 to switch on again. You won't lose your hdmi mode and framebuffer doing that.

We did add this into the firmware, but some applications (like omxplayer) don't stop the blanking and we got complaints about video blanking. You can enable the behaviour with hdmi_blanking=1 in config.txt.

Collaborator

popcornmix commented Aug 19, 2015

@lealanko you may be better off using vcgencmd display_power 0 to switch off and vcgencmd display_power 1 to switch on again. You won't lose your hdmi mode and framebuffer doing that.

We did add this into the firmware, but some applications (like omxplayer) don't stop the blanking and we got complaints about video blanking. You can enable the behaviour with hdmi_blanking=1 in config.txt.

@lealanko

This comment has been minimized.

Show comment
Hide comment
@lealanko

lealanko Aug 19, 2015

I did consider that, but calling tvservice -o lowered the Pi's power consumption measurably, unlike vcgencmd display_power 0. Maybe tvservice turned off some video processing circuits and not just the signal? Since the point of DPMS is to save power, it seemed like the more reasonable thing to use.

I did consider that, but calling tvservice -o lowered the Pi's power consumption measurably, unlike vcgencmd display_power 0. Maybe tvservice turned off some video processing circuits and not just the signal? Since the point of DPMS is to save power, it seemed like the more reasonable thing to use.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 19, 2015

@popcornmix I can confirm this works for me, and is much better done at the firmware level rather than the application level; This hould be in https://www.raspberrypi.org/documentation/configuration/config-txt.md so I will PR it in shortly.

t3chguy commented Aug 19, 2015

@popcornmix I can confirm this works for me, and is much better done at the firmware level rather than the application level; This hould be in https://www.raspberrypi.org/documentation/configuration/config-txt.md so I will PR it in shortly.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Aug 19, 2015

Collaborator

tvservice -o does kill the framebuffer, so will avoid the HVS (hardware video scaler) fetching/converting/scaling framebuffer. However you are probably talking less than 100 milliwatts.
Successfully getting your monitor into power saving mode may be saving you tens of watts.

Collaborator

popcornmix commented Aug 19, 2015

tvservice -o does kill the framebuffer, so will avoid the HVS (hardware video scaler) fetching/converting/scaling framebuffer. However you are probably talking less than 100 milliwatts.
Successfully getting your monitor into power saving mode may be saving you tens of watts.

@t3chguy t3chguy referenced this issue in raspberrypi/documentation Aug 19, 2015

Closed

Add hdmi_blanking config option #245

@lealanko

This comment has been minimized.

Show comment
Hide comment
@lealanko

lealanko Aug 19, 2015

My AC power meter (of course notoriously imprecise at such low currents) showed the power of Pi2 dropping from 3 W to 2 W upon tvservice -o. I might do more precise DC current measurements later. In any case, DPMS off mode does actually turn some video hardware off both on AMD and Intel, saving several watts. Surely RPi, meant for much more power-conscious use, should follow suit?

Setting hdmi_blanking=1 indeed works, although it seems to leave the framebuffer on. I must say I'm quite miffed that I only now found out about it now after writing the workaround. There are numerous questions about DPMS not working, both on stackoverflow, the rpi forums, and of course right here. This is the first time the solution has actually been advertised.

In any case, preventing DPMS from working seems like a very questionable default. It breaks the principle of least astonishment. DPMS is a standard facility on every X desktop, and anyone using X on the Pi would expect it to work the same there as everywhere else. It's much easier to disable DPMS on X than to enable blanking on config.txt. So please consider changing the default.

My AC power meter (of course notoriously imprecise at such low currents) showed the power of Pi2 dropping from 3 W to 2 W upon tvservice -o. I might do more precise DC current measurements later. In any case, DPMS off mode does actually turn some video hardware off both on AMD and Intel, saving several watts. Surely RPi, meant for much more power-conscious use, should follow suit?

Setting hdmi_blanking=1 indeed works, although it seems to leave the framebuffer on. I must say I'm quite miffed that I only now found out about it now after writing the workaround. There are numerous questions about DPMS not working, both on stackoverflow, the rpi forums, and of course right here. This is the first time the solution has actually been advertised.

In any case, preventing DPMS from working seems like a very questionable default. It breaks the principle of least astonishment. DPMS is a standard facility on every X desktop, and anyone using X on the Pi would expect it to work the same there as everywhere else. It's much easier to disable DPMS on X than to enable blanking on config.txt. So please consider changing the default.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 19, 2015

I will shortly do some precise measurements on a milliamp+milliwatt scale, between hdmi_blanking=1 and tvservice -o
And I agree @lealanko that a LOT of sources want this but nowhere seems to document hdmi_blanking=1 except the changelog. I have added a PR to add this into the main MD file for the config.txt.

t3chguy commented Aug 19, 2015

I will shortly do some precise measurements on a milliamp+milliwatt scale, between hdmi_blanking=1 and tvservice -o
And I agree @lealanko that a LOT of sources want this but nowhere seems to document hdmi_blanking=1 except the changelog. I have added a PR to add this into the main MD file for the config.txt.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 19, 2015

Test Current (mA) Power (mW)
idle Logged in 381 2035
hdmi_blanking 373 2013
tvservice -o 343 1819

So there is a difference and saving, but it is very minor in comparison to the saving made by the Monitor actually switching into standby.

t3chguy commented Aug 19, 2015

Test Current (mA) Power (mW)
idle Logged in 381 2035
hdmi_blanking 373 2013
tvservice -o 343 1819

So there is a difference and saving, but it is very minor in comparison to the saving made by the Monitor actually switching into standby.

@kukabu

This comment has been minimized.

Show comment
Hide comment
@kukabu

kukabu Aug 24, 2015

I'm using a headless RPi and disabled video via 'tvservice -o'

now I see it in dmesg:
[ 1831.045696] raspberrypi-firmware soc:firmware: Request 0x00040002 returned status 0x80000001
[ 1831.045731] bcm2708_fb soc:fb: bcm2708_fb_blank(1) failed: -22

kukabu commented Aug 24, 2015

I'm using a headless RPi and disabled video via 'tvservice -o'

now I see it in dmesg:
[ 1831.045696] raspberrypi-firmware soc:firmware: Request 0x00040002 returned status 0x80000001
[ 1831.045731] bcm2708_fb soc:fb: bcm2708_fb_blank(1) failed: -22

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Aug 24, 2015

Collaborator

@kukabu that makes sense. If display is turned off then blanking it is impossible.
Possibly we should suppress the message, but it is harmless.

Collaborator

popcornmix commented Aug 24, 2015

@kukabu that makes sense. If display is turned off then blanking it is impossible.
Possibly we should suppress the message, but it is harmless.

@kukabu

This comment has been minimized.

Show comment
Hide comment

kukabu commented Aug 25, 2015

@popcornmix thanks

@robbharvey

This comment has been minimized.

Show comment
Hide comment
@robbharvey

robbharvey Sep 17, 2015

tvservice -o will not support the requirements for my hardware application (as it produces lines within our products selected 7in touch screen). Screen blanking doesn't pose a power issue but produces too much ambient light for my specific needs (my application requires complete blackout conditions). Does anyone know of any alternatives to enable proper DPMS shutdown from the Pi?

tvservice -o will not support the requirements for my hardware application (as it produces lines within our products selected 7in touch screen). Screen blanking doesn't pose a power issue but produces too much ambient light for my specific needs (my application requires complete blackout conditions). Does anyone know of any alternatives to enable proper DPMS shutdown from the Pi?

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Sep 17, 2015

@robbharvey read from about 10 lines up about hdmi_blanking in config.txt [https://github.com/raspberrypi/documentation/pull/245]

t3chguy commented Sep 17, 2015

@robbharvey read from about 10 lines up about hdmi_blanking in config.txt [https://github.com/raspberrypi/documentation/pull/245]

@robbharvey

This comment has been minimized.

Show comment
Hide comment
@robbharvey

robbharvey Sep 17, 2015

Thanks for the quick response @t3chguy. Unfortunately "vcgencmd display_power 0" with "hdmi_blanking=1" produces the same result as tvservice -o. This may be an issue with my choice of LCD panel (which seems to handle an absence of HDMI signals with vertical lines). Can you (or anyone else) confirm that switching the HDMI off is equivalent to a DPMS (off) result...meaning, when DPMS shuts "off" the monitor, does it just disable the HDMI port(like tvservice -o - implying the monitor responds to the absence of an input with a power saving state) or are there specific set of instructions sent to the monitor/screen to move it into a power saving mode? Thank you for your time!

Thanks for the quick response @t3chguy. Unfortunately "vcgencmd display_power 0" with "hdmi_blanking=1" produces the same result as tvservice -o. This may be an issue with my choice of LCD panel (which seems to handle an absence of HDMI signals with vertical lines). Can you (or anyone else) confirm that switching the HDMI off is equivalent to a DPMS (off) result...meaning, when DPMS shuts "off" the monitor, does it just disable the HDMI port(like tvservice -o - implying the monitor responds to the absence of an input with a power saving state) or are there specific set of instructions sent to the monitor/screen to move it into a power saving mode? Thank you for your time!

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Sep 18, 2015

Collaborator

@robbharvey why don't you connect the LCD to another device that supports DPMS (e.g. a windows or linux PC) and see how LCD behaves?

Collaborator

popcornmix commented Sep 18, 2015

@robbharvey why don't you connect the LCD to another device that supports DPMS (e.g. a windows or linux PC) and see how LCD behaves?

@falaca

This comment has been minimized.

Show comment
Hide comment
@falaca

falaca Feb 6, 2016

tvservice is giving me a lot of trouble, and I have DPMS disabled ("xserver-command=X -s 0 dpms" in lightdm.conf, and both BLANK_TIME and POWERDOWN_TIME set to 0 in /etc/kbd/config).

When I run tvservice -o, and then tvservice -p shortly after, I need to run "fbset -depth 8; fbset -depth 16; DISPLAY=:0 xrefresh" as others here have reported. That is no problem. However, if I leave it for a more extended period of time (~30 minutes), it doesn't work. I have a completely blank screen, and when I run fbset -depth 8 I get:

ioctl FBIOPUT_VSCREENINFO: Invalid argument

And my dmesg is full of these sort of errors:

[ 2428.465039] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465056] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465062] detected fb_set_par error, error code: -22
[ 2428.465288] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465303] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465309] bcm2708_fb_pan_display(0,0) returns=-22

This seems to be more easily reproducible if omxplayer is running when I run tvservice -o. So I modified my cron job to first shut down omxplayer and then turn off the display. My results seem to be a bit different (before, both fbset -depth 8 and fbset -depth 16 used to throw errors, but now only the former throws the error). I'm really not concerned about 1 or 2 watts, I just want to be able to shut down the TV and turn it back on the next day. @popcornmix maybe I'll try vcgencmd display_power 0 and vcgencmd display_power 1 like you suggested in one of your comments above.

Is this the right place to report this, and is there any further information I can provide?

falaca commented Feb 6, 2016

tvservice is giving me a lot of trouble, and I have DPMS disabled ("xserver-command=X -s 0 dpms" in lightdm.conf, and both BLANK_TIME and POWERDOWN_TIME set to 0 in /etc/kbd/config).

When I run tvservice -o, and then tvservice -p shortly after, I need to run "fbset -depth 8; fbset -depth 16; DISPLAY=:0 xrefresh" as others here have reported. That is no problem. However, if I leave it for a more extended period of time (~30 minutes), it doesn't work. I have a completely blank screen, and when I run fbset -depth 8 I get:

ioctl FBIOPUT_VSCREENINFO: Invalid argument

And my dmesg is full of these sort of errors:

[ 2428.465039] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465056] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465062] detected fb_set_par error, error code: -22
[ 2428.465288] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465303] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465309] bcm2708_fb_pan_display(0,0) returns=-22

This seems to be more easily reproducible if omxplayer is running when I run tvservice -o. So I modified my cron job to first shut down omxplayer and then turn off the display. My results seem to be a bit different (before, both fbset -depth 8 and fbset -depth 16 used to throw errors, but now only the former throws the error). I'm really not concerned about 1 or 2 watts, I just want to be able to shut down the TV and turn it back on the next day. @popcornmix maybe I'll try vcgencmd display_power 0 and vcgencmd display_power 1 like you suggested in one of your comments above.

Is this the right place to report this, and is there any further information I can provide?

@falaca

This comment has been minimized.

Show comment
Hide comment
@falaca

falaca Feb 7, 2016

So I tried "vcgencmd display_power" instead, and for a few hours it seemed to be working, but then something went wrong and this is what I got in dmesg after typing "vcgencmd display_power" in the terminal (without a 1 or 0, I just wanted to see it print out the status):

[ 8517.172639] ------------[ cut here ]------------
[ 8517.172713] WARNING: CPU: 0 PID: 20641 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[ 8517.172787] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_rng bcm2835_gpiomem snd_bcm2835 snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[ 8517.172929] CPU: 0 PID: 20641 Comm: HTV Notify Not tainted 4.1.17+ #834
[ 8517.172947] Hardware name: BCM2708
[ 8517.173017] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[ 8517.173052] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[ 8517.173096] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[ 8517.173128] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[ 8517.173164] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[ 8517.173196] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[ 8517.173236] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[ 8517.173268] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[ 8517.173299] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[ 8517.173318] ---[ end trace f5af9a7ec2528f9d ]---
[ 8517.173339] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:20638

In the terminal, I got the following output:

vc_gencmd_send returned -1
vchi_msg_dequeue -> -1(22)

falaca commented Feb 7, 2016

So I tried "vcgencmd display_power" instead, and for a few hours it seemed to be working, but then something went wrong and this is what I got in dmesg after typing "vcgencmd display_power" in the terminal (without a 1 or 0, I just wanted to see it print out the status):

[ 8517.172639] ------------[ cut here ]------------
[ 8517.172713] WARNING: CPU: 0 PID: 20641 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[ 8517.172787] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_rng bcm2835_gpiomem snd_bcm2835 snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[ 8517.172929] CPU: 0 PID: 20641 Comm: HTV Notify Not tainted 4.1.17+ #834
[ 8517.172947] Hardware name: BCM2708
[ 8517.173017] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[ 8517.173052] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[ 8517.173096] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[ 8517.173128] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[ 8517.173164] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[ 8517.173196] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[ 8517.173236] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[ 8517.173268] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[ 8517.173299] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[ 8517.173318] ---[ end trace f5af9a7ec2528f9d ]---
[ 8517.173339] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:20638

In the terminal, I got the following output:

vc_gencmd_send returned -1
vchi_msg_dequeue -> -1(22)
@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 7, 2016

Collaborator

@falaca Can you provide a way of reproducing the issue?
e.g. provide a script that when run on a clean raspbian image produces that failure?

Collaborator

popcornmix commented Feb 7, 2016

@falaca Can you provide a way of reproducing the issue?
e.g. provide a script that when run on a clean raspbian image produces that failure?

@falaca

This comment has been minimized.

Show comment
Hide comment
@falaca

falaca Feb 7, 2016

@popcornmix For the first issue (using tvservice), it's very easy for me to reproduce. Just start a live RTSP stream with omxplayer, run tvservice -o, wait roughly 30 minutes, and then run tvservice -p. The screen will be blank, and trying to "revive" it with fbset and xrefresh will generate those errors in dmesg.

I start omxplayer via /etc/xdg/autostart, with the following bash script:

#!/bin/bash
until false; do
    stream=`cat /home/pi/streamvid/stream.txt`
    omxplayer --live --threshold 0 $stream
    echo "Restarting omxplayer..."
    sleep 3
done

And I have a cherrypy (python) web application running, which listens on localhost:8000/tvon and /tvoff, and executes a bash script that runs tvservice -p or -o when it receives a GET request at those URLs. I also autostart the web application in /etc/xdg/autostart. It doesn't make a difference whether I run the command manually or through the web app, but I'm sharing just in case it matters in some way that doesn't occur to me.

As for the stack trace that came up last night when I tried "vcgencmd display_power" instead of tvservice, I restarted the pi and it seems like so far today it hasn't reoccured. So it seems like that might be an intermittent issue, as opposed to the omxplayer/tvservice issue which is easily reproducible.

I am running Raspbian Jessie, and almost everything is default (no overclocking or anything) except for disabling DPMS via lightdm.conf and /etc/kbd/conf. Other than that, I just have a few python and bash scripts as described above.

falaca commented Feb 7, 2016

@popcornmix For the first issue (using tvservice), it's very easy for me to reproduce. Just start a live RTSP stream with omxplayer, run tvservice -o, wait roughly 30 minutes, and then run tvservice -p. The screen will be blank, and trying to "revive" it with fbset and xrefresh will generate those errors in dmesg.

I start omxplayer via /etc/xdg/autostart, with the following bash script:

#!/bin/bash
until false; do
    stream=`cat /home/pi/streamvid/stream.txt`
    omxplayer --live --threshold 0 $stream
    echo "Restarting omxplayer..."
    sleep 3
done

And I have a cherrypy (python) web application running, which listens on localhost:8000/tvon and /tvoff, and executes a bash script that runs tvservice -p or -o when it receives a GET request at those URLs. I also autostart the web application in /etc/xdg/autostart. It doesn't make a difference whether I run the command manually or through the web app, but I'm sharing just in case it matters in some way that doesn't occur to me.

As for the stack trace that came up last night when I tried "vcgencmd display_power" instead of tvservice, I restarted the pi and it seems like so far today it hasn't reoccured. So it seems like that might be an intermittent issue, as opposed to the omxplayer/tvservice issue which is easily reproducible.

I am running Raspbian Jessie, and almost everything is default (no overclocking or anything) except for disabling DPMS via lightdm.conf and /etc/kbd/conf. Other than that, I just have a few python and bash scripts as described above.

@falaca

This comment has been minimized.

Show comment
Hide comment
@falaca

falaca Feb 8, 2016

@popcornmix I ran some more tests tonight (on a different raspberry pi and different TV) and found out what the real issue was - now I have a simple and bullet-proof way for you to reproduce it.

It turns out that it has nothing to do with omxplayer - I had neglected another change that I made last week, which was to add a /snapshot URL to my web application, which returns a screenshot of the raspberry pi taken with this little program: https://github.com/AndrewFromMelbourne/raspi2png

So here's how to reproduce the problem:

  1. Boot up into the default Raspbian desktop (I have only tested this issue with the GUI running)
  2. ssh into the raspberry pi
  3. Run tvservice -o
  4. Run ./raspi2png -w 240 -h 135 -c 1 -s > /dev/null several times in quick succession (I just copy/paste and then press up/enter on my keyboard ~20 times)
  5. Each time you run the command, you will see the error raspi2png: vc_dispmanx_snapshot() failed
  6. Run tvservice -p

After the above steps, your display will be blank. Running fbset -depth 8 && fbset -depth 16 && DISPLAY=:0 xrefresh as suggested in some of the above comments will be ineffective, and result in the error messages in dmesg which I shared previously.

Interestingly, I realized when testing on the other raspberry pi that the latest commit to that program fixes the issue by checking that that the display handle returned by vc_dispmanx_display_open() is not 0 before attempting to call vc_dispmanx_snapshot(): AndrewFromMelbourne/raspi2png@808fb02

So to reproduce this bug, you will have to revert that last commit. So to put it simply, I believe that this bug is triggered by running vc_dispmanx_snapshot() with 0 as the first function parameter while the HDMI port is powered off.

falaca commented Feb 8, 2016

@popcornmix I ran some more tests tonight (on a different raspberry pi and different TV) and found out what the real issue was - now I have a simple and bullet-proof way for you to reproduce it.

It turns out that it has nothing to do with omxplayer - I had neglected another change that I made last week, which was to add a /snapshot URL to my web application, which returns a screenshot of the raspberry pi taken with this little program: https://github.com/AndrewFromMelbourne/raspi2png

So here's how to reproduce the problem:

  1. Boot up into the default Raspbian desktop (I have only tested this issue with the GUI running)
  2. ssh into the raspberry pi
  3. Run tvservice -o
  4. Run ./raspi2png -w 240 -h 135 -c 1 -s > /dev/null several times in quick succession (I just copy/paste and then press up/enter on my keyboard ~20 times)
  5. Each time you run the command, you will see the error raspi2png: vc_dispmanx_snapshot() failed
  6. Run tvservice -p

After the above steps, your display will be blank. Running fbset -depth 8 && fbset -depth 16 && DISPLAY=:0 xrefresh as suggested in some of the above comments will be ineffective, and result in the error messages in dmesg which I shared previously.

Interestingly, I realized when testing on the other raspberry pi that the latest commit to that program fixes the issue by checking that that the display handle returned by vc_dispmanx_display_open() is not 0 before attempting to call vc_dispmanx_snapshot(): AndrewFromMelbourne/raspi2png@808fb02

So to reproduce this bug, you will have to revert that last commit. So to put it simply, I believe that this bug is triggered by running vc_dispmanx_snapshot() with 0 as the first function parameter while the HDMI port is powered off.

@falaca

This comment has been minimized.

Show comment
Hide comment
@falaca

falaca Feb 9, 2016

@popcornmix After compiling the updated version of raspi2png, everything seemed to be working fine throughout the day (the TV was turning on and off at the scheduled times, and I would occasionally check my web interface to make sure that it was displaying the correct content). About an hour ago I pulled up my web interface and just left it running on the side. It grabs an updated thumbnail of the display (240x135 pixels) every 5 seconds, and eventually I got the kernel oops again. This was with display_power set to 0, and just displaying the default Raspbian desktop (I modified my cron job to stop omxplayer when it shuts off the TV). So I think there must be more issues with the firmware's snapshot API.

Here's the stack trace:

[88010.798884] ------------[ cut here ]------------
[88010.798956] WARNING: CPU: 0 PID: 25716 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[88010.798975] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_gpiomem snd_bcm2835 bcm2835_rng snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[88010.799071] CPU: 0 PID: 25716 Comm: HTV Notify Not tainted 4.1.17+ #834
[88010.799084] Hardware name: BCM2708
[88010.799151] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[88010.799242] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[88010.799286] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[88010.799318] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[88010.799354] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[88010.799386] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[88010.799427] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[88010.799459] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[88010.799557] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[88010.799579] ---[ end trace 524380e672d2d838 ]---
[88010.799646] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:25709

So basically these are 2 separate bugs:

  1. Described in my previous post, where the framebuffer is permanently killed as a result of attempting (and of course failing) to take a snapshot after running tvservice -o.
  2. Kernel oops occurs after taking many snapshots after setting display_power set to 0.

Edit: Also, I was able to reproduce (1) on another raspberry pi + TV, but I haven't tried to reproduce (2). The other TV I'm using supports CEC so I'm able to turn that one on/off using cec-client. So I seem to have no issues taking snapshots as long as the raspberry pi's HDMI port is active.

falaca commented Feb 9, 2016

@popcornmix After compiling the updated version of raspi2png, everything seemed to be working fine throughout the day (the TV was turning on and off at the scheduled times, and I would occasionally check my web interface to make sure that it was displaying the correct content). About an hour ago I pulled up my web interface and just left it running on the side. It grabs an updated thumbnail of the display (240x135 pixels) every 5 seconds, and eventually I got the kernel oops again. This was with display_power set to 0, and just displaying the default Raspbian desktop (I modified my cron job to stop omxplayer when it shuts off the TV). So I think there must be more issues with the firmware's snapshot API.

Here's the stack trace:

[88010.798884] ------------[ cut here ]------------
[88010.798956] WARNING: CPU: 0 PID: 25716 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[88010.798975] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_gpiomem snd_bcm2835 bcm2835_rng snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[88010.799071] CPU: 0 PID: 25716 Comm: HTV Notify Not tainted 4.1.17+ #834
[88010.799084] Hardware name: BCM2708
[88010.799151] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[88010.799242] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[88010.799286] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[88010.799318] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[88010.799354] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[88010.799386] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[88010.799427] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[88010.799459] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[88010.799557] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[88010.799579] ---[ end trace 524380e672d2d838 ]---
[88010.799646] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:25709

So basically these are 2 separate bugs:

  1. Described in my previous post, where the framebuffer is permanently killed as a result of attempting (and of course failing) to take a snapshot after running tvservice -o.
  2. Kernel oops occurs after taking many snapshots after setting display_power set to 0.

Edit: Also, I was able to reproduce (1) on another raspberry pi + TV, but I haven't tried to reproduce (2). The other TV I'm using supports CEC so I'm able to turn that one on/off using cec-client. So I seem to have no issues taking snapshots as long as the raspberry pi's HDMI port is active.

@Ruffio

This comment has been minimized.

Show comment
Hide comment
@Ruffio

Ruffio Aug 10, 2016

@AGWA has this issue been resolved? If yes, then please close this issue.

Ruffio commented Aug 10, 2016

@AGWA has this issue been resolved? If yes, then please close this issue.

@TheTechnoGuy

This comment has been minimized.

Show comment
Hide comment
@TheTechnoGuy

TheTechnoGuy Aug 10, 2016

My #1 issue with my Raspberry Pi boards is that I can't walk away and leave the display turned on because VESA Display Power Management (DPMS) doesn't work. It works on Beaglebone Black - why not on Raspberry Pi? I've been waiting 2 years for a fix; I think there are many other people waiting for this fix as well. Please do NOT close this until the problem is resolved.

My #1 issue with my Raspberry Pi boards is that I can't walk away and leave the display turned on because VESA Display Power Management (DPMS) doesn't work. It works on Beaglebone Black - why not on Raspberry Pi? I've been waiting 2 years for a fix; I think there are many other people waiting for this fix as well. Please do NOT close this until the problem is resolved.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 10, 2016

@TheTechnoGuy try what I tried adding to the config.txt docs
raspberrypi/documentation#245

t3chguy commented Aug 10, 2016

@TheTechnoGuy try what I tried adding to the config.txt docs
raspberrypi/documentation#245

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Aug 10, 2016

Collaborator

bcm2708_fb_blank was implemented in kernel with:
bbbf1fc

We initially disabled the HDMI based on that, but it caused issues for apps that didn't use the framebuffer (e.g. omxplayer) which would lose the display after a few minutes.

So, it is now optional. Enable with hdmi_blanking=1 in config.txt.

Collaborator

popcornmix commented Aug 10, 2016

bcm2708_fb_blank was implemented in kernel with:
bbbf1fc

We initially disabled the HDMI based on that, but it caused issues for apps that didn't use the framebuffer (e.g. omxplayer) which would lose the display after a few minutes.

So, it is now optional. Enable with hdmi_blanking=1 in config.txt.

@AGWA AGWA closed this Aug 10, 2016

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Aug 10, 2016

@popcornmix or anyone else that may be able to help, anything you can do to get raspberrypi/documentation#245 applied, as https://www.raspberrypi.org/documentation/configuration/config-txt.md still contains no mention of hdmi_blanking.

t3chguy commented Aug 10, 2016

@popcornmix or anyone else that may be able to help, anything you can do to get raspberrypi/documentation#245 applied, as https://www.raspberrypi.org/documentation/configuration/config-txt.md still contains no mention of hdmi_blanking.

@grigorig grigorig referenced this issue in raspberrypi/firmware Oct 18, 2016

Closed

DPMS power saving with VGA666 #672

@xeusito

This comment has been minimized.

Show comment
Hide comment
@xeusito

xeusito Oct 22, 2016

hdmi_blanking works great with Touchscreen monitor 27" iiyama T2735MSC.

I was wondering if anyone knows how to adjust the time rpi waits until it switches the monitor off.

xeusito commented Oct 22, 2016

hdmi_blanking works great with Touchscreen monitor 27" iiyama T2735MSC.

I was wondering if anyone knows how to adjust the time rpi waits until it switches the monitor off.

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Oct 22, 2016

@xeusito it'll be in userland, as in likely whatever screensaver your DE ships with will trigger it. So configure that

t3chguy commented Oct 22, 2016

@xeusito it'll be in userland, as in likely whatever screensaver your DE ships with will trigger it. So configure that

@xeusito

This comment has been minimized.

Show comment
Hide comment
@xeusito

xeusito Oct 22, 2016

erhm.. could you be a bit more specific? I'm not sure what userland means.. is it somewhere in folder /usr?
and DE means distribution right? I'm running raspbian jessie with pixel kernel 4.4.

Thanks !

xeusito commented Oct 22, 2016

erhm.. could you be a bit more specific? I'm not sure what userland means.. is it somewhere in folder /usr?
and DE means distribution right? I'm running raspbian jessie with pixel kernel 4.4.

Thanks !

@t3chguy

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Oct 22, 2016

Sorry, DE is Desktop Environment, as in Pixel
Probably a menu in some Pixel settings pane.
I will likely install Pixel later on today so will get back to you if you cannot find it.

t3chguy commented Oct 22, 2016

Sorry, DE is Desktop Environment, as in Pixel
Probably a menu in some Pixel settings pane.
I will likely install Pixel later on today so will get back to you if you cannot find it.

t3chguy added a commit to t3chguy/documentation that referenced this issue Jan 8, 2017

AisforAstronaut added a commit to raspberrypi/documentation that referenced this issue Mar 2, 2017

Add hdmi_blanking config option (copy of #245) (#532)
* Remove unnecessary licence files

* Add hdmi_blanking config option

ref: raspberrypi/linux#487 (comment)

* Update config-txt.md

nathanchance pushed a commit to nathanchance/pi-kernel that referenced this issue May 28, 2018

usb: gadget: ffs: Execute copy_to_user() with USER_DS set
[ Upstream commit 4058ebf ]

When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.

This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.

For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.

	Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
	Modules linked in:
	CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
	Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
	Workqueue: events ffs_user_copy_worker
	task: ffffffc87afc8080 task.stack: ffffffc87a00c000
	PC is at __arch_copy_to_user+0x190/0x220
	LR is at copy_to_iter+0x78/0x3c8
	[...]
	[<ffffff800847b790>] __arch_copy_to_user+0x190/0x220
	[<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
	[<ffffff80080b8c64>] process_one_work+0x1dc/0x460
	[<ffffff80080b8f38>] worker_thread+0x50/0x4b0
	[<ffffff80080bf5a0>] kthread+0xd8/0xf0
	[<ffffff8008083680>] ret_from_fork+0x10/0x50

Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.

This patch is analogous to commit d7ffde3 ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

popcornmix pushed a commit that referenced this issue May 29, 2018

usb: gadget: ffs: Execute copy_to_user() with USER_DS set
[ Upstream commit 4058ebf ]

When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.

This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.

For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.

	Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
	Modules linked in:
	CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
	Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
	Workqueue: events ffs_user_copy_worker
	task: ffffffc87afc8080 task.stack: ffffffc87a00c000
	PC is at __arch_copy_to_user+0x190/0x220
	LR is at copy_to_iter+0x78/0x3c8
	[...]
	[<ffffff800847b790>] __arch_copy_to_user+0x190/0x220
	[<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
	[<ffffff80080b8c64>] process_one_work+0x1dc/0x460
	[<ffffff80080b8f38>] worker_thread+0x50/0x4b0
	[<ffffff80080bf5a0>] kthread+0xd8/0xf0
	[<ffffff8008083680>] ret_from_fork+0x10/0x50

Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.

This patch is analogous to commit d7ffde3 ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment