X.Org Server Development Process Is Questioned

[Ibidem]

Yuuuuuuuuuup. Remember, kernel policy is anything that ever hits mainline that userspace can use can never break. Ever. If someone wants to run a motif app from 1995 that was designed around kernel 2.4.12 (im picking a random release number there lol), that app has to work as far as the kernel is concerned. It can break because of userspace changes, thats fine, but if it can't run then it can't be because of kernel changes. If it is because of kernel changes then its considered a bug to be fixed.

Whatever implementation of revoke() goes into the kernel has to be perfect on the first run or extensible enough to not matter.

I'd say it would be ideal if it were extensible.

That motif app from 1995 would be an elf or a.out binary for Linux 1.2, though-and I've run Gimp 0.54 release binaries recently, which come pretty close.
(Just curiousity; yes, you probably would prefer the newer version. It's comparable to xpaint for the most part.)

Allegedly, at one point they made sure that the original bash from when Linux binaries were first released still worked.

[squirrl]

GEM has nothing to do with EXA and XXA, GEM is still still being used in kernel (Wayland is pretty much dependent on it cuz everything is a GEM object or is a GEM handle)

DRI was supplanted by DRI2...which was in the X server, not the kernel. The x server drops stuff.

Modesetting moved from the X server (userspace) to the kernel (KMS)

Nvidia keeps up because...they replace most of the stack with their own pieces because of cross-platform support


Wanna try again squirrl?

You obviously didn't get the point!
They keep changing everything is the point.
Stuff moves in and out of the Xserver on Whim!
GEM has tendrils in Xserver too
Besides, it may be in the kernel now, but later it'll be in Xserver totally.
there I tried again.

[Ericg]

You obviously didn't get the point!
They keep changing everything is the point.
Stuff moves in and out of the Xserver on Whim!
GEM has tendrils in Xserver too
Besides, it may be in the kernel now, but later it'll be in Xserver totally.
there I tried again.

Things were in the X server because they wanted it to be cross-platform. This happened before, the X server once upon a time had a printing server inside of it because they wanted to be cross-platform. Once the issue of cross-platform got taken out of the equation, then things started to be moved out of the X server and into the kernel.

I really cant think of anything that was taken from the x server, put into the kernel, and then put back into the x server...

And yes, things do keep changing because the linux graphics stack was at one point about 10 years out of date, now we're playing catchup and trying to get a solid footing on things. So there will be a lot of chaos until things settle (which they are now, the move forward is Wayland which will remove the giant middle-man that is the X server out of the way)

[daniels]

DRI is about 15 years old; DRI2 has been in the X server for 5 years now.

XAA is 17 years old; EXA is 8 years old; UXA is 5 years old.

The original modesetting infrastructure is nearly 20 years old; RandR 1.2 is 7 years old, and the five-year old KMS is a fairly literal port of the RandR 1.2 API into kernel space.

Considering how much technology has changed since 1996, is that actually too fast a rate of change for you?

[daniels]

Things were in the X server because they wanted it to be cross-platform. This happened before, the X server once upon a time had a printing server inside of it because they wanted to be cross-platform. Once the issue of cross-platform got taken out of the equation, then things started to be moved out of the X server and into the kernel.

Xprint got removed because it was a terrible, terrible, terrible idea that fulfilled none of its goals and made everyone deeply unhappy. http://cgit.freedesktop.org/xorg/xprint/log/ should give you an idea of how popular it is.

[Heidi572]

I wish the development was more effective so we had less bugs.

[varikonniemi]

There are problems in the design of X that prevents it from being fixed without breaking everything. Breaking everything gives you an opportunity to design it from scratch properly.

[uid313]

DRI is about 15 years old; DRI2 has been in the X server for 5 years now.

XAA is 17 years old; EXA is 8 years old; UXA is 5 years old.

The original modesetting infrastructure is nearly 20 years old; RandR 1.2 is 7 years old, and the five-year old KMS is a fairly literal port of the RandR 1.2 API into kernel space.

Considering how much technology has changed since 1996, is that actually too fast a rate of change for you?

XAA and DRI is removed now?
Is EXA removed yet? Can it be removed? Will it be removed?
Now DRI3 is on the way, so when that happens, will DRI2 be removed?

What else can be removed?

There are problems in the design of X that prevents it from being fixed without breaking everything. Breaking everything gives you an opportunity to design it from scratch properly.

Somethings cant be fixed/changed without breaking everything.
But maybe we can remove lots of things that nobody uses these days.
Sure, X.org Server wont be 100% compliant with X11 anymore, but at least we will have got rid of lots of old legacy cruft, and made the code base smaller and more easier to maintain.

[Ericg]

XAA and DRI is removed now?
Is EXA removed yet? Can it be removed? Will it be removed?
Now DRI3 is on the way, so when that happens, will DRI2 be removed?

What else can be removed?

I'm not sure if they can removed, because of applications still using them (maybe not DRI, but def DRI2) XXA has been partially supplanted by EXA though there is still a driver or two using XXA.

Somethings cant be fixed/changed without breaking everything.
But maybe we can remove lots of things that nobody uses these days.
Sure, X.org Server wont be 100% compliant with X11 anymore, but at least we will have got rid of lots of old legacy cruft, and made the code base smaller and more easier to maintain.

1) At that point..we have Wayland :P
2) The problem with breaking Xorg and X11 compliance is I think Xorg is the X consortium now, so if they break the X protocol, that would imply X12 protocol...which is Wayland. But if they call it X12, then anyone who has any interest in X still would need to get the chance to chime in with what they think X12 should look like. Hence Wayland, it was a clean break from backwards compatibility and old people and old thoughts and ideas.

[uid313]

1) At that point..we have Wayland :P
2) The problem with breaking Xorg and X11 compliance is I think Xorg is the X consortium now, so if they break the X protocol, that would imply X12 protocol...which is Wayland. But if they call it X12, then anyone who has any interest in X still would need to get the chance to chime in with what they think X12 should look like. Hence Wayland, it was a clean break from backwards compatibility and old people and old thoughts and ideas.

No, if they just stripped away unused features so the X.org Server would not be a full implementation of the X11 protocol, then that would not be X12, it would be a partial implementation of X11 or a a implementation of a subset of the X11 protocol, or X11 light.

X12 is an another protocol and a discussed successor to the X11 protocol.
http://www.x.org/wiki/Development/X12

Also, Wayland is something different. Also, since Wayland can use XWayland to run X.org Server on top of Wayland, then we could still cut fat of X.org Server while using it together with Wayland.