procount
Posts: 1294
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Wed Aug 08, 2018 12:41 pm

@JamesH - Did you discover why the default overscan values had changed in this version? Are they still different or did you manage to revert them?
There was also the issue of start_x not booting when applied to (EDIT:) Raspbian installed by PINN.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Wed Aug 08, 2018 12:58 pm

procount wrote:
Wed Aug 08, 2018 12:41 pm
@JamesH - Did you discover why the default overscan values had changed in this version? Are they still different or did you manage to revert them?
There was also the issue of start_x not booting when applied to (EDIT:) Raspbian installed by PINN.
IIRC, the problem is that there is only one set of overscan numbers, but we now have multiple displays. I should probably add some extra config items, along the lines of...

hdmi_overscan_xxxx
dsi_overscan_xxxx
dpi_overscan_xxxx

That would make things a load easier, I think. Need to look at it again.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

procount
Posts: 1294
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Wed Aug 08, 2018 1:11 pm

There was also the issue that WITHOUT any overscan settings in config.txt, start.elf had overscan DISABLED, but your new start_x.elf had overscan ENABLED, so "disable_overscan=1" has to be exlicitly set to get the same behaviour as before. (viewtopic.php?f=63&t=216399&p=1336659#p1336659)
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Wed Aug 08, 2018 1:31 pm

procount wrote:
Wed Aug 08, 2018 1:11 pm
There was also the issue that WITHOUT any overscan settings in config.txt, start.elf had overscan DISABLED, but your new start_x.elf had overscan ENABLED, so "disable_overscan=1" has to be exlicitly set to get the same behaviour as before. (viewtopic.php?f=63&t=216399&p=1336659#p1336659)
Ahh, I remember now. Will take a look once have got source tree back to sane state after the DPI/DSI hackery. There were a few bug fixes in there that needed to be pushed, and they were mixed up in the hackfest.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 9:59 am

Hi jamesh,

Looks like you're working on updating the documentation : https://github.com/raspberrypi/document ... t/video.md
dpi_timings
This allows setting of raw DPI timing values for a custom mode, selected using dpi_group=2 and dpi_mode=87.
dpi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> &lt;interlaced> <pixel_freq> <aspect_ratio>
<h_active_pixels> = horizontal pixels (width)
<h_sync_polarity> = invert hsync polarity
<h_front_porch> = horizontal forward padding from DE acitve edge
<h_sync_pulse> = hsync pulse width in pixel clocks
<h_back_porch> = vertical back padding from DE active edge
<v_active_lines> = vertical pixels height (lines)
<v_sync_polarity> = invert vsync polarity
<v_front_porch> = vertical forward padding from DE active edge
<v_sync_pulse> = vsync pulse width in pixel clocks
<v_back_porch> = vertical back padding from DE active edge
<v_sync_offset_a> = leave at zero
<v_sync_offset_b> = leave at zero
<pixel_rep> = leave at zero
<frame_rate> = screen refresh rate in Hz
<interlaced> = leave at zero
<pixel_freq> = clock frequency (widthheightframerate)
<aspect_ratio> = *
The aspect ratio can be set to one of eight values (choose the closest for your screen):
HDMI_ASPECT_4_3 = 1
HDMI_ASPECT_14_9 = 2
HDMI_ASPECT_16_9 = 3
HDMI_ASPECT_5_4 = 4
HDMI_ASPECT_16_10 = 5
HDMI_ASPECT_15_9 = 6
HDMI_ASPECT_21_9 = 7
HDMI_ASPECT_64_27 = 8
although HDMI_ASPECT should be self-explained you might think about changing it to DPI_ASPECT here. I know, it's just cosmetics, but it may prevent failure/questions in the future.

Sorry to annoy you, but I'm now missing a 'display_DPI_rotate'. For consistancy (i.e. when there is DPI display only) this will be required. I understand it's possible it can't be put to good use for dual-display use (HDMI + DPI) as we might hit some performance limits (might also be rare case that one of the screens is in portrait while the other is in landscape).

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 10:26 am

aBUGSworstnightmare wrote:
Thu Aug 09, 2018 9:59 am
Hi jamesh,

Looks like you're working on updating the documentation : https://github.com/raspberrypi/document ... t/video.md
dpi_timings
This allows setting of raw DPI timing values for a custom mode, selected using dpi_group=2 and dpi_mode=87.
dpi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> &lt;interlaced> <pixel_freq> <aspect_ratio>
<h_active_pixels> = horizontal pixels (width)
<h_sync_polarity> = invert hsync polarity
<h_front_porch> = horizontal forward padding from DE acitve edge
<h_sync_pulse> = hsync pulse width in pixel clocks
<h_back_porch> = vertical back padding from DE active edge
<v_active_lines> = vertical pixels height (lines)
<v_sync_polarity> = invert vsync polarity
<v_front_porch> = vertical forward padding from DE active edge
<v_sync_pulse> = vsync pulse width in pixel clocks
<v_back_porch> = vertical back padding from DE active edge
<v_sync_offset_a> = leave at zero
<v_sync_offset_b> = leave at zero
<pixel_rep> = leave at zero
<frame_rate> = screen refresh rate in Hz
<interlaced> = leave at zero
<pixel_freq> = clock frequency (widthheightframerate)
<aspect_ratio> = *
The aspect ratio can be set to one of eight values (choose the closest for your screen):
HDMI_ASPECT_4_3 = 1
HDMI_ASPECT_14_9 = 2
HDMI_ASPECT_16_9 = 3
HDMI_ASPECT_5_4 = 4
HDMI_ASPECT_16_10 = 5
HDMI_ASPECT_15_9 = 6
HDMI_ASPECT_21_9 = 7
HDMI_ASPECT_64_27 = 8
although HDMI_ASPECT should be self-explained you might think about changing it to DPI_ASPECT here. I know, it's just cosmetics, but it may prevent failure/questions in the future.

Sorry to annoy you, but I'm now missing a 'display_DPI_rotate'. For consistancy (i.e. when there is DPI display only) this will be required. I understand it's possible it can't be put to good use for dual-display use (HDMI + DPI) as we might hit some performance limits (might also be rare case that one of the screens is in portrait while the other is in landscape).
Can't you use display_lcd_rotate? Since I have been unable to get DSI and DPI working together, it shoudl be fine for that? Or are you moving between setups and do not want to change the config.txt all the time?

Nearly figured out the overscan stuff - a little more convoluted than expected.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 11:25 am

Uuups! Sorry completely forgot that display_lcd_rotate is there already :oops: shame on me :oops:
Anyhow, will test once you've released it.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 11:31 am

Here is a new start_x.elf

https://drive.google.com/open?id=1sT902 ... gRGAjrjrWA

This has all my recent changes, plus I hope the fixes for the overscan problems reported. You still use the standard overscan config.txt entries, but the system will automatically disable overscan for LCD devices (including DMT duisplays running off the HDMI), leaving normal HDMI to use the overscans defined.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 12:38 pm

jamesh wrote: Here is a new start_x.elf

https://drive.google.com/open?id=1sT902 ... gRGAjrjrWA

This has all my recent changes, plus I hope the fixes for the overscan problems reported. You still use the standard overscan config.txt entries, but the system will automatically disable overscan for LCD devices (including DMT duisplays running off the HDMI), leaving normal HDMI to use the overscans defined.
I've switched to a different test Hardware which is using a 'real' DPI display so I might have an issue there. Neverthless I wanted to check which kernel to be used.
Is viewtopic.php?f=63&t=216399&start=100#p1347811 (4.14.58) still valid or can I also use latest one (4.14.61 is what you'll end up after rpi-update)?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 1:26 pm

You need to use the kernel I supplied, the rpi-update kernel doesn't have the framebuffer changes.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 2:37 pm

Arghhhhhh

git reset --hard is NOT your friend. I'll be doing all those overscan code changes again then....
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

procount
Posts: 1294
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 2:59 pm

Lol 😀

Code: Select all

tar cf restorepoint.tar .git
#do dangerous git stuff
If failure
   tar xf restorepoint.tar
fi
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 3:11 pm

Hi jamesh,

sorry, but something seems to be wrong as I can't get it to work!
Steps done:
1) prepare a fresh uSD, boot and configure (initial setting for WiFi,Keyboard, etc) using HDMI display only
2) sudo rpi-update d985893a
3) reboot
--> working fine until here
4) shutdown

