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

[Mario Kleiner]

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?

-mario


On Wed, Mar 21, 2018 at 5:27 PM, Adam Jackson <ajax at nwnk.net> wrote:
> On Mon, 2018-03-12 at 17:11 +0000, Daniel Stone wrote:
>> On 12 March 2018 at 16:57, Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
>> > The check for "no modifier specified" in drmmode_is_format_supported()
>> > should check for DRM_FORMAT_MOD_INVALID, not for zero, as zero actually
>> > means DRM_FORMAT_MOD_LINEAR.
>>
>> If I had a time machine, that would probably be the first thing I
>> would change about the modifiers API.
>>
>> Reviewed-by: Daniel Stone <daniels at collabora.com>
>
> Programming isn't about math, it's about numerology. Merged, thanks:
>
> remote: I: patch #209954 updated using rev 757e0ee1884f2a34a287d632462e3bc689eccb3d.
> remote: I: 1 patch(es) updated to state Accepted.
> To ssh://git.freedesktop.org/git/xorg/xserver
>    136b45e0c0..757e0ee188  master -> master
>
> - ajax