[PATCH v2 00/14] Use systemd-logind to manage /dev/... nodes for us

[Hans de Goede]

Hi,

On 02/11/2014 04:04 AM, Dave Airlie wrote:
> On Tue, Feb 4, 2014 at 9:49 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi All,
>>
>> Here is v2 of my systemd-logind / run the xserver without root rights series,
>> this version drops some already merged patches, and addresses all the review
>> comments on the first RFC posting of these series.
>>
>> One open question is if we want to add a capabilities field to video
>> drivers like this version already does for input drivers, and then only
>> let systemd-logind manage the fd for /dev/dri/card# nodes if the driver
>> claims to support server managed fds ?  I think this is a good idea, but I've
>> not done this yet in this version since I was not sure what others would think
>> of it.
>>
> 
> Hi,
> 
> odev changes look good to me, so patches 5-9 are Reviewed-by: Dave
> Airlie <airlied at redhat.com>

Thanks for the review!

> I'm not systemd-logind aware enough to know about the rest yet,
> 
> Well we already have a number of flags from video drivers probing,
> like the needs hw one etc, do you need
> to have a separate capabilities field in the driver?

Let me try to explain, currently if logind is active and thus server
managed fds are in use, the /dev/dri/card node will get fetched from
logind from: hw/xfree86/os-support/linux/lnx_platform.c: get_drm_info()
and then it is left open for the driver to use.

For input drivers it was decided that it would be good to have a way
for drivers to signal that they don't support server managed fds, so
that the /dev/input/event node does not end up getting opened twice.

For video drivers I guess this is even more important, since only one
fd can be master.

So there are 2 questions:
1) Do we want to have a similar mechanism for video drivers, or are
we just going to declare that all video drivers will need to support
server managed fds. My vote goes to having a similar mechanism, both
so as to be consistent with input drivers, as well as for the binary
drivers

2) If we want such a mechanism how does the xserver find out if the
driver supports server-fds. So we need a way to get this info from
the driver before calling platformProbe, so that we can close the
server-fd and thus drop master rights on the server-fd.

AFAIK there is no way to communicate such driver capabilities from
driver to xserver before calling platformProbe, hence my suggestion
of adding a capabilities field to DriverRec.

Note that get_drm_info will always keep trying to use a server-fd, as
at this point we don't know which driver we will use yet. This is just
like how get_drm_info does an open + close of the fd in the non
server-fd scenario. Except that the close happens somewhat later,
or not at all for server-fd supporting drivers.

Regards,

Hans