[PATCH 01/12] dbus-core: Move to hw/xfree86/common dir

[Hans de Goede]

Hi,

On 01/28/2014 07:46 AM, Peter Hutterer wrote:
> On Thu, Jan 23, 2014 at 02:58:17PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 01/23/2014 01:56 PM, Daniel Stone wrote:
>>> Hi,
>>>
>>> On 23 January 2014 11:16, Hans de Goede <hdegoede at redhat.com> wrote:
>>>> Ok, I've put it back in config (while keeping the other changes like making
>>>> it no longer mutually exclusive with udev). I've pushed the updated version
>>>> here:
>>>> http://cgit.freedesktop.org/~jwrdegoede/xserver
>>>
>>> Thanks for this.
>>>
>>> bb992fbd config: drop the dbus API
>>>     This should've been removed a long time ago.
>>>
>>> c68423c0 dbus-core: Attempt to connect to dbus ASAP
>>>     Seems fine to me, assuming that all users of the hook don't assume
>>> we're further along in the init process than we are.
>>
>> Good point /me checks the hal config backend ... nope should not be a problem.
> 
> I think Daniel's point here is that anything that gets triggered by the hook
> must not think we're further ahead than we are. so the interesting bit here
> is whether we change when we're reading from the dbus fd the first time and
> what effect that has.

Right, I understood as much the first time. When config_init gets called we
already have initialized pretty much everything, and that is when the hook
will get called. It will get called slightly sooner but not much.

Which means that the hal code will be calling NewInputDeviceRequest() slightly
earlier. This should not be a problem however since the udev code path already
calls NewInputDeviceRequest() directly from config_init() rather then waiting
for some fd activity. So in essence this makes the hal code path behave more
like the udev code path.

>>> 738b1e91 dbus-core: Make dbus-core no longer mutually exclusive with udev
>>>     Sorry to keep bikeshedding, but I do worry slightly about taking
>>> over the dbus_core_*() namespace.  Should be safe in theory, since I
>>> doubt anyone's going to be adding to the D-Bus C API anytime soon, but
>>> ...
>>
>> Hmm, unless you really strongly object I'm going to just stick with the
>> dbus_core_... naming, I don't see that becoming a problem in the future.
> 
> it's a good idea imo, but this is something we can simply search/replace
> once this set has landed rather than having the rename and the subsequent
> rebase struggles.

Ok.

>>>     Also, we could move dbus_core_init() out of xf86Init, into
>>> dix/main.c's loop around the same time.
>>
>> dbus_core_... is still defined in libconfig.la now, and thus only
>> available in hw/xfree86/* as libconfig.la is not linked in to any
>> other binaries using dix.
> 
> plus, iirc if we link it into dix we'd have to worry about Xephyr and
> everything else starting to use the hotplug configs, something that needs a
> bit more testing and sorting out.

Right.

>>> 8d972e0c xf86Xinput: Modify API for server-managed fd support
>>>     I worry a little that drivers won't necessarily support this -
>>> would be nice to check by forcing them to define
>>> I_SUPPORT_SERVER_MANAGED_FDS or something; either that, or extend
>>> InputDriverRec with an equivalent flag which must be set.
>>
>> Interesting idea, I've investigating this on my todo list for Monday
>> (I'm not working tomorrow).
> 
> how about adding the pre-opened fd into a separate field and provide a 
> xf86GetManagedFD() call that merely returns that field.
> that way the driver code comes essentially down to:
> 
> pInfo->fd = xf86GetManagedFD(pInfo);
> if (pInfo->fd < 0)
>     pInfo->fd = open("path");
> 
> and supporting this in the drivers is easy with a few ifdefs, and the server
> is simple as well for the non-systemd case.  

I don't see how this helps with Daniel's worry about drivers not being ported,
the way I see it for non ported drivers we don't want to call systemd_logind_get_fd
at all. So we need to check if the driver is capable of dealing with server
managed fds before calling systemd_logind_get_fd, which means delaying the
systemd_logind_get_fd till we have figured out which driver to use, and having some
flag in the driver to indicate it can deal with managed fds.

This seems like an almost orthogonal problem to the API for the driver getting
the fd to me.

Regards,

Hans