Wooting Analog Interface v2#9
Conversation
|
Thanks for the PR. I'll take a look at it later since I'll also have to port this to C++. |
|
It seems to me like you're ignoring the first byte, which is quite important for disambiguating, e.g. the Fn key and the F key. |
oh mb i forgor to re-add it after messing around |
|
From what I can tell, tho, the first byte is just encoding the position? So I don't think this v2 interface is usable as it is right now. |
|
it seems to be working fine for me on a arm 60he with the beta firmware, unless im missing something... |
|
gonna make this a draft for now |
|
The thing is that this |
|
hmm i see, i guess its best to wait for a proper update from wootings side.. glancing over the sdk it seems fairly incomplete for now and the beta websoftware seems to be using some sort of manual lookup tables for every board (might be wrong since its minified and obfuscated js) |
|
So, this is what they gave me: uint8_t column : 5;
uint8_t row : 3;
// scoped to key namespace
uint8_t keycode;
bool actuated : 1;
uint8_t reserved : 1;
uint8_t keyNamespace : 4;
//higher precision
uint16_t analogValue: 10; |
|
My C++ implementation for reference: calamity-inc/Soup@9a82fee |
|
pawsome, this would need to be tested on other keyboard layouts than the 60he to make sure its solid |
|
I think the approach with having a separate provider for the V2 interface was fine |
|
the demo running this https://girlglock.github.io/JavaScript-SDK/demo |
|
LGTM |
| const keycode = data.getUint8(i + 1); | ||
| if (keycode === 0) break; |
There was a problem hiding this comment.
I would avoid using the keycode being 0 as the basis for a null entry.
In practice right now, I don't think there's any way to have a valid keycode that has 0 here, but that's not necessarily a given.
In the Analog SDK, we usually use the value being 0 as the basis for null entry
There was a problem hiding this comment.
Otherwise I would match the behaviour of the v1 handling here, where it's the keyNamespace + keycode being 0 that is used as the basis for null entry.
As namespace 0 is equivalent to the HID Keyboard Page (0x7) which has 0 reserved. So I would not expect that to ever be a valid value for a key
| { | ||
| const keycode = data.getUint8(i + 1); | ||
| if (keycode === 0) break; | ||
| const packed = data.getUint8(i + 2); |
There was a problem hiding this comment.
Note that the first bit of the packed section is the key's actuated state if that is of interest
The behaviour should be consistent across all keyboards using the v2 Analog Interface :) (exception being the row/col position [as that is related to the matrix of the particular device], but that's not being utilised here anyway) |
ive had someone with a two he (arm) report that only a few keys would ever report unless they used usage_page 0xFF55 instead of 0xFF53 thats why im a bit skeptical i had someone else test it with a two non arm and it worked fine on 0xFF53 |
| const scancode = (keyNamespace << 8) | keycode; | ||
| const value = (value_hi << 2) | value_lo; | ||
|
|
||
| if (keyNamespace === 0 && keycode === 0) break; |
There was a problem hiding this comment.
Given that scancode contains both values, comparing that to 0 directly would make more sense.
3 participants
the beta firmware swaps to analog interface v2 (v5.3.0)