If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Yes, that is a developers opinion. X, to me, is still network transparent since I can still run apps with 'ssh -X'. And the 'new' login manager lightdm also contains functioning XDMCP.

That makes the total pretty network transparent to me...

Fact that this is not important with design decisions in X, does not make it not network transparent anymore. It just does not work as well as it used to...

Its RELATIVELY network transparent. If the app is okay with DRI 1 or RENDER, they can be network transparent. Though Wayland should be able to have better Network Transparency than even X since it removes the round-trips-before-render synchronous design. (Yes I know XCB is asych but no much uses it, a lot of stuff is still on Xlib which means round-trips)

"X is not network transparent anymore and hasn't been for years." -- Daniel Stone (one of the head devs on X.org and)

I understand what he meant by that in that FOSDEM presentation but for the end user X is still very much network transparent in practice, at least as much as, say, an NFS filesystem. Granted, in the same sense, so is VNC and whatever other mechanism gets folded into the Wayland context. Though in my experience X had always provided far better ability and flexibility than VNC stuff, but it's been a long time since I've even touched VNC or Windows RDP-anything.

There's quite a bit of X criticism these days (and Mr. Stone's presentation was a bit off-putting to me in that sense) and it's probably true to say that X has fallen behind the competition. But a decade ago X was far superior at certain things than the alternatives so I don't think some of the original design ideas were necessarily based on numskull concepts. I accept that maybe it's time for something different but yikes this has been a hostile break.

Than it IS network transparent. Sjees, why would one play an OpenGL game over a LAN? That's insane. Then they should make OpenGL network transparent, NOT X. (which is my opinion of course...)

Gig-Eth could do openGL over LAN but thats an extreme case right now.

But let's not forget: Whats X's worst-case-scenario? Network. The absolute WORST position you can put an X-server in is over the network (more so than Windows Display Manager or whatever Apple's DM is) Why? Round-Trips. Every fail/success call back and forth between the X server and the app-- which is a lot due to being synchronous-- has to travel over the network and gets affected by network lag.

Can you do network transparent applications with X? Yes. People have decades. SHOULD you? Probably not. Would you WANT to? Hell no. Not for anything that requires any amount of back and forth between your side and the server side.

This is one part about Wayland that will be pretty nice. Client side chooses whether we get Rooted desktop or Rootless, (full desktop, VNC, or only individual windows, X) its A-sync, every frame is perfect, built in compression. We may finally get Windows RDP quality built into the desktop instead of being an afterthought (NX)

There's quite a bit of X criticism these days (and Mr. Stone's presentation was a bit off-putting to me in that sense) and it's probably true to say that X has fallen behind the competition. But a decade ago X was far superior at certain things than the alternatives so I don't think some of the original design ideas were necessarily based on numskull concepts. I accept that maybe it's time for something different but yikes this has been a hostile break.

Was his presentation heavy on the criticism? Yes. Was it necessary? Maybe not. Am I glad he did it? Yes. We needed someone to shine a light on all of the things wrong with the X protocol and having an X server in the middle.

Was X superior in the past? No doubt about it, 100% agree. But unfortunately 2 things happened: 1) We (the X community) started to rest on our laurels and we get burned because of it. 2) The X protocol wasn't updated. We worked around it, extended it. We were treating symptoms instead of treating the problem.

There's been a lot of hostility towards X for a couple reasons.

1) Games are coming to Linux now, games adjust the resolution to ensure a smooth experience. This shined a bright light on the fact that X has a hard time (Though not impossible) with adjusting the resolution dynamically. With Wayland this get fixed by applying black borders like windows does.

2) Multi-monitor, and Multi-GPU is a mess under X thanks in part to the way it handles multiple (protocol) screens. DRI3 & DMA-BUF is attempting to fix that by in part making Xorg "More Wayland like" though its still being developed. Last update on DRI3 was at XDC last fall when Keith Packard and Eric Anholt came up with it on the fly.

This is one area where I really like Wayland's attitude of "Thats a client problem." Wayland is just a barebones protocol that you can build upon, its a framework, YOU (the clients) have to build up and make it usable. It is there to facility security and show pretty pictures, and to get out of the way.

