2020-03-04 09:49 AM
I need to connect a Waveshare Electronics 5.5" HDMI AMOLED display that does not provide it's supported modes, their website states it needs to be configured manually with the following
max_framebuffer_height=1920
max_usb_current=1
config_hdmi_boost=10
hdmi_group=2
hdmi_force_hotplug=1
hdmi_mode=87
hdmi_timings=1080 1 26 4 50 1920 1 8 2 6 0 0 0 60 0 135580000 3
How would I do this on the openstlinux_eglfs st-example-image-qt image ?
Thanks in advance.
Solved! Go to Solution.
2021-11-30 04:56 AM
After a few trial and error attempts and with some great ST guides I was able to figure this out. I am sharing the solution to this issue for anyone else that might find this useful.
First for the permission issue on the modetest. In wenston distros the weston@root.service has to be stoped. In eglfs there is no weston service. In order to run a modetest the framebuffer has to be empty. In my case was the psplash-drm example that was running.
root@stm32mp1:~# modetest -M stm -s 32:480x1920
setting mode 480x1920-60.00Hz@XR24 on connectors 32, crtc 35
failed to set mode: Permission denied
Stoping the example (or any other eglfs/qt application) will free the framebuffer for modetest
psplash-drm-quit
The main issue in my case was the clock as indicated by @PatrickF . The display needed a 79MHz pixel clock. The MP1 can support up to 90MHz as indicated in the FAQ but the default configuration for DK1 and DK2 boards is 74MHz. So changing the clock worked as intended. To change the clock I created a custom image in cubeMX and compiled it as described in this guide.
2020-03-04 11:46 PM
Please see https://wiki.st.com/stm32mpu/wiki/How_to_display_on_HDMI
You should use "modetest -M stm" to retrieve all modes provided by your display.
We do not support 135.58MHz pixel clock as stated in the hdmi_timings above, so if your display does not have lower frame rate mode which fit with 74.25MHz pixel clock (e.g. 30fps), there is no chances that your full HD (1920x1080) display could work.
Note also as stated in the wiki, that 1920x1080 might not work properly in all of your use cases as on DK2 the DDR is only 16-bits and CPU/GPU might not have enough performances.
2020-03-05 02:41 AM
Thank you Patrick.
Unfortunately modetest does not return any display modes for this display, see output below.
I've contacted the supplier to obtain what display modes it does support.
The link you kindly provided shows how to manually configure Weston using /etc/xdg/weston/weston.ini, assuming the display supplier provides the display mode info for this AMOLED display, how would one manually configure eglfs to support alternate modes ?
# modetest -M stm
Encoders:
id crtc type possible crtcs possible clones
28 0 DPI 0x00000001 0x00000000
Connectors:
id encoder status name size (mm) modes encoders
29 0 connected HDMI-A-1 0x0 0 28
props:
1 EDID:
flags: immutable blob
blobs:
value:
00ffffffffffff002194333400888888
1c1c0103800000780a0dc9a057479827
12484c00000001010101010101010101
010101010101b8353868408010702020
8400803874000018b835386840801070
20208400803874000018000000fc0054
3737392d3130387831393230000000fd
00147801ff1d000a202020202020016f
02031a7147c646464646464623090701
8301000065030c001000b83538684080
107020208400803874000018b8353868
4080107020208400803874000018b835
38684080107020208400803874000018
b8353868408010702020840080387400
00180000000000000000000000000000
0000000000000000000000000000002f
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
5 link-status:
flags: enum
enums: Good=0 Bad=1
value: 0
6 non-desktop:
flags: immutable range
values: 0 1
value: 0
19 CRTC_ID:
flags: object
value: 0
CRTCs:
.
.
.
and on an STM32MP157A-DK1 running stock Linux OS with Weston :-
root@stm32mp1:~# echo 4 > /sys/module/drm/parameters/debug
root@stm32mp1:~# systemctl restart weston
root@stm32mp1:~# dmesg
[ 499.441942] Gcnano is present and activated
[ 500.162116] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:29:HDMI-A-1]
[ 500.200736] [drm:drm_add_display_info] non_desktop set to 0
[ 500.200758] [drm:drm_add_display_info] HDMI: DVI dual 0, max TMDS clock 0 kHz
[ 500.200807] [drm:drm_add_edid_modes.part.19] ELD monitor T779-108x1920
[ 500.200827] [drm:drm_add_edid_modes.part.19] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0
[ 500.200841] [drm:drm_add_edid_modes.part.19] ELD size 36, SAD count 1
[ 500.200854] [drm:drm_add_display_info] non_desktop set to 0
[ 500.200866] [drm:drm_add_display_info] HDMI: DVI dual 0, max TMDS clock 0 kHz
[ 500.202072] [drm:drm_mode_debug_printmodeline] Modeline 33:"1080x1920" 60 137520 1080 1112 1144 1184 1920 1928 1932 1936 0x48 0xa
[ 500.202088] [drm:drm_mode_prune_invalid] Not using 1080x1920 mode: CLOCK_HIGH
[ 500.202110] [drm:drm_mode_debug_printmodeline] Modeline 40:"1280x720" 0 148500 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[ 500.202122] [drm:drm_mode_prune_invalid] Not using 1280x720 mode: CLOCK_HIGH
Best,
Paul.
2021-11-10 09:20 AM
Hi @wpaulilkinson and @PatrickF,
I know that its been a while but is there any chance that you figured this out?
I am facing a similar issue. I have a display with particular specifications that I want to configure in ostl-eglfs. I have already configured it to run on a rPi with the following settings. I made sure that my timings are compatible with STM32MP157D-DK1 according to this article. Our display will need 79MHz which seems within spec.
DISPLAY Specs:
hdmi_pixel_freq_limit=400000000
hdmi_timings=480 0 70 35 45 1920 0 12 2 2 0 0 0 60 0 73180000 0
hdmi_drive=2
disable_overscan=1
max_framebuffer_width=2560
max_framebuffer_height=2560
display_rotate=3
framebuffer_width=1920
framebuffer_height=480
hdmi_aspect_21_9=7
hdmi_mode=87
hdmi_group=2
hdmi_ignore_edid=0xa5000080
Modetest returns one mode available but the screen remains unresponsive. The 0x0 size on the connector does not look very promising either.
Connectors:
id encoder status name size (mm) modes encoders
32 31 connected HDMI-A-1 0x0 1 31
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 480x1920 60.00 480 550 585 630 1920 1932 1934 1936 73180 flags: nhsync, nvsync; type: preferred, driver
When I am trying to set this mode I get a permission denied error. The weston@root.service as indicated in this wiki page does not exist in EGLFS.
root@stm32mp1:~# systemctl stop weston@root.service
Failed to stop weston@root.service: Unit weston@root.service not loaded.
root@stm32mp1:~# modetest -M stm -s 32:480x1920
setting mode 480x1920-60.00Hz@XR24 on connectors 32, crtc 35
failed to set mode: Permission denied
Following the suggested article it seems that /etc/xdg/weston/weston.ini does not exist in eglfs either.
Any advice or help will be highly appreciated
2021-11-30 04:56 AM
After a few trial and error attempts and with some great ST guides I was able to figure this out. I am sharing the solution to this issue for anyone else that might find this useful.
First for the permission issue on the modetest. In wenston distros the weston@root.service has to be stoped. In eglfs there is no weston service. In order to run a modetest the framebuffer has to be empty. In my case was the psplash-drm example that was running.
root@stm32mp1:~# modetest -M stm -s 32:480x1920
setting mode 480x1920-60.00Hz@XR24 on connectors 32, crtc 35
failed to set mode: Permission denied
Stoping the example (or any other eglfs/qt application) will free the framebuffer for modetest
psplash-drm-quit
The main issue in my case was the clock as indicated by @PatrickF . The display needed a 79MHz pixel clock. The MP1 can support up to 90MHz as indicated in the FAQ but the default configuration for DK1 and DK2 boards is 74MHz. So changing the clock worked as intended. To change the clock I created a custom image in cubeMX and compiled it as described in this guide.