[Bug] Portico 75 rotary encoder is mapped in reverse

[normanr]

Describe the Bug

I recently acquired a (second hand, but new in box) Portico 75 and the factory firmware worked correctly with the encoder (clockwise = volume up, counterclockwise = volume down). The firmware only supported VIA protocol version 9 which didn't have full support for encoders (it just showed it as 3 buttons), but otherwise everything worked fine.

I upgraded to the latest QMK firmware to upgrade VIA protocol to version 12 so that the encoder would be correctly shown on the UI, and now the encoder seems to be reversed (clockwise = volume down, counterclockwise = volume up). The mapping shown in VIA is correct, so it's the hardware decoding of the the rotary encoder that is reversed.

Is this "just" a matter of swapping the pin_a and pin_b in the keyboard.json? (In the meantime I have a work around of mapping the encoder "backwards" in using VIA).

Keyboard Used

portico75

Link to product page (if applicable)

No response

Operating System

Debian Linux

qmk doctor Output

qmk is not installed

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[lesshonor]

Adding #define ENCODER_DIRECTION_FLIP to your keymap's config.h will handle this without any modification of keyboard-level files.

[normanr]

I'm using the prebuilt firmware supplied by VIA, so I was hoping that the fix could be made upstream in QMK so that the VIA firmware builds would just pick it up automatically.

[lesshonor]

It isn't impossible for the current keyboard definition in QMK to be incorrect, but that's a tenuous conclusion to draw from a single report with a number of unresolved external variables. The firmware flashed by the manufacturer/vendor/previous owner is entirely unknown. The VIA layout specification and/or keymap (which are not housed in this repository or maintained by its owners) may be the source of your problem, vs how the encoder pins are defined.

I suspect you'd need more in the way of receipts from other portico75 owners for a PR which modifies the keyboard definition to get anywhere.

[normanr]

So when testing for the regression I haven't had to use any of the VIA features. I just flash the prebuilt firmware, and try the rotary encoder immediately. I did some bisecting and the prebuilt firmware from 2022-12-08 does not have the bug, where-as the prebuilt firmware from 2023-01-23 does have the bug. The only commit to the portico75 directory in that range seems to be a73014f. I'll have to get a working build environment to double-check that it's the root cause though.

[normanr]

ahh, I see -- the encoder to keymap mapping was wrong before that change:

 #define ENCODERS_CW_KEY { { 14, 3 }  }
 #define ENCODERS_CCW_KEY  { { 14, 4 } }

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
     [0] = LAYOUT_75_via(
       ...
       ...
       ...         KC_VOLD,
       ...         KC_VOLU,

so I assume the old code got the rotary encoder mapping wrong, and also got the keymap wrong, and then when the rotary encoder mapping was moved to encoder map the keymap bug was fixed, but the encoder direction was not.

[normanr]

I also tried the latest pre-build nightly from ci.qmk.fm (tkc_portico75_default.hex at ce2f7d8) and the rotary encoder is reversed (clockwise turns the volume down, counterclockwise turns the volume up)