5) copy kernel (this one: https://drive.google.com/open?id=1I7kbX ... qqQhnUnVe3) and start_x.elf (this one https://drive.google.com/open?id=1sT902 ... gRGAjrjrWA) to uSD
6) add 'start_x=1' to config.txt
7) boot RPi
--> Pi bootes, but no more USB devices - mouse/keyboard/BT/WiFi - all of them are dead

What did I miss?
Note: I'm using RPi3B for testing

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 3:17 pm

aBUGSworstnightmare wrote:
Thu Aug 09, 2018 3:11 pm
Hi jamesh,

sorry, but something seems to be wrong as I can't get it to work!
Steps done:
1) prepare a fresh uSD, boot and configure (initial setting for WiFi,Keyboard, etc) using HDMI display only
2) sudo rpi-update d985893a
3) reboot
--> working fine until here
4) shutdown

5) copy kernel (this one: https://drive.google.com/open?id=1I7kbX ... qqQhnUnVe3) and start_x.elf (this one https://drive.google.com/open?id=1sT902 ... gRGAjrjrWA) to uSD
6) add 'start_x=1' to config.txt
7) boot RPi
--> Pi bootes, but no more USB devices - mouse/keyboard/BT/WiFi - all of them are dead

What did I miss?
Note: I'm using RPi3B for testing
That implies your kernel modules do not match your kernel. What does uname -a say?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 3:21 pm

