https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253277
--- Comment #2 from Olivier Certner <[email protected]> ---
Hi,
As for the high-level problem I'm fixing, I wrote this description:
> Typically, sddm exactly triggers the problem. So when you try to open
> another session through it, the first session's sockets are crushed
> and it becomes stale.
What do you find unclear in it exactly?
As for the low-level description, let me recapitulate with more context. As you
most probably know, there are two ways that Xorg selects its display at
startup:
- Either you supply an explicit display on the command-line (e.g., ":1").
- Or you do not, and either "-displayfd" has been specified, in which case Xorg
will try to assign some automatically, or it has not, in which case :0 is used
by default.
("-displayfd" has other effects, but this is a separate discussion, relevant to
the other bug #253278.)
The problem is with the automatic assignment of display. It works by trying to
grab the first display available (from :0 when using UNIX sockets), which it
does by simply unlinking an existing socket file and then binding a new socket
to the same file. When the server is run as root, this operation always
succeeds, and any existing socket for :0 ("/tmp/.X11-UNIX/X0") that would exist
is removed. This leaves any preexisting X session on :0 stale (e.g., launching
new apps make them go to the new session).
And SDDM triggers that: It passes "-displayfd", and no display directive,
relying on the server to do display assignmnent, which it doesn't do correctly.
Now, I agree that this problem is probably not FreeBSD specific (it affects
platforms/distributions running Xorg as root). If you prefer, I'll report it
upstream and we'll see how it goes.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.