1. 17 Feb, 2019 2 commits
  2. 09 Feb, 2019 2 commits
  3. 08 Feb, 2019 3 commits
  4. 07 Feb, 2019 10 commits
  5. 06 Feb, 2019 2 commits
  6. 05 Feb, 2019 2 commits
  7. 29 Jan, 2019 4 commits
  8. 28 Jan, 2019 2 commits
  9. 14 Jan, 2019 7 commits
  10. 07 Jan, 2019 5 commits
  11. 04 Jan, 2019 1 commit
    • Hans de Goede's avatar
      Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device · e9eb788f
      Hans de Goede authored
      The Microsoft documenation for the PNP0C40 device aka the
      "Windows-compatible button array" describes the 5th GpioInt listed in
      the resources as: '5. Interrupt corresponding to the "Rotation Lock"
      button, if supported'.
      
      Notice this describes the 5th entry as a button while we sofar have been
      mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232
      which actually comes with a rotation-lock button, the button indeed is a
      button and not a slider/switch. An image search for other Windows tablets
      has found 2 more models with a rotation-lock button and on both of those
      it too is a push-button and not a slider/switch.
      
      Further evidence can be found in the HUT extension HUTRR52 from Microsoft
      which adds rotation lock support to the HUT, which describes 2 different
      usages: "0xC9 System Display Rotation Lock Button" and
      "0xCA System Display Rotation Lock Slider Switch" note that switch is seen
      as a separate thing here and the non switch wording is an exact match for
      the "Windows-compatible button array" spec wording.
      
      TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong
      because the 5th GPIO is for a push-button not a switch.
      
      This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      e9eb788f