dividuum wrote: ↑
Thu Aug 01, 2019 2:28 pm
I'm currently porting info-beamer pi
to the Pi4. I'm using DRM to set up a GL surface without using X at all. A few questions came up while working on that:
- When is /dev/dri/card0 and when is /dev/dri/card1 active? Usually it's card1, but I remember seeing card0 successfully working as well.
Pi0-3 you only have the vc4 driver, therefore render is via /dev/dri/card0. Pi4 has both vc4 for render, and v3d for 3D. You can probe the devices for their capabilities - only one should acknowledge that it has DRIVER_RENDER or DRIVER_MODESET capabilities.
[*]Are there always two crtc->encoder->connector "pipelines" for each connected display? I'm trying to get a grasp on how drm works, and from what I understood
, it seems that it should also be possible to have a single crtc and then drives to encoders?
I'd only expect one crtc->encoder->connector per display. What makes you think there are two?
is the lowest level DRM test tool. "modetest -M vc4" for my single headed display lists
Code: Select all
id crtc type possible crtcs possible clones
50 49 TMDS 0x00000001 0x00000000
id encoder status name size (mm) modes encoders
51 50 connected HDMI-A-1 1600x900 81 50
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
4096x2160 30 4096 4184 4272 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync, 2D; type: driver
id fb pos size
49 60 (0,0) (1920x1080)
1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync, 2D; type: driver
Some hardware supports cloning using the output of one crtc to feed multiple encoders. The Pi SoC does not.
If I get my relationships right, then:
Planes are fed into the HVS
CRTC = PixelValve
encoder = DSI/DPI/HDMI blocks.
connector is a slightly abstract concept as the outputs of the encoder blocks can't be remapped to alternate connectors, and most connector parameters actually modify encoder parameters.
Pixelvalves can only feed one destination.
dividuum wrote:[*] If I use multiple drmModeSetCrtc for each display for a cloned output, I guess I have to drmModePageFlip for each of them? I'm confused on how that's supposed to work if there's a single eglSwapBuffers followed by two drmModePageFlip calls. In the worst case, I guess one of the flips handlers might have to wait for full frame cycle (1/60s) in case it just missed the vsync event? Any insight on how something like that is usually handled? Is there a way to synchronize the vsync on the two connectors somehow? What happens if the refresh rate doesn't match?
I don't believe there is any guarantee that the displays will be in sync, and there's nothing stopping the displays having different refresh rates other than your application. The beat effects could be fun if one is at 24Hz and one at 25Hz.
You'll need to be very careful with buffer management, and only return the old buffer to egl once both displays have completed the respective flip.
X gives up in disgust and only single buffers!
dividuum wrote:[*] Querying drmModeGetResources doesn't seem to detect a newly connected screen. The number of connectors returned seems to depend on which screen was connected when the Pi started. Disconnecting a screen changes the modes available to the corresponding connector, but it's still marked as DRM_MODE_CONNECTED. How can I detect new displays and correctly detect their status?
Hot plug is still not supported with FKMS. With 7 different display outputs (DSI0, DSI1, DPI, VEC, HDMI0, HDMI1, and transposer) but only 3 HVS channels there has to be a decision made as to how the resources are allocated, and that is done at boot time within the firmware.
If there is an HDMI screen connected at boot, then we may be able to add hotplug notifications for subsequent connections/removal, but it's not that high on the priority list.
vc4-kms-v3d on a Pi0-3 should support hotplug. The driver changes haven't been made yet for Pi4 (it's on the list).
dividuum wrote:[*] Is there any guaranteed mapping between the DRM connectors and the dispmanx displays? So far it seems that DISPMANX_ID_HDMI0 is connector 0 and DISPMANX_ID_HDMI1 is connector 1.
If in doubt, then enumerate and check the display types.
The enumeration order in the firmware is always the same, and FKMS enumerates the displays in the same order as DispmanX. HDMI0 will always be enumerated before HDMI1. If HDMI0 is not connected, then HDMI1 will be assigned HDMI-A-1. I did look into trying to make the connector names match, but the names that can be assigned in the kernel are never passed out to userspace!
DSI and DPI displays will always both be reported as DSI.
dividuum wrote:[*] Is there a vc_gencmd hdmi_adjust_clock for HDMI1? Or does hdmi_adjust_clock adjust both HDMI0 and HDMI1?
I don't believe that is hooked up at all. It's certainly not something I've tested.
dividuum wrote:[*] Is it possible to create a GL surface with a resolution not matching the screen resolution? Previously I could create an arbitrarily sized dispmanx layer, place/scale that on the screen and then eglCreateWindowSurface on it.
From a DRM perspective, absolutely. How to get GL and DRM to co-operate and actually do it I couldn't say.
dividuum wrote:[*] Possibly related: Is it possible to create a GL surface spanning two screens? I would guess so if I create a gbm surface with the combined size and then call drmModeAddFB2WithModifiers with correct offset/strides/etc?
That sounds correct. X works in this way - GL renders the screen to a framebuffer that encompasses the entire desktop, and then each DRM plane is given a source rectangle on that buffer.
[*] Is there any useful documentation on drm/gbm and how all that plays together? I'd really prefer a less trial&error approach. I've yet to find a man page for drmModeSetCrtc for example. Documentation seem to be horrible
Documentation - that million dollar question. If you find any really good docs then please let me know!
The kernel API docs are at https://www.kernel.org/doc/html/latest/ ... -uapi.html
There was a post on dri-devel recently of someone trying to pull together userland documentation, but it didn't seem to go very far. https://www.spinics.net/lists/dri-devel/msg214986.html
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.