• Patrik Fimml's avatar
    Input: Add "inhibited" property · a1816164
    Patrik Fimml authored
    Userspace might want to implement a policy to temporarily disregard input
    from certain devices, including not treating them as wakeup sources.
    
    An example use case is a laptop, whose keyboard can be folded under the
    screen to create tablet-like experience. The user then must hold the laptop
    in such a way that it is difficult to avoid pressing the keyboard keys. It
    is therefore desirable to temporarily disregard input from the keyboard,
    until it is folded back. This obviously is a policy which should be kept
    out of the kernel, but the kernel must provide suitable means to implement
    such a policy.
    
    This patch adds a sysfs interface for exactly this purpose.
    
    To implement the said interface it adds an "inhibited" property to struct
    input_dev, and effectively creates four states a device can be in: closed
    uninhibited, closed inhibited, open uninhibited, open inhibited. It also
    defers calling driver's ->open() and ->close() to until they are actually
    needed, e.g. it makes no sense to prepare the underlying device for
    generating events (->open()) if the device is inhibited.
    
                  uninhibit
    closed      <------------ closed
    uninhibited ------------> inhibited
          | ^     inhibit        | ^
     1st  | |               1st  | |
     open | |               open | |
          | |                    | |
          | | last               | | last
          | | close              | | close
          v |     uninhibit      v |
    open        <------------ open
    uninhibited ------------> inhibited
    
    The top inhibit/uninhibit transition happens when users == 0.
    The bottom inhibit/uninhibit transition happens when users > 0.
    The left open/close transition happens when !inhibited.
    The right open/close transition happens when inhibited.
    Due to all transitions being serialized with dev->mutex, it is impossible
    to have "diagonal" transitions between closed uninhibited and open
    inhibited or between open uninhibited and closed inhibited.
    
    No new callbacks are added to drivers, because their open() and close()
    serve exactly the purpose to tell the driver to start/stop providing
    events to the input core. Consequently, open() and close() - if provided
    - are called in both inhibit and uninhibit paths.
    Signed-off-by: default avatarPatrik Fimml <patrikf@chromium.org>
    Co-developed-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
    Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
    Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
    a1816164
input.c 64.7 KB