The original article by Thomas Petazzoni can be found in his STM32MP1 blog.
Achtung
- Ausgangsbasis sind die Vorarbeiten aus Lab 3
- Bei Buildroot mit stm32mp157c-dk2.dts konfigurieren
Introduction
In Linux, both display controllers and GPUs are managed by a Linux kernel subsystem called DRM, for Direct Rendering Manager. The DRM drivers are located in drivers/gpu/drm in the Linux kernel source code. If the hardware also has a GPU in addition to the display controller, then the most significant part of handling the GPU is done in user-space libraries implementing OpenGL. In the open-source world, the de-facto standard OpenGL implementation is Mesa3D, which has support for a number of different GPUs. From a GPU driver perspective, the kernel mainly serves as a way for the user-space OpenGL library to allocate buffers and send commands to the GPU.
...
In our case, we are going to use the Qt graphical toolkit, and on embedded Linux systems, it has four main display backends: eglfs (which requires an OpenGL/EGL graphics stack), linuxfb (which uses a simple legacy framebuffer interface), wayland (for Wayland, obviously) and xcb (for X.org). To keep things simple and because we don’t require OpenGL support, we will use the linuxfb backend.
Touch panel support in the Linux kernel
...
With the touch panel working, let’s move on to the display. In fact, you know the display is already working: the fbcon kernel driver provides a console over the framebuffer, which is why you are seeing the Linux kernel messages on the screen. Nevertheless, let’s use the modetest program from libdrm. Without any argument, it just prints out some details about the available display hardware. First the encoders:
...
| Codeblock | ||||||
|---|---|---|---|---|---|---|
| ||||||
# modetest
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...failed
trying to open device 'tilcdc'...failed
trying to open device 'msm'...failed
trying to open device 'sti'...failed
trying to open device 'tegra'...failed
trying to open device 'imx-drm'...failed
trying to open device 'rockchip'...failed
trying to open device 'atmel-hlcdc'...failed
trying to open device 'fsl-dcu-drm'...failed
trying to open device 'vc4'...failed
trying to open device 'virtio_gpu'...failed
trying to open device 'mediatek'...failed
trying to open device 'meson'...failed
trying to open device 'pl111'...failed
trying to open device 'stm'...done
Encoders:
id crtc type possible crtcs possible clones
28 0 DPI 0x00000001 0x00000000
30 33 DSI 0x00000001 0x00000000 |
So the display controller has two encoders:
- one with a DPI interface (i.e parallel RGB interface) and..
- one with a (MIPI) DSI interface.
Then, we have the list of connectors:
| Codeblock | ||||||
|---|---|---|---|---|---|---|
| ||||||
Connectors:
id encoder status name size (mm) modes encoders
29 0 connected HDMI-A-1 520x320 5 28
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#1 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#2 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, pvsync; type: driver
#3 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
#4 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
props:
1 EDID:
flags: immutable blob
blobs:
value:
00ffffffffffff0009d10a7845540000
1d120103803420782ec5c4a3574a9c23
124f52a56b807100810095008180b300
a940d1000101283c80a070b023403020
360007442100001a000000ff00463738
30303937345a4c300a20000000fd0032
551f5e11000a202020202020000000fc
0042656e51204732343030570a2001e6
02031af14604900301850766030c0010
00008301000023090707011d007251d0
1e206e285500c48e2100001f011d8018
711c1620582c2500c48e2100009e8c0a
d08a20e02d10103e9600c48e21000019
023a801871382d40582c4500c48e2100
0006d60980a020e02d1008602200128e
2108081800000000000000000000002c
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
31 30 connected DSI-1 52x86 1 30
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 480x800 50.00 480 578 610 708 800 815 825 839 29700 flags: ; type: preferred, driver
props:
1 EDID:
flags: immutable blob
blobs:
value:
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: 33
CRTCs:
id fb pos size
33 41 (0,0) (480x800)
#0 480x800 50.00 480 578 610 708 800 815 825 839 29700 flags: ; type: preferred, driver
props:
20 ACTIVE:
flags: range
values: 0 1
value: 1
21 MODE_ID:
flags: blob
blobs:
value:
04740000e00142026202c40200002003
2f033903470300003200000000000000
48000000343830783830300000000000
00000000000000000000000000000000
00000000
18 OUT_FENCE_PTR:
flags: range
values: 0 18446744073709551615
value: 0
25 GAMMA_LUT:
flags: blob
blobs:
value:
26 GAMMA_LUT_SIZE:
flags: immutable range
values: 0 4294967295
value: 256
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
32 33 41 0,0 0,0 0 0x00000001
formats: AR24 XR24 RG24 RG16 AR15 XR15 AR12 XR12 C8
props:
7 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
16 FB_ID:
flags: object
value: 41
17 IN_FENCE_FD:
flags: signed range
values: -1 2147483647
value: -1
19 CRTC_ID:
flags: object
value: 33
12 CRTC_X:
flags: signed range
values: -2147483648 2147483647
value: 0
13 CRTC_Y:
flags: signed range
values: -2147483648 2147483647
value: 0
14 CRTC_W:
flags: range
values: 0 2147483647
value: 480
15 CRTC_H:
flags: range
values: 0 2147483647
value: 800
8 SRC_X:
flags: range
values: 0 4294967295
value: 0
9 SRC_Y:
flags: range
values: 0 4294967295
value: 0
10 SRC_W:
flags: range
values: 0 4294967295
value: 31457280
11 SRC_H:
flags: range
values: 0 4294967295
value: 52428800
34 0 0 0,0 0,0 0 0x00000001
formats: AR24 RG24 RG16 AR15 AR12 C8
props:
7 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
16 FB_ID:
flags: object
value: 0
17 IN_FENCE_FD:
flags: signed range
values: -1 2147483647
value: -1
19 CRTC_ID:
flags: object
value: 0
12 CRTC_X:
flags: signed range
values: -2147483648 2147483647
value: 0
13 CRTC_Y:
flags: signed range
values: -2147483648 2147483647
value: 0
14 CRTC_W:
flags: range
values: 0 2147483647
value: 0
15 CRTC_H:
flags: range
values: 0 2147483647
value: 0
8 SRC_X:
flags: range
values: 0 4294967295
value: 0
9 SRC_Y:
flags: range
values: 0 4294967295
value: 0
10 SRC_W:
flags: range
values: 0 4294967295
value: 0
11 SRC_H:
flags: range
values: 0 4294967295
value: 0
Frame buffers:
id size pitch
|
We have a HDMI connector, which can be used with the encoder of id 31, that is the DPI encoder. Indeed, the RGB parallel interface of the STM32 processor is fed on the board into an HDMI transceiver, that goes out with HDMI signals on connector CN9. So from the point of view of the SoC, it is a parallel RGB interface, but thanks to the HDMI transceiver on the Discovery board, it is in fact usable as an HDMI connector.
The second connector is the DSI connector, which can be used with encoder of id 30, i.e the DSI encoder, which makes sense.
So let’s ask modetest to display its test picture on the DSI connector, which has id 30 for DSI panel resolution is 480×800, so we’ll use the following command:
# modetest -s 31:480x800
And voilà:
Now if we plug an HDMI screen to the HDMI connector, the modetest output about connector 29 changes as the connector is no longer disconnected:
| Codeblock | ||||||
|---|---|---|---|---|---|---|
| ||||||
Connectors:
id encoder status name size (mm) modes encoders
29 0 connected HDMI-A-1 520x320 5 28
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#1 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#2 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, pvsync; type: driver
#3 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
#4 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
props:
1 EDID:
flags: immutable blob
blobs:
value:
00ffffffffffff0009d10a7845540000
1d120103803420782ec5c4a3574a9c23
124f52a56b807100810095008180b300
a940d1000101283c80a070b023403020
360007442100001a000000ff00463738
30303937345a4c300a20000000fd0032
551f5e11000a202020202020000000fc
0042656e51204732343030570a2001e6
02031af14604900301850766030c0010
00008301000023090707011d007251d0
1e206e285500c48e2100001f011d8018
711c1620582c2500c48e2100009e8c0a
d08a20e02d10103e9600c48e21000019
023a801871382d40582c4500c48e2100
0006d60980a020e02d1008602200128e
2108081800000000000000000000002c
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 |
So the display controller has two encoders: one with a DPI interface (i.e parallel RGB interface) and one with a (MIPI) DSI interface.
Then, we have the list of connectors:
Connectors:
id encoder status name size (mm) modes encoders
29 0 disconnected HDMI-A-1 0x0 0 28
[..]
31 30 connected DSI-1 52x86 1 30
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
480x800 50 480 578 610 708 800 815 825 839 29700 flags: ; type: preferred, driver
We have a HDMI connector, which can be used with the encoder of id 28, that is the DPI encoder. Indeed, the RGB parallel interface of the STM32 processor is fed on the board into an HDMI transceiver, that goes out with HDMI signals on connector CN9. So from the point of view of the SoC, it is a parallel RGB interface, but thanks to the HDMI transceiver on the Discovery board, it is in fact usable as an HDMI connector.
The second connector is the DSI connector, which can be used with encoder of id 30, i.e the DSI encoder, which makes sense.
So let’s ask modetest to display its test picture on the DSI connector, which has id 31. The DSI panel resolution is 480×800, so we’ll use the following command:
# modetest -s 31:480x800
And voilà:
Now if we plug an HDMI screen to the HDMI connector, the modetest output about connector 29 changes as the connector is no longer disconnected:
...
So we can ask modetest to display a 1280×720 picture on the HDMI screen:
# modetest -s 29:1280x720
Enabling Qt5 support in Buildroot
...
# /usr/lib/qt/examples/gui/analogclock/analogclock -platform linuxfb
Then, another one which allows to test the touch panel:
# /usr/lib/qt/examples/widgets/scroller/graphicsview/graphicsview -platform linuxfb
And a more “complete” and useful application, which as you can see does not fit very well on a 480×800 screen in portrait mode, but also allows to use the touchscreenwhich allows to test the touch panel:
# /usr/lib/qt/examples/widgets/widgetsscroller/calculatorgraphicsview/calculatorgraphicsview -platform linuxfb
Filesystem size
To conclude this article, let’s have a look at the size of our filesystem size. After a completely clean build (make clean all), Buildroot can generate a nice graph of the filesystem size using make graph-size. In our case, it generates the following graph:
And a more “complete” and useful application, which as you can see does not fit very well on a 480×800 screen in portrait mode, but also allows to use the touchscreen:
#
Filesystem size
To conclude this article, let’s have a look at the size of our filesystem size. After a completely clean build (make clean all), Buildroot can generate a nice graph of the filesystem size using make graph-size. In our case, it generates the following graph:
| View file | ||||
|---|---|---|---|---|
|
/usr/lib/qt/examples/) on the target). Also, the dejavu font package is quite large, with 9.6 MB.