The Process For Eventually Releasing X.Org Server 1.21

[cmakeshift]

Why change X in compatibility-breaking ways, now of all times? Just by the lack of enthusiasm releasing 11.21 we can tell that X is destined for being a compatibility solution. And little else.

That's a ridiculous statement. At best Microsoft only ignored it, just like everyone else did. It died entirely on its own.

Let me rephrase what happened: Be wanted to sell boxes with a dual booting setup, but MS stepped in and didn't want to allow for that, claiming it would breach deals for licensing Windows. Looking at how Haiku is shaping up, I'd say it would've been an amazing OS for multimedia workstations.

[oiaohm]

Sometimes I really need to know when is VBlank occurring because Mesa has a bugged VSync behavior. Time to put up my demonstration GIF again:

The horrible part is with Vsync is you mostly find out after then have to attempt to calculate how long to next vsync. If you have your maths wrong bad things happen of course dynamic clock rates really don't help.

[tildearrow]

Now I'm really curious. I don't want to GLX to go away either but why would you not want to have buffer swapping with sync to VBlank?

Sometimes I really need to know when is VBlank occurring because Mesa has a bugged VSync behavior. Time to put up my demonstration GIF again:

[oiaohm]

Nope it would be a total bullshit move but not surprising coming from you.

Let's see, to add more effort, drop it and then have users chroot instead of... having it just work because it's not dropped. I wonder which option is more attractive.

Current xlib today is implemented on top of xcb any how.

https://xcb.pdx.freedesktop.narkive.com/A4WpsAcO/problem-with-xcb-based-xlib-and-multithreaded-applications

Pure direct xlib has not existed for quite some time. Its no different to how Microsoft ships stuff with windows and turns it into a optional run-time package that you have to install.

[Weasel]

X11 protocol defines backwards compadiblity. Dropping xlib out of systems by default could be a good thing.
We have flatpak and snap and chroot so old applications needing Xlib could be bundled up with a runtime.

Someways kicking xlib out and leaving xcb in by default would be a very good thing.

Nope it would be a total bullshit move but not surprising coming from you.

Let's see, to add more effort, drop it and then have users chroot instead of... having it just work because it's not dropped. I wonder which option is more attractive.

[Weasel]

and macOS is a success too.

You forgot the sarcasm.

[oiaohm]

Pardon major rework. Prior Answers are after >

Drop DRI1 and DRI2?
> What about old hardware?

Lets get real here. UMS(usermode setting drivers) Most distributions are not building these any more that is your DRI 1 drivers. That hardware is not powerful enough to turn over firefox or chrome.
DRI2 there are pure DRI2 drivers left. All DRI2 drivers have in fact migrated to DRI3.
The problem with dropping DRI1/DRI2 is not old hardware. Its the NVIDIA closed source driver. It will break the NVIDIA closed source driver because they are using deprecated calls. Really its over due for this.

Drop all drivers except xf86-video-modesetting?
> What about old hardware?

Basically the same as first. Drop all drivers except modesetting effects Nvidia a lot but AMD/Intel custom hardware tweaks are hit has well.
Old hardware since the disappear of UMS drivers is support by modesetting how.

Create a GLAMOR built a top of Vulkan instead of OpenGL?
> Vulkamor

I do expect this one at some point.

Revise DRI3 to v3.3? (with what?)
>OK...?

Really should with freesync stuff. So there should be a new version of DRI.

Drop Xlib in favor of XCB (never going to happen)
>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).

X11 protocol defines backwards compadiblity. Dropping xlib out of systems by default could be a good thing.
We have flatpak and snap and chroot so old applications needing Xlib could be bundled up with a runtime.

Someways kicking xlib out and leaving xcb in by default would be a very good thing.

AR/VR stuff? A new XRandR version?
> Probably. What would that new RandR version bring though?

This would fairly be because you have updates the DRI level.

Drop any acceleration architectures? Is EXA, SNA, UXA, KAA, XAA all really needed? We now have GLAMOR!
>I repeat: What about old hardware?!

All those 2D accelerators horrible overlap with each other.

https://www.x.org/wiki/ExaStatus/

Like work should be put in to finish off the merge of KAA and XAA into EXA. That would kill off 2.
SNA by intel is on by default. UXA is intel old superseded. SNA is meant to support all hardware that UXA did if it does not its a bug.

So out of the list really only 3 should exist. EXA, SNA, GLAMOR. Using the others is really work around to a bug in EXA or SNA.

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?

A build flag to build a reduced, minimal X build only suitable for usage through XWayland?
>Would be cool, but somebody should re-engineer the whole XWayland architecture anyway.

This explains another area the next one.

Is Panoramix/Xinerama, COMPOSITE, DamageExt, GLX, DBE, and framebuffer still needed?
>Yes, many of these still needed! Are you crazy?!:

Not exactly 100 percent 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

If all composite solutions are going to be way-land compositors in future the Composte and Damage extentions from X11 protocol can absolutely go by by.

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)

This one I agree with. I have answered the vblank one the reality is in cpu you cannot really wait for vblank. If you are you are using a timing running in the cpu that has adjusted based on present time. So GPU limitations are an ass.

Is Xinput and xkbd still needed with libinput?
>Are you serious once again? libinput is a backend to XInput/XKB. Furthermore, once again, what about old hardware?

We are getting close that there are no other Xinput/XKB drivers other than libinput for x.org server.
Almost all the old drivers hardware support has been moved into libinput.

The effected hardware list is insanely small if you remove the GLX one out that list and ingnore the Nvidia closed source driver death.

If Intel graphics card turns out to be high end then doing this level of extreme will be more possible.

[boxie]

Getting rid of X entirely would do a better job of that if that's what distros are interested in.

Why not both? The cut down XWayland could be the carrot - and smitty with a massive stick could come and whack people with the NO MOAR X stick :P

[smitty3268]

Uhm, the entire protocol was just redesigned from scratch as HTTP2 a short while ago. Bad analogy.

http/2 was published 4 years ago. That's older than multiple wayland releases.

In fact, you can track it's history back through SPDY which was initially announced right around the same time that Wayland was. You could very roughly compare http1 and x11 dates too, if you wanted to extend things even further.

All of which is ignoring the fact that my post was obviously sarcastic and not meant to be thought too deeply about.