Simple weston clients do not correctly resize their buffers

Yep, there's ioctl() DRM_CAP_DUMB_BUFFER that does that before actually creating the dumb buffer. https://gitlab.freedesktop.org/mesa/drm/-/blob/master/libkms/dumb.c#L196

Maybe that fails? 

libgbm tries to create kms driver. In case of control0 which supports DUMB it goes here
https://gitlab.freedesktop.org/mesa/drm/-/blob/master/libkms/linux.c#L143
in case of render node
https://gitlab.freedesktop.org/mesa/drm/-/blob/master/libkms/linux.c#L100
fails

Indeed, I also speculate the same thing. W/o it would effectively destroy the DRM-backend if EGL (which needs GBM) failed to initialize. Thing is that that happens early on, when creating the necessary bits for the renderer to work. Any buffer creation DUMB or not, happens afterwards. 

Regarding fail to open gbm device, for me it always happen with weston-simple-dmabuf-egl.

I have found that weston-simple-dmabuf-egl opens gbm for DRM render node and it fails since it does not support DUMB allocations and gbm does not support PowerVR device.

I have got curious how weston work. I suspect that weston uses control DRM node which support DUMB allocation which allows to create gbm device based on it.

 just fyi, as I've seen the same issue with chromium79, about the fact that it can't open/create the gbm device. I kind of assume that it attempts to do the same thing as weston-simple-dmabuf-egl which by the looks of it it seems it attempts to uses the incorrect DRM device. The display device/driver is different than the GPU and, at sometimes at reboot, they're changed. I think this might be the same issue we are seeing on chromium79.

 even if opening the correct DRM device, there's no code that handles the resize on both clients. It used to work in the past because there were/was no resizing involved.