Igalia
Cog not working with modeset renderer on Beagle Bone
Hello,
On the BeagleBone black when drm backend with the modeset renderer is used the display screen remains black and I have the following warning :
(cog:402): Cog-DRM-WARNING **: 07:50:00.867: failed to schedule a page flip: Invalid argument
With the gles renderer cog is running, I attached both logs if it can help.
The issue seems to come from the atomic modesetting but I couldn't figure out which settings could make the drm driver failing ? I tried to set COG_PLATFORM_DRM_MODE_MAX=1024x768@60 but still nothing on my display.
cog-drm-gles.log cog-drm-modeset.log dmesg-cog-drm-gles.log dmesg-cog-drm-modeset.log
From the messages in cog-drm-modeset.log (good set of log files, by the way!) it looks like Cog is trying to use a plane that does not support the AR24 pixel format (ARGB8888), which is what we get rendered from WebKit. So of course the driver bails out and produces an error whan validating the transaction:
[ 425.732192] [drm:drm_atomic_check_only] [PLANE:31:plane-0] invalid pixel format AR24 little-endian (0x34325241), modifier 0x0
[ 425.732206] [drm:drm_atomic_check_only] [PLANE:31:plane-0] atomic core check failed
Using the GLES renderer works because in that case because Cog picks an EGL configuration with an output pixel format compatible with the selected DRM plane, in this case RG16 (that's 16-bit RGB565):
(cog:372): Cog-DRM-DEBUG: 07:50:49.836: cog_drm_gles_renderer_new: Using plane #31, crtc #32, connector #34 (atomic).
(cog:372): Cog-DRM-DEBUG: 07:50:49.917: cog_drm_gles_renderer_initialize: Using config #8 with format 'RG16'
You can try setting WEBKIT_EGL_PIXEL_LAYOUT=RGB565 in the environment before running Cog. That will make WebKit RGB565 internally so I expect then the frames we get from WebKit should be in that format, which the DRM plane picked by the modeset renderer should be able to display. I have not tried this personally, but may be the quickest way forward for you.
Another thing we might want to try is making the modeset renderer code smarter so it tries finding a suitable plane that supports ARGB8888/XRGB8888. It would be interesting to have a better idea of what the KMS/DRM driver supports, so if you could provide the output of the drm_info tool (or upload it to the drmdb) that would be useful to know if it would be even possible to find a suitable plane in this hardware.
FWIW, disabling atomic mode setting should not make a difference in this case, but in case you may want to know, can be done this way:
cat > cog.ini <<EOF
[drm]
disable-atomic-modesetting = true
EOF
cog --config=cog.ini ...
The supported config file options are listed in the documentation.
Apparently one can set the default pixel format in /etc/powervr.ini (at least according to some sources):
cat > /etc/powervr.ini <<EOF
[default]
WindowSystem=libpvrDRMWSEGL.so
DefaultPixelFormat=ARGB8888
EOF
I don't have hardware at hand with a PowerVR graphics chip, so unfortunately I cannot try this myself. Hopefully the tips help 🤞🏼
From the messages in
cog-drm-modeset.log(good set of log files, by the way!) it looks like Cog is trying to use a plane that does not support theAR24pixel format (ARGB8888), which is what we get rendered from WebKit. So of course the driver bails out and produces an error whan validating the transaction:[ 425.732192] [drm:drm_atomic_check_only] [PLANE:31:plane-0] invalid pixel format AR24 little-endian (0x34325241), modifier 0x0 [ 425.732206] [drm:drm_atomic_check_only] [PLANE:31:plane-0] atomic core check failedUsing the GLES renderer works because in that case because Cog picks an EGL configuration with an output pixel format compatible with the selected DRM plane, in this case
RG16(that's 16-bit RGB565):(cog:372): Cog-DRM-DEBUG: 07:50:49.836: cog_drm_gles_renderer_new: Using plane #31, crtc #32, connector #34 (atomic). (cog:372): Cog-DRM-DEBUG: 07:50:49.917: cog_drm_gles_renderer_initialize: Using config #8 with format 'RG16'You can try setting
WEBKIT_EGL_PIXEL_LAYOUT=RGB565in the environment before running Cog. That will make WebKit RGB565 internally so I expect then the frames we get from WebKit should be in that format, which the DRM plane picked by the modeset renderer should be able to display. I have not tried this personally, but may be the quickest way forward for you.Another thing we might want to try is making the modeset renderer code smarter so it tries finding a suitable plane that supports ARGB8888/XRGB8888. It would be interesting to have a better idea of what the KMS/DRM driver supports, so if you could provide the output of the drm_info tool (or upload it to the drmdb) that would be useful to know if it would be even possible to find a suitable plane in this hardware.
Ok I've completly forgot that the pixel format was set in webkit, I actually tried to set RGB565 in https://github.com/Igalia/cog/blob/master/platform/drm/cog-drm-modeset-renderer.c#L243 but this didn't work? I've uploaded drminfo for the BBB here: https://drmdb.emersion.fr/snapshots/57e8f167ee37
Based on drminfo there are three pixel format available: RGB565, BGR888 and XBGR8888
Setting WEBKIT_EGL_PIXEL_LAYOUT=RGB565 works but based on https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp#L105 it wouldn't be possible to set it to BGR888 or XBGR8888 ? Currently it triggers an exception :
Unknown pixel layout XBGR8888, falling back to RGBA8888
Thanks !
FWIW, disabling atomic mode setting should not make a difference in this case, but in case you may want to know, can be done this way:
cat > cog.ini <<EOF [drm] disable-atomic-modesetting = true EOF cog --config=cog.ini ...
The supported config file options are listed in the documentation.
Im using cog 0.14.1 and it seems that the option is not applied :
(cog:674): Cog-DRM-DEBUG: 09:32:32.851: cog_drm_modeset_renderer_new: Using plane #31, crtc #32, connector #34 (atomic).
Apparently one can set the default pixel format in
/etc/powervr.ini(at least according to some sources):cat > /etc/powervr.ini <<EOF [default] WindowSystem=libpvrDRMWSEGL.so DefaultPixelFormat=ARGB8888 EOFI don't have hardware at hand with a PowerVR graphics chip, so unfortunately I cannot try this myself. Hopefully the tips help 🤞🏼
This doesn't seems to work from what I observed, drm_info always returns RGB565 ?
Apparently one can set the default pixel format in
/etc/powervr.ini(at least according to some sources):cat > /etc/powervr.ini <<EOF [default] WindowSystem=libpvrDRMWSEGL.so DefaultPixelFormat=ARGB8888 EOFI don't have hardware at hand with a PowerVR graphics chip, so unfortunately I cannot try this myself. Hopefully the tips help 🤞🏼
This doesn't seems to work from what I observed, drm_info always returns RGB565 ?
Ah, good to know, so we better don't recommend again trying to change the pixel format there.
It seems that RGB565 is the only pixel format that might work in your particular configuration, then. The output from drm_info is clear and the DRM driver really wants to have 24-bit depth color in BGR format, which is the reason why Cog cannot manage to find a way of using an RGB-ordered pixel format—which is what WebKit is providing. With the GLES renderer we are basically using the GPU to convert XRGB8888 to RGB565. I suppose we could try to one of:
- Add an option to allow manually tell the GLES renderer which pixel format to use.
- Make the GLES renderer prefer 24-bit color formats over 16-bit ones, and in that case we would still have the GPU do the conversion to XBGR8888 but at least there would not be loss of color bit depth 🤔
- Allow choosing
WEBKIT_EGL_PIXEL_LAYOUT=XBGR8888, and hope there aren't many places inside WebKit which assume RGB-ordering of the components.
@zdobersek, @alexgcastro: Any thoughts on these options? The first two ones would be rather quick to implement, but I could use a second opinion.
Oh wait, I just realized from the drmdb entry (thanks a lot for posting it!) that the DRM output is driving a LCD controller. Does the LCD panel actually support 24-bit color, or only 16-bit? In the latter case, I think picking RGB565 may be the better option in your case—and we may still want to investigate why the modeset renderer has issues with the RGB565 mode.