bcm2708_fb_check_var doesn't account for screen rotation

[mschorer]

we're using fullHD screens with screen_rotation set to 90/270 degrees.
we're also using "tvservice -o/-p" to send the display to sleep/wakeup ...
tvservice returns an error ...

this works perfectly if the screen is rotated 0/180 degrees, but fails if rotation is 90/270 ... as is obvious from https://github.com/raspberrypi/linux/blob/rpi-3.6.y/drivers/video/bcm2708_fb.c#L194

the comparison needs to be rotation-aware? e.g.

if (( <screen_rot> & 0x01) ? (xres > 1200) : (yres > 1200)) {

[popcornmix]

Perhaps

if (xres * yres > 1920 * 1200 || xres > 1920 || yres > 1920)

would be sufficient. I think the 1200 limit is more a sanity check than an absolute limit.
There's a danger if too high a resolution is selected you may get no image at all, so I'll need to check it's not easy to create an an invalid framebuffer with this change.

[mschorer]

fine for me ... when can i have it? ;-)

[popcornmix]

Source is pushed (76d183f) and I've sanity checked:

tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16

does the right thing. Should be in next rpi-update (probably at weekend).

[mschorer]

Perfect!
On 30 Jan 2014 18:44, "popcornmix" [email protected] wrote:

