Gbm_surface_create fails if flags != 0

If gbm_surface_create is given either or both of the usual flags that mutter uses: GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING then it fails with errno==ENOSYS (Function not implemented). Setting flags to zero however makes gbm_surface_create succeed.

Confirmed the behaviour persists even after upgrading to 545.29.06.

Discovered in Nvidia secondary GPU copy acceleration (!3304) · Merge requests · GNOME / mutter · GitLab

If it’s actually complaining about arguments then I suspect EINVAL would be a less confusing error than ENOSYS. Although given that nvidia-drm can successfully scanout and render using flags=0, returning success would make even more sense.

Just for the record, this is Daniel van Vugt, who is single-handedly trying to improve the experience of running Gnome Desktop on systems with a dedicated NVIDIA GPU (as you can see in his merge request).
So ya’ll better recognize and explain why gbm_surface_create is failing when passing the flags.

I can confirm this problem. It can be easily reproduced by enabling modeset and fbdev on the latest nvidia drivers, booting into the console, and using kmsxx/kmscube/cube-gbm.cpp at master · tomba/kmsxx · GitHub line 53 to create a surface. The program will crash if the flags are left as-is, but display successfully if the flags are replaced with a 0.