[PATCH] [RFC] socket activation code for xserver

[Hans de Goede]

Hi,

On 11/25/2013 03:24 PM, Łukasz Stelmach wrote:
> It was <2013-11-25 pon 14:49>, when Łukasz Stelmach wrote:
>> It was <2013-11-25 pon 13:46>, when Hans de Goede wrote:
>>> Hi Łukasz,
>>
>> Hello, nice to ... meet you :-)
>>
>>> I'm a new member of Red Hat's graphics team. At the request
>>> of Peter Hutterer I've been looking at your systemd socket
>>> activation patches.
>>>
>>> Applying / building them was not a problem.
>>>
>>> My initial thought for testing socket activation was to
>>> write the necessary unit files and patch gdm to not start
>>> X for local displays. But the latter bit is much harder
>>> then it sounds.
>>>
>>> Typically the display-manager will start X with a --auth
>>> parameter passing a file with auth-cookies in there. When
>>> using socket based activation this won't work. We may be
>>> able to work around this, but I wonder if it is worth
>>> the trouble.
>>>
>>> Which has left me wondering what the use-case is for this,
>>> and how you envision socket activation working for X in
>>> a traditional Linux desktop setup with xdm/gdm/kdm ?
>>
>> I work for Samsung, me and my teammates are preparing Tizen. Tizen's not
>> quite traditional Linux system and it is a single-user system at the
>> moment (at least the mobile profile). This will probably change and we
>> will use some kind of dm but not yet. Even when we do so we might want
>> some more programmes to connect X during boot.
>>
>> We've got the DISPLAY variable set to :0 for the entire user session
>> (managed by systemd --user) and a few other processes. With these
>> conditions in mind running X as a simple socket-activated service
>> without a display manager is the simplest option for us.

Ok, I already suspected as much. I'll give your patches a simple test-run
tomorrow, and if all goes well re-post a slightly polished up version of
them them to the list for review.

>>
>> For more traditional setups one might try using systemd-run to create
>> the service to be activated. Yet another
>
> ... option is to create a wrapper/rewrite a display manager so they can
> be started upon connection to the socket and exec*(2) Xorg.

That won't work on the classic linux desktop setup, as the display-manager
is the 1st X-client. So if the dm is started upon the 1st connection, and
the 1st connection is established by them dm we have a chicken and egg
problem. I think you're single user system without a dm is a valid use-case,
and that for systems which use a dm, just doing things the old way is
the best for now.

Regards,

Hans