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

11–20 of 134 posts

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

#11

Post by simion314 »

roenxi wrote: post #7
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?

The basic problem with X11 is it wraps a whole bunch of things into one software package. So in theory you have to know about fonts, OpenGL, graphics drivers & memory management, the window model and networking simultaneously to configure and run the thing. Wayland is a protocol for a well designed future where all that functionality is broken up into separate pieces of software. Wayland handles the window model and…

The issue is I need the powerfull features, like I have a script that OCR a region of the screen when I press a button (the coordinates depend of the app that runs) so I do not want a GUI provided by the DE to let me capture the screen.

Anyway the issue with Wayland is that it is not ready, the important screen recording feature is yet not here,I seen also some complaints from gamers and their issues are a won't fix, probably when Wayland will be actually ready we will need something to replace it or a Wayland 2 that learned from first attempt mistakes.

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

#12

Post by dyanaraps »

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

Earlier quoted context omitted.

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…

Instead of xdotool, you can use this: https://github.com/ReimuNotMoe/ydotool

Not exactly a 1:1 replacement though:

> This program requires access to /dev/uinput. This usually requires root permissions.

Source: https://github.com/ReimuNotMoe/ydotool#runtime

Edit: I'll also add that only 5~ commands have been implemented so far in ydotool.

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

#13

Post by aloer »

simion314 wrote: post #11
roenxi wrote: post #7

Earlier quoted context omitted.

The basic problem with X11 is it wraps a whole bunch of things into one software package. So in theory you have to know about fonts, OpenGL, graphics drivers & memory management, the window model and networking simultaneously to configure and run the thing. Wayland is a protocol for a well designed future where all that functionality is broken up into separate pieces of software. Wayland handles the window model and…

The issue is I need the powerfull features, like I have a script that OCR a region of the screen when I press a button (the coordinates depend of the app that runs) so I do not want a GUI provided by the DE to let me capture the screen. Anyway the issue with Wayland is that it is not ready, the important screen recording feature is yet not here,I seen also some complaints from gamers and their issues are a won't fix,…

Could you tell us more about the use case here? What do you use the OCR for?

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

#14

Post by roenxi »

shmerl wrote: post #10
roenxi wrote: post #9

Earlier quoted context omitted.

