<div dir="ltr">Hi <div class="gmail_extra"> <div class="gmail_quote">On Wed, Mar 21, 2018 at 10:09 PM, Mario Kleiner <<a href="mailto:mario.kleiner.de@gmail.com" target="_blank">mario.kleiner.de@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks. However, seems we may have one more problem with the new code on slightly older < gen 9 Intel hw. Either that, or something is botched on my system atm., after pulling in all kind of updates to xorg-proto and xcb-proto and libdrm and stuff to make the server and mesa compile again. Using x-server/mesa master from last friday plus my patch, everything was fine when testing on radeon-kms and nouveau-kms, but when i tested on Intel IvyBridge (gen 5), i stared at a blank screen. Xorg log reported modeset failure with EINVAL iirc, the kernel at drm.debug level 1 reported: Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235103] [drm:drm_atomic_set_mode_prop_for_crtc [drm]] Set [MODE:] for CRTC state ffff9496185e3000 Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235112] [drm:drm_mode_object_put [drm]] OBJ ID: 81 (4) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235122] [drm:drm_mode_object_put [drm]] OBJ ID: 81 (3) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235133] [drm:drm_mode_object_get [drm]] OBJ ID: 50 (5) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235142] [drm:drm_mode_object_get [drm]] OBJ ID: 50 (6) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235152] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:50:HDMI-A-1] ffff9495e9629c00 state to ffff94961bb27400 Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235162] [drm:drm_mode_object_put [drm]] OBJ ID: 50 (7) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235171] [drm:drm_atomic_check_only [drm]] checking ffff94961bb27400 HERE --> Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235181] [drm:drm_atomic_check_only [drm]] Invalid pixel format AR24 little-endian (0x34325241) Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235189] [drm:drm_atomic_check_only [drm]] [PLANE:26:primary A] atomic core check failed Mar 16 19:30:48 kleinerm-MaxtorLinux kernel: [ 576.235198] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state ffff94961bb27400 This makes sense, as looking at i915-kms, Intel hw before Skylake does not support setting ARGB pixel formats, only Skylake and later do. Iirc radeon/amdgpu/nouveau-kms treat ARGB formats like XRGB formats, so they are nominally supported, even if ARGB is simply mapped to XRGB hw programming for scanout on some hw. In modesetting ddx, we create gbm buffers as either ARGB8888 or ARGB2101010, not checking if hw supports this. When using the new drmAddFB2WithModifiers ioctl, we choose format to be whatever the gbm buffers format is, so that might end badly. When i tried the obvious hack of switching to depth 24 -> XRGB8888 and depth 30 -> XRGB2101010 i gbm buffer creation, that made modesetting work again at depth 24, but now broke pageflipping again. For depth 30 it died somewhere deep in pixman during server startup. Looking at the current code in glamor and modesetting ddx, using XRGB8888 and XRGB2101010 consistently for depth 24 or depth 30 would actually make more sense to me than ARGB8888 and ARGB2101010, but hacking that in didn't immediately improve the situation. That was the point when i decided it is weekend. Maybe we need some fallback mapping of gbm formats to xrgb fallback pixel formats, just for the code path of drmAddFB2WithModifiers, similar to what we do in weston for the direct scanout path? Create buffers in ARGB, but submit them as XRGB for scanout? </blockquote><div> </div><div>Yeap, I ended up at the same point in downstream bug <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1558476">https://bugzilla.redhat.com/show_bug.cgi?id=1558476</a>, yet using XRGB8888 instead of ARGB8888 fixes the issue reliably here... </div><div>Cheers, </div><div>Olivier </div></div></div></div>