[HN Gopher] X Window System Basics (2014)
___________________________________________________________________
X Window System Basics (2014)
Author : ingve
Score : 114 points
Date : 2023-01-10 17:58 UTC (5 hours ago)
(HTM) web link (magcius.github.io)
(TXT) w3m dump (magcius.github.io)
| dang wrote:
| Related:
|
| _Xplain - Explaining X11 for the rest of us (2017)_ -
| https://news.ycombinator.com/item?id=24197528 - Aug 2020 (89
| comments)
|
| _X Window System Basics (2014)_ -
| https://news.ycombinator.com/item?id=21118633 - Sept 2019 (20
| comments)
|
| _Xplain - Explaining X11 for the rest of us_ -
| https://news.ycombinator.com/item?id=12042548 - July 2016 (44
| comments)
|
| _XPlain - Explaining X11 for the rest of us_ -
| https://news.ycombinator.com/item?id=8019346 - July 2014 (65
| comments)
|
| _Xplain: Explaining X11 for the rest of us_ -
| https://news.ycombinator.com/item?id=6978274 - Dec 2013 (19
| comments)
| tabtab wrote:
| Does anyone know of a project that puts an XML wrapper (markup)
| or command line interface around X Window? That way one can use
| or interface with an X Window "browser" without writing C.
| LtWorf wrote:
| You might want to check dbus... most desktop applications have
| a dbus interface. I normally use qdbus from command line.
| ktpsns wrote:
| XML interfaces are common in toolkits, look at Guile for GTK or
| Qt Quick/QML. One of the ancient X window toolkits was the
| Athena widget set (baked in most X servers,
| https://www.x.org/releases/X11R7.7/doc/libXaw/libXaw.html). I
| don't know from XML interface to design Athena GUIs.
| buescher wrote:
| dtksh did that, more or less. not with xml.
|
| https://www.brendangregg.com/dtkshdemos.html
| throwawaybutwhy wrote:
| Maybe xdotool [0] is what you're looking for.
|
| [0] https://github.com/jordansissel/xdotool/
| [deleted]
| JustSomeNobody wrote:
| Curious and slightly off topic, but does anyone know of a good
| tutorial on writing a basic GUI library (windows, widgets,
| composition, etc)?
|
| I have no intention of writing one in any usable sense, but it
| would be cool to write up a toy one.
| nesarkvechnep wrote:
| Only slightly off topic?
| commandlinefan wrote:
| I continue to be amazed that X is still around. I can sort of
| understand why it was done the way it was done back when it was
| first created (although even then, the concept of running the
| actual code remotely but the X server locally seems strange).
| There _must_ be more efficient ways to organize a graphics
| library now; it seems like X continues to be the Linux standard
| from inertia.
| vermaden wrote:
| Amazed?
|
| I am amazed that people try to force limited and unfinished
| Wayland instead of X11. I recently had RHEL on ThinkPad T14 at
| work - which by default uses Wayland - yet even employer by
| default switches settings to X11 because EVERYTHING works there
| as desired - including screen sharing and/or recording.
|
| ... and for my personal stuff? I have ZERO issues with X11 on
| FreeBSD - why would I switch to Wayland if everything works as
| desired on X11? FreeBSD of course supports Wayland and you can
| use it there if you wish - but I just do not see the point of
| it. I do not have ANY screen flickering or other issues on X11.
|
| Not to mention that A LOT of stuff is X11 only and not ported
| (and never will be) to Wayland.
| BaculumMeumEst wrote:
| The issues with xorg that i'm aware of are that it's awful to
| maintain and that it has security issues like everything
| being able to access your clipboard.
|
| And xwayland exists so porting isn't much of an issue.
|
| But yeah, despite all that i'm on x11 still as well. I need
| to use proprietary nvidia drivers and I don't want to run
| full gnome or whatever to make that run smoothly. I'll
| probably be dead before dwm stops working on an updated
| system.
| woodruffw wrote:
| I don't mean this in a flamey way, but I've always wondered
| what the importance of clipboard isolation is, given how
| bad of a user experience it results in.
|
| I'm a security engineer, and I can't think of many threat
| models in which an attacker can snoop clipboard contents
| but can't do much worse things, which I assume is why
| neither macOS nor Windows has ever bothered with clipboard
| isolation.
|
| (It's entirely possible I'm under-thinking it!)
| kaba0 wrote:
| I don't own nvidia, but from what I read they finally
| managed to have proper DRM support in their drivers which
| was the only limiting factor for Wayland (as opposed to
| nvidia patching your X server binary to run the proprietary
| driver, Wayland in itself only depends on proper linux
| kernel APIs which weren't supported by nvidia for a long
| time)
| odiroot wrote:
| I have T14 (AMD version) with Arch on it. I use Wayland
| because it's the only way to get HiDPI and fractional scaling
| to work well.
|
| Pretty much the only problem I have with it, is lack of good
| screen-recording software. OBS is a bit of an overkill for
| short screen-casts.
| hulitu wrote:
| > I am amazed that people try to force limited and unfinished
| Wayland instead of X11.
|
| The xorg people phylosophy seems to be: if it works, fix it.
| Since xorg forked XFree86 the quality has gone down.
| asveikau wrote:
| I remember using XFree86 in the late 90s and first ~3 years
| of the 2000s. When the X server started changing a lot
| circa 2003 it was really exciting, and I very eagerly
| anticipated those releases. I think Xorg is better than
| XFree86.
|
| Some of the things they did off the top of my head:
|
| * Render extension. This enabled all sorts of things, like
| easier drawing and scaling of pixmaps, or better font
| handling.
|
| * Less monolithic build, phase out imake. This allowed
| iterating various components at different rates.
|
| * Better auto configuration - less need to write a config
| file for the most common configurations.
|
| XCB was also a good idea. I don't think it lived up to full
| potential because interest in writing code for X waned.
|
| I think one thing that was lost to history are some of the
| proprietary X servers, such as those by Sun and SGI. The
| XFree86/Xorg lineage is missing their input.
| kaba0 wrote:
| > I am amazed that people try to force limited and unfinished
| Wayland
|
| Can we just not do this useless flamewar under every similar
| topic's thread? Especially that no, noone wants to force
| Wayland, they want _something_ that is under active
| maintenance, which X11 is not anymore, since every maintainer
| of it left /migrated to Wayland.
|
| > Not to mention that A LOT of stuff is X11 only and not
| ported (and never will be) to Wayland.
|
| Hmm, only if the goddamn maintainers of X11 who came up with
| Wayland thought of that. They could have named it something
| like W11.. no, XWayland!
| spijdar wrote:
| Wayland is a complicated and sore topic for a lot of people,
| but I think I've gained some perspective over time.
|
| From a historical perspective, the "why Wayland?" question is
| incredibly obvious IMO. The old Linux graphics stack
| consisted of the dumb Linux framebuffer and fbcon, and the
| separate Xorg stack with all its DDX/UMS drivers that
| required root-level permissions, and only provided a graphics
| API for ... Xorg. Your options were either Xorg, or the
| framebuffer, which IIRC didn't always support all of the
| available display modes.
|
| Wayland was part of a wider push to rewrite the Linux
| graphics stack, with the new stack of KMS/DRM/DRI3/Mesa being
| a huge improvement over the 2000s Linux GUI stack. This came
| at the cost of old UMS and DRI drivers, making e.g. PowerPC
| Mac GPUs largely useless now (very unstable and incapable of
| suspend-to-RAM), while unifying mode-setting between the
| kernel and userland (no more praying the video card doesn't
| crash when ctrl-alt-f2'ing), also allowing for an arbitrary
| number of shared video buffers to be created (including by
| non GLX video applications) which makes compositors work in a
| not-hacked-together sense, but _also_ allows for e.g.
| hardware video decoders to work in a not-hacky way.
|
| Coupled with the addition of evdev to replace the Xorg DDX
| stuff like all the custom peripheral drivers, and you finally
| had a kernel-level API for accessing your video and input
| hardware. These were all prerequisites for the idea of
| "Wayland", decoupling the video and input layers from the
| display server and creating a low level API for window server
| things, so that you can have both small window servers (e.g.
| wlroots-based compositors) as well as "thick" environments
| (Mutter/KWin-based desktops).
|
| Part of what makes this confusing is a lot of these benefits
| trickled down to Xorg itself. Nowadays evdev (and libinput)
| have replaced the old DDXs on Xorg, and I think most distros
| have switched to using xf86-video-modesetting, which could be
| thought of as "Wayland-style rendering on Xorg", in the sense
| it uses pure DRM and Mesa to render instead of GPU-specific
| DDX drivers.
|
| So Xorg has gotten a lot of the benefits of Wayland's
| development "for free" anyway. This is intentional, as you
| mention, a lot of things will never be ported to Wayland.
| Wayland is not a replacement for X11, but an API for
| implementing the display server at a lower level than X11
| allowed, while allowing us to implement full X11
| compatibility "for free", by embedding Xorg in the form of
| Xwayland.
|
| I think this makes a ton of sense for the majority of
| desktop-environment level compositors like Mutter (GNOME) and
| KWin (Plasma), which were already massive and implemented so
| much of their own functionality outside of Xorg, that it made
| sense to just let them do their own compositing. Same with
| GTK and Qt, which were already doing "their own rendering"
| outside of X.
|
| Didn't mean for this to become an apologetic rant for
| Wayland, but as a "wayland skeptic" myself I feel like most
| anti-wayland arguments miss the forest for the trees (screen
| sharing not working). As an olive branch, though, I'll also
| add I don't think the wayland version of the big compositors
| like Mutter or KWin actually do much for end users, and it's
| pretty shameful how they've been launched with so many bugs,
| with no compelling user story beyond "better scaling" and
| "flicker".
| anthk wrote:
| Xenocara under OpenBSD and Hyperbola don't run as root.
| spijdar wrote:
| True, though it does so using KMS/DRM adapted from Linux
| [0], which I would argue were created in the same spirit
| as Wayland, even if they're not strictly related.
|
| [0] https://marc.info/?l=openbsd-
| cvs&;m=139245772023497&w=2
| robinsonb5 wrote:
| To be fair I don't really care all that much whether my box
| is running something X11-based or something Wayland-based.
| What I care about is whether it can still do today the
| things it could do 15 years ago. I'm finding it extremely
| frustrating that the answer is tending towards "no" - even
| with Xorg - but my impression is that Wayland increases the
| "no" count somewhat.
| tapoxi wrote:
| In the examples of screen sharing and recording, they work on
| Wayland but the application needs to be aware and request
| permission. Zoom and Chrome both support this, AFAIK.
| sprash wrote:
| Actually they don't work "on Wayland". The Wayland protocol
| provides no mechanisms for screen sharing and it is not
| intended that it ever will. Screen sharing has to be done
| by external protocols that are either compositor specific
| or using a somewhat standardized dbus protocol that is
| completely separate from Wayland.
| badsectoracula wrote:
| > although even then, the concept of running the actual code
| remotely but the X server locally seems strange
|
| I don't think it is strange when you consider that terminals
| (including some with graphical capabilities) where common back
| in the day, with multiple terminals connecting to a single
| beefy computer.
|
| In fact there were even dedicated X terminals (basically cheap
| computers running an X server) in the early 90s:
|
| https://en.wikipedia.org/wiki/X_terminal
| JackFr wrote:
| I had a Tektronix dumb X terminal die with literal black
| smoke pouring out the back of it at work circa 1992. It
| turned out great cause I got a Sun as a replacement.
| digitalsankhara wrote:
| Seems logical to me when the technology of the era is taken
| into account. Having the application code running on the most
| powerful machine i.e the server and then sending the graphics
| commands to be rendered on your specialist graphics workstation
| would make sense. I don't know enough about the actual
| efficiency of the X Window protocol though.
|
| But don't we model this type of protocol today with the web?
| kaba0 wrote:
| Well, the web can shift rendering between server and client
| side depending on the developers' needs, but graphics is done
| mostly on the client side with their hardware. And while
| things tend to cycle between "centralized" then "edge
| computing" and back, graphics does make more sense to stuck
| to the client device, especially with ever bigger screen
| resolutions/color spaces/refresh rates paired with low-
| latency requirements.
| amelius wrote:
| > There must be more efficient ways to organize a graphics
| library now
|
| You can perhaps write a more efficient graphics library now,
| but what if in a few decades the servers are way more powerful
| again compared to the clients/terminals?
| johnny22 wrote:
| what is "standard"? The default way to display/interact with
| gui applications on many distros is no longer X based.
| badsectoracula wrote:
| I don't think that is the case. Pretty much all distros have
| an X server available. A few distros install some desktop
| environment out of the box and some of those use a desktop
| environment that uses a Wayland compositor instead of an X
| server using the kernel graphics APIs, but even in those
| environments there is an X server (XWayland) right above the
| compositor (technically you can have a Wayland setup without
| XWayland but that'd just make the desktop less useful so i
| don't think there is any distro doing that by default -
| though even if there is, i don't think it'd be majority).
|
| But TBH i think most distros either use X server based
| environments or do not provide a default OOTB environment at
| all.
| johnny22 wrote:
| i never said they don't have an x server available. They
| all do. All of the general purpose ones that provide
| wayland sessions still provide an x11 fallback session
| where both are possible, and of course for those DE/WM
| where wayland based solutions don't exist.
|
| RHEL has deprecated xorg-server and will provide support
| for those x11 DE/WM via rootful xwayland sessions.
| throwawaybutwhy wrote:
| Not from inertia, but from the overwhelming hubris of those who
| aimed to supplant it with something new.
|
| IPv6 and Wayland have a lot in common.
| eikenberry wrote:
| Wayland seems more in line with Python3 than IPv6. With Valve
| now helping with the development and nearly all other issues
| addressed... seems it will be the default on all major
| distros within the next few years.
| stonogo wrote:
| X runs on so many more platforms than Wayland, even if
| every single Linux distribution switched tomorrow there
| would still be good reason to support X. Python3 is
| strictly an improvement on every platform, I don't think
| they're analogous because there really is no good reason to
| keep Python2 around.
| kirbyfan64sos wrote:
| > X runs on so many more platforms than Wayland [...]
| Python3 is strictly an improvement on every platform, I
| don't think they're analogous because there really is no
| good reason to keep Python2 around
|
| X runs on more platforms than Wayland because...it was
| ported to them. Just like things use Python 3 because
| they were ported to it.
|
| This is also understating the reach of X I think: it's
| widely used in the embedded world, is seeing increasing
| support in BSDs, and has even been used on macOS
| (https://github.com/owl-compositor/owl). People have even
| used it to embed an entire compositor inside a GTK app
| (https://github.com/alexlarsson/wakefield).
|
| That isn't to say that libwayland has a lot of Linux-isms
| in it, but afaik they're not really _structural_ as much
| as there is lack of interest to generalize things more.
| Heck, the protocol-oriented architecture would even make
| it easier for anything Linux-esque to be removed in favor
| of alternative protocols.
| kaba0 wrote:
| Wayland is actually much better for embedded use cases
| and is actively used by several car companies in their
| car displays.
| yyyk wrote:
| IPv6 maybe, but Wayland's protocol choices were IMHO caused
| by that part of the UI stack getting nigh zero resources. So
| every iteration from XFree86 ended up deprecating and
| removing features, and Wayland turns not having features into
| a 'feature'; Actual standards move into Desktop environments
| where (some) investment was happening. The standard following
| economics, as it were.
| silon42 wrote:
| system UI is not a simple graphics library... that's a huge
| oversimplification...
| erik_seaberg wrote:
| In this era I have access to a lot of computers. I don't want
| to run _everything_ on the one under my desk that happens to
| have a GPU. It's kind of crazy that popular frameworks are
| getting worse at remote rendering, and it's one reason backend
| services are switching to Javascript and Wasm frontends.
| bmacho wrote:
| Isn't the concept of remotely running graphic applications more
| important now than ever before? Everything runs through WSL,
| and different containers and virtual machines and emulators
| now.
| yamtaddle wrote:
| I dunno. I only recently tried an X-Client with persistent
| sessions (that is, you can disconnect then reconnect later and
| all your stuff will still be running, right where you left off)
| and if it didn't feel like a kinda-janky barely-used-and-
| supported afterthought of a project, it'd have felt like the
| most-correct way to work in this, the year 2023 (well, I first
| tried it in like 2020, I guess).
|
| ... and I'm a happy Mac user, haven't been deep in Linux-on-
| the-Desktop land in over a decade, and still felt that way.
| Koshkin wrote:
| > _X server locally seems strange_
|
| Why does it seem strange? It's the same as what you do when you
| run, say, a web browser locally. (The only difference is, we do
| not call the browser "web _server_. ")
| simplicio wrote:
| Feel like HN should start a collection to pay the author to
| finish the series, since it shows up here every few months, but
| the writer has (understandably) not had the time/inclination to
| complete it.
| Jasper_ wrote:
| Author here. I left the Linux world 6 years ago, though my
| passion for making this kind of educational content has not
| faded. These days, I work in the games industry, and make
| videos explaining game graphics concepts.
|
| https://www.youtube.com/watch?v=By7qcgaqGI4
|
| I left a small retrospective the last time this got posted
| here. I believe what I'm doing now is far more interesting.
| https://news.ycombinator.com/item?id=21041340
| trashburger wrote:
| Make sure to read the chapters after it by clicking the right
| arrow too, it gets better.
| MonkeyClub wrote:
| Indeed the site is a little treasure trove!
|
| You can get to all the contents here:
| https://magcius.github.io/xplain/article/index.html
|
| Summary of the contents: i. Introduction &
| Table of Contents ii. X Window System Basics iii.
| Advanced Window Techniques iv. Adding Transparency
| v. Regional Geometry vi. Basic 2D Rasterization
___________________________________________________________________
(page generated 2023-01-10 23:01 UTC)