The Process For Eventually Releasing X.Org Server 1.21

[phoronix]

Phoronix: The Process For Eventually Releasing X.Org Server 1.21

While formally the X.Org Server aimed to put out a new feature update every six months, in recent years they have been well off that trajectory with not much feature activity going on especially now that GLAMOR / XWayland / xf86-video-modesetting have stabilized and many Linux distributions eyeing Wayland by default. But there is now at least some little bit of interest in what's going into X.Org Server 1.21...

http://www.phoronix.com/scan.php?page=news_item&px=Xorg-Server-1.21-Release-Means

[uid313]

What could X.Org Server 1.21 and the future hold for the X Window System?

• Drop DRI1 and DRI2?
• Drop all drivers except xf86-video-modesetting?
• Create a GLAMOR built a top of Vulkan instead of OpenGL?
• Revise DRI3 to v3.3? (with what?)
• Drop Xlib in favor of XCB (never going to happen)
• AR/VR stuff? A new XRandR version?
• Drop any acceleration architectures? Is EXA, SNA, UXA, KAA, XAA all really needed? We now have GLAMOR!
• A build flag to build a reduced, minimal X build only suitable for usage through XWayland?
• Is Panoramix/Xinerama, COMPOSITE, DamageExt, GLX, DBE, and framebuffer still needed?
• Is Xinput and xkbd still needed with libinput?

[Soul_keeper]

I see this as a good thing.
Most everything that has been updated consistently, seems to have gotten bloated and become impossible to compile without spending days/weeks studying their new fangled build systems and countless hipster deps.
KISS and don't break what works.

[tildearrow]

What could X.Org Server 1.21 and the future hold for the X Window System?

• Drop DRI1 and DRI2?
• Drop all drivers except xf86-video-modesetting?
• Create a GLAMOR built a top of Vulkan instead of OpenGL?
• Revise DRI3 to v3.3? (with what?)
• Drop Xlib in favor of XCB (never going to happen)
• AR/VR stuff? A new XRandR version?
• Drop any acceleration architectures? Is EXA, SNA, UXA, KAA, XAA all really needed? We now have GLAMOR!
• A build flag to build a reduced, minimal X build only suitable for usage through XWayland?
• Is Panoramix/Xinerama, COMPOSITE, DamageExt, GLX, DBE, and framebuffer still needed?
• Is Xinput and xkbd still needed with libinput?

What about old hardware?
What about old hardware?
Vulkamor.
OK...?
Please don't. I know you like breaking compatibility, but this is exactly why Windows has been a success (in many cases it is backwards compatible).
Probably. What would that new RandR version bring though?
I repeat: What about old hardware?!
Would be cool, but somebody should re-engineer the whole XWayland architecture anyway.
Yes, many of these still needed! Are you crazy?!:

• Composite is necessary to have a compositor.
• Damage is necessary for battery/power savings as it allows telling a compositor only to render a small portion of the screen
• GLX? Look. Why would you want to remove something 95% of applications still use?! (furthermore, please tell me how can I wait for VBlank without swapping buffers in EGL)

Are you serious once again? libinput is a backend to XInput/XKB. Furthermore, once again, what about old hardware?

Seems like everyone likes breaking compatibility THIS early, and I hate it! This is why you are my competition.

[Vistaus]

Please don't. I know you like breaking compatibility, but this is exactly why Windows has been a success (in many cases it is backwards compatible).

So? macOS broke compatibility two times (first PowerPC to Intel and now dropping 32-bit) and macOS is a success too.

[Brisse]

tildearrow Vistaus IMO, Windows was a success because of MS's close relations to OEM's, and pretty much every retail PC comes with Windows pre-installed, leaving barely any choice to mainstream consumers. They are a success because they monopolized the desktop/laptop market early on and locked out any attempt at competition.

[Ironmask]

tildearrow Vistaus IMO, Windows was a success because of MS's close relations to OEM's, and pretty much every retail PC comes with Windows pre-installed, leaving barely any choice to mainstream consumers. They are a success because they monopolized the desktop/laptop market early on and locked out any attempt at competition.

What competition? There was competition and anti-competitive behavior when Digital Research was around but MS quickly surpassed their products in features. To this day there isn't an OS with as much of a stable ecosystem as Windows. macOS constantly breaks apps through updates and doesn't like OEMs, Linux is beginning to solidify with standard packages like systemd but is still too much of a fragmented mess for OEMs to be concerned with, especially with all the distros. There's OEMs that sell Linux machines, especially IBM, but nobody cares because they can't be sure it'll run all the software they need or have support from the manufacturer. Even entire governments have tried Linux but switched back to Windows because the cost of maintaining Linux in a desktop work environment is still just too expensive and error-prone.
Nobody's offered a better product yet, it's not a grand conspiracy. I can't stand that general philosophy of "if X didn't exist then there would be a sea of better alternatives" it's the opposite, a large corporation needs to put money into funding research and development so alternatives can copy it (just look at how many Linux DEs copy or mimic macOS and Windows). If you want Linux to surpass Windows in the desktop market, make it better then Windows, don't cry that MS isn't sharing it's gummy worms with the class. I can see Linux becoming as good as Windows in the next decade, especially with more and more packages becoming mainstream in almost all distros and the new WSL 2.0 system making cross-platform development a breeze. But right now? Not a chance.

[Guest]

What competition? There was competition and anti-competitive behavior when Digital Research was around but MS quickly surpassed their products in features. To this day there isn't an OS with as much of a stable ecosystem as Windows. macOS constantly breaks apps through updates and doesn't like OEMs, Linux is beginning to solidify with standard packages like systemd but is still too much of a fragmented mess for OEMs to be concerned with, especially with all the distros. There's OEMs that sell Linux machines, especially IBM, but nobody cares because they can't be sure it'll run all the software they need or have support from the manufacturer. Even entire governments have tried Linux but switched back to Windows because the cost of maintaining Linux in a desktop work environment is still just too expensive and error-prone.
Nobody's offered a better product yet, it's not a grand conspiracy. I can't stand that general philosophy of "if X didn't exist then there would be a sea of better alternatives" it's the opposite, a large corporation needs to put money into funding research and development so alternatives can copy it (just look at how many Linux DEs copy or mimic macOS and Windows). If you want Linux to surpass Windows in the desktop market, make it better then Windows, don't cry that MS isn't sharing it's gummy worms with the class. I can see Linux becoming as good as Windows in the next decade, especially with more and more packages becoming mainstream in almost all distros and the new WSL 2.0 system making cross-platform development a breeze. But right now? Not a chance.

Just take a look at BeOS, and how Microsoft killed Be with their deals with OEMs. They actively fight against the possibility of someone competing with them, and considering the cost of OS development, there won't be many who will attempt it.

[Anvil]

sounds to me pretty much like Wayland, will we see anymore wayland releases anytime soon or the future? ( thats up in the air ) i think Xserver will survive whereas Wayland IMO is almost another Titanic

[boxie]

What could X.Org Server 1.21 and the future hold for the X Window System?

• A build flag to build a reduced, minimal X build only suitable for usage through XWayland?

A separate XWayland build that has only minimal (and restrictive) set of features would be cool. It could reduce attack surface and reduce the amount of stuff required.

make it require a modern hardware set (GLAMOR / libinput etc) to keep size down through feature restriction.

Promote it as the primary way to use X apps and ask distros to the full X if requested.

Backwards compatibility is maintained, smaller feature set means less attack surface, more chance of maintenance on a more focused part of the stack.

tildearrow do you see a problem with this sort of path forward?