jamesh wrote:What does uname -a say?
I have no idea as mouse and keyboard are no longer working --> I can't check.

As said, I've started with a fresh Installation (2018-06-27 Raspbian) and only did what I've described in my last post. I did not Keep a copy of the kernel/start_x.elf on this uSD so I will have to start from scratch.

Will give it another try tomorrow, also testing new start_x.elf on the system which I used last week.

procount
Posts: 1294
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 3:27 pm

You could try removing start_x=1 from config.txt and see if it boots with usb then :shrug:
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
DougieLawson
Posts: 34167
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Multiple Frame buffer beta testers wanted

Thu Aug 09, 2018 4:36 pm

I've got a chance to test this stuff out tomorrow. Can you build a version for 4.14.61-v7+?
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

2012-18: 1B*5, 2B*2, B+, A+, Z, ZW, 3Bs*3, 3B+

Any DMs sent on Twitter will be answered next month.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 7:36 am

First result of this morning, using same HW as here viewtopic.php?f=63&t=216399&start=100#p1347829, but adding your latest start_x.elf (viewtopic.php?f=63&t=216399&start=125#p1350905):

dpi_timings is not regonized! Using hdmi_timings instead brings the screen connected to DPI into life. Changing it to dpi_timings leaves you with HDMI screen only after reboot.

As you've asked yesterday, here is uname-a result of todays HW:

Code: Select all

[email protected]:~ $ sudo uname -a
Linux raspberrypi 4.14.56-v7+ #311 SMP Mon Jul 30 14:49:38 BST 2018 armv7l GNU/Linux
Will prepare another uSD + HW for testing later today..

EDIT: BTW, here is the config.txt which im uisng atm. I've started by indroducing hdmi_mode and hdmi_group already as I want to check with a monitor that requiers custom timing later today (menas as soon as dpi_timings is reognized).

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=35

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
start_x=1
gpu_mem=208

# ---------------------------------------------
# Enable DPI
# --------------------------------------------- 
dtoverlay=dpi24
enable_dpi_lcd=1

