Chris, how do you make this as missing dma-fence support?

Just realised I missed the "timeline" part of

[17:35:45.463] warning: Disabling render GPU timeline due to missing EGL_ANDROID_native_fence_sync extension

(read as "disabling render GPU due to missing extension").

Since it doesn't say why it doesn't create the GL context, that looks like the easiest warning to fix first.

The fatal bit is probably the GBM surface creation: my guess is that the KMS driver exposes IN_MODIFIERS so we try to use gbm_surface_create_with_modifiers and when it fails because i915 Mesa is blissfully unaware, we just tank the whole setup rather than falling back to no modifiers.

Created attachment 142102 [details]
Stderr output of weston when successfully run on i965

Here is the output weston-launch produces for me in a i965 device, with no errors, just so that you can compare it to the one from i915, since there are some warnings which are printed in both cases.

Created attachment 142104 [details]
Stderr output of weston when successfully run on i965 (forcing the same OpenGL ES version than i915)

I redid the log but forcing the use of OpenGL ES 2.0 on i965, the same version i915 uses, to make the differences more obvious.

I removed the misleading bit from the title, because lack of EGL_ANDROID_native_fence_sync will not stop weston.

lspci on my laptop lists:
Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I get the same errors when trying to start weston:
...
[] failed to create gbm surface
[] Failed to init output gl state
[] Enabling output "LVDS-1" failed.
[] Error: cannot enable output 'LVDS-1' without heads.

From
https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg38763.html
I was able to work around the problem using:

$ weston --use-pixmap

ugh.  typo.   $ weston --use-pixman

(can't edit comments?)

(In reply to Duane Voth from comment #8)
> $ weston --use-pixman

Thanks for the hint. I hadn't tried this one.

The workaround dismisses the error message but, unfortunately, doesn't enable hardware acceleration, at least for me:

> $ glxinfo
>   Extended renderer info (GLX_MESA_query_renderer):
>      Vendor: VMware, Inc. (0xffffffff)
>      Device: llvmpipe (LLVM 7.0, 128 bits) (0xffffffff)
>      Version: 18.2.5
>      Accelerated: no
>      Video memory: 1982MB
>      Unified memory: no

(In reply to magiblot from comment #9)
> The workaround dismisses the error message but, unfortunately, doesn't
> enable hardware acceleration

Yes, the whole point of --use-pixman is to use Pixman software rendering which will be faster than GL with a software renderer. If anything, it will disable hardware acceleration for the compositor and apps.

It is used to get something on screen, when hardware acceleration doesn't work for any reason.

Daniel's guess in comment #3 is still the best guess here.

One thing to test to confirm would be to hack Weston's build so that HAVE_GBM_MODIFIERS will not get defined. If that works, then we know that using gbm_surface_create_with_modifiers() does not work while gbm_surface_create() works.

(In reply to Pekka Paalanen from comment #10)

If all you need is a tester, I'm up for anything.

Is there any simple way (e.g. using a PKGBUILD file) to compile weston with undefined HAVE_GBM_MODIFIERS?

Thanks.

(In reply to magiblot from comment #11)
> Is there any simple way (e.g. using a PKGBUILD file) to compile weston with
> undefined HAVE_GBM_MODIFIERS?

Not really, it needs to be patched out. There should be just one occurrence in configure.ac for it so hacking the condition to always evaluate to false or change the HAVE_ name to something else should do it.

A Weston patch is available here, but needs testing: https://gitlab.freedesktop.org/wayland/weston/merge_requests/92

Created attachment 143267 [details]
Stderr output of weston when run on i915 (with patch from comment #13)

(In reply to Daniel Stone from comment #13)

Thank you very much! I applied the patch over weston-git and tried again. It got closer, but still doesn't work for me.

The following errors have now appeared:

> [13:53:34.450] failed to create kms fb: No such file or directory
> [13:53:34.450] failed to get drm_fb for bo
> [13:53:34.979] failed to create kms fb: No such file or directory
> [13:53:34.980] failed to get drm_fb for bo
> [13:53:35.035] failed to create kms fb: No such file or directory
> [13:53:35.035] failed to get drm_fb for bo

weston doesn't crash or anything. After startup, the content of the tty continues being shown and weston appears to be idle. Ctrl+Alt+Backspace exits weston normally and control is given back to the shell.

Cheers.

I have the same exact problem on HP Pavilion DV4000 and I do confirm that undefining HAVE_GBM_MODIFIERS (5c8eef147c27a95ebb8ba79e19ebb190b025cbe0) allows Weston to run without --use-pixman.

(In reply to magiblot from comment #14)
> Created attachment 143267 [details]
> Stderr output of weston when run on i915 (with patch from comment #13)
> 
> (In reply to Daniel Stone from comment #13)
> 
> Thank you very much! I applied the patch over weston-git and tried again. It
> got closer, but still doesn't work for me.
> 
> The following errors have now appeared:
> 
> > [13:53:34.450] failed to create kms fb: No such file or directory
> > [13:53:34.450] failed to get drm_fb for bo
> > [13:53:34.979] failed to create kms fb: No such file or directory
> > [13:53:34.980] failed to get drm_fb for bo
> > [13:53:35.035] failed to create kms fb: No such file or directory
> > [13:53:35.035] failed to get drm_fb for bo
> 
> weston doesn't crash or anything. After startup, the content of the tty
> continues being shown and weston appears to be idle. Ctrl+Alt+Backspace
> exits weston normally and control is given back to the shell.
> 
> Cheers.

If you add #undef HAVE_GBM_MODIFIERS into libweston/compositor-drm.c and rebuild, it should do as a temporary hack.

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: https://gitlab.gnome.org/GNOME/mutter/issues/127 . 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 -----

Created attachment 144243 [details] [review]
gbm: gbm_bo_get_handle_for_plane fallback to nonplanar handle

Here is a patch for Mesa 19.0.3 that fixes the issue for me on Fedora 30 x86_64. Essentially the patch returns the nonplanar handle if the API check fails, making the gbm_bo_get_handle_for_plane() call equivalent to gbm_bo_get_handle() if requesting plane 0. With this patch, weston starts up and works correctly for me. Gnome Shell remains unaffected.

Merge request (against master) here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/871

This should eventually be backported to 19.0.

Fixed with b2200514 in Mesa.