Quoth the wiki 'PipeWire is a rather new multimedia framework by GNOME'. There will be people who don't want to use GNOME frameworks and don't want to use the GNOME window manager. Wayland is enforcing a policy ('don't access other devices graphics output') where it should be providing capability ('an applications graphics output is private by default but that can be configured'). However it looks like the design of…

From what I gather, Pipewire isn't part of Gnome, i.e. it's generic and can be used with any DE. For example, all compositors are using libinput, which replaces legacy ways of X handling input. It's not mandated by the protocol either. So I don't see why they can't use Pipewire for audio and video needs. If anyone wants to make a better alternative to standardize on - they are free to propose it.

But libinput is a freedesktop.org project, ie, supported by the same people who are working on Wayland. It was specifically built to support Wayland.

Pipewire looks like some audio-visual framework for GNOME and GTK apps and while it might be fantastic it is both new and not very comprehensibly advertised. And it will probably be very complicated and involve some rather interesting design issues compared to building something in when the Wayland protocol was created.

We're coming out of a world where the standard used to be "run graphics drivers in userspace!" so any weird compromise is workable (including an audio framework deciding on graphics security policy). But ultimately the idea that a GNOME-sponsored effort is going to be what sorts out the security model for desktop apps is weird. I can't find anything to suggest that Pipewire is intended to be the definitive way to do screen recording, it looks to me like that might be a happy side effect. It wouldn't be surprising if it turns into two or three competing ideas.

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

#15

Post by jchw »

shmerl wrote: post #6
jchw wrote: post #3

Earlier quoted context omitted.

I'm running Sway WM right now, a Wayland compositor that implements an i3-compatible window manager, and in fact working on the code (hopefully merging my first contribution soon.) I'd say the biggest issue is really maturity. I actually find Wayland to be a surprisingly nice piece of software engineering. I don't know if I like the architecture really, but it comes together fairly nicely in the end. For example, the…

I think capturing desktop and screenshots should be addressed by standard Wayland extensions with integration with something like Pipewire as far as I know. I didn't follow the progress of that though. Some details here: https://wiki.archlinux.org/index.php/PipeWire Some features though are surely missing. Such as support for adaptive sync. No one really is pushing that forward. See: https://github.com/swaywm/wlroots…

Like I said... I gave up and bought an AMD card. Not everyone is going to do this. It's a step down from my NVIDIA card.

I think there is still hope. Obviously today's reality is still bleak with signed blobs and plenty of question marks, but I think open-gpu-doc is a sign that NVIDIA does actually want to square away this problem, maybe they're just not sure how.

I do believe NVIDIA is mostly responsible for Wayland's poor adoption, and I firmly believe that this also lead to Wayland not getting as much developer attention as it could've gotten. The fact that one company wields this much power is a serious problem. I kind of understand the hostility Linux kernel developers seem to have towards proprietary drivers under Linux now.

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

#16

Post by simion314 »

aloer wrote: post #13
simion314 wrote: post #11

Earlier quoted context omitted.

The issue is I need the powerfull features, like I have a script that OCR a region of the screen when I press a button (the coordinates depend of the app that runs) so I do not want a GUI provided by the DE to let me capture the screen. Anyway the issue with Wayland is that it is not ready, the important screen recording feature is yet not here,I seen also some complaints from gamers and their issues are a won't fix,…

Could you tell us more about the use case here? What do you use the OCR for?

I suffer of macular degeneration https://en.wikipedia.org/wiki/Macular_degeneration , so I am having issues reading texts , I am using TTS and Zoom features for most applications but the big issue I have is with video games. For open source game engines I can patch them to have the text pushed to my TTS scripts but for closed source game engine OCR or zoom is the only solution but it has a lot of issues.

1 my zoom follows the mouse but this is broken is nome games where the trying to move the zoom area to the edge where the text is would move the camera in game , pausing the game is a solution but some games would put a Pause screen on top of te text I want to read.

The OCR has issues when games use fancy fonts, old games use some pixelated fonts that are impossible to OCR, other games use more artistic fonts that are also hard to OCR, other games use text over semi transp[arent background and it makes hard to separate the text from the background.

For DirectX I am thinking if I could maybe intercept the draw text calls, I am considering making a Stack OVerflow post but I am a bit anxious that I am not sure what the correct title and tags should be and I could get the off topic and the question closed.

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

#17

Post by pcr910303 »

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.

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

#18

Post by shmerl »

jchw wrote: post #15
shmerl wrote: post #6

Earlier quoted context omitted.

I think capturing desktop and screenshots should be addressed by standard Wayland extensions with integration with something like Pipewire as far as I know. I didn't follow the progress of that though. Some details here: https://wiki.archlinux.org/index.php/PipeWire Some features though are surely missing. Such as support for adaptive sync. No one really is pushing that forward. See: https://github.com/swaywm/wlroots…

Like I said... I gave up and bought an AMD card. Not everyone is going to do this. It's a step down from my NVIDIA card. I think there is still hope. Obviously today's reality is still bleak with signed blobs and plenty of question marks, but I think open-gpu-doc is a sign that NVIDIA does actually want to square away this problem, maybe they're just not sure how. I do believe NVIDIA is mostly responsible for Wayland…

Kernel developers are right to push back against blobs. Nvidia is the bad player here.

AMD is doing fine though. I have RX 5700 XT, and besides for some rough edges due to it being very new and drivers still fixing bugs, it's a very good card.

I expect Nvidia usage on Linux to plummet, due to their refusal to provide open drivers. It's already happening, just will take some time for it to drop to the point where they have little influence.

See: https://www.gamingonlinux.com/index.php?module=statistics&vi...

So in the long term it's not a problem.

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

#19

Post by sprash »

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" mantra Wayland has no design philosophy at all. It is also a weak argument to introduce a new protocol. With modern drivers it is rare to experience tearing on X11 and on some occasions it even makes sense to disable vsync (e.g. competitive gaming).

The introduction of Wayland was a mistake because X11 has a huge ecosystem with lot of little programs and a large diverse users base. Almost every Unix OS supported X11 at some point. There is a reason why Intel still stuffs the i368 instruction set in their processors, Microsoft Windows still can execute programs from 1995 and IBM is still able to make money with vastly overpriced mainframes. Successful systems have the tendency to stay and accumulate cruft as a result. The abandonment of X11 will be a heavy blow to the FOSS community (and maybe that is exactly the intend).

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

#20

Post by jdub »

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

X11 and its ecosystem of applications isn't abandoned by Wayland, because you can run an X11 server on Wayland. By all means, debate the merits of Wayland itself, but don't lean on inaccuracies and conspiracy theories.
Post reply on HN