<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Wayland compositors are unable to use hardware acceleration on i915"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108487#c17">Comment # 17</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Wayland compositors are unable to use hardware acceleration on i915"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108487">bug 108487</a>
              from <span class="vcard"><a class="email" href="mailto:alexvillacislasso@hotmail.com" title="Alex Villacís Lasso <alexvillacislasso@hotmail.com>"> <span class="fn">Alex Villacís Lasso</span></a>
</span></b>
        <pre>I see the exact same issue on my machine when trying weston. This bug is very
similar to one I had a hand in working around in mutter:
<a href="https://gitlab.gnome.org/GNOME/mutter/issues/127">https://gitlab.gnome.org/GNOME/mutter/issues/127</a> . The mutter workaround
essentially tries calling gbm_bo_get_handle_for_plane() on plane 0 of the bo,
sees if the call succeeded, and if not, falls back on calling
gbm_bo_get_handle() while storing DRM_FORMAT_MOD_INVALID, which in turn causes
the subsequent code to call drmModeAddFB[2]() instead of the unsupported
drmModeAddFB2WithModifiers().

This should really be fixed in mesa. Quoting myself from the mutter bug report:
----- BEGIN QUOTE -----
@daniels I think I found the cause why mesa code fails the
gbm_bo_get_handle_for_plane call with the i915 driver. However, it is not clear
to me whether it is an actual bug, or just the code "working" as designed.

The gbm_bo_get_handle_for_plane implementation was introduced by commit
f9567ab435217a72cbae628336ead84dc0b2a803 (gbm: Export a getter for per plane
handles). This implementation contains the following check, which remains to
this day:

   if (!dri->image || dri->image->base.version < 13 || !dri->image->fromPlanar)
   {
      errno = ENOSYS;
      return ret;
   }

One of the conditions for the call is that the base.version member is 13 or
above. This member (dri->image) is a __DRIimageExtension *, according to
src/gbm/backends/dri/gbm_driint.h in the Mesa code.

There are several DRI drivers that define a static __DRIimageExtension with
type __DRI_IMAGE, along with an API version. In the case of i965
(src/mesa/drivers/dri/i965/intel_screen.c), the api is at version 16. However,
in the case of i915 (src/mesa/drivers/dri/i915/intel_screen.c) the api is at
version 7.

At first sight, it looks as though the version check in the initial commit is
too restrictive. According to include/GL/internal/dri_interface.h in the Mesa
code, the fromPlanar member of __DRIimage should be available since __DRI_IMAGE
API version 5. However, the commit does not include comments on why version 13
is the minimum required for fetching the plane handle. Again, according to
include/GL/internal/dri_interface.h, the one property that requires 13 as a
minimum is __DRI_IMAGE_ATTRIB_OFFSET. So maybe the code assumes that whoever
calls  gbm_bo_get_handle_for_plane will also fetch the offset.

----- END QUOTE -----</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>