Source is pushed (76d183fhttps://github.com/raspberrypi/linux/commit/76d183fbc25004148d3f844a8c78c7cbc59dd1f0)
and I've sanity checked:

tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16

does the right thing. Should be in next rpi-update (probably at weekend).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/463#issuecomment-33712572
.

[popcornmix]

rpi-update firmware should have this fix. Please update and test.

[mschorer]

hmmh ...
it seems to work for rotations of 0/180 degrees.

for left/right-protrait (rot 90/270) setups ... the screen stays black:

• no tvservice error.
• screen turns on (from sleep) and shows correct resolution (in menu).
• qt app runs without errors @ proper res
• getting a screenshot from the app shows the right content
• screen all black.

i'm running in 1366x768@24bit ...

[popcornmix]

First, does this work (from console):

tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16

Note, after powering off display, the framebuffer needs to be recreated with something like fbset.
You may also need to do something like xrefresh to ensure framebuffer is refreshed.

[mschorer]

i know that and no it doesn't (no error but black screen)
also, i'm using qt via eglfs from the console so no X involved.

my process is:

• run qt app, exit if we need to sleep
• run "tvservice -o"
• run sleep app, exit if we need to wake up
• do a "tvservice -p && fbset -depth 16 && fbset -depth 24"
• loop

this does work with in a production digital signage setup for rotation of 0/180 degrees - but gives black for 90/270.
tvservice used to return an error with -p before the fix - now it doesn't anymore.
the framebuffer including opengl acceleration is working as i see in the screenshot - qt used to return something like "no framebuffer available" and bail out before.

only the display stays black.

is there another sanity check in the firmware preventing the "display-bitstream-generator" being "switched on"?

[popcornmix]

Really I need to see the failure here. Can you try a clean raspbian install and enable 90 degrees rotation and check if:

tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16

results in console returning. If it does, what is the minimal number of things you do to provoke a black screen.

[mschorer]

sure i tested your statement!
the screen stays black but is powered on - no error displayed on the commandline!

pi@piMaster ~ $ tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16
Powering off HDMI
Powering on HDMI with preferred settings
pi@piMaster ~ $ tvservice -s
state 0x12001a [HDMI DMT (81) RGB full 16:9], 1366x768 @ 60Hz, progressive
pi@piMaster ~ $

the above is from a ssh session (to be able to see something).
the same happens if done on the pi console via keyboard.

i mentioned all the other stuff only to show that i had my learning curve with pi's diplay controller.

[popcornmix]

Just to confirm was this with a clean raspbian image?
Did you run rpi-update to get the fixed kernel? (I didn't mention this, but you should).

[mschorer]

freshly downloaded "2014-01-07-wheezy-raspbian.zip".
boot into console.
ssh into machine.
set "display_rotate=3" in config.txt

pi@raspberrypi ~ $ tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16
Powering off HDMI
Powering on HDMI with preferred settings
ioctl FBIOPUT_VSCREENINFO: Invalid argument
pi@raspberrypi ~ $

=> ioctl error and black/blank screen as expected
then "sudo rpi-update".
then "sudo reboot"
boot into console.
ssh into machine.

pi@raspberrypi ~ $ tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16
Powering off HDMI
Powering on HDMI with preferred settings
pi@raspberrypi ~ $

=> no ioctl error as expected, STILL BLACK SCREEN

comment display rotation
reboot. normal display. ssh in.

pi@raspberrypi ~ $ tvservice -o && tvservice -p && fbset -depth 8 && fbset -depth 16
Powering off HDMI
Powering on HDMI with preferred settings
pi@raspberrypi ~ $

=> screen blinks off and goes on again. console as before.

[szantaii]

This issue is also affects me.

The same thing happens what @mschorer described. I'd like to turn off and on the HDMI, and I'm also using a 270° rotated display (/boot/config.txt):

hdmi_group=2
hdmi_mode=35
hdmi_force_hotplug=1
display_rotate=3

Has the fix gone into Raspbian already? (I'm using the latest one, I'm regularly update it.)

[popcornmix]

The latest firmware is

$ uname -a
Linux raspberrypi 3.12.19+ #684 PREEMPT Fri May 16 19:27:32 BST 2014 armv6l GNU/Linux

Is that what you are running? (run rpi-update to get it if not).

[szantaii]

I was still on a 3.10 kernel:

$ uname -a
Linux raspberrypi 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux

But after I ran an rpi-update, I got the latest:

$ uname -a
Linux raspberrypi 3.12.19+ #684 PREEMPT Fri May 16 19:27:32 BST 2014 armv6l GNU/Linux

However the issue still exists. If I remove the previously mentioned options from /boot/config.txt then I can turn off and on the HDMI without any problems. However when my screen is rotated, then the monitor turns back on, but it remains completely black.

[popcornmix]

Can you report output of

tvservice -s
fbset

[szantaii]

This is the output when my display is rotated.

$ /opt/vc/bin/tvservice -s
state 0x120016 [DVI DMT (35) RGB full 5:4], 1280x1024 @ 60.00Hz, progressive

$ fbset 

mode "1024x1280"
    geometry 1024 1280 1024 1280 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

[mschorer]

mine are:

pi@rpi ~ $ /opt/vc/bin/tvservice -s
state 0x120016 [DVI DMT (27) RGB full 16:10], 1280x800 @ 60Hz, progressive
pi@rpi ~ $ fbset

mode "800x1280"
    geometry 800 1280 800 1280 24
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/8,8/16,0/24
endmode

i tested a couple of fw versions for this "feature": only the tvservice error disppeared, the display did never go back to a visible console in 90/270 rotations.

[popcornmix]

Okay, I can reproduce the issue. I'll see what I can do.

[mschorer]

great!

this really is a requirement for portrait digital signage displays!

[popcornmix]

Can you test after updating with rpi-update?

[rklueber]

You are my hero. Works!

[popcornmix]

@mschorer can you test and close if happy?

[mschorer]

@popcornmix: sure. Not sure if i`ll get to it on monday though. Latest on
wednesday ...

Thanks. That`ll be a huge improvement!
Am 23.05.2014 23:47 schrieb "popcornmix" [email protected]:

@mschorer https://github.com/mschorer can you test and close if happy?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/463#issuecomment-44064226
.

[szantaii]

I just ran an rpi-update to get the lastest firmware:

$ uname -a
Linux raspberrypi 3.12.20+ #685 PREEMPT Fri May 23 18:59:01 BST 2014 armv6l GNU/Linux

Tested the stuff, and now it works, so the monitor turns back on and everythings displays correctly. I've tested this both in console and under the default LXDE session also.

@popcornmix Thanks for resolving this so fast! Could you point me to the code that was changed to fix this issue? I just want to learn what was the problem.

[popcornmix]

It was on firmware side (in start.elf).
Basically when running with display_rotate or dispmanx_offline an extra frame buffer is allocated.
It turned out that when powering off this got freed, but wasn't reallocated when powered back on again.

[mschorer]

Works for me now!

Thanks!