Hi On Wed, Mar 21, 2018 at 10:09 PM, Mario Kleiner <mario.kleiner...@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
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
