(or one unit either side of mid)
#🤖│community_dev
knotty night
chilly oar
You mean
^^
public static short Invert(short number) {
return number <= short.MinValue ? short.MaxValue * -1 : number * -1;
}
^^
knotty night
accuracy around mid-point way more important that accuracy at extremes, but fidelity That does not invert?
<= is pointless
it's a short
only = possible
or >
chilly oar
If MinValue is -254 and number is -255 due to a very fast press it's not.
knotty night
number <= short.MinValue
chilly oar
-255 is a short
quiet root
thats a byte
chilly oar
it is 0x80
knotty night
number is a short, it cannot possibly be less than the min value
quiet root
a short goes from -32768 to 32767
chilly oar
oh short is 2 byte, so it is 0x8000 = -32768
chilly oar
Signed: From −32,768 to 32,767
knotty night
Ignoring that... return number = short.MinValue ? short.MaxValue * -1 : number * -1
chilly oar
from your link
knotty night
input of -32768 would return -32767
knotty night
well, apart from that 😛
chilly oar
if MinValue is -32767 an number is -32768 you code don't do eliminate that.
quiet root
knotty night
minvalue is -32768
quiet root
u literally said urself what the min val is
the function only accepts number from -32768 to 32767 inclusive
so u cant go lower or higher
chilly oar
I thought you don't want MinValue to be -32768???
quiet root
knotty night
I want this to be my results table
Input Output
-32768 32767
32767 -32768
0 0
1 1
-1 -1
Any other values in-between should be as faithful as possible
quiet root
and i wouldnt want 32767 to invert to -32768 cause i dont know of any game that actually just sees -32768 as max
usually they take the last 5 values
so -32768 to -32764
chilly oar
Ok, now I get what you want
knotty night
"last 5 values"?
quiet root
way to unreliable to just use 1 raw data value
because of well electronics
so usually the window for a 100% deflection in games themselves is 5-10 values
regardless of deadzones
knotty night
You mean most games consider the 5 values at each extreme to be "max deflection"?
quiet root
as far as i know from my time in stuff like flight sim x yes
knotty night
Bear in mind that most of my stuff is for remapping apps where end-users are writing plugins
So I like to make it easy on them to detect conditions such as "Axis at neutral" or "Axis at max"
quiet root
its dumb to just consider -32768 as 100% for the reason of electronics getting older etc and thus more unreliable anyway
knotty night
Modern Hall Sensor sticks do not suffer from wear
quiet root
the hall sensor doesnt
the stick does
its made out of some material thus it will degrade
unless its made of diamond
props to u then
knotty night
I doubt that will stop it from being able to achieve max deflection?
Besides, if it does, re-calibrate
Making concessions in other places is solving the problem in the wrong place IMHO
quiet root
i could say that about recalibrating aswell?
chilly oar
for that @knotty night this function do the job:
public static short Invert(short number) {
return number == short.MinValue ? short.MaxValue : (number == short.MaxValue ? short.MinValue : number * -1);
}
why the extra ()
knotty night
No, that's the place you are meant to solve that problem
quiet root
completely unnecessary
the place we are meant to solve this is in the hardware itself
just make it even more durable
sticks with a titanium base or smth
so wear is reduced
knotty night
There is already conversion taking place in the calibration, even if it is brand new
chilly oar
THis should produce the values you want @knotty night
knotty night
the device is almost certainly not natively 16-bit
quiet root
@chilly oar u can still leave out () around the second ternary
knotty night
AFAIK no joysticks are
quiet root
the compiler keeps track
knotty night
Best I am aware of is 15-bit
chilly oar
it is for a better visuality
quiet root
public static short Invert(short number) {
return number == short.MinValue
? short.MaxValue
: (number == short.MaxValue
? short.MinValue
: number * -1);
}
At the end of the day, when you move the joystick all the way right, if it does not report the maximum value as stated by the HID descriptor, then the joystick is mis-configured
chilly oar
how do you the syntax highlight thing?
quiet root
magic
knotty night
fixing that by catering to the lowest common denominator is just wrong IMHO
quiet root
ya so imo then we should get full titanium sticks
to reduce even the ear etc
that way u dont even need to recalibrate
knotty night
No, if your stick is not calibrated properly, that's your problem to solve, not for the programmer to make everybody else's sticks underperform just to cater for your laziness / ignorance
chilly oar
It depends, I think...
knotty night
Maybe in a game where you can make that call, but when I am writing code for UCR, I try and take a best-practice approach
chilly oar
It would be good to implement calibration and a deadzone option.
knotty night
DZ is another of those things that it never ceases to amaze me how many programmers get wrong
I had such high hopes for the wooting and MWO, but they have a massive enforced DZ
which is coded wrong
it's like a 10% DZ or something, but at 11% deflection, input is at like 11%, not 1%
chilly oar
so the user can have a fixed calibration per hardware but can change this on every profile for your programm differently
knotty night
So whilst you can use anti-dz, there's little to no ease-in
I am gonna have to try to implement a strobing anti-dz
So when eg at 5% deflection, it strobes the axis 10%/0%/10%/0% etc
chilly oar
Can you give an example of the deadzone from Wooting? I know if you reach like 240 or something on the analog interface for RAW support they raise it to full 255.
knotty night
You mean the anti-dz in wooting? what does it do?
It raises the minimum output value
so eg a 10% anti-dz, when at 1% input, the output will be @ 11%
to try and get rid of a 10% dz
chilly oar
It's worse, all over 225 are set to 255.
https://github.com/WootingKb/wooting-analog-sdk/blob/master/src/wooting-analog-sdk.c#L123
knotty night
but it only works perfectly if the DZ in the game is programmed right
Dunno what is going on there
chilly oar
At the moment I don't use the analog interface for RAW support
knotty night
I have an AHK wrapper for the analog API, can't say that I have noticed it jumping from 225 to 255
But I did not look that hard
But yeah, looks suspect. <@&375234916776017933> why do analog values seem to be capped to 225?
daring abyss
@knotty night I can confirm the problem with multiple sensors not reaching max raw output value. Roughly 30% on my WTT PCB do not reach max raw output when bottomed out.
knotty night
WTT?
knotty night
Did you check the graph on the analog page?
daring abyss
Yes,
knotty night
By default, it does not seem to map to the full range
daring abyss
knotty night
I had one key like that
daring abyss
with this curve, 70% of the switch sensors reached max output whereas 30% did not
knotty night
Also with that key, if I held it full down and moved finger around, it would vary a lot
swapped out switch, it went away
daring abyss
Can confirm,. a lot of jumpy reading when "wobbling" the stem when fully pressed down
knotty night
Yeah, this seems to be a faulty / bad tolerance switch or something
daring abyss
I also witnessed non-linear readings, i.e., values jumping notabily back and forth (1-2%) while slowly pressing down the switch stem
knotty night
With the ones that do not hit max, how far off are they?
daring abyss
typicaly, 0.5-1% off
chilly oar
If you don't want the caped values just use the code and change it or build your own version of the dll.
knotty night
So it sounds like it would not be too big of a deal to calibrate the stick to the lesser values
in the short term at least
Use DIView instead of windows calibration, it's tons easier
daring abyss
yes, each sensor should be calibrated individually whenever you change a switch
knotty night
FYI, the form to set calib axes in DIView has a slight bug, you cannot type in the - symbol
daring abyss
I used DIVIew ofc
knotty night
You can copy the value to the clipboard and paste it in tho
daring abyss
And calibration on the OS level does not suffice, since it only calibrates the HID wrt to your current profile
knotty night
eh?
daring abyss
As soon as you assign your virtual HID device to other keys, your DIView callibration is off
knotty night
Calib is per-axis
if you set the calib values for that axis, no matter what key you map to it, it will use those calib values
daring abyss
Yes, as soon as you assigna an axis to another key (=sensor) your calib is off though
Ideally, you should be able to calib the sensors on your PCB via firmware
knotty night
Well, if you set the calib for the "bad" axis values, then yes, other "non-bad" keys will max out slightly early
chilly oar
He is right, because you have to calibrate every key differently
knotty night
but keys maxing out .5-1% early is much better than keys never maxing out at all IMHO
daring abyss
I see what your saying, you want to set an outer DZ by default
chilly oar
So maybe you must have two calibations, one per axis plus one per key.
knotty night
No, just calib all axes to max out .5-1% early
daring abyss
That's what an outer dz is
knotty night
Then you can map any key to it and not care
daring abyss
Sure, I agree this is a possibility.
knotty night
It's just the same setting as the max values. Normally it would be like -32768..32767, you just set it to something like -32700..327600
oops
-32760..32760
daring abyss
Long-term, I hope for an callibration method on the firmware level for each switch sensor individually, though
knotty night
Hmm, not sure that will happen. If joysticks with 6 axes don't do that in hardware, I would be surprised if the W2 with 122 axes would
And it would need to happen in the hardware surely, else it would not affect the API?
chilly oar
Hmm, I know they have no memory left on the MCU but maybe on the EPROM, and the calibration values belong to it in my opinion.
knotty night
What size are the values at the HID level? 8 bit?
I am guessing so, since it is 8-bit in the API
chilly oar
Which values? On the Xinput / Dinput they are 16 bit, on the RAW analog interface only 8 bit
The MCU is a 8/16 bit processor
chilly oar
Maybe expect only a 8 bit range.
To test it for true 16 bit values you have to read a few pakages and look on the bitchanges
if it jumps
knotty night
I don't see how to do it except how DI does it - Min/Max values and it stretches the range between those
so eg a perfectly calibrated key is 0/255
chilly oar
No, have to look at the distinct change.
knotty night
I spose maybe only an "end" value?
but that would not cater for keys that start registering at 2%
If you wanted to allow full calibration per key, you would need 2 values
But I spose they don't need to both be 8-bit
You could maybe use 2x 4-bit values, and it is a delta difference
Ok would not cater for a key that is so bad that it only registers 1/4 of it's range, but there's not a lot of point in supporting that
chilly oar
They are working on to expend the range per software in the future, so I think the current state isn't the best you can get out of it. They just limit it due to prevent probems.
After a quick look at the RAW data on the USB conncetion it looks like just 256 distinct value.
daring abyss
Another issue with the raw values is the--at least in parts--quite jumpy sensor readings while slowly pressing down a switch.
knotty night
This does not hugely surprise me, given the mechanism at use
It's extremely susceptible to tolerances
quiet root
i mean are we talking about it jumping frequently or about the amplitude
knotty night
jumpy sensor readings
daring abyss
@knotty night Agreed, but they need to implement some smoothing, filtering
knotty night
it's light bouncing around a cast plastic mult-part lens
quiet root
evil yes but as in it jumps huge ranges or it jumps around frequently
knotty night
so unless it grips that post perfectly, wiggle in the key is gonna affect light path
I saw one switch that was orders of magnitude worse than the rest
daring abyss
Same here, I had a broken switch that wasn't able to reach more than 50% output
nimble whale
I'm also posting here, maybe it reaches wooting developers better, have you guys thought about implementing "hair trigger mode" actuation á'la steam controller inside the keyboard?
I made a little mockup in a prototyping environment
notice how I can trigger multiple keypresses before the key fully travels back to the top
knotty night
What is this node system @nimble whale ?
proud oasis
hm. any feedback to this pr? https://github.com/WootingKb/wooting-rgb-sdk/pull/10 i added quite some stuf
also added new dll exports so people can figure out if the keyboard is a wooting one or a wooting two
oh and i have no clue if it compiles on linux
boreal nest
@knotty night
I'm more than a little late with this but I didn't see it mentioned. There is a "perfect" way to flip the sign on any integer: ~num+1. For a way that avoids overflow, int flip(int x) { return x==INT_MIN?~x:~x+1; } or a more generic way (at least for C++) being template <class T> T flip(T value) { T min = 1<<(sizeof(T)*8-1); return value==min?~value:~value+1; }
@proud oasis
Something odd I noticed looking at the Wootility code is that they use a limit of 117 instead of 116 for the highest key on the Two (technically 118 but it's always compared < 118). Not sure why that is
boreal nest
Yeah but it's checking against there being 118 of them
boreal nest
, Ia = new Map([[u.WOOTING_ONE, 96], [u.WOOTING_TWO, 118]])
getRgbProfile(e, t) {
return Ja(this, void 0, void 0, function*() {
const r = t === u.WOOTING_ONE ? 96 : 118;```
etc. It's everywherewhere is that from?
boreal nest
The Wootility's code
boreal nest
Though to be fair I think that's because 118 is an even number and it makes some other bits easier
Lots of Ia.get(type)/2
knotty night
@boreal nest what is ~ ?
boreal nest
Twiddle. Flips every bit, so twiddling 0b1010 is 0b0101
knotty night
What I meant is that it is technically impossible to preserve 100% fidelity when flipping a signed int
Seeing as the + / - scales are uneven
boreal nest
True
knotty night
But if there is an agreed "best" way of doing it, that is certainly of interest
So with that technique, where are the gaps?
boreal nest
It works because integers are stored in two's compliment. char x = -1 is 0b11111111. So (~-1)+1 is 0b00000000+1
knotty night
Seeing the +1 makes me think lots of values will change
boreal nest
There are no gaps or got'chas with the technique beyond making sure that you handle the minimum to avoid overflow
nimble whale
@knotty night that is https://vvvv.org really good for quick prototyping. those HID nodes are not vanilla though
knotty night
Oh hold on
No, that's wrong
If -ve maps to positive basically as abs value, then there must
But not if ou shift whole scale I spose?
But then you will get some odd conversions?
boreal nest
Here's an example: char x = 24; // 0b00011000, twiddling that becomes 0b11100111 (-25), add one to get -24. Works in reverse as well, char x = -24; // 0b11101000, twiddling becomes 0b00010111 (23), add one to get 24
boreal nest
The only got'cha is the minimum value. 0b10000000 (-128) becomes 0b01111111 (127), so adding one will overflow back to -128. Likewise, twiddling 0 becomes 0b11111111, adding 1 overflows back to 0
knotty night
Right, so IMHO it's worse than my technique
boreal nest
int flip(int x) { return x==INT_MIN?~x:~x+1; } this handles the minimum got'cha by not adding 1 so that flip(INT_MIN) returns INT_MAX. Every other possible value for x works fine
knotty night
That breaks mid point
boreal nest
template <class T> T flip(T value) { T min = 1<<(sizeof(T)*8-1); return value==min?~value:~value+1; } template version does the bitshifting because it can't rely on INT_MAX, LONG_MAX, etc, and needs to find the minimum for T manually
knotty night
0 does not map to 0
boreal nest
It does
char x = 0; //0b00000000 twiddling becomes 0b11111111 (-1), adding one becomes 0 again
knotty night
ahh ok
So what maps to what? As mentioned before, the best conversion I can come up with does this:
-32768 32767
-32767 32767
32767 -32768
32766 -32766
0 0
1 -1
-1 1
(All other numbers are * -1)
what are you guys trying?
knotty night
invert signed int while preserving mid-point and extremes
boreal nest
-32768 maps to 32767, everything else maps to *-1
boreal nest
Two's compliment maths
knotty night
so 32767 does not map to -32768 ?
boreal nest
Nope, it maps to -32767 as that's what you'd expect flipping the sign on 32767 to do
knotty night
Yeah, but not ideal IMHO
proud oasis
why don't you just subtract 0 with N?
boreal nest
Overflow issues. 0-(-128) will overflow back to -128
knotty night
I would rather have -32767 unreachanble via invert than -32768
max deflection should always be achievable, so the logic if (value == short.MaxValue) works
if you had code that did that, feeding in an inverted axis would mean this code would never trigger
so, given that you must lose one unit of fidelity somewhere, the best place IMHO to lose it is one unit from maximum
proud oasis
name a use case
knotty night
UCR
proud oasis
in what situation would you want to invert -32768
knotty night
inverting an axis in a remapping application
proud oasis
k
knotty night
A similar problem arises if you want to remap from DirectInput to XInput
proud oasis
well.. if it ever reports -32768 i'd doubt it's value anyways
knotty night
mid-point of a DI axis is 32767 : more units at the high end of the scale
mid-point of XI axis is 0: more units at low end of scale
I dunno, maybe I am being overly anal about this 😛
I am mellowing some - currently in UCR, DI axes are flipped to make the mid-points line up with 100% fidelity - I think I should just not worry about it, as everyone just checks the "Invert" checkbox anyway
proud oasis
it's the same with floating point randomness. when you generate a number between 0 and 1 you want to include 0 but exclude 1
nobody bats an eye cause that's what happens anyways
but there are always people who think "1" would be possible randomness
chilly oar
@knotty night so DirectInput must be always between 0 and the max value, there no press is in the middle? I thought the API would make a transformation from the HID Report.
So why it shows up correclty under "joy.cpl" and DIview?
Is there any documentation about this? Can't find something so far.
chilly oar
Ok, I think I got it now.
Dinput do make a transformation of the values from the source values to 0 up to 65535 there 32767 is the center.
faint vapor
Can't wait to use the RGB SDK with my 
2 
quiet root
well use it then
glacial sable
i am still having a bit of trouble getting the example to run :/
quiet root
which example
faint vapor
@quiet root I can't, it doesn't support the W2 yet
quiet root
if u mean as in the bugs
proud oasis
or use this
quiet root
thats firmware side
faint vapor
need x64
proud oasis
this is x64
quiet root
u can build the dll urself tho
proud oasis
i renamed it
faint vapor
quiet root
i mean the whole point of it coming with the visual studio solution is that anyone can build it
via 1 click
proud oasis
works with both wooting one and two
true
but you still have to wait half an hour to install vs
quiet root
in germany ya
faint vapor
it works 🤔
quiet root
in any country with FTTH u wait like 10 minutes
quiet root
only 100mbit
quiet root
i get down rates of easily 400mbit even in the VS installer
proud oasis
i have 40 mbit upload
quiet root
@glacial sable so what cant u get to work
glacial sable
the baic rgb and analog examples . everythings goes well until the npm install
quiet root
wait theres examples?
proud oasis
@glacial sable do the following:
npm install --global --production windows-build-tools
cd into the example project, npm install ffi have fun
unless you are on linux
quiet root
yikes using npm build tools
quiet root
id actually recommend installing the vs build tools and python 2.7
never got the npm build tools to work on a pc
glacial sable
yea i tried npm install ffi but same error
quiet root
well because u cant run node-gyp
it requires vs build tools and python 2.7 to be installed
glacial sable
both is
quiet root
do u have any other python versions installed?
glacial sable
3.5 i think
quiet root
well then u need to tell node-gyp which python version to use
so
npm config set python /path/to/py2.7
glacial sable
still rip
quiet root
whats the exact error
glacial sable
thats the end of it
quiet root
i need a few lines higher up
proud oasis
wrong ffi version
change package.json to "ffi": "git+https://github.com/node-ffi/node-ffi.git"
quiet root
thats a problem with the package of the example then tho
should honestly have a natively compiled ndoe sdk
not rely on ffi
proud oasis
there are native builds on npm?
faint vapor
Just install ffi and the prerequisites
easy as that
hm, I can't address the numpad keys with coordinates that would make sense
16,1 (x,y) is Pg Up and 17,1 is F10 
(using the dll sent in here on a W2)
17,1 should actually be Numlock
knotty night
@chilly oar "Press in the middle"?
you mean like on an XInput controller, the click stick?
chilly oar
The middle from Min to Max and because Dinput is always from 0 to 65535, the center (middle) is always 32767.
But maybe not for special calibration, who knows...
boreal nest
I'm currently working on a "pure" NodeJS implementation of the SDK. I have one done that's nearly 1:1 the same to the existing but it's kinda ugly code. Only Node module needed being node-hid
There might already be one or two on npm for it
@faint vapor If you're using wooting_rgb_direct_set_key then it's a firmware bug at the moment that setting any of the new keys to the Two doesn't work correctly. For now you have to use the array functions. The version of the SDK I'm working on makes this a little easier
faint vapor
idk about working around firmware bugs in SDKs, sounds wrong to me
might also result in it never being fixed
boreal nest
Oh it doesn't fix anything, or even work around it. I've got a couple extra "undocumented" functions that poll the current profile from the keyboard so you can populate the array with the current state rather than having it all 0s
Just makes the array functions easier to use
boreal nest
Right now it works like...
const { Keyboard } = require('./keyboard');
let kb = Keyboard.get(); // enumerates and returns the first One/Two found
kb.init(); // does internal setup
// keyboard can now be used for analog, but for leds...
let { leds } = kb;
leds.mode = Keyboard.Modes.Direct; // defaults to Array
leds.init(); // calls the "undocumented" functions GetCurrentRgbProfileIndex to find the currently in-use profile and GetRgbMainProfile to read it + populate the Array mode buffers, and enables SDK mode on the keyboard
//leds.autoUpd = true; // does support automatic updating, but I don't use that in this example
leds.setKey(Keyboard.LEDs.S, 255, 255, 255); // in this mode, calls leds.directSetKey(...)
leds.updateKeyboard(); // does nothing in Direct mode. Calls the equiv of wooting_rgb_array_update_keyboard in Array mode
// do more stuff //
leds.reset(); // optional. Disables leds until .init() is called again, and resets any LED changes made
kb.disconnect(); // calls leds.reset() anyway
There's also leds.setLoc(row, col, r, g, b) alternatives for both modes in case those are preferred. Internally they look up the row/col on a table and call setKey() anyway
Still need to finish testing things then I'll probably toss it up on GitHub
proud oasis
repo?
boreal nest
Don't have one set up yet
proud oasis
eew
boreal nest
Well I didn't want to put it up without testing it decently well first, to avoid immediately pushing a dozen updates to fix bugs/typos
proud oasis
that's what branches are for
and squash merging into master
throwing a big blob on git keeps a clean history. true. BUT... it will also make it pretty hard to understand the thought process of the dev
boreal nest
https://github.com/ApeironTsuka/wooting-sdk Don't judge me for possibly ugly code XD
proud oasis
why does nobody want to audit my rgb sdk pull request? xD
boreal nest
Biggest difference is I reversed the order of arguments of sendFeature so that you can do .sendFeature(USB.GetRgbMainProfile, index) instead of .sendFeature(USB.GetRgbMainProfile, 0, 0, 0, index) ... the only call to sendFeatre() with arguments in a weird order is for SdkSingleColor which has b, g, r, index
boreal nest
Yeah, it's only SdkSingleColor (WOOTING_SINGLE_COLOR_COMMAND) that has them in the weird backwards order
proud oasis
i wonder how many write cycles the internal profile storage has before it wears out and dies
boreal nest
All of the other calls I've seen have the first real argument as parameter3, so I flipped the whole thing around. One outlier is better than a bunch of calls with 0, 0, 0, theSingleArgumentTheCallWants
proud oasis
and how much of a speed difference it would be to modify profiles instead of using the array / direct stuff
this is a insane thought though
boreal nest
It's not actually modifying the profile. It uses the calls the Wootility uses to preview your changes on the keyboard
proud oasis
hm ok
boreal nest
That's why .reset() still works
proud oasis
fun part about using the preview: the wooting internal effects don't break when you change colors through that
boreal nest
Oh they can if you do some weird things. I tried it in testing... keyboard freaks out a bit if you're using certain FX modes and try to change things
proud oasis
hm interesting
boreal nest
That's what the classifyEffects function inside of profileUpdateKeyboard is there for
proud oasis
does rgb accuracy change when you use the profile preview instead of the direct call?
boreal nest
Was trying with the Ripple mode + Random Colors enabled. It wasn't a fan of that. Also of note is that the Wootility itself is also not a big fan of anything using the keyboard while it's active. This includes both the SDK calls as well as the Profile mode calls
proud oasis
ye ofc it isn't happy about that
i still think the sdk needs a server infrastructure
boreal nest
Even something blinking with the Direct SDK calls makes it a little unhappy
proud oasis
so there is a service that does the usb stuff and everything just calls that service
so applications could be classified as background, overlay etc.
boreal nest
Using Profile mode, the color accuracy is the same as when setting via the Wootility
proud oasis
interesting
boreal nest
But it's using a completely different set of USB commands to do it
proud oasis
well i assume the profile related firmware code is more up2date than the public sdk api
boreal nest
Possibly
boreal nest
The upside of Profile mode is also that changing modes still works. You'd need to periodically poll .getCurrentProfile() to notice a change and either pre-load the entire set of 4 profile maps or call .loadCurrentProfile() whenever a change is detected
And no needed special handling of capslock/numlock. I just don't know if there are any side effects to doing things that way, which is why it defaults to Array mode
proud oasis
if (this.sdkEnabled) { return false; } wait whut.. you can even detect if someone uses the sdk?
boreal nest
It's a flag set when enableSdk() is called, which is always is as part of leds.init() in Direct and Array modes
proud oasis
oh gotcha
did you play with this yet? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array
just wondering cause you do alot of masking to ensure you stay in 8 bits
boreal nest
I tried with node-hid, but it only seems to support regular arrays
boreal nest
Or one of its dependencies is. I didn't dig too far into it
proud oasis
currently trying to figure out the profile change. the map structure is just [r,g,b,r,g,b,r,g,b,r,g,b...] using the led id's?
and you send this in two passes?
boreal nest
Yeah
boreal nest
Same structure as is returned from GetRgbColorsPart1/2
It's packed into 2-byte pairs
Internally I keep it as a usable map, but it's packed
let packRgb = (rgb) => { let x = ((0xf8&rgb[0])<<8)|((0xfc&rgb[1])<<3)|((0xf8&rgb[2])>>3); return [x&0xff, (x&0xff00)>>8 ]; };
let packMap = (map) => {
let out = [];
for (let i = 0, l = map.length; i < l; i+=3) { out.push(...packRgb(map.slice(i, i+3))); }
return out;
};```
before being sentDrops the lowest 3 bits, 2 bits, and 3 bits of RGB as part of the packing
Reason for what?
boreal nest
shrugs That's the format the keyboard expects from the Wootility
boreal nest
let unpackRgb = (a) => { let p = (a[1]<<8)|a[0]; return [(p&0xf800)>>8,(p&0x7e0)>>3,(p&0x1f)<<3]; };
let unpackMap = () => {
let a = [...color1, ...color2], out = [];
for (let i = 0, l = a.length; i < l; i+=2) { out.push(...unpackRgb([a[i], a[i+1]])); }
return out;
};```
Likewise the one it sends when you request a profileembedded can be a bitch when it comes to storage space
boreal nest
3/2/3 bits isn't a lot value-wise. Definitely nothing noticable to the naked eye
proud oasis
yep
i assume the profile api causes higher cpu load on the keyboard
just an assumption
boreal nest
That would be my guess as well. Or at least my fear
proud oasis
cause i think the sdk api pretty much reflects the framebuffer storage for the led controllers
boreal nest
I don't know how to test for that
proud oasis
so it's just a data forwarding instead of reprocessing
well. if you know the name of the led controllers i could look it up
boreal nest
Don't really intend to keep Profile mode around. If we can figure out why the SDK calls don't match color-wise, then that can be fixed and Array mode would be all you'd need
proud oasis
ye we just need a firmware update i assume
though it's highly possible the profile colors go through color correction before sent to the led controllers
boreal nest
The only downside then is you can't use .setBrightness in Direct or Array modes because the USB call used is ignored when using SDK stuff
proud oasis
ye true
in aurora i currently just have a layer above the whole keyboard that i can change the transparency for
kinda hacky
boreal nest
Would have to do that manually... read profile -> set brightness to full -> emulate brightness control by changing the rgb values in the Array buffer
proud oasis
profile does not need crc right?
boreal nest
CRC is generated as part of sendBuffer() regardless of what's being sent
chilly oar
@boreal nest Did you have a W2?
boreal nest
Yeah I do
chilly oar
Can you do me a favor and make a test for me.
Did you have steam installed on windows?
boreal nest
I'm a Linux user so... kinda?
chilly oar
Hmm, so you can't help me to test something
boreal nest
Ahh, sorry lol
quiet root
sad the twooting doesnt double as htc vice controller
chilly oar
If you uses the RAW analog interface you can have up to 16 different keys.
That's like two full controllers.
boreal nest
That's how many you can have held at once with the raw analog interface
knotty night
I completed the ScanCode -> Row/Column lookup table last night - now have a test script that checks every key on the keyboard and sees if it can light up the key, given just a scancode
@quiet root @proud oasis looks like those DLLs you gave me made improvements, but seeing the issues with NumLock, Numpad, F9 that I think I saw you guys talking about
proud oasis
emonas figured out how the wootility does stuff
different rgb api
seems to be more precise coloring
knotty night
ah, so they in the process of rewriting?
proud oasis
our guess is that the twooting caused a decent firmware rewrite
and they didn't touch the public sdk api yet
knotty night
So what, we have to wait, or are we able to hit this API ourselves?
proud oasis
the profile rgb api can also set all the led's in two usb communications
@boreal nest made a pure javascript sdk
it's in there
i'm currently in the progress of implementing the "wootility rgb preview" around the original api's
knotty night
I don't think I can use that from C#?
boreal nest
Nah, but you can easily figure out how it works to do it on the C# side
proud oasis
cause we think the api's are not in the sdk for good reason
knotty night
Well if you get any joy, lemme know 😃
proud oasis
well for some reason my profile color part packages always fail though
@boreal nest this looking somewhat off to you? https://share.home.gottz.de/2019/02/devenv_2019-02-26_12-54-42.png
boreal nest
You're not copying the full rgb buffer in
knotty night
@boreal nest Fixed your readme for you
boreal nest
I think
proud oasis
huh? i thought i need to fill it with 50%
boreal nest
Wait no nvm yeah, I misread lol
proud oasis
static bool wooting_profile_update() {
printf("wooting_profile_update\n");
if (!wooting_usb_find_keyboard()) return false;
uint8_t count = wooting_usb_meta.wooting_one ? 96 : 118;
printf("first buffer %u\n", wooting_usb_send_profile_buffer(0, count/2-1, rgb_profile_buffer));
printf("second buffer %u\n", wooting_usb_send_profile_buffer(count/2, count-1, rgb_profile_buffer + count));
printf("refresh rgb colors %u\n", wooting_usb_send_feature(WOOTING_PROFILE_REFRESH_RGB_COLORS, 0, 0, 0, 0));
return true;
}
that's how i call it
you know.. pointer arithmetic. thus rgb_profile_buffer + count points to the second half of the buffer
boreal nest
What part is failing?
knotty night
You just needed the file to have the .md extension
proud oasis
all wooting_usb_send_profile_buffer calls
the buffer is fine btw. i constructed and verified it
boreal nest
Thanks @knotty night lol
proud oasis
dis is magic
boreal nest
Only other thought is the memcpy line. You're copying 6 bytes over the end since size includes the header
proud oasis
8 bytes over
boreal nest
8?
proud oasis
do i need to crc the header too?
boreal nest
report_buffer[127] and report_buffer[128] being the crc
Yep. The full report, except for the final 2 bytes where the crc goes
But in your screenshot there, the final value of size is 124, so you're missing 5 bytes somewhere
proud oasis
start and end is fine though right?
boreal nest
Should be
It might be because the full packet isn't using up the entire 127 bytes above the crc. Should have it explicitly set report_buffer[127] and [128]
Since the firmware expects 127/128 to have the crc specifically, and for the crc to be of bytes 0 through 126 (even the unused 0s)
proud oasis
ah ok
such yeps
this was it
another thing i wonder is.. why did nobody try this before the EU shipments started happening
boreal nest
Try what?
proud oasis
taking the api apart like that
boreal nest
Rocky disected the Wootility back in October, apparently. There's a pin with the names of all of the USB commands
proud oasis
oh.. holy shit
boreal nest
Same info I dug in there to find before I knew that pin was there lol
Doesn't have what arguments any of them take, but it's a good jumping off point for where to look
proud oasis
i wish web usb was less restrictive to what devices you can use
would be fun to create a control panel that you can simply use by browsing to it
boreal nest
That also sounds very scary. Imagine a website bricking keyboards just by visiting
proud oasis
this is why we can't have nice things right?
boreal nest
Yep
proud oasis
just a glympse at where this could be used: chromebooks
boreal nest
For that you could install it as an extension, which would have elevated permissions and possibly access to more things like full HID access
boreal nest
Same with Chrome - there are things installed extensions and apps have access to that standard web never will
knotty night
I suspect HTML5Gamepad is using some form of HID access?
boreal nest
Not directly. The browser does the HID stuff and sends gamepad events with changes
knotty night
That would make sense
tight panther
any idea why i get Keyboard not connected in the basic node example?
faint vapor
@tight panther Wooting2?
faint vapor
@tight panther The current version only works with the Wooting 1.
Options:
- Wait for this PR: https://github.com/WootingKb/wooting-rgb-sdk/pull/10
- Use the "pre-merge" binary: https://discordapp.com/channels/167181566978555904/453072453435129856/549702840571002922
knotty night
POC for AHK being able to "Find" the appropriate key on a Wooting for a given hotkey
via the analog / rgb APIs
so, for example, your a:: hotkey that binds to Q can also easily get analog values for the A key on the wooting
I am trying to make a layout-independent way to access the API, as the current .NET setup seems to be QWERTY specific
So this all relies on a scancode to row/column lookup table, then a lookup on that scancode which yields a locale-specific name
knotty night
proud oasis
i still wonder why people pay for github private
faint vapor
It's free
weary mulch
it's only 2 months out of date, if that's already very... how out of date is uh.... man... uh... some other example...
wet knot
This is honestly the one thing I love about github
I have 3 emails so I've absuded it
knotty night
OK, I got every key working on my keyboard with my AHK wrapper - able to find wooting row/column for every key on keyboard and get analog values. rgb not working for all keys, but AFAIK that's an API problem
Any non-QWERTY / Non-ISO wooting owners out there fancy testing for me? You don't need AHK installed
quiet root
well i got a qwertz iso board
how did it know that z is on row "2"
is actually row 3
knotty night
it uses AHK to subscribe to every scancode, and AHK to get the name for that scancode
the row / column is a scancode to row/col table I made
knotty night
I would have thought scancodes remained constant for a key in a given location
so the key to the right of T - labelled Z for you and Y for me, should have same SC
knotty night
so what code does that key show for you in my app?
quiet root
and pls use the disconnect function when closing ur ahk app
knotty night
For me, that is 21
knotty night
I just tried to match the charts they have for the API
it's not meant to be user-facing stuff
quiet root
well rn it is
knotty night
it's not something aimed at the consumer masses, it's a debug tool
showing the values I am passing to the API
I don't subscribe to every key via the api to begin with
I subscribe to every key using AHK
the first time you press a key, it does a lookup on the scancode of that AHK key, and tries to find the matching wooting key
when you press Z, but it gets row/col wrong, I take it you do not get analog values appearing when you press Z?
quiet root
i do but as a human i dont start counting from 0
i mean thats pürob a "me thing" but i correct values to make it easier for myself
knotty night
When you press a key, something like this will appear:
Subscribed to Key via API
Code: 21, Name: y
Row: 2, Column: 6
i will just unsubscribe from explaining the same thing 200 more times
knotty night
This says "I saw that key via AHK, now I am going to start polling the analog API, passing it row 2, column 6
If I start increasing those by 1, it makes it more difficult to use as a tool
It's a tool to debug a look up table to an interface of an API...
so I report the values I got from the lookup table accurately
astral zinc
Hey there! Did the music spectrum happen? :/
hybrid lake
Hi all. I want to open a discussion about the direction of the RGB SDK and the Analog SDK. I've written posts on the github repo's. Please check them out and share your thoughts!
https://github.com/WootingKb/wooting-analog-sdk/issues/14
https://github.com/WootingKb/wooting-rgb-sdk/issues/13
proud oasis
@astral zinc this?
oh jeroen.. that's the gamma profile you sent to me
much more accurate than without it
simply download this: https://ci.appveyor.com/project/antonpup/aurora/builds/22635337/artifacts and throw this dll into the aurora directory:
quiet root
and not get numpad cause aurora doesnt have the twooting
proud oasis
@quiet root you didn't realize the link right?
proud oasis
ye.
quiet root
still doesnt have the twooting in GH
proud oasis
just use my dll too. it also does gamma correction for the rgb so colors appear more accurate.
you might want to set that in aurora too
proud oasis
?
wooting one
that's what you are quoting there
this is the wooting two build: https://ci.appveyor.com/project/antonpup/aurora/builds/22635337/artifacts
quiet root
thats the GH repo of aurora
quiet root
i see
ya 3 billion branches
instead of a simple master/stable thing
k i shall never contrib to aurora
proud oasis
you aware there are more than two people working on aurora right?
quiet root
yes so?
proud oasis
people create their own branches for features n stuff
totally the right thing to do
and appveyor simply builds everything
quiet root
the right thing would be forking and branching in ur own repo
and then PR in the main repo in master
proud oasis
you half asleep or something? get your facts straight. this is not my build
i only built the dll
quiet root
i never claimed its urs
lol
i just said creating 3 billion branches in the main repo is dumb
and the right thing would be that people fork, code updates in their repo and then PR the changes to master
and then having stable and maybe a branch for like a bit faster releases
proud oasis
including active contributors?
proud oasis
doesn't work for private repo's though
quiet root
lol we are literally talking about a public repo
proud oasis
it was a comment about that concept
proud oasis
nice. just realized you can customize caps / scroll / num with aurora
normal sapphire
I've just released an early version of some Rust bindings to the Wooting SDK for anyone interested. (https://github.com/davidtwco/rust-wooting-sdk / https://crates.io/crates/wooting-sdk)
placid ledge
@quiet root 😩 👌 sry the branches are so triggering
Some of the branches are a bit ambiguous as they are old/dead, but atm the only ones that matter are master, dev, v0.6 (then gh-pages & gh-pages-dev) which are all kinda self explanitory
quiet root
aöö good just gave my opinion from bigger open source projects with more than 100 contribs
imo the cleanest solution
placid ledge
using the forks for individual development is a good idea
the branches are fairly messy tbf, you planted a seed and I procrastinated by cleaning them up a bit haha
quiet root
whos maintaining the main repo? only you?
placid ledge
At this point it's kinda a mess, but I am the 'lead'(?) developer I guess
As Anton isn't able to work on it anymore he left it to me to look after
quiet root
was about to ask since its still on antons profile
placid ledge
yeah, there's plans to move it to an organisation at some point, might drill him down more on that
quiet root
that should have happened a bit sooner anyway to keep it "clean" idk also makes it easier to change leads
btw does the dev build install over the stable build?
if i just run the setup
strong siren
i dont use the setup but it should install over it yes
boreal nest
GottZ, you're a genius
knotty night
@hybrid lake When you said it was real expensive to join the USB club, what are you referring to? Cost of getting a VID?
knotty night
and what would that bring us?
It gets you a VID if you don't already have one it seems
But you can buy a single VID for a one-off fee of $2000 apparently?
Oh, looks like it maybe went up
Currently looks to be $5k, going up to $6k in June
I was just wondering if we could maybe share with someone else - for example, I wonder if Nefarius is considering getting one - I mean, there's 65k PIDs in a VID, we ain't gonna use them all...
Saying that tho, not really sure we need an official one? I mean vJoy has been using a random one for years (BEAD/1234)
OpenMoko appear to be giving out free PIDs if you are FOSS: http://wiki.openmoko.org/wiki/USB_Product_IDs
Must meet Open Source Hardware rules:
https://www.oshwa.org/definition/
knotty night
Or pid.codes
http://pid.codes
proud oasis
when i read from the keyboard the first 4 bytes are 0xD0 0xDA 0xFF 0x88 i assume that's the magic number the keyboard always tells us right?
¯_(ツ)_/¯
if (wooting_firmware_version.combined <= 0x011803) {
red = gammaFilter[red * 80 / 100];
green = gammaFilter[green];
blue = gammaFilter[blue * 80 / 100];
}
i guess that's alright eh?
knotty night
@proud oasis so model is encoded in serial? ANSI/ISO too?
proud oasis
no i derive it from the hid pid
knotty night
Oh, different PIDs, would make sense
proud oasis
i also threw this in now: if (!wooting_usb_meta.connected) wooting_usb_find_keyboard();
cause a connect is required to derive the version
the gamma profile could probably be improved even further but this is quite decent already.
@knotty night
https://github.com/WootingKb/wooting-rgb-sdk/blob/0fc39fa1b0e5436005278e6eb63a8217e2259f9f/src/wooting-usb.h#L20-L26
https://github.com/WootingKb/wooting-rgb-sdk/blob/0fc39fa1b0e5436005278e6eb63a8217e2259f9f/src/wooting-usb.c#L19
https://github.com/WootingKb/wooting-rgb-sdk/blob/0fc39fa1b0e5436005278e6eb63a8217e2259f9f/src/wooting-usb.c#L84-L100
proud oasis
@knotty night i assume i could use the serial number to derive that information
ISO / ANSI i mean
hm. the serial contains product id, revision, product number, supplier, year of production and week of production. i assume the product id would do the job.
anyone with a ansi wooting two who could give me the contents between W and H in your serial number? (not from wootility but from the sticker on your keyboard please)
contains product number and revision
knotty night
can do when I get home
proud oasis
oh wait.. there is a model number too
proud oasis
no i dea how to retrive that but i can get the key count and device config
boreal nest
@proud oasis The four bytes are
magic number 1
magic number 2
I have no idea
status code of that feature report (136=auccess, 255=error, 102=unknown report)
proud oasis
hm. ok so it reports if something was successful
boreal nest
That third byte is never referenced anywhere and the Wootility's own verification code ignores it
proud oasis
i also noticed it grants you with crc
boreal nest
Yeah, buffer 126/127, same rules as for the buffers sent to it
proud oasis
yep.
D0DAFF8870000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009AAD00 (example response from GetNumberOfKeys)
boreal nest
Seems like "best practice" is to always do a read immediately after a feature report
if (this.ledhdl.sendFeatureReport(buf) == ReportSize) {
let buffer = this.ledhdl.readTimeout(20);
if ((buffer.length < 128) ||
(Keyboard.getCrc16ccitt(buffer, buffer.length - 2) != ((buffer[127] << 8) | buffer[126])) ||
((buffer[0] != 0xd0) || (buffer[1] != 0xda)) ||
(buffer[3] != USB.Success)) { return undefined; }
return buffer.slice(4, 126);
}```
How it works in mine nowGetNumberOfKeys is an odd one. Seems to return the number of keys that GetAnalogValues supplies. Expected values: 87 (One in ANSI layout), 88 (One in ISO), and 111 (Two)
knotty night
IIRC, someone said something before about best practice being to call some API endpoint on dispose
can't seem to see anything
I am calling RGBControl.Reset(); on exit of my library, don't see any equivalent for analog
I see void wooting_usb_disconnect(bool trigger_cb) in wooting-usb.c, but I do not see it exposed in the .NET wrapper
quiet root
because its not exposed in the dll
all exported functions by the unmodified github code for the sdk dll
ud prob use the last one wooting_set_disconnected_cb
knotty night
that's to be notified if the kb disconnects, no?
I am just wondering if there is anything I should do as my library exits, to play nice
I seem to remember someone the other day saying my script should do something on exit
boreal nest
There is no equiv on the analog side, as analog is a read-only API
And yes, it should always call the reset function as the SDK uses an RGB mode that blocks most things from working visually (caps lock, num lock, fn lock, winkey lock, rgb fx, rgb profile switching though the analog bindings still change, etc)
knotty night
OK, covered all that I think, starting to prepare for release, documentation etc...
If there's anyone who feels like testing who has an ANSI wooting, I could maybe add ANSI support for 1.0
faint vapor
Uhm
Anyone got an idea how to write tests for Wooting stuff? 
I mean I could just color a key and if that doesn't set the keyboard on fire then hooray
boreal nest
What sort of tests?
proud oasis
you forgot that GetNumberOfKeys returns 112 for two iso. so i'd say.. this is all that's required to differentiate between iso and ansi
boreal nest
Or you can call GetDeviceConfig. buffer[5] is the layout: 0 for ANSI, 1 for ISO
You can also pull other useful info from there:
Default digital profile, buffer[0] & 0x01
XInput disabled flag, buffer[0] & 0x80
Tachyon mode enabled flag, buffer[0] & 0x40
Windows key disabled in firmware flag, buffer[0] & 0x20
Default analog profile, buffer[1]
Default mode, buffer[2] (not sure what this is exactly, has been consistently 0 in limited testing)
Fn key analog keycode, buffer[3]
Mode key analog keycode, buffer[4]
Fn lock enabled by default in firmware flag, buffer[6] > 0
Oh, default mode is 0 = digital, 1 = analog... selector between which profile type is default I suppose
Been trying to put a little helper/toolkit thing together to watch key locks (num, caps, scroll, win, fn) and handle the color switching for them, as well as handle the brightness keys and reloading led profiles when it lazily detects it's been changed (watching for GetCurrentRgbProfileIndex to change) but it seems watching the analog interface puts too much of a strain on things. As does watching GetCurrentRgbProfileIndex. Might have to add a proper queuing system in place so that the led/config interface has queued writes with 25-50ms between to give it a chance to catch up ... if that would work. The strain is presented as a segfault (in the case of the analog interface) or a general "could not read data from device" error on the readTimeout that follows sendFeature
I mean.. it works fine on its own, but added to my system monitor thing, which was at most doing 3 or 4 calls to sdkColorsReport every 200ms, it was apparently too much for it
knotty night
Where do I get GetNumberOfKeys ? Is it part of a new analog/rgb dll?
boreal nest
Check the top pinned message in here for it, and send it via wooting_usb_send_feature with the params as 0,0,0,0
knotty night
I use the .NET wrapper
boreal nest
Does the .Net wrapper give you access to the USB calls?
boreal nest
Then.. not much you can do without modifying the wrapper to add it, I suppose
knotty night
Well I am currently using a local build anyway
Because the latest nuget version is out of date
I merged a change to fix the wrapper for .NET, and he hasn't pushed a nuget package for it yet
boreal nest
There's also GetDigitalProfile which might be useful. First (and only) return value (buffer[0]) is the inverse analog value representing the set actuation point (meaning 255 is key up, 0 is key bottomed out)
knotty night
I don't think I have that either
boreal nest
Can change whenever the profile switches, so watching for that would be needed as well, but it could come in handy if you want to support digital keys when only reading analog
knotty night
https://github.com/simon-wh/Wooting.NET/blob/master/Wooting.NET/RGBControl.cs
https://github.com/simon-wh/Wooting.NET/blob/master/Wooting.NET/AnalogReader.cs
Those are the two interfaces you get with the .NET wrapper
I am crap at imports etc, so I would not really know how to add more myself
boreal nest
I don't know C#, but uhh..
[DllImport(sdkDLL, EntryPoint = "wooting_usb_send_feature", CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs(UnmanagedType.I1)]
public static bool SendFeature(byte command, byte param0 = 0, byte param1 = 0, byte param2 = 0, byte param3 = 0);
And via that I can get number of keys?
boreal nest
There's probably more to it. Seems too simple
knotty night
lemme try it in my fork
placid ledge
I hadn't realised that the wooting_usb* functions needed to be wrapped around as well
must have overlooked them when I was setting up the wrapper
boreal nest
They wouldn't normally
knotty night
oh hi !
boreal nest
But you can use them to uhh... use "undocumented" calls
At least until more official versions are either added to the SDK proper or are just otherwise opened up
placid ledge
Ah, right, that must've been why I ignored them, seems like they're the calls used by the rgb sdk, so circumventing that and going straight to wooting_usb wasn't my intention.
knotty night
If you are about and active, would be great if we could get this sorted and a new nuget package pushed today
placid ledge
And @knotty night I can update the nuget package whenever you want me to, if you've got more you think you'll throw in then I can leave it a bit or do it later
knotty night
I dunno if you have been keeping abreast of the plans, but it looks like the APIs are going to be changing to use ScanCode as the identifier
AFAIK, your existing key name to wooting code enum is only valid for QWERTY
boreal nest
@knotty night You'd also need uhm... hid_read to read back the response
knotty night
I have some helpers and stuff in my WootingAHK repo that may belong better in the .NET wrapper
placid ledge
I've roughly been keeping an eye on what's happening with stuff
knotty night
ie a ScanCode <-> Row/Column lookup table
placid ledge
I was under the impression that the wooting keys applies to the particular led rather than what it has as its input
Oh wait, I've forgotten how I set mine up, ignore that last bit
knotty night
Other apps interfacing with the wooting should not really need to use a proprietary way to identify keys
placid ledge
but the wooting keys do correspond to that position of the keyboard, not what it has as its input
yeah, in aurora it's really frustrating having a million different enums to convert into for interfacing with various devices
they all do it slightly differently
knotty night
in your enum, Keys.Q points to the top left letter
placid ledge
if the scan code works s.t. it is effectively just the same thing as what I've set up where Q is the Q led on the standard layout and doesn't change with what your layout then it doesn't really change a whole pile for me
Yeah
If it changes based on the keyboard layout, that'd be problematic
placid ledge
Yeah, but I'm talking about Q pointing to the that point on the keyboard regardless of layout
placid ledge
It's necessary for lighting up over the canvas, I just use it as an easier way of pointing to the areas of the keyboard
knotty night
So ScanCode 16 points to the position of Q on a QWERTY
then you have a "GetKeyName" function, which on a QWERTY, would return Q
but on AZERTY would return A
placid ledge
If there's a way to light say, the key that inputs Q and the key that is in the position of Q in the standard layout, then that's fine
knotty night
plus you have the opposite
given a key name, get the SC, which then gets you the row/col
placid ledge
but only having it light up the key that inputs Q is not helpful
knotty night
why not?
if you want to refer to things purely by position, use the row/col
if you want to say "I need to light up the Q key, regardless of where it currently is", use ScanCode
placid ledge
I mean, if the only way to light up a key is one where it lights up the key that inputs the given key, that's not helpful
knotty night
no, you have both
placid ledge
That's fine then
For aurora I don't care what it inputs, only lighting up the key in that position
boreal nest
@knotty night There's an interesting call in the keyboard already labeled GetHidCodeDataProfile. Returns a list of ids that are mapped to both key name and row/col. For instance, the first returned value is 38. In their lookup table, this comes out to be Escape, and paired to row/col 0,0. Could this be of help in doing a layout-agnostic setup?
knotty night
It should be some non-proprietary way - ie Scan Code or maybe VK
But I think VK is windows specific?
boreal nest
Probably Windows-specific
knotty night
Imagine a game or something interfacing with the Wooting. Let's say it's purely using RGB
It has input come in in it's poll loop for the SC of the Q key
it want to light up the Q key when you hold it, for whatever reason
So it needs to be able to set RGB from a Scan Code
Similar kind of thing for a game with abilities on 1/2/3/4 maybe
it wants to set LED red for when skill is on cooldown, and green for when it is available
Same deal with my AHK wrapper - I have a hotkey to the Q key, and I also want to get analog values for it
So I just do GetKeySC(A_ThisHotkey) and I have the SC for that hotkey
If all you want to do is a ripple effect or something, then you care not about SCs really, you just use raw row/col
boreal nest
Worse is, right now, the LED and analog code maps aren't even the same
A is 6 under LEDs, but 49 under analog
proud oasis
ye i assume what we get are the true controller adresses
boreal nest
I'll probably end up adding a Wooting<->scan code conversion table in mine so that all of the functions take scan codes and internally get converted to their appropriate analog/LED address
knotty night
Whew, that took a lot longer than expected to tidy things up and finish the docs
Am about ready to make initial release, barring ANSI support
boreal nest
The problem with scan codes is there's no official single standard. USB has its own set. PS/2 has its own set. Windows has its own virtual set...
F1 is 0x70 in Windows VK, USB it's 0x3a, 0x3b in PS/2 I think...
knotty night
really?
I have not messed around with it that much at a native level, mainly via Interception
boreal nest
And then IBM's website says F1 is 0x07
knotty night
and when I do that, don't matter if it comes from USB or PS/2, same value
some stuff not supported via interception on USB tho - media keys
boreal nest
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.keyboardtechref/doc/kybdtech/Key.htm IBM
http://www.kbdedit.com/manual/low_level_vk_list.html Windows VK
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html PS/2 I think?
https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2 USB
None of them are the least bit consistent with eachother
boreal nest
Gotta link them to something
The translation from scan code to locale's character is the OS's job
knotty night
it's from android, could be different, but I take your point
we need an OS-agnostic way
boreal nest
http://www.quadibloc.com/comp/scan.htm Table on here has 4 different scan code sets
None of which are the Windows VK ones
knotty night
Yeah, I never really truly groked SCs
such a deep subject
so many ifs and buts
All I can say as there seems to be a way that consistently works on windows
boreal nest
There's also the issue that A1, A2, A3, Mode, and Fn don't have standard scan codes. Fn key itself isn't normally sent to the OS, either
Windows abstracts the hardware scan codes (in one of the at least 4 sets from that chart) into its own VK scan code standard
knotty night
Yeah, that too, but there are other ways to handle that
I am not against RGB using row/col natively
that kind of makes sense
boreal nest
But then that standard isn't likely to extend to Mac or Linux
knotty night
well, unless maybe that standard can be made to work there, but that could be a lot of work
boreal nest
So really, there's no single standard scan code that can be used - using the Wooting set for analog and translating to/from led is as good an option as any
knotty night
I don't see that for input, you don't need A1, A2 etc surely?
boreal nest
Or led and translate to/from analog
knotty night
only conceivably for RGB?
boreal nest
You can read the A1/2/3, Fn, and Mode keys from analog
boreal nest
(and it's quite helpful to, since in SDK mode you have to manually catch Fn+Mode etc to do the toggle light yourself)
knotty night
Or even one endpoint specifically to subscribe to mode, since that's logically separate, then a SubscribeA(<int>) to subscribe to A key # whatever
boreal nest
Since there's no standard... it's just as easy to on-the-fly detect locale and convert the Wooting maps to the locale via a table in memory rather than constants
knotty night
Why try and jam all possible normal keys, plus the extras into one range?
boreal nest
You know which location on the board the 'A' key is, and what key is there in locale X
Well I mean like, say the OS is configured with an AZERTY layout. You can on-the-fly reconfigure the maps to say the 'Q' key is now the 'A' key. Has the same behind-the-scenes value but is now under the identifier 'A'. So SubscribeA() now subscribes to the internal ID of 'Q'
Really no matter what choice, it's going to be a headache
knotty night
Yeah, but if you change language layout, that's your bag
we don't have a crystal ball
Looking at this wooting_usb_send_feature, not seeing how it is gonna help me get number of keys
oh right, I see
hid_read
boreal nest
wooting_usb_send_feature(16, 0, 0, 0, 0); hid_read(whatever arguments I don't remember offhand);
The first 4 bytes are header, then the data starts
boreal nest
Header is:
0xd0
0xda
No clue what this byte is for. Seems to be ignored.
Either 0x66 (unknown command), 0x88 (success), or 0xff (error)
It's included from hidapi
knotty night
So I would not be able to do this in C# simply it seems, best to tweak with the C
boreal nest
int HID_API_EXPORT HID_API_CALL hid_read(hid_device *device, unsigned char *data, size_t length);
Has that signature
knotty night
Yeah, but then dealing with that, dunno what values exactly I need, sounds like a lot of stabbing in the dark when I was looking to wrap things up for the night
boreal nest
Ahh, fair enough lol
knotty night
It's no biggie, can add ANSI support in 0.0.2 😛
Just get something out there and check it doesn't fall over horribly when the masses get their hands on it 😉
boreal nest
GetNumberOfKeys returns:
On the One: 87 (ANSI) or 88 (ISO)
On the Two: 111 (ANSI) or 112 (ISO)
knotty night
Yeah but I have no idea how to import hid_read
don't see it on pinvoke.net
GetRawInputData maybe?
boreal nest
No idea. I don't really touch C#
knotty night
I rarely go down to the basement - it's dark and scary 😛
I tend to stay upstairs in fluffy managed land
boreal nest
Been sticking more to NodeJS these days so I know how you feel lol
faint vapor
Created some GitHub review 3 days ago
Didn't know you'd had to send it specifically
so it was drafting around for like 3 days 
proud oasis
@knotty night last night i had a dream.. there is a command to disable digital input from the keyboard. it's also possible to make the sdk work with multiple keyboards and give them unique id's through the serial number or usb path... now think about four wootings where you use three of them for macros with different rgb patterns on them. all hooked in ahk xD
that's not impossible
boreal nest
I tried looking into how to switch what profile the keyboard is using via software. There's two commands - ActivateProfile and LoadRgbProfile. Unforunately, LoadRgbProfile doesn't appear to switch the digital/analog side of things (no surprise there), and I've had no success getting ActivateProfile to do anything other than crash the firmware when passed anything other than 0 or 1 despite it appearing to take profile number (0 to 3)
proud oasis
active profile crashes?! i'll verify that
i was hoping to add it into aurora so i can see the active profile
boreal nest
sendFeature(23, 2).. about a second later, keyboard crashes
boreal nest
Oh, no, reading is fine. I was looking for a way to switch via software the way the Wootility does
proud oasis
i really think we need a linux version of aurora
boreal nest
They were supposedly doing a full rewrite of Aurora with cross-platform in mind.. but the dev-rewrite branch hasn't been touched in months
proud oasis
i assume it would work if rgb turns off, then you set it and then back on
boreal nest
Can confirm ActivateProfile does what it says on the tin when passed 1 at least. But, > 1 doesn't work despite the Wootility apparently sending it 0-3 when you switch profiles. I don't know what I'm doing wrong
Oh I'm just an idiot is all. It's not been crashing. It's been locking the enter key down.... derp
And the reason it was doing that is because I was switching to a profile without digital keys enabled... in the middle of a key event
boreal nest
Next up.. uhm.. idk.. custom loading (but not saving!) full profiles?
knotty night
@proud oasis I could pretty much do all that already for digital keys
It's just that the Wooting APIs don't support multi-device
proud oasis
ye. it just uses the first device it finds
knotty night
For disabling keys, you probably want to allow it on a per-key basis. Blocking the whole keyboard is a bit brutal
proud oasis
for a macro keyboard scenario that's quite a thing
knotty night
Yeah, in that case
But surely anyone using a Wooting just as a macro keyboard needs their head examined?
or just straight up got too much money for their own good 😛
proud oasis
tbh look at streamdeck and other "solutions"
knotty night
Needing analog on a 2nd keyboard seems pretty edge-casey, and we already have it fully working for difgital
proud oasis
their price is insane
knotty night
SD is not analog
proud oasis
so i'd prefer buying a second wooting instead
knotty night
Yeah I have one
2nd hand tho
new they are stupid pricey
SD being controlled from AHK
proud oasis
that is nice indeed
knotty night
Multi-SD support
use one SD to control 2nd SD
Well, I added the multi-SD support, still waiting on someone to test it
The new librasry I am using is "OpenMacroBoard" - a guy is trying to put together an open SD-like device you can build yourself
proud oasis
awesome
btw.. wanna know something stupid?
currently reverse engineering another usb device
proud oasis
page:usage
0x1337:1 = reserved by the spec. thus illegal usage but who cares. 0xff00 - 0xffff is vendor specific
0x0001:6 = keyboard
0x000C:1 = consumer control (this could be the api i assume)
0x0001:5 = gamepad
0xffff:1 = vendor defined. (no idea)
0x0001:5 = gamepad```
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdfinteresting that it lists itself twice as gamepad and keyboard
proud oasis
@boreal nest do you by any chance know if this is obtainable with node-hid? https://github.com/signal11/hidapi/issues/99 this is literally what i try to reimplement in node: https://share.home.gottz.de/2019/03/devenv_2019-03-03_17-04-36.png
(not wooting related though)
proud oasis
if (type == "cmd" && hdev.readTimeout(200).length > 0) {
type = "raw";
}
works ¯_(ツ)_/¯
boreal nest
Doesn't seem to. There's a package named usb that has bMaxPacketSize0 under the device descriptor, but that's all I've found with Node bindings (uses libusb)
Device {
busNumber: 1,
deviceAddress: 46,
deviceDescriptor:
{ bLength: 18,
bDescriptorType: 1,
bcdUSB: 512,
bDeviceClass: 0,
bDeviceSubClass: 0,
bDeviceProtocol: 0,
bMaxPacketSize0: 64,
idVendor: 1003,
idProduct: 65282,
bcdDevice: 273,
iManufacturer: 1,
iProduct: 2,
iSerialNumber: 0,
bNumConfigurations: 1 },
portNumbers: [ 14 ] }```
Example one for the Two. Dunno how useful any of the info is for what you're after
hallow tartan
hey i still havent gotting my black switches i orderd them on 16 feb said it was posted last week i sent an email no has gotting back
i sent email thursday
glacial horizon
@wide nymph
wide nymph
Hmmmmmmm, shipping. Keep it on the emails. We are processing as much as possible. A lot shipped out.
hallow tartan
@wide nymph ok am just getting a bit worried
@wide nymph they said they shiped it over a week a go
knotty night
@proud oasis well all I can tell from that is it's something Panasonic (Or at least using their VID)
proud oasis
na. i'm tampering with a lexip mouse. pledged it on kickstarter. though they made alot more money than wooting, they failed badly at software. almost nobody actually likes this mouse.
since i already reverse engineered their control panel and driver i'm going to add rgb support for aurora first and then head my findings over to a friend who will then implement a proper driver and cp in rust-lang for the community.
grizzled wolf
tbh, I think most of the attention for lexip after their mouse was for their ceramic feet
proud oasis
the feet are definitely neat.
but i'd clearly not recommend this mouse to anyone
oh and i figured out quite some details
the kickstarter project was a hoax
they made the exact same mouse in 2011
the control panel is mostly untouched since then
and i even traced down the developers of the cp. turns out they left the company around 2011/2012 (firmware and cp devs)
knotty night
That's low
In the market for a new mouse, but nothing really grabs me ATM. I am kind of tied to Logitech, as they seem to be the only people who do switchable free/ratcheted wheels with L/R tilt
I want the aforementioned wheel features plus 7 or so extra buttons
proud oasis
the thumb joystick of the lexip sure is nice though
i also use it for scrolling and side scrolling
knotty night
meh to round throw thumbsticks
proud oasis
i srsly abandoned my mx master for it