3) Flicker/Stutter/Tear free is basically impossible in games or video apps on X without the drivers getting involved and being really careful. Why? Round-trips mostly if i'm understanding things right. Yay synchronous design!!! What do you do under X to get no more flicker / stutter / tear in apps? You introduce a compositor with compositing enabled. Whats the setting that most people should have turned on? Disable compositing for full-screen windows. See the problem?

4) Protocol is a behemoth. Why is it a behemoth? "Mechanism, not policy." Its not a framework, its an implementation. What do we NEED it to be? Framework. See the inherit problem? Originally you didn't have Qt or GTK or EFL drawing rectangles. You told X, draw a rectangle. And X had a set way to do that. In the 80s and 90s when everything looked like windows 95 that was probably okay. Core protocol hasn't been updated since X11. We've just extended it and worked around X's inherit flaws but we've never tried to actually fix it. Mainly because "Fixing it" would mean doing what we are doing anyway....write a new protocol. It just so happens that this new protocol is called Wayland instead of X12.

If we had called Wayland "X12" No one would've given a shit, they would've been like "Yes! The protocol is being updated!" Instead everyone screamed "The wayland developers dont know what theyre doing!" Guess what...Most of the Wayland devs are former or current Xorg devs. They KNOW what X's faults are, they have to cry themselves to sleep every night that they read code from 12years ago that no ones updated since.

Keith Packard, accidentally, made a great point during his conference at FOSDOM or Linux.conf.au (forget which). He said the way they depreciate things in Xorg is they break it on accident, time passes, if no one's submitted a bug about it, it must mean no one cares about it. Therefore it must be safe to remove. Whats the point he accidentally made? The protocol is such a mess, and so many parts of it are unused bits that they can even break things on accident and no one will notice for months, or years even.

Daniel Stone made a similar point that I loved. He said there was originally 4 ways to handle input in Xorg. 1's been depreciated and the 3 that are left are all inter-dependent on eachother. He said "There's currently about 3 people on the planet that really understand how input works under X...and I really wish I wasn't one of them." Thats a big problem if thats the attitude that a big Dev has for Xorg. 3 seperate API's that are all interdependent on eachother? Problem. Only 3 people on the planet that understand how it works? Problem.

Whats my point? Why do we need Wayland? Because X is big. X is big and X gets in the way. We need something light weight, we need something asynchronous so we dont have all of these round-trips, we need something that knows it shouldn't be in the way. It should not be a deterrent, it should be an implementer, something that will enable us to keep pushing forward graphics-wise and to enable us to change the things that need to be changed as time progresses in the future. Wayland satisfies all of those.

Xlib is synchronous piece of shit used by GTK and Qt.
There is XCB which is much more modern and asynchronous but nobody is using it, because they already use Xlib and they made so many special case workarounds and confusing ugly hacks which they don't understand so they don't want to touch that code and port it to XCB.

I think they should make an X11 Light protocol, which is a subset of the X11 protocol with all unnecessary ancient cruft that not used anymore ripped out.

Xlib is synchronous piece of shit used by GTK and Qt.
There is XCB which is much more modern and asynchronous but nobody is using it, because they already use Xlib and they made so many special case workarounds and confusing ugly hacks which they don't understand so they don't want to touch that code and port it to XCB.

I think they should make an X11 Light protocol, which is a subset of the X11 protocol with all unnecessary ancient cruft that not used anymore ripped out.

Kind of like SVG Tiny is to SVG, and what OpenGL ES is to OpenGL.

I agree they SHOULD have. But at this point? Why bother? By the time they DID design, and spec-out and write "X11-Light" Wayland would probably be hitting desktops

I agree they SHOULD have. But at this point? Why bother? By the time they DID design, and spec-out and write "X11-Light" Wayland would probably be hitting desktops

Since X11-Light would be a subset of the X11 protocol, there would not be much writing of specifications.
We have X.org Server which is a implementation of X11, now just rip out and burn as much as you can while making sure it still compiles and runs the usual stuff.
Then see whats left.