What process created this X11 window?(unix.stackexchange.com)
unix.stackexchange.com
What process created this X11 window?
https://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window
83 comments
Why is x11 so backwards?
On Wayland, each window is a composer, each component that makes up a screen is a compositor. Don't mid them up. Simply put each window manages their own process tree as its much cleaner. Its very simple. What you need to do is simply install dbus-systemd and issue SummonPoettering which will give you a clean docker workspace. Simply put this is far superior to X11. In short on Wayland, you only need to push one button to kill an errant window - the power button
On Wayland, each window is a composer, each component that makes up a screen is a compositor. Don't mid them up. Simply put each window manages their own process tree as its much cleaner. Its very simple. What you need to do is simply install dbus-systemd and issue SummonPoettering which will give you a clean docker workspace. Simply put this is far superior to X11. In short on Wayland, you only need to push one button to kill an errant window - the power button
> Why is x11 so backwards?
Because it was built in a different time. Back in the 80s and early 90s, X11 provided a way for institutions and companies to mix-and-match their hardware and software environments, each with different capabilities. They would have big iron running expensive software and cheap(er) terminals that could display those applications across a campus.
In a university environment, before there was a PC and network in every dorm room, before laptops were a thing, this was awesome. You could walk up to any workstation or X11 terminal on campus, and immediately have access to all of your applications, files, and everything else. And when PCs and networking came to the dorms, you could get an X server for your PC and do the same.
But those days are long past; the networking use case, which was one of the most important aspects of X11, is pretty much no longer relevant. It's really surprising that Wayland still hasn't completely taken over, and they still haven't figured out how to handle certain interprocess communication that would allow screen sharing and other common desktop functionality.
Because it was built in a different time. Back in the 80s and early 90s, X11 provided a way for institutions and companies to mix-and-match their hardware and software environments, each with different capabilities. They would have big iron running expensive software and cheap(er) terminals that could display those applications across a campus.
In a university environment, before there was a PC and network in every dorm room, before laptops were a thing, this was awesome. You could walk up to any workstation or X11 terminal on campus, and immediately have access to all of your applications, files, and everything else. And when PCs and networking came to the dorms, you could get an X server for your PC and do the same.
But those days are long past; the networking use case, which was one of the most important aspects of X11, is pretty much no longer relevant. It's really surprising that Wayland still hasn't completely taken over, and they still haven't figured out how to handle certain interprocess communication that would allow screen sharing and other common desktop functionality.
I’m still predicting that Wayland will become an implementation detail of web browsers and some games. It doesn’t make sense for every app to render pixels in software and stream them from a datacenter, not for every desktop to have its own copy of every app.
While true, it wasn't the only protocol for doing that, just the one that won mostly due to OSF/Motif politics, when GNU/Linux came to be that was already pretty much settled.
I felt my comment was so dripping with sarcasm nobody would miss it. SummonPoettering??? Yet like a moth to a flame you missed the point and jumped right into the reasons x11 sucks
The more on-point sarcasm is, the harder it is to distinguish from the actual proponents' views.
In the future, someone will (re)invent wayland-compose.yaml and announce that as the second-best thing after sliced bread. Imagine that technology - each window is a separate container! Our ancestors would be so proud. Then, you start your browser via "wayland-compose up" and that will load 50 additional containers via dbus-systemd, because "that is the only proper way" to run your application.
And we thought chrome was genius to introduce one process per tab. One container per tab, its better than one VM per tab.
Under Wayland with Gnome (it's gnome-specific), I recently learned you can kill windows by using Looking Glass:
// 1. Open looking glass: Alt+F2 > lg
// 2. Use picker to pick window (button on the top left corner).
// 3. Now an object r(0) of type MetaSurfaceActor is available in the
// gjs console (or some other number if you've already used it).
// To get pid:
r(0).get_parent().get_parent().get_meta_window().get_pid()
// To kill window and process:
r(0).get_parent().get_parent().get_meta_window().kill()
...wait, does Wayland not have a drop in replacement for xkill?
Some weeks ago I searched for a more general solution that doesn't depend on the compositor and doesn't need root (i.e. an xkill replacement), but I didn't find one.
As a frequent user of xkill I was surprised by that too, but I remember reading somewhere that making a terminal application kill another application's window is not allowed by design. Reusing a sibling commenter's analogy, it's kind of like some javascript functions in the browser can only be triggered by user actions for security reasons.
The compositor, however, is allowed to kill the windows it's showing. So if you want to kill a window, you can ask the compositor to do it for you. Gnome, KDE [0], sway [1], etc.. each expose this functionality in a way that differ between each other.
[0] https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xki...
[1] https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_t...
As a frequent user of xkill I was surprised by that too, but I remember reading somewhere that making a terminal application kill another application's window is not allowed by design. Reusing a sibling commenter's analogy, it's kind of like some javascript functions in the browser can only be triggered by user actions for security reasons.
The compositor, however, is allowed to kill the windows it's showing. So if you want to kill a window, you can ask the compositor to do it for you. Gnome, KDE [0], sway [1], etc.. each expose this functionality in a way that differ between each other.
[0] https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xki...
[1] https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_t...
And eventually KDE, Gnome, and so forth will develop a shared layer on top of Wayland to handle such core functions can call them Wprops, they'll all implement the same _NET_WAYLAND_HINTS and a new group freewayland.org will come together to standardize it. Then waykill will work globally
But of course by then (late 2030s) we as an industry will appreciate that Wayland has deep unfixable flaws and nobody is willing to maintain it and everyone should switch to ... V-something... let's say "Vineyard", the new graphical system that everyone agrees we should switch to ASAP because this time we got it right;)
In the 2030s everyone will finally acknowledge the sheer elegance of Arcan ( www.arcan-fe.com ) and admit out loud that Wayland's "just use a GUI toolkit!" was cope for Wayland being a reflexively underspecified protocol, an unfortunate result of its devs suffering from X11-PTSD.
Vineyard I can actually see, after Martha's Vineyard -- following the Red Hat trend of naming system components after Massachusetts towns (Wayland, Weston, Dracut, Plymouth...).
Lol. You must be new to SW development "good practices". If they don't "release" a new library version every second year, "god" will strike them. /s
Wayland doesn't have the kind of abstraction that would allow that, partly since it would make it very hard to guarantee perfect frame rendering.
A lot of what X11 does is instead handled by Wayland "compositors", they deal with almost all such policy logic. This is largely the same situation as on Windows or macOS, which Linux desktops are finally starting to catch up to.
A lot of what X11 does is instead handled by Wayland "compositors", they deal with almost all such policy logic. This is largely the same situation as on Windows or macOS, which Linux desktops are finally starting to catch up to.
I can't tell what level of parody we're at; if we're currently being serious, why would xkill or equivalent make rendering any harder than a normal close event?
It would require that Wayland be aware of internals of the "compositor". Instead of that, Wayland is only aware of surfaces, which it can guarantee can be stitched together within a certain time budget. Hence none of the tearing that is unavoidable with X11.
A window close event goes to the "compositor" of a surface, without being aware of which PID may have caused what is currently rendered on that surface.
Windows and macOS do the same, if only because they have a single "compositor"/window manager.
A window close event goes to the "compositor" of a surface, without being aware of which PID may have caused what is currently rendered on that surface.
Windows and macOS do the same, if only because they have a single "compositor"/window manager.
I don't think it's parody. Wayland is just so kafkaesque not even windows know their own contents.
Windows know their own contents, but Wayland doesn't. "Compositors" do know which PID has which window, though. Hence why there are "compositor"-specific alternatives to xkill.
Simply jump into a Javascript runtime and run some functions from your runner! BTW your entire desktop is just an electron app rendering Wayland in WebGL.
[deleted]
> Simply put each window manages their own process tree as its much cleaner. Its very simple.
And not correct: Processes can have multiple windows. Or no windows.
And not correct: Processes can have multiple windows. Or no windows.
Not if running on Ubuntu! They've replaced Docker with Snap, so you will have to dbus into ~/snap and patch the hook into the package. Of course, this will not work with the inferior Flatpak apps (which you shouldn't be using anyway as they are buggy and not as cool as snaps).
I left Ubuntu because of snap, still haven't heard anything positive so seems like the right move so far.
Unironically: yeah, I've switched to Debian everywhere and never looked back.
[deleted]
I suspect this is satire.
The fact 5 commenters did not understand it shows how willingly people will put up with the limitations of their software and diss the software they don't like.
Surely the summoning of Leinart Poettering's spirit to find dead Pids in Waylands Hades was a dead giveaway
Surely the summoning of Leinart Poettering's spirit to find dead Pids in Waylands Hades was a dead giveaway
I think it was funny, despite how much X11 has annoyed me over the years or how much I appreciate the correctness goals of both systemd and Wayland.
> Why is x11 so backwards?
Hasn't it been pretty much ossified for the last 30 years?
Hasn't it been pretty much ossified for the last 30 years?
Well a definitive press of the power button seems the good way of killing a window, as such notion simply shouldn't exist. One could also argue that those who complains in sarcasm about such unnecessary longings should do the same.
High grade sarcasm? You had me going until the power button part.
So wild, I googled this exact thing yesterday and got to the same stackoverflow post. And now it's on the first page of HN.
This has happened to me a few times with HN.
I suspect HN is really run by a hyper-intelligent A.I. which is guiding us all to a brighter future.
I suspect HN is really run by a hyper-intelligent A.I. which is guiding us all to a brighter future.
Nah someone with Wikipedia database access probably looks for obscure article hits and submits them to HN for the karma.
Or a phone-home keylogger
dang?
You're discounting billions of people to whom this didn't happen, because of which they didn't make a HN comment about it.
I think he was just making a joke
[deleted]
X11 is a network protocol. The process which created this X11 windows could be on a different box, running in the kernel or have the whole X11 exchange replayed from the magnetic tape.
Presumably which of these states of affairs pertains to a specific window is, though, at some level knowable. The question of which process created the window is not necessarily bounded to ‘processes running in user space on this machine right now’, but something created it.
And 99% of the time the answer will be a locally running process, which makes it a highly pertinent question even without the caveats.
It’s not clever to point out that a question may not have a simple answer and therefore to reject the question as flawed.
And 99% of the time the answer will be a locally running process, which makes it a highly pertinent question even without the caveats.
It’s not clever to point out that a question may not have a simple answer and therefore to reject the question as flawed.
From a 2020's perspective, X11 is deeply weird.
It was written back when huge enormous servers were the only systems with enough oomph to do anything useful, and those servers had 128mb of ram (think of something like a sun 3/480 with a 33mhz 68030).
It was common to have a room of X terminals each with 1-8mb of ram for a 15-19 inch display (with 1-8bit color). In that context, everything ran on another system, often you'd have processes running on several different systems and you'd have to be careful about managing authorization otherwise people would figure out your DISPLAY and run their programs against your X terminal (innocuous, like 300 Xeyes programs or malicious like a keyboard snooper, depending on where and when).
In 2020 this whole scenario sounds absurd, but it was the way of things from when X11 was designed and through the first 15 years of X being a thing.
In some ways, the question is like asking "what is the process ID that generated this http response?"
[edited to add the analogy]
It was written back when huge enormous servers were the only systems with enough oomph to do anything useful, and those servers had 128mb of ram (think of something like a sun 3/480 with a 33mhz 68030).
It was common to have a room of X terminals each with 1-8mb of ram for a 15-19 inch display (with 1-8bit color). In that context, everything ran on another system, often you'd have processes running on several different systems and you'd have to be careful about managing authorization otherwise people would figure out your DISPLAY and run their programs against your X terminal (innocuous, like 300 Xeyes programs or malicious like a keyboard snooper, depending on where and when).
In 2020 this whole scenario sounds absurd, but it was the way of things from when X11 was designed and through the first 15 years of X being a thing.
In some ways, the question is like asking "what is the process ID that generated this http response?"
[edited to add the analogy]
> In 2020 this whole scenario sounds absurd
It's not really absurd at all. In fact, the increase in processor speed, core count and installed RAM means that it even more likely that in a given context, a single desktop computer system has far more capacity than a single user needs.
So, you extend the number of users that can utilize that capacity by sitting them in front of an X Terminal, which from their perspective is just like sitting in front of the "real" monitor of the machine.
This doesn't make sense for gamers, compile-happy developers or data crunching, but then this model never made sense for those use cases. But a dentist's office with a central desktop and 8 users? You just don't need 8 computers - 1 computer plus 7 or 8 X Terminals is far better use of resources.
It's not really absurd at all. In fact, the increase in processor speed, core count and installed RAM means that it even more likely that in a given context, a single desktop computer system has far more capacity than a single user needs.
So, you extend the number of users that can utilize that capacity by sitting them in front of an X Terminal, which from their perspective is just like sitting in front of the "real" monitor of the machine.
This doesn't make sense for gamers, compile-happy developers or data crunching, but then this model never made sense for those use cases. But a dentist's office with a central desktop and 8 users? You just don't need 8 computers - 1 computer plus 7 or 8 X Terminals is far better use of resources.
A random piece of junk refurbished dell small computer from amazon with a windows 10 pro license is $200. It's more powerful than every single computer I administered from 1990-2005, put together.
What you say is true -- they don't really need the power, but golly they've got it anyhow.
What you say is true -- they don't really need the power, but golly they've got it anyhow.
> From a 2020's perspective, X11 is deeply weird.
X11 is a distributed systems non-meshed networking protocol, that outputs to screens as a side effect.
Knowing about Erlang dist and figuring out how to do X11 a few years ago, everything makes a lot of sense. Except for xlib. xlib is a bit better now, but it turns a pretty decent (but certainly not without flaws) async protocol and implements blocking synchronous calls... And then most toolkits were based on that. Sometimes you really do need to wait for a reply, but so many things don't need it, and all the waiting makes actually networked X much less usable.:(
X11 is a distributed systems non-meshed networking protocol, that outputs to screens as a side effect.
Knowing about Erlang dist and figuring out how to do X11 a few years ago, everything makes a lot of sense. Except for xlib. xlib is a bit better now, but it turns a pretty decent (but certainly not without flaws) async protocol and implements blocking synchronous calls... And then most toolkits were based on that. Sometimes you really do need to wait for a reply, but so many things don't need it, and all the waiting makes actually networked X much less usable.:(
Why is it absurd? I use the remoting feature all the time - got probably 10 remote windows being displayed from various machines across the network right now.
Multi-user graphical computing seems to forever sit just outside the more common use case lexicon.
Being able to ask another machine to run something and display it where you are is a seriously great feature.
These days I have largely given up. Too many just don't see it. Sad day.
One of my favorite X11 setups was engineering CAD software for about 30 users. I had a beefy SGI running the program and data management system.
No user could ever touch that data except through the program. Better, the data goes where it is supposed to go with the user more concerned with just doing the work with few worries.
One happy side effect was users were largely free to run what they wanted as their desktop computer. As long as a respectable X server was available for their machine, they were good to go.
Being able to ask another machine to run something and display it where you are is a seriously great feature.
These days I have largely given up. Too many just don't see it. Sad day.
One of my favorite X11 setups was engineering CAD software for about 30 users. I had a beefy SGI running the program and data management system.
No user could ever touch that data except through the program. Better, the data goes where it is supposed to go with the user more concerned with just doing the work with few worries.
One happy side effect was users were largely free to run what they wanted as their desktop computer. As long as a respectable X server was available for their machine, they were good to go.
You’re aware that web browsers have filled that role pretty effectively, right?
Sort of.
Having run high 3nd X CAD modeling applications on SGI, for example, browser stuff seems clunky and anything really performant seems to load executables locally.
That said, yes! Browsers act a lot like X servers do.
What I am getting at here is not entirely a technical problem.
Most computers offered a single user, eventually multi tasking graphical environment.
The computers running a well implemented X window system offered multi user graphical computing. It could and often was run as a single user graphical environment too.
X had everything compartmentalized, and that allowed a sysadmin to set the computing up any way that made sense.
Once, just for fun, I had one machine serving up fonts, another doing window management, yet another serving the graphics to the user, another one sharing files to another one running the application!
5 machines all contributing to any number of graphical users, and in my toy, fun case, that was two users. One user was me, and I was using an sgi, and the other Windows 2000. Was kind of fun to see their face as the familiar application looked the same on his windows box as it did on IRIX
Two clicks on an icon, or a command given and "the application" happened on whatever machine was serving up graphics.
Having run high 3nd X CAD modeling applications on SGI, for example, browser stuff seems clunky and anything really performant seems to load executables locally.
That said, yes! Browsers act a lot like X servers do.
What I am getting at here is not entirely a technical problem.
Most computers offered a single user, eventually multi tasking graphical environment.
The computers running a well implemented X window system offered multi user graphical computing. It could and often was run as a single user graphical environment too.
X had everything compartmentalized, and that allowed a sysadmin to set the computing up any way that made sense.
Once, just for fun, I had one machine serving up fonts, another doing window management, yet another serving the graphics to the user, another one sharing files to another one running the application!
5 machines all contributing to any number of graphical users, and in my toy, fun case, that was two users. One user was me, and I was using an sgi, and the other Windows 2000. Was kind of fun to see their face as the familiar application looked the same on his windows box as it did on IRIX
Two clicks on an icon, or a command given and "the application" happened on whatever machine was serving up graphics.
Indeed -- web browsers are very comparable to X -- especially with things like web sockets or streaming media.
Which is why I offered that the question "what process is generating my window" is comparable to "what is the PID of the process that generated this HTTPs response?"
Which is why I offered that the question "what process is generating my window" is comparable to "what is the PID of the process that generated this HTTPs response?"
I feel that using a browser with cloud shell alongside some cloud instances is a time travel to how I was doing development on the university computing center and my years of dotcom wave.
The more things change, the more they stay the same.
The more things change, the more they stay the same.
do you use ssh -XC these days? It's way faster than the classic
DISPLAY=somewherelse:0 application&
Yeah, ssh's management of the X authorization tokens and managing the display stuff was one of the killer features of ssh over things like kerberized telnet or rsh. Another really nice feature of it was that it didn't have any of the idiotic user count enforcement nonsense that was default on a "workstation" licensed ultrix system, where you couldn't have more than 2 people logged into the system without the more expensive license.
Compression's nice - especially for X, and X over ISDN.
Compression's nice - especially for X, and X over ISDN.
> otherwise people would figure out your DISPLAY and run their programs against your X terminal
This was always good for fun gags. In the 1990s I worked at a company where all the developers used X terminals on an HPUX host. If you were bored you could run little programs that made all the windows on someone else's terminal melt, or flip around, etc.
This was always good for fun gags. In the 1990s I worked at a company where all the developers used X terminals on an HPUX host. If you were bored you could run little programs that made all the windows on someone else's terminal melt, or flip around, etc.
Things like this also worked in the small NeXT lab we had at UW-Seattle. Including, um, sound.
Which is why my login script on the university lab disabled xhost for those funny guys.
> In 2020 this whole scenario sounds absurd
Why ? I use Citrix at work in 2023 and nobody thinks it absurd to run the program on another computer and display it on yours.
Except the wayland developers (last i heard). /s
Why ? I use Citrix at work in 2023 and nobody thinks it absurd to run the program on another computer and display it on yours.
Except the wayland developers (last i heard). /s
For the most part things these days are all "stuff on your screen is stuff running on your computer" or "stuff in this window is stuff running on that computer"
There are definitely ways of "this program/window is on that computer / that program/window is that computer" but getting to that point requires some effort, rather than it just being "the way everything works"
With windows, or macos, or even X on linux, the vast majority of things displayed on your screen are on the computer that's within 3 feet of you, other than if you're running a "remote desktop protocol" sort of session.
There are definitely ways of "this program/window is on that computer / that program/window is that computer" but getting to that point requires some effort, rather than it just being "the way everything works"
With windows, or macos, or even X on linux, the vast majority of things displayed on your screen are on the computer that's within 3 feet of you, other than if you're running a "remote desktop protocol" sort of session.
The majority of things displayed on my screen are in a datacenter, which is sending rendering instructions to a window server on my desktop. But now the rendering instructions are in Javascript and the window server also browses hypertext.
I find Windows Remote Virtual Desktop to be pretty useful for running remote things. I'm sure it's just RRP under the hood but the UI integration is nice.
On enterprise consulting using remote VMs is quite common, due to security issues.
Right -- but the notion that each window on your system is managed by some random process running on a random remote system, and it's all seamlessly integrated, is just not a normal idiom today.
You can run a remote window in an RDP session, etc, but it's different from X where the server may be the only processing running on the system you're sitting in front of and everything else is a melange of remote systems. Even a chromebook -- the UI is driven by stuff on the "local" computer.
With X, I can run a window manager on one host, and a mixture of random windows spread across as many remote hosts as I have open windows. Plan9 is similar, but for every other modern GUI / OS setup there's a "local first" mind set. Sure, you can do things in a totally different way but those are largely the exceptions.
You can run a remote window in an RDP session, etc, but it's different from X where the server may be the only processing running on the system you're sitting in front of and everything else is a melange of remote systems. Even a chromebook -- the UI is driven by stuff on the "local" computer.
With X, I can run a window manager on one host, and a mixture of random windows spread across as many remote hosts as I have open windows. Plan9 is similar, but for every other modern GUI / OS setup there's a "local first" mind set. Sure, you can do things in a totally different way but those are largely the exceptions.
"And 99% of the time the answer will be a locally running process"
Depends on the environment - for years I used either an HP X terminal or a PC running an X server and the one thing I could be confident about in both cases was that the process wasn't running locally.
Mind you - that wasn't recently!
Depends on the environment - for years I used either an HP X terminal or a PC running an X server and the one thing I could be confident about in both cases was that the process wasn't running locally.
Mind you - that wasn't recently!
The posed question addresses this in the second paragraph, after the very short first paragraph.
>The easiest way to check who that window belongs to is to run XKillClient for it i.e.: xkill -id 0x1600045 and see which process just died. But only if you don't mind killing it of course!
But but but what does xkill use internally to figure this out. Can we just use that?
But but but what does xkill use internally to figure this out. Can we just use that?
That's not mapping a PID to the window though - it's just destroying a window ID and seeing what happens to error out - which might not happen if the app was written to handle the window being destroyed outside it's control, or it's running on a different machine where you won't see any error output/a process dying.
https://gitlab.freedesktop.org/xorg/app/xkill/-/blob/master/...
It literally is using XKillClient - https://linux.die.net/man/3/xkillclient
You can kill the connection of another client if you know its id. That's one of the reasons why we love X11 so much.
Another way, as josefx mentioned, is to kill the PID from _NET_WM_PID window property. This is often used by window managers when they offer to kill an unresponsive application.
It literally is using XKillClient - https://linux.die.net/man/3/xkillclient
You can kill the connection of another client if you know its id. That's one of the reasons why we love X11 so much.
Another way, as josefx mentioned, is to kill the PID from _NET_WM_PID window property. This is often used by window managers when they offer to kill an unresponsive application.
Funnily enough, this is how I usually figure out who's using a long running, but unknown server process.
Kill it and quietly listen to see if anyone in the office immediately screams. If so, quickly restart it and log out. Otherwise move on with your day, and wait for any angry emails.
Kill it and quietly listen to see if anyone in the office immediately screams. If so, quickly restart it and log out. Otherwise move on with your day, and wait for any angry emails.
Quite sure it just uses _NET_WM_PID and fails if it isn't there. At least as far as I remember I had issues terminating my own application with xkill until I set the _NET_WM_PID myself, the framework I used only did the bare minimum to get a window on the screen.
crotchfire(1)
With XEmbed, what may look like a single window is actually multiple windows all managed by different processes with their own render loops.
Speaking of XEmbed, many years ago, we had an application that ran complicated visualization pipelines. We wanted to add a modern GUI around it to configure it and provide interaction. We didn't have the ability to rewrite the original application, so we wrote a Gtk GUI and used XEmbed to embed the other process in it, then used a unix socket to send commands back and forth. To the user, it was seamless and worked really well!