Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the working of X11 from the ground up (2017)

magcius.github.io

Post reply on HN
Print view View original

61–70 of 134 posts

Re: Understanding the working of X11 from the ground up (2017)

#61

Post by geofft »

datenwolf wrote: post #56
seba_dos1 wrote: post #52

Earlier quoted context omitted.

Umm, but Wayland and PulseAudio do have accessible interfaces from the file system... Wayland even requires it, as opposed to X11 which could work over TCP socket as well. No idea about systemd though (I think it uses dbus?)

These are only sockets through, through which you have to multiplex-serialize all the commands. In the Plan9 model, each and everything is represented by an individual file system entry. In Rio (Plan9's windowing system) every window is represented by a directory in a 9p tree, and you draw to it by opening a framebuffer file inside the window directory and manipulating that. Furthermore, terminals know about their wi…

Sure, but that's the Plan 9 philosophy. UNIX doesn't even have /proc/$pid/fd/ - there's no way to refer to another process's stdio unless you have the fd passed to you, and stdio is kind of the basis of UNIX. So by UNIX's definition of "everything is a file," we're still there.

Re: Understanding the working of X11 from the ground up (2017)

#62

Post by Jasper_ »

shmerl wrote: post #2

> I've made a personal decision to leave the Linux, X11, and Wayland worlds mostly behind. I understand X11 has a lot of unfixable problems, but what's wrong with Wayland world?

Author here.

I had been working on Linux professionally for about 6 years at that point, and got burned out on it. I have a lot of thoughts on the success of Linux as a general-use platform but mostly keep them to myself these days.

I still have a deep love for graphics, and have since moved onto working in the games industry, where I am much happier. I also still have a passion for explaining graphics topics.

Current efforts:

https://noclip.website/

https://blog.mecheye.net/2018/03/deconstructing-the-water-ef...

https://www.youtube.com/watch?v=8rCRsOLiO7k

Re: Understanding the working of X11 from the ground up (2017)

#63

Post by makomk »

the_why_of_y wrote: post #59
makomk wrote: post #35

Earlier quoted context omitted.

Also, even the limited X11 support which there currently is under Wayland will probably go the way of the dodo because it involves about the same amount of code as supporting X11 natively. For example, it requires every Wayland compositor to be a X window manager with all the complexity that implies, plus running a full hardware-accelerated X server and the OpenGL driver support for that. I can't imagine the desktop…

Xwayland doesn't need a hardware specific DDX driver, because firstly, many of the features can be implemented by forwarding to the Wayland server, and secondly, the drawing operations (which don't exist in Wayland) have been implemented hardware independently, based on OpenGL, in the GLAMOR backend. https://blog.mecheye.net/2014/04/xwayland/ https://wayland.freedesktop.org/docs/html/ch05.html If hardware vendors don…

X doesn't need a hardware specific DDX driver either when running on hardware supported by Wayland+Xwayland. The GLAMOR backend works just as well for a standalone X server, and it can just use the same libraries and APIs as Wayland does for the rest of the stuff. (There's not really any kind of hardware abstraction layer in Wayland itself.) The main reason why people use the hardware specific X drivers still is because they're more mature and robust than the Wayland stuff.

Re: Understanding the working of X11 from the ground up (2017)

#64

Post by Jasper_ »

sprash wrote: post #19

Money Quote: > So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice. That is something that can not be said about Wayland. Besides the "every frame is perfect"…

Author of the article here.

One of my many mistakes that burned me out on the whole project was trying to present X11 in a neutral way. I personally believe there's a lot broken with the architecture and the ecosystem, but wanted to let X11 sell its own ideas, slowly letting you figure out they were the wrong ones. But that never happened. I should have been more up-front by pointing out brokenness when I see it. The whole window tree was the wrong idea.

I worked closely on Wayland for a few years of my professional life, and helped design important parts. I believe X11 made plenty of wrong choices, and Wayland made much more informed ones.

But my attempt at staying neutral only fueled the Wayland vs. X11 debate. I stepped away entirely from open-source graphics in 2016, but it still goes on today.

