Xephyr input hotplugging support

2015-03-20 Thread LaƩrcio de Sousa
Hi there! Some time ago, I've written about my plans to port latest Xephyr graphical improvements to xf86-video-nested, mainly for single-GPU multiseat purposes. Now I realised that maintaining a driver is beyond my capabilities, and I'd like to try another approach: implement the missing parts in

Re: [PATCH xinit 2/2] startx: Make startx auto display select work with per user /tmp dirs

2015-03-20 Thread Ray Strode
Hi, On Fri, Mar 20, 2015 at 10:02 AM, Hans de Goede 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

Re: [PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

2015-03-20 Thread Ray Strode
Hi, On Fri, Mar 20, 2015 at 1:01 PM, Jasper St. Pierre wrote: > ... Why does displayfd imply nolock? It doesn't really matter why it implies, nolock, I guess. The issue at hand is that it does (and always has) implied nolock. You can't fix that without breaking things that rely on it being noloc

Re: [PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

2015-03-20 Thread Jasper St. Pierre
... Why does displayfd imply nolock? That seems strange to me. I consider the .X0-lock files an API that we shouldn't break. On Fri, Mar 20, 2015 at 7:02 AM, Hans de Goede wrote: > Currently startx relies on /tmp/.X?-lock being present for automatically > picking a free display number. This does

Re: [PATCH 0/5] Trivial randr cleanups

2015-03-20 Thread Alex Deucher
On Thu, Mar 19, 2015 at 9:01 AM, Emil Velikov wrote: > Hello all, > > Noticed that as optimus support landed in randr, the latter became extra > chatty, flooding the logs on said systems. Afaict the messages are not > really meaningful outside the development stage, so I've decided to > remove the

[PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

2015-03-20 Thread Hans de Goede
Currently startx relies on /tmp/.X?-lock being present for automatically picking a free display number. This does not work if -nolock is used when starting the server, or if the server is started with -displayfd as -displayfd implies -nolock. This is becoming a problem now that -displayfd is getti

[PATCH xinit 2/2] startx: Make startx auto display select work with per user /tmp dirs

2015-03-20 Thread Hans de Goede
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). Signed-off-by: Hans de Goede --- startx.cpp | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)