[weston] gbm_surface_get_in_fence_fd()

[RomainNaour]

Hi,

The weston patch [1] use gbm_surface_get_in_fence_fd() which is undefined:

../libweston/backend-drm/kms.c: In function ‘drm_output_apply_state_atomic’:
../libweston/backend-drm/kms.c:947:17: warning: implicit declaration of function ‘gbm_surface_get_in_fence_fd’ [-Wimplicit-function-declaration]
  947 |   in_fence_fd = gbm_surface_get_in_fence_fd(output->gbm_surface);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[198/413] Linking target libweston/backend-drm/drm-backend.so

/backend-drm/drm-backend.so.p/kms.c.o: in function `drm_pending_state_apply_atomic':
kms.c:(.text+0x1144): undefined reference to `gbm_surface_get_in_fence_fd'
collect2: error: ld returned 1 exit status

I can't find where this function is defined.

[1] patches/weston/0003-backend-drm-fix-flickering-for-imx-driver.patch

[gibsson]

Hi Romain, This definitely builds on my end. And this function is defined in libgbm/gbm.h provided by imx-gpu-viv. Please check that you are using master branch of the buildroot repo and close the issue when build passes ;)

[RomainNaour]

Hi Gary, Thanks for the reply!

I was using a modified version of nitrogen6x_qt5_gst1_mainline_defconfig where I added the weston package (Yes, I'm still using the sabrelite board). I removed the patch to workaround the issue since gbm_surface_get_in_fence_fd() is only provided by imx-gpu-viv. When using mainline mesa this function is not defined.

I'm not sure how do you want handle this issue since nitrogen6x_qt5_gst1_mainline_defconfig is only one defconfig without imx-gpu-viv where weston is not selected. It can be interesting to provide imx8 mainline defconfig with weston but this patch should trigger this issue.

Best regards, Romain

[RomainNaour]

Outch, the imx-gpu-viv-6.4.3.p1.0-aarch32 and imx-gpu-viv-6.4.3.p1.0-aarch64 doesn't provide the same content... gbm.h is missing from aarch32 archive.

This is unexpected :)

Best regards, Romain

[gibsson]

Hi Romain, Well I guess I'll remove GLOBAL_PATCH_DIR for the mainline config. Although it might be useful for BlueZ if you have the BD-SDMAC module, most our customers have the TiWi-BLE which works with standard BlueZ. All the other patches are NXP-specific. Or another option is to split the patch dir into 2: 1 for all configs (including mainline), 1 for NXP-based BSP. But considering your last comment, it could event be 1 for all configs (bluez only basically) and 1 for imx8 (gst + weston). Regards, Gary

[RomainNaour]

Since we know now that the weston patch is specific to aarch64 with imx-gpu-viv it makes sense to move it to another global patch directory imx8 (NXP-based BSP + gst + weston). It's always difficult to handle such "conditional" patches :)