Skip to content
Snippets Groups Projects

Draft: arm64: dts: imx8mq-librem5: Enable autorepeat for volume keys

1 unresolved thread

Enable autorepeat so that userspace can easily handle increasing or decreasing volume continuously.

Signed-off-by: Evangelos Ribeiro Tzaras evangelos.tzaras@puri.sm

However this does not seem to work: Holding down either key does not produce events with value 2:

Event: time 1684003107.258641, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1684003107.258641, -------------- SYN_REPORT ------------
Event: time 1684003109.678310, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1684003109.678310, -------------- SYN_REPORT ------------
Event: time 1684003113.919863, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1684003113.919863, -------------- SYN_REPORT ------------
Event: time 1684003116.043017, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1684003116.043017, -------------- SYN_REPORT ------------

Merge request reports

Members who can merge are allowed to add commits.

Checking pipeline status.

Ready to merge by members who can write to the target branch.
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • added 1 commit

    • 7d5e6eca - arm64: dts: imx8mq-librem5: Enable autorepeat for volume keys

    Compare with previous version

    • Enable autorepeat so that userspace can easily handle increasing or decreasing volume continuously.

      Repeat is not really needed for this, closing.

      I'm still (mildly) curious as to why that change to the device tree did not end up producing repeat events though.

    • The example in docs looks slightly different than what you did :)

      examples:
        - |
          #include <dt-bindings/interrupt-controller/irq.h>
      
          gpio-keys {
              compatible = "gpio-keys";
              autorepeat;
      
              key-up {
                  label = "GPIO Key UP";
                  linux,code = <103>;
                  gpios = <&gpio1 0 1>;
              };
      
              key-down {
                  label = "GPIO Key DOWN";
                  linux,code = <108>;
                  interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
              };
          };
    • Another case of PEBCAK :(

    • Looking at it now, I think it may actually make sense to enable it here, even if it's not going to be used by phoc. WWAN_WAKE won't really be affected (and is going to go away from gpio-keys in the future anyway), and volume keys should probably generate autorepeat events as that may help other DEs.

    • Ok, let me reopen and update it with your suggestion from above then!

    • This does work, however running evtest after booting that kernel I got lots of:

      Event: time 1684770780.896079, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770780.896079, -------------- SYN_REPORT ------------
      Event: time 1684770780.935912, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770780.935912, -------------- SYN_REPORT ------------
      Event: time 1684770780.976087, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770780.976087, -------------- SYN_REPORT ------------
      Event: time 1684770781.016093, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770781.016093, -------------- SYN_REPORT ------------
      Event: time 1684770781.056097, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770781.056097, -------------- SYN_REPORT ------------

      the repeat for (what I assume is the modem GPIO) only stopped (without actually releasing, i.e. value 0) once a volume key has been pressed and starts repeating again when coming out of suspend:

      Event: time 1684770938.072259, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770938.072259, -------------- SYN_REPORT ------------
      Event: time 1684770938.112249, type 1 (EV_KEY), code 169 (KEY_PHONE), value 2
      Event: time 1684770938.112249, -------------- SYN_REPORT ------------
      Event: time 1684770938.141666, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
      Event: time 1684770938.141666, -------------- SYN_REPORT ------------
      Event: time 1684770938.280785, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
      Event: time 1684770938.280785, -------------- SYN_REPORT ------------
      Event: time 1684770941.220026, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
      Event: time 1684770941.220026, -------------- SYN_REPORT ------------
      Event: time 1684770941.373754, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
      Event: time 1684770941.373754, -------------- SYN_REPORT ------------
      Event: time 1684770943.411651, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
      Event: time 1684770943.411651, -------------- SYN_REPORT ------------
      Event: time 1684770943.683752, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 2
      Event: time 1684770943.683752, -------------- SYN_REPORT ------------
      Event: time 1684770943.688812, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
      Event: time 1684770943.688812, -------------- SYN_REPORT ------------

      I'm not sure how much of a problem this is (in terms of wasting CPU cycles?), but it certainly feels weird to me.

      Maybe this should be deferred until WWAN_WAKE goes away from gpio-keys?

    • Ah yes, that's with modem being off I guess?

      Maybe this should be deferred until WWAN_WAKE goes away from gpio-keys?

      Yup.

    • Please register or sign in to reply
Please register or sign in to reply