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

[Peter Hutterer]

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.

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

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

Cheers,
   Peter