xf86-input-libinput: Changes to 'master'

Peter Hutterer whot at kemper.freedesktop.org
Sun Dec 7 14:42:37 PST 2014


 src/libinput.c |  126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 121 insertions(+), 5 deletions(-)

New commits:
commit 0c4eaf5480168b468547cdb3bd8ce5247b5a5378
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Tue Dec 2 12:29:07 2014 +1000

    Support server-side fds
    
    libinput's device handling and server-side fd handling are a bit of a
    mismatch, so this is hackier than one would hope for.
    
    The server sets pInfo->fd and the options "fd" and "device".
    The server requires pInfo->fd to be the one triggering select(2) to call the
    correct pInfo->read_input. We can't pass an fd to use into libinput, all we
    have is the open_restricted callback. That callback gives us the context, but
    not the pInfo with the fd we want.
    
    The solution:
    1) In PreInit, store the patch + fd combination in a driver-wide list. Search
    that list for an fd in open_restricted, return the pre-openend fd.
    
    2) Overwrite all devices' pInfo->fd with the libinput epollfd. In this driver
    we don't care about which device read_input is called on, we get the correct
    pInfo to post events from through the struct libinput_device of the libinput
    events.
    
    3) When a device is closed, swap the real fd back in so systemd-logind closes the
    right fd.
    
    This saves us worrying about keeping the right refcount on who currently has
    the fd set to the libinput fd. We just set it for all devices, let the server
    figure out which device to call (the first in inputInfo.devices) and we only
    need to remember to swap it back during DEVICE_OFF.
    
    If the server calls close on a pInfo->fd without telling the driver, that's a
    bug anyway.
    
    This patch also drops the pInfo->fd = -1 calls, they've been unnecessary since
    at least 1.11, possibly earlier.
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Hans de Goede <hdegoede at redhat.com>



More information about the xorg-commit mailing list