On Mon, Mar 23, 2015 at 02:16:13PM +0000, Jon TURNEY wrote: > > > On 20/03/2015 17:16, Ray Strode wrote: > >On Fri, Mar 20, 2015 at 10:02 AM, Hans de Goede <[email protected]> wrote: > >>If a separate /tmp per user is used the existing auto display select code > >>does not work, add an extra check for the unix socket for the display number > >>existing in /proc/net/unix (linux only). > > > >This patch and the previous patch make sense to me near term. It > >fixes some corner > >cases without regressing any others. I do think a better medium-term > >solution would > >be for xinit to start using -displayfd and startx to drop its "try to > >figure out a display > >number" heuristics. There's just no reason programs that start an X > >server should be > >trawling around in /tmp and/or binding to sockets up front (except for > >hysterical raisins) > > I wrote a patch [1] a while ago to teach xinit to handle the -displayfd > option. > > If I understand you correctly, you are suggesting something slightly > different, that -displayfd should be used by default if a display number > isn't explicitly specified, but this might serve as a starting point... > > [1] > http://cgit.freedesktop.org/~jturney/xinit/commit/?id=c6dc4db8fdcbe115867f6f4a1ab9138536f99fec
The patch itself looks fine, minus a couple of coding style differences with the rest of the file. they should be fixed. Plus, you're leaving the pipe open from what I can tell. What gets interesting is using that from startx. The order of startx is pretty much: 1) dig around in the system to find a suitable $DISPLAY 2) add xauth entries for $DISPLAY 3) xinit Now, I've tried to avoid anything xauth-related, but from the little I know: to support displayfd in startx you'd have to communicate back to startx about the $DISPLAY and do the xauth dance before continuing with the xinit initial client connection. AFAICT, that's the tricky bit about -displayfd support in startx. Does that make sense or am I way off here? Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
