Skip to content
  • Mario Kleiner's avatar
    dri3: Fix DRI3.2 support for drivers other than modesetting-ddx. · 352a5ac8
    Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
    Both xf86-video-intel and xf86-video-nouveau cause OpenGL clients to
    fail when used with DRI3 on server 1.20 with Mesa 18.1.
    
    Reason is that the servers DRI3 version is now unconditionally reported
    as DRI3 1.2 to 1.2 capable clients. This causes clients using Mesa 18.1
    to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
    DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx do not
    support the needed hooks like info->pixmap_from_fds or
    info->get_formats, info->get_modifiers. Unfortunately we can't simply
    report the servers DRI3 version as 1.0 in this case, as the reported
    version can not be specific to a X-Screen, and different screens may
    have drivers with different capabilities.
    
    Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
    and simply reporting an empty set of supported modifiers for the
    DRI3GetSupportedModifiers request if the ddx doesn't support DRI 3.2.
    
    Clients like Mesa 18.1's dri3 loader respond to the empty set of
    reported modifiers by falling back to a dri driver selected buffer
    format (image->createImageWithModifiers responds to a NULL modifier_list
    by acting like ->createImage()). This works, but Mesa 18.1 will still
    try to use the DRI3PixmapFromBuffers request to create the corresponding
    pixmap, just passing in a modifier that corresponds to whatever tiling
    the dri driver selected by default. To prevent this request - and
    thereby the client - from failing with a BadImplementation error, remove
    the check for modifier == DRM_MOD_FORMAT_INVALID in the pixmap_from_fd
    fallback path of dri3_pixmap_from_fds() and trust that if we hit the
    fallback path then the client will have passed a buffer with some driver
    specific default tiling that can be handled by pixmap_from_fd.
    
    Another approach would be for Mesa's dri3 loader to keep track how a
    buffer was created (with explicit modifiers or not), and then call
    DRI3PixmapFromBuffers or DRI3PixmapFromBuffer, but then any future DRI3
    client implementation would need to be fixed, so the server side is
    probably the better place for this.
    
    Tested on Intel Ivybridge and NVidia Pascal.
    
    Fixes: 6e7c40f6
    
     ("dri3: Add multi-planar/modifier buffer requests")
    Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Daniel Stone <daniels@collabora.com>
    Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
    Tested-by: default avatarMike Lothian <mike@fireburn.co.uk>
    Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
    352a5ac8