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

[Dave Airlie]

>
> 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?
>

sorry about delay, I'm not really sure I've a good opinion here on how to go,

but what about driverFunc, can't you use that to get flags back from
the driver before probe?

We use that now to send some flags from the drivers back to the server.

though I'm quite happy to accept that everyone should handle server-fds,
just make sure the driver authors know what to change to make it work.

and port -modesetting :)
Dave.

> 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