Bug 99791

Summary:	Wayland EGL do not fallback to software rendering anymore when the wl_drm interface is not available
Product:	Mesa	Reporter:	Cédric Legrand <legrand.cedric.01>
Component:	EGL/Wayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED FIXED	QA Contact:	mesa-dev
Severity:	major
Priority:	medium	CC:	emil.l.velikov, legrand.cedric.01
Version:	17.0
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Cédric Legrand 2017-02-13 12:05:08 UTC

Hello,

Since my system update to Mesa 17.0.0-rc3, the Wayland EGL implementation does not fallback to software rendering anymore when the wl_drm interface is not available.

After a quick look on the code, it seems that the implementation sends a WL_DRM_FORMAT_* inconditionaly, even when wl_drm is not available. Of course, this triggers an error on the server side as wl_shm does not know them:
 -> wl_display@1.error(wl_shm_pool@14, 0, "invalid format 0x34325258")

Thanks,
Cédric Legrand

Comment 1 Pekka Paalanen 2017-02-13 12:16:55 UTC

DRM format codes are identical to wl_shm format codes, except for argb8888 and xrgb8888. It is very unfortunate to have these exceptions, but they are there.

Comment 2 Pekka Paalanen 2017-02-13 14:46:20 UTC

I believe that the Mesa commit:

commit cb5e799448c959fa9f0d7ea76999ac6f8c0ad88e
Author: Emil Velikov <emil.velikov@collabora.com>
Date:   Mon Nov 28 18:25:19 2016 +0000

    egl/wayland: unify dri2_wl_create_surface implementations

is causing this regression by dropping the special-casing of the two formats that differ between DRM fourccs and wl_shm formats.

WL_DRM_FORMAT_XRGB8888 != WL_SHM_FORMAT_XRGB8888
WL_DRM_FORMAT_ARGB8888 != WL_SHM_FORMAT_ARGB8888

Comment 3 Daniel Stone 2017-02-13 14:58:21 UTC

(In reply to Pekka Paalanen from comment #2)
> I believe that the Mesa commit:
> 
> commit cb5e799448c959fa9f0d7ea76999ac6f8c0ad88e
> Author: Emil Velikov <emil.velikov@collabora.com>
> Date:   Mon Nov 28 18:25:19 2016 +0000
> 
>     egl/wayland: unify dri2_wl_create_surface implementations
> 
> is causing this regression by dropping the special-casing of the two formats
> that differ between DRM fourccs and wl_shm formats.
> 
> WL_DRM_FORMAT_XRGB8888 != WL_SHM_FORMAT_XRGB8888
> WL_DRM_FORMAT_ARGB8888 != WL_SHM_FORMAT_ARGB8888

I also believe you're right, and sent this patch earlier:
https://lists.freedesktop.org/archives/mesa-dev/2017-February/144133.html

I'd attach it, but Chrome seems to be allergic to file dialogs atm.

Comment 4 Cédric Legrand 2017-02-14 11:47:56 UTC

I applied Daniel's patch from comment #3 on Mesa 17.0.0, I can confirm that it fixes the issue, thanks a lot. Unfortunately, it did not have time to land in the final release...

I don't know if you want to close this issue now or wait for the patch to be merged, so I will let you do it.

Comment 5 Emil Velikov 2017-03-04 16:16:30 UTC

Just realised that we forgot the bugzilla tag in the patch :-(
The following patch was merged and should address the issue.

Thanks for the help gents.

commit a1727aa75ed252cd19c296ccf83cb595be971744
Author: Daniel Stone <daniels@collabora.com>
Date:   Mon Feb 13 14:06:10 2017 +0000

    egl/wayland: Don't use DRM format codes for SHM

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.