Re: RFC: automatic _NET_WM_PID setting for local clients
On Tue, 23 Jul 2019 13:57:01 -0700 x...@pengaru.com said: it'd be much more reliable to set _NET_STARTUP_ID to the content of whatever the DESKTOP_STARTUP_ID env var has and enforce this in xlib itself. this can be inherited down the chain through your launching/containers/whatever and passed in for that launch instance. assuming your wm of course can do this and track every launch instance it started off and map it back to that instance... but it can know reliably then "THIS action of launching here resulted in that window over there". much better than _NET_WM_PID because the pid here may not be the pid of whatever was forked - but some other child process or even unrelated other pid. > Hello folks, > > I'd like to propose that Xorg set the _NET_WM_PID property on new > windows for local clients @ window create time whenever possible. > > This is something I added localy years ago to more reliably have this > property set with uncooperative clients that didn't set it. My window > manager integrates client process monitoring and relies on this property > for acquiring the PID of connected clients. > > At the time, it was just a few X clients that were problematic, stuff > like xpdf and other smaller programs using less popular toolkits or no > toolkit at all. It wasn't such a big deal, so I promptly forgot about > it and stopped building my own Xorg debs with the patch, living with the > absent monitoring overlays on those windows. > > Fast-forward to today; I'm using systemd-nspawn for running X clients - > particularly network-facing clients like FireFox where I _strongly_ > prefer isolating the client from accessing things like my home directory > for obvious reasons (ssh keys, etc). > > These programs are cooperative and set _NET_WM_PID, but the PID they set > is from the perspective of the container namespace. The display server > is running in the global host namespace, where this PID has zero > relevance. The same goes for my window manager, it to runs in the > host's namespace, so when it gets this PID and tries to monitor the > process subtree rooted at that PID in /proc, it either finds nothing or > the entirely wrong tree. > > So again I'm wishing the display server would just set this property for > local clients immediately when creating the window, which would not only > make the property more reliable but now it would also set it from the > PIDNS of the Xorg server, that I would argue is far more meaningful. > > I happened to still have the old patch I was using to do this back in > the day, and have attached it as-is for discussion purposes. > > Thanks, > Vito Caputo -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
RFC: automatic _NET_WM_PID setting for local clients
Hello folks,
I'd like to propose that Xorg set the _NET_WM_PID property on new
windows for local clients @ window create time whenever possible.
This is something I added localy years ago to more reliably have this
property set with uncooperative clients that didn't set it. My window
manager integrates client process monitoring and relies on this property
for acquiring the PID of connected clients.
At the time, it was just a few X clients that were problematic, stuff
like xpdf and other smaller programs using less popular toolkits or no
toolkit at all. It wasn't such a big deal, so I promptly forgot about
it and stopped building my own Xorg debs with the patch, living with the
absent monitoring overlays on those windows.
Fast-forward to today; I'm using systemd-nspawn for running X clients -
particularly network-facing clients like FireFox where I _strongly_
prefer isolating the client from accessing things like my home directory
for obvious reasons (ssh keys, etc).
These programs are cooperative and set _NET_WM_PID, but the PID they set
is from the perspective of the container namespace. The display server
is running in the global host namespace, where this PID has zero
relevance. The same goes for my window manager, it to runs in the
host's namespace, so when it gets this PID and tries to monitor the
process subtree rooted at that PID in /proc, it either finds nothing or
the entirely wrong tree.
So again I'm wishing the display server would just set this property for
local clients immediately when creating the window, which would not only
make the property more reliable but now it would also set it from the
PIDNS of the Xorg server, that I would argue is far more meaningful.
I happened to still have the old patch I was using to do this back in
the day, and have attached it as-is for discussion purposes.
Thanks,
Vito Caputo
--- xorg-server-1.12.4/dix/window.c 2012-05-17 10:09:02.0 -0700
+++ xorg-server-1.12.4.hacked/dix/window.c 2014-06-04 18:54:33.570855708
-0700
@@ -840,6 +840,20 @@
event.u.createNotify.override = pWin->overrideRedirect;
DeliverEvents(pParent, , 1, NullWindow);
}
+
+if (pScreen->root == pParent) {
+/* top-level windows with local connections can reliably get
_NET_WM_PID set by the server */
+LocalClientCredRec *lcc;
+if (GetLocalClientCreds(client, ) != -1)
+if (lcc->fieldsSet & LCC_PID_SET) {
+Atom prop;
+
+prop = MakeAtom("_NET_WM_PID", strlen("_NET_WM_PID"), TRUE);
+dixChangeWindowProperty(client, pWin, prop,
+XA_CARDINAL, 32, PropModeReplace,
+1, >pid, FALSE);
+}
+}
return pWin;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Mon, 2019-07-22 at 12:53 -0400, Felix Miata wrote: > No joy: > (EE) TSENG(0): No valid Framebuffer address in PCI config space; > > Does this mean the ET6100 needs manual configuration of PCI Bus ID? Other? I think it means the driver is broken, now. Repairable, but. Specifically: > [72.334] (WW) Falling back to old probe method for tseng If we ever see this for a PCI device, where the driver subsequently binds and tries to initialize, then something has probably gone wrong. In this case it's that the tseng driver lacks a pci-specific probe method (the PciProbe slot in DriverRec), and the "old" probe method seems not to find the corresponding PCI device descriptor. So by the time we hit here: https://gitlab.freedesktop.org/xorg/driver/xf86-video-tseng/blob/master/src/tseng_driver.c#L883 PCI_REGION_BASE() returns NULL here since the device descriptor is empty, and the driver throws its hands up in despair. But the real descriptor _does_ correctly describe the video memory BAR: [72.041] (--) PCI:*(0:0:10:0) 100c:3208:: rev 112, Mem @ 0xe800/16777216, I/O @ 0xd000/256, BIOS @ 0x/16777216 There are other drivers that also only have a legacy probe method that I believe have been seen to work since the pciaccess conversion, so I'm sure this is fixable. But apparently I dropped those drivers from Fedora about eight years ago, so I'm unlikely to find time to fix them. Should be an easy project for anyone who has such hardware to test with though. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