Re: Understanding the working of X11 from the ground up (2017)

#65

Post by impostir »

sprash wrote: post #19

Money Quote: > So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice. That is something that can not be said about Wayland. Besides the "every frame is perfect"…

I run a Arch with the newest GPU drivers and the Compton compositor. I still have significant screen tearing in every app except video games with v-sync enabled and mpv with the vulkan backend.

Re: Understanding the working of X11 from the ground up (2017)

#66

Post by alxlaz »

heavenlyblue wrote: post #43
alxlaz wrote: post #34

Earlier quoted context omitted.

The uncomfortable truth today is that, while having to touch an X config file hasn't been a thing in more than 10 years, it will take you some fiddling with your favourite Wayland compositor (of which only three -- two massive DEs and a tiling compositor -- are anywhere near being useful) just to get it to stop crashing on that one application that you need, or to get things like multiple monitors or middle-click cop…

Are you saying that Wayland doesn’t not only run on Nvidia, it’s also buggy as hell?

Yeah, I also should have said that the response of the other part of the community isn't exactly sympathetic (or useful), either.

Truth is, a lot of the reason why X11 works so well today is that a bunch of us put up with a lot of X11 crap back in the day. E.g. things like xdotool haven't existed forever, either, and it took a lot of itches (and imperfect way of scratching them) before someone wrote that. X11 wasn't exactly hassle-free for a very long time. And you get to fiddle with config files with Wayland, too, but none of these files are as long as a small section in XF86Config.

That's how free software matures -- in the open. If you want to contribute towards hiring a team of testers, you're welcome, because no one does that as a hobby. And all this is in a context were fewer and fewer developers are interested in desktop development, and fewer and fewer companies are interested in investing in desktop development.

Re: Understanding the working of X11 from the ground up (2017)

#67

Post by tarruda »

krychu wrote: post #58

I haven't used linux as my primary OS for many years now. If not X11 or Wayland, what other alternative? Is there some other relevant development going on?

There's Arcan: https://github.com/letoram/arcan . In the words of the developer, it is a "multimedia engine" (a combination of display server, game engine and multimedia framework).

It is an interesting project and the YouTube presentation is pretty convincing: https://m.youtube.com/watch?v=07nqZIFRDJg

A great example of what a motivated and disciplined developer can achieve.

Re: Understanding the working of X11 from the ground up (2017)

#68

Post by strictfp »

mmrezaie wrote: post #27
pcr910303 wrote: post #17

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on... And now nobody uses the file system for these purposes.

How do you think it should have evolved? I personaly think posix way of filesystem needs to be changed into specialized oject filesystems, but I am not sure what object filesystem for a UNIX OS should look like specially since it needs to be generalized into something all the other sub-systems can benefit from.

It could have evolved into REST (which it didn't, but they're deceptively similar).

Re: Understanding the working of X11 from the ground up (2017)

#69

Post by zzzcpan »

yjftsjthsd-h wrote: post #4
shmerl wrote: post #2

> I've made a personal decision to leave the Linux, X11, and Wayland worlds mostly behind. I understand X11 has a lot of unfixable problems, but what's wrong with Wayland world?

From my perspective, Wayland "fixes" things that could allow bad things but were also useful. For instance, screenshots/recording took a long time to be implemented, and is still constrained, because of the security risk of arbitrary programs recording the screen. Because that is a risk... but users still want it. As another example, I use xdotool to inject input to programs in X; in Wayland, that would need to be ex…

Well, removing or not implementing such features because of security is always a big fat sign of something sneaky or even worse, outright incompetent going on. As such security risks of features can always be addressed through some sort of authorization mechanism.

Re: Understanding the working of X11 from the ground up (2017)

#70

Post by kebman »

This was a really nice demo! It can even be used to understand concepts used in the HTML5 canvas, such as aliasing. Hell, it could possibly used as en entry to learning how to program ray tracers. At the bare bones, construction of complex bodies in POV-Ray was used by Constructive Solid Geometry hearkening back to the basic union, xor, intersection, etc, operations done in the demo, at least on a conceptual level.
Post reply on HN