[PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Olivier Fourdan]

Hi

On Wed, Mar 21, 2018 at 10:09 PM, Mario Kleiner <mario.kleiner.de at gmail.com>
wrote:

> 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?
>

Yeap, I ended up at the same point in downstream bug
https://bugzilla.redhat.com/show_bug.cgi?id=1558476, yet using XRGB8888
instead of ARGB8888 fixes the issue reliably here...

Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180323/1f79fd55/attachment.html>