I am not so sure that GBM support was motivated primarily by the Linux desktop community. It's rather a symptom of industry-wide trends. I work in the automoti

I am not so sure that GBM support was motivated primarily by the Linux desktop community. It's rather a symptom of industry-wide trends. I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware. I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well. For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.