xf86-input-libinput: Changes to 'master'

[Peter Hutterer]

 src/xf86libinput.c |  480 ++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 400 insertions(+), 80 deletions(-)

New commits:
commit c943739a2bfd4c380db0b21bc35b73deb7496c8a
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Wed Nov 11 10:10:58 2015 +1000

    Split mixed pointer/keyboard devices into two separate X devices
    
    The server struggles with devices that are both, the protocol (especially XI2)
    requires a fairly strict separation of pointer vs keyboard devices. Though the
    server has a couple of hacks to route events correctly, mixed
    devices still experience bugs like [1].
    
    Instead of advertising the device as a single mixed device, split the device
    into two X devices, one with only a pointer/touch component, one with only a
    keyboard component. This ensures that the device is effectively attached to
    both the VCP and the VCK, something the XI2 protocol doesn't really allow.
    
    This patch drops the keyboard capability on a mixed device, duplicates the
    input options and attributes and queues a NewInputDeviceRequest call. The new
    device only has the keyboard capability but is otherwise unchanged. The
    wacom driver has used this approach for years.
    
    The WorkProc is necessary to avoid inconsistent state, the server doesn't
    handle a NewInputDeviceRequest during PreInit well.
    
    The approach:
    During pre-init we create a struct xf86libinput_device with the
    libinput_device and a unique ID. The child device has that ID added to the
    options and will look for the other device during its pre-init. The two
    devices then share the xf86libinput_device struct.
    
    We only have a single epollfd for all devices  and the server calls read_input
    on the first device in the list with the epollfd as pInfo->fd. That shared
    struct is used as the userdata on the libinput_device we get back from the
    event, and each device is in the xorg_list device_list of that shared struct.
    We loop through those to find the ones with the right capabilities and
    post the event through that device.
    
    Since devices can be enabled and disabled independently, the rest of the code
    makes sure that we only ever add the device to libinput when the first shared
    device is enabled, and remove it accordingly.
    
    [1] https://bugs.freedesktop.org/show_bug.cgi?id=49950
    
    https://bugs.freedesktop.org/show_bug.cgi?id=92896
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Hans de Goede <hdegoede at redhat.com>

commit a72e96538af2c4a94ead48f96e8e59a2a4980a64
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Fri Nov 13 09:39:29 2015 +1000

    Add a helper function for the driver context initialization
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Hans de Goede <hdegoede at redhat.com>

commit b1a9bea6079550fa8be4fa0b2e18ea810b0ea68c
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Wed Nov 11 09:12:33 2015 +1000

    Copy the device capabilities to the X driver struct
    
    And use those copied caps instead of the direct device capability calls.
    
    No functional changes at this point, this is preparation work for selectively
    disabling capabilities on a device.
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Hans de Goede <hdegoede at redhat.com>

commit a6aad69a97c68fa96e0a836e735b1a7f319b92df
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Wed Nov 11 09:02:22 2015 +1000

    Split type_name detection out into a helper function
    
    No functional changes
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Hans de Goede <hdegoede at redhat.com>