# ---------------------------------------------
# Make DPI default output
# ---------------------------------------------
display_default_lcd=1

# ---------------------------------------------
# custom HDMI mode
# ---------------------------------------------
dpi_group=2
dpi_mode=87

# ---------------------------------------------
# DPI output format definitions
# ---------------------------------------------
dpi_output_format=461847

# ---------------------------------------------
# HDMI timing definitions
# ---------------------------------------------
hdmi_timings=1280 1 40 1 1 800 1 12 2 1 0 0 0 60 0 83500000 5

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 8:14 am

aBUGSworstnightmare wrote:
Fri Aug 10, 2018 7:36 am
First result of this morning, using same HW as here viewtopic.php?f=63&t=216399&start=100#p1347829, but adding your latest start_x.elf (viewtopic.php?f=63&t=216399&start=125#p1350905):

dpi_timings is not regonized! Using hdmi_timings instead brings the screen connected to DPI into life. Changing it to dpi_timings leaves you with HDMI screen only after reboot.
That is odd. It's working here.

I'll do another build/release cycle today, which will also bump the kernel to the current rpi-update.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 8:23 am

jamesh wrote:That is odd. It's working here.
Can you provide details of the HW you're using (DPI-display (model brand) and HDMI screen). Maybe it's an issue with the reolution.

My scrot screenshot shows both desktops, total resolution at my end is 2560x1024. DPI screen is the right one (with mountain wallpaper).
2018-08-02-163159_2560x1024_scaled.jpg
Scaled down 'scrot' screenshot.
2018-08-02-163159_2560x1024_scaled.jpg (26.73 KiB) Viewed 755 times

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20752
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 8:38 am

aBUGSworstnightmare wrote:
Fri Aug 10, 2018 8:23 am
jamesh wrote:That is odd. It's working here.
Can you provide details of the HW you're using (DPI-display (model brand) and HDMI screen). Maybe it's an issue with the reolution.

My scrot screenshot shows both desktops, total resolution at my end is 2560x1024. DPI screen is the right one (with mountain wallpaper).
2018-08-02-163159_2560x1024_scaled.jpg
Resolution is irrelevent, the code is exactly the same as the stuff for hdmi_timings, but just works on 'dpi-timings' instead, and is done in the DPI driver itself.

It's an Adafruit display I believe, running through their Kippah board.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 8:43 am

jamesh wrote: It's an Adafruit display I believe, running through their Kippah board.
Understood! I have a 5in (which is 800x480pixels) and the kippah at home. Nevertheless, doesn't explain why it runs with the Kippah and not here.
Let me Change Resolution of the HDMI Screen to VGA ....

procount
Posts: 1294
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:07 am

Probably just a typo in this thread, but @JamesH said 'dpi-timings' and @aBUGSworstnightmare used 'dpi_timings' ?? ;)
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:15 am

@jamesh: there must be something different at your end.
As said, changed the HDMI screen Resolution to VGA (-> hdmi_mode=4, hdmi_group=2) and the result was as expected:
2018-08-02-171504_1920x800_scaled.jpg
result with hdmi_timings line for DPI configuration (DPI Screen is WXGA, mountain wallpaper)
2018-08-02-171504_1920x800_scaled.jpg (33.45 KiB) Viewed 725 times
When changing 'hdmi_timings' to 'dpi_timimgs', DPI Screen stops working and only HDMI frambuffer is gerenarted
2018-08-02-171724_640x480_scaled.jpg
result with dpi_timings line for DPI configuration (DPI Screen is not working, only one frambuffer created
2018-08-02-171724_640x480_scaled.jpg (86.75 KiB) Viewed 725 times

aBUGSworstnightmare
Posts: 1080
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:18 am

procount wrote:
Fri Aug 10, 2018 9:07 am
Probably just a typo in this thread, but @JamesH said 'dpi-timings' and @aBUGSworstnightmare used 'dpi_timings' ?? ;)
Sorry, but I can't follow your comment. :?:

Return to “General discussion”