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

101–110 of 134 posts

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

#101

Post by rasz »

Mathnerd314 wrote: post #94
raphlinus wrote: post #82

Looking over this stuff, I get an uneasy feeling. X was a brilliant solution to problems 35 years ago, where you barely had enough memory for a full frame buffer and the graphics model was primitive (no antialiasing or transparency). From what I've seen, Wayland is a good solution for the model maybe 15 years ago, where you're willing to accept the frame-and-a-half latency hit from having a compositor in the path. Ba…

Wayland's latency was improved a few years ago to about half a frame, there's probably more room for improvement, but I think just getting a 240hz monitor is better investment of resources: https://ppaalanen.blogspot.com/2015/02/weston-repaint-schedu... The only applications strongly sensitive to latency are video games or similar, and they take a special low-latency path through the graphics stack, exclusive full-sc…

>The only applications strongly sensitive to latency are video games

paining with a pen/tablet/mouse

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

#102

Post by shmerl »

gmueckl wrote: post #98
shmerl wrote: post #87

Earlier quoted context omitted.

In the Linux world. All of their problems (roughly you can call them poor integration with the Linux stack) are consequences of them refusing to upstream their kernel driver. The fact that Nvidia blob fails you less is not a good indicator for you, unless you test with Mesa as well in each case. Mesa is a lot stricter about OpenGL spec compliance. So if you only test on Nvidia, you likely have bugs that you didn't no…

Every time I tested with Mesa and had issues, it turned out that Mesa was out of spec and quite specifically lying about that fact. And this was with absolutely essential features like rendering into floating point textures. So no, Mesa is not an indicator for spec compliance, either.

I suppose that was a long time ago? Today Mesa is compliant a lot more than Nvidia blob.

See also: https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-T...

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

#103

Post by bitwize »

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…

Maintaining Xwayland basically means maintaining all of Xorg except the hardware-specific drivers. And Red Hat doesn't want to maintain that code base anymore. Therefore, Xwayland will soon be abandoned, then deprecated, then removed entirely.

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

#104

Post by gmueckl »

shmerl wrote: post #102
gmueckl wrote: post #98

Earlier quoted context omitted.

Every time I tested with Mesa and had issues, it turned out that Mesa was out of spec and quite specifically lying about that fact. And this was with absolutely essential features like rendering into floating point textures. So no, Mesa is not an indicator for spec compliance, either.

I suppose that was a long time ago? Today Mesa is compliant a lot more than Nvidia blob. See also: https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-T...

Well, that was just one example that I found really egregious. I am usually right to distrust Mesa more than the nVidia blob.

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

#105

Post by raphlinus »

zaxcellent wrote: post #100
pcwalton wrote: post #92

Earlier quoted context omitted.

> If you're ever in south bay area and want to meet up at a coffee shop, let's :) For what it's worth, I would be very interested in chatting about this too, as this is my area right now. I'm working on what will hopefully become the Firefox OS compositor integration library, with an eye toward optimum power consumption, and am knee-deep in details of cross-platform composition. It's a very interesting topic.

This topic is also of interest to me. I work on a compositor integration protocol called virtio-wayland that is intended to allow Wayland apps running inside of VMs to communicate with a Wayland compositor on the host, shared memory and all. It's used for the Linux apps support for Chrome OS.

I don't get to the south bay often, but sounds like it might be good to have a little compositor meetup. I can certainly vouch for pcwalton's interest and knowledge in the topic :) Follow up by email?

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

#106

Post by shmerl »

gmueckl wrote: post #104
shmerl wrote: post #102

Earlier quoted context omitted.

I suppose that was a long time ago? Today Mesa is compliant a lot more than Nvidia blob. See also: https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-T...

Well, that was just one example that I found really egregious. I am usually right to distrust Mesa more than the nVidia blob.

So when was it exactly? I doubt recently. Mesa progressed to the point of full compliance a few years ago. Today, it's trusted a lot more than the blob, due to the later silently swallowing errors frequently and messing around with substituting shaders behind the scenes.

Try testing current Mesa versions. Previous experiences are no longer relevant.

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

#107

Post by zapzupnz »

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"…

Do you have a horse in this race? I ask because the writer's background is in writing Wayland, a lot of other commenters are writing software related to compositing, and there are even a few developers of X Window Systems.

I only ask because it's very easy to be cynical online and I'm not sure that this comment comes with much to back it up. There's very much an 'old man shouting at cloud' vibe to it, even if unintended, but I ask in good faith in case you have insights we don't know yet. :)

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

#108

Post by zapzupnz »

gmueckl wrote: post #74
crispinb wrote: post #22

Earlier quoted context omitted.

> The screenshot tool is just flat out not present when running under Wayland due to the above issue. That's odd - it's present (and functioning) in my Firefox (69.0.1) running on Gnome-on-wayland Firefox is generally quite crashy, however, which I'm guessing is Wayland-related

So Firefox supports screenshots when running on the Gnome compositor, but not running on sway? Looks like we're heading into interesting times where applications are getting tied to certain DEs with little to no cross-compatibility.

> interesting times where applications are getting tied to certain DEs with little to no cross-compatibility

What's old is new, apparently.

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

#109

Post by fao_ »

geofft wrote: post #61
datenwolf wrote: post #56

Earlier quoted context omitted.

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.

> Sure, but that's the Plan 9 philosophy.

As mentioned earlier, Plan9 is what UNIX research edition 8 grew into (as I understand it), it's possibly one of the best examples of the UNIX philosophy.

It's important to note that UNIX the actual implementation is a moving target because of the many versions, just because the designers didn't see something could be achieved in UNIX (resources, time, effort, etc.) or just plain didn't think about it, doesn't mean that it doesn't embody the UNIX philosophy :)

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

#110

Post by jlokier »

Znafon wrote: post #44
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.

> I realize that the UNIX philosophy (everything is a file) is dead Was it ever alive? As far as I know lo0, eth0 and others where never accessible as a file interface and we still rely on them. Is there something to gain to give them a name on the filesystem?

They actually are accessible as a file interface:

  ls /sys/class/net
You can't read and write packets via the interface, but there are configuration knobs and statistics you can access.

I think it's quite messy and inconsistent that some network interface attributes are only in sysfs, and others are only accessible via AF_NETLINK (usually via the "ip" tool). But it's there.

Post reply on HN