| > Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems. Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction. > From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves. As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11. |
a) nvidia's refusal to implement GBM in their driver was their own choice. The abstraction was never removed; GBM is the abstraction over all drivers.
b) nvidia already relented and implemented GBM in their driver.
The latter doesn't necessarily mean nvidia is a good choice of GPU even now, because it requires a proprietary driver, so compositor / Mesa / kernel devs cannot debug the full stack when anything goes wrong. So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers, regardless of whether you use it with X or wayland.
>As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs).
wlroots exists to solve that problem. Whether an individual compositor decides to use it or not is up to the compositor.
At least in KDE's case, wlroots did not exist at the time they added Wayland support so of course it's understandable that they don't use it. There's a fork of kwin that uses wlroots ( https://gitlab.com/kwinft/kwinft ) but I believe it's just an experimental one-person effort rather than anything that kwin devs are working on as a replacement.