#🤖│community_dev
1 messages · Page 19 of 1
Can always find it used on ebay - probably rather cheap from someone pissed off and wanting rid of it
i assume this will indeed happen
yeah someone in my area is selling one new because it was supposed to support Macs later in it's life, but it never did.
the whole cp is written in c#. including the helper runtimes. i doubt this is easily portable to macos
but hey.. thanks to c# it's decompilable
i smell a rewrite in c
You can run C# on Mac/Linux via Mono, as long as the devs avoided certain Windows-only extentions
.Net core?
the cp contains a hell lot of winapi stuff so.. no.
rip
Welp, maybe via Mono in Wine, then
I might try my hand at a simple profile auto-switcher. What's the best trigger for it... process start or process switch? Start is easier (watch for game.exe to appear -> load profile(s)) but I feel switch would be more useful (watch for game.exe to become the active window -> load profile(s) -> alt-tab to something else -> profile(s) for that load instead) but I worry about write cycles since there appears to be no way around writing over existing keybinds/DKS when that's back
It would be really cool if there were an API to control the wootility. So many OEMs lack such functionality
Would allow 3rd-party apps to co-exist nicely with the wootility
@boreal nest Just profile switching is safe. There's no EEPROM involved
However, for automatic loading/switching (load game->game-related profiles are loaded onto the keyboard under configured profiles) does I'd imagine. Something that the Wootility would end up doing itself for such a system. Wouldn't do any more writes than someone manually swapping active profiles around for the same purpose, I suppose?
Have been leaning towards watching for process start so that things are only written twice worst-case since the use-case of alt-tabbing around and having profiles loading for whatever is the active window doesn't seem the most useful
Current thought process:
load config (profile name from Wootility, intended slot of 0-3, whether to backup/restore each slot individually)
setup watchers via find-process (or similar module)
if found
. back up existing profiles in configured slots if different than the ones intended to be loaded (using wootility_config.json for names) if configured to
. load configured named profiles from beta_profiles.json and load into appropriate slots, updating wootility_config.json with new names
. when the process exits, load backup profiles back onto configured slots, if needed
Hopefully that would avoid as many writes as is possible to - especially when configured not to restore
I think limiting the wootility to only being able to load into 3 slots is a mistake
Seems massively limiting, going to regret it later IMHO
There being 3 slots for the 3 buttons - fine
but that should not be the sole pool it can load from
Technically does 4. But I think that's for internal memory limitations
Then maybe doing everything on the device is a mistake or something
But other OEM devices do not have this limitation
And I don't see it as a solvable problem
The user probably only cares about "load this profile plz"
If you start requiring them to unload a profile just to do that, that's not cool
I'm not sure how large the EEPROM is, but a single RGB profile alone one a Two takes up 302 bytes. Add a further ~160 bytes for the analog info.. and those 4 profiles alone are ~1.2kb
I am not worried about RGB
Oh derp I REALLY screwed that math up
More of an issue for input profiles
If / when you get automatic profile switching, that simply does not work with the 3 slot mode
model
On-board saved is so you don't need the software running in order to swap/load profiles for most cases
If the profile to be loaded is not one of the 3, which of the 3 do you unload?
I have this mode on my logitech and I never, ever use it
I'd assume, much like the way I intended to prototype it, the slots would be configurable
IMHO it's solely for tournament play etc
It makes way more sense for the wootility to always be loaded and it squirts the profile down to the device as needed
This is the one thing existing OEMs got right
I remember somewhere mentioning GTA and someone having 3 profiles just for GTA (flight, walking, driving) ... so for auto-loading, I'd imagine configure walking for slot A1, driving on A2, flying on A3 -> watch GTA to start -> load those profiles into those slots
yeah but that's pretty edge-casey
Auto-load in general kinda is
what happens for your average person with say 10 profiles
not at all
Everyone I know uses it
Everyone
Still, you'd probably want to configure which slot(s) get used so you can still use the A/Mode keys
Like all my mates who I play games with use the OEM s/w to configure game profiles and have it auto-switch
(For mice this is, but same deal)
who cares??
unless you need multiple per-game, this is a fluff feature
As I said, this is the ONE thing that IMHO Logitech got right in LGS
(Once you select "Lock to profile when running" that is)
What's the use case for needing to swap between 10 in a single day?
The only aspect of the LGS implementation is that to create a profile you need to specify exe and it just browses disk rather than showing running apps
why is single day relevant?
I set a profile up for a game once
I never, ever need to touch it again
it just works any time I play that game
today or 5 years from now
Auto-load would do the same thing, though. In the same way as the LGS one does, even
You set it up once and it would auto-load into whatever slot(s) you want
And auto-switch to that slot since that's not difficult
OK, I see your point
Auto-load means "Take these profile(s) and put them in these slot(s)"
Yup
and activate one
would need to activate one, else it's a step back from competitors
in the GTA use-case, it may not be one you end up using, but meh, it's a multi-profile setup
Optionally activate, in such a case as a game where you mainly use a profile with digital disabled, but still need to type a login prompt. I've never been a fan of doing any change that a user didn't explicitly request
hmm, that's a good point
In the GTA case, it could populate A1/2/3 but stay on the digital profile
What happens if you hit the digital mode button while digital is active?
does it go to last analog mode?
That would make sense maybe?
I THINK it's possible to set the default analog profile, so what mode it switches to in that case might be configurable
Just thinking of the case where you may tell it to load 1 profile, but you forgot which slot you put it in
That would 100% be me
would be simplest maybe if digital just toggled normal mode on / off
And yep, it should be possible to change which analog profile is default - but that's an extra write to the EEPROM
Or maybe not - at least that particular setting result doesn't appear to do what I thought it did
4 slots is mostly because of memory limitations. I think in general having everything on the keyboard has been a "mistake" in that it really limits what you can do. Most companies have switches to doing everything PC side, for good reasons
But I think there's a good middle ground, we could make a 5th dynamic profile completely controlled by the PC
Just for the "loading based on application launched" use case
No eeprom involved
That would work, as long as you can also set an in-memory flag on the keyboard to disable the normal operation of the profile switching keys. That way, the in-memory 5th profile can be more easily controlled
@hybrid lake Well 3+1 on-board slots is in-line with what other OEMs do - my logitech has 3 for on-board
So as long as you can make firmware changes etc to bring it more in-line with what's desired, then no harm done in the long term, lesson learned
Have a profile auto-switcher prototyped. Don't have it actually writing to the keyboard yet (it's stubbed out to only print to console) but it works. Config format is
[
{
exe: 'filename.exe',
profiles: [
{
slot: n, /* profile slot to load into */
name: 'profile from Wootility to load',
restore: true/false, /* controls if it should backup/restore the profile that's already in that slot */
xInput: true/false /* whether to use the XInput or DInput part of the analog */
},
...
],
switchTo: n /* switch to a particular profile after loading */
},
...
]
I tried to find a way to watch by the full path rather than just the exe name but I couldn't find a single cross-platform process watcher that had it. Can anyone think of something I'm missing? Aside from the obvious: a UI to configure it with
... as well as DKS, but I'm waiting for that to reach the public build before I look into that
no one is emailing me back i still dont have my black switches its been 2 weeks since you guys said they have been posted i would like a reply please and know if am gonna get them
@dawn totem @hybrid lake no one is emailing me back i still dont have my black switches its been 2 weeks since you guys said they have been posted i would like a reply please and know if am gonna get them
sorry about this
No worries, I’ll have erik get on it
i got told 2 to 3 days its been all most 2 weeks and am getting worryd if they are coming
This is a developer channel, please use next time the "questions answers" channel for this topic...
ok
fok
how do I distribute an npm package that contains stuff that has to be built with node-gyp but without forcing the user to install build tools? 
I don't wanna host executables, but also want installation to be quick and easy
oof
not possible they will have to install build tools altho u can add the build tools installer npm package as dependency
dunno if that suffices tho cause python
You have to parse the interface number from the path @topaz pollen, that's what we used to do
```(device.path.indexOf(IOUSBHostInterface@${interfaceNr}) > -1) || (device.path.indexOf(IOUSBInterface@${interfaceNr}) > -1))
It's some old wrong commented code, but it gives an idea
Yes, that's better
Although hidapi has an issue with usage pages and linux
https://gist.github.com/vtkacenko/5698ea55badcfcd7658a72501027e272#file-sample-cxx-L22 works on macOS and Linux for me. Don't remember if I had time to retest on Windows as well.
Mik maybe that key 88 output is also why the kb wakes the pc from sleep?
Aside the zero data for the analog interface, my W1 don't seems to send any packages without a press of a key under digital profile.
But I'm surprised about your complains about the wake up from sleep only for the new firmware, because it's an issue for a long time for me and not a new one. Because of that I don't use hibernation mode anymore. But maybe another device did this...
where has the dks gone on the new wootility?
😦
@grizzled wolf DKS was gone since 3.0.0, they are working on the improved version, it's in beta now.
Hey, does anyone know where the profile saves live in Windows. I want to set my actuation curves a little more precisely
Damn...
Know of anyway to set them via actual values instead of the very fiddly sliders?
Being able to type the number
No necessarily several decimal places
Even just putting in an Integer would be ideal
If the values are actually 0 - 255 than any of those would be great
Because some games (e.g CS:GO) will allow you to do things like walk faster than the walk speed, but not have footsteps if you're at a certain input value
Yeah...
@hybrid lake can I please ask for this as a feature?
Nah they haven't haha
Also would it be possible to set the analog curves envelope to not ramp at the start and end. But actually allow it so that no matter how hard the key is pressed, only one value will ever be put out?
Profiles (not counting the 4 saved on the keyboard itself) are saved in %appdata%/wootility/beta_profiles.json @smoky vortex. If you want to edit one that's save on the keyboard, you have to duplicate it first, edit that one, and swap it in over the one up top
Do note that you'll want to open that file in something aware of how JSON works so it can format it in a more human-readable way. It's all a single line with no whitespace
Ahh, in that case, JSON.stringify(JSON.parse(require('fs').readFileSync('path to there').toString()), null, ' ');
It shouldn't. The Wootility is built using Electron, so it's using JSON.parse and should be reading the whole file as-is
But it'll save it back as a single line the next time it saves anyway
Unfortunately it seems that Wootility doesn't like setting the first value to 0, then 126 values of 70 then the last value as 255
I'm assuming there's something happening under the hood with the way the curves work and because it isn't sane in how it handles it I'll have to leave it with my eyeballed version that has weird start and end values
Thanks anyway @boreal nest
Strange. But was worth the shot at least
Yeah indeed.
It's honestly weird. I'll show you two arrays
This works in CS:
[1,113,0,0,0,0,0,0,0,0,0,0,0,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,70,253,255]
This doesn't:
[1,113,0,0,0,0,0,0,0,0,0,0,0,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,69,253,255]
The top one was generated using the built in GUI tool. The bottom one just replaces all the 70's with 69
The graph for the top array (Working)
Interestingly the values of that middle line is 69/70, but on the graph it's showing a value that's more like 191
This are 128 values, the RAW values are 256 numbers, so I guess there are one Y for every two possible X points.
There's some trickery in how analog curves are handled. At first we just designed the 128 byte mapping for a 256 byte mapping, with every value directly corresponding to a value in the array.
After we tried making a nice analog curve however we choose to got for a limited amount of points we can move and then interpolate the values in between those points. I did that because I didn't know how else I could make a dynamic graph that you can drag. That was pretty long ago t.b.h., back when we just started with the Wootility.
Anyway, because of that decision we had to save the dynamic points somehow (the four dots in the graph), so we did that in the first 11 bytes, since it's a deadzone anyway. So for the Wootility it 'draws' the curve determined by indexes in the first 11 bytes, but the keyboard still uses the direct mapping in the rest of the array
It's not optimal, it's just design changing a bit over time 😛
Correction: the first two values are just the X position of the second and third point
Since the X values of the first and last point are 0 and 114 (127 - 13 deadzone)
the cake curve is a lie
The RAW data from the optical sensor isn't a linear curve, impossible. So normally all devices are applying a transformation to create a linear curve.
As long as the data is consistant in its function (every X has only one Y and the other way around so you can flip the axis of the real (none discrete) function) it don't lead to a problem at all.
It doesn’t lie? It’s just stores the coordinates and the “raw” values, which is inefficient
i mean its better than storing it for each key
If you want totally precise control over input / output values, then why not read via the API?
lame anyone could do that
Is there the possibility of a budget wooting keyboard where just wasd the numpad and the arrow keys are analog but the others aren’t? The sweet spot for keyboards is around 65-80 USD that would be ideal.
Great concept on paper and could bring you more recognition as a company.
Just curious if anymore models are a possibility or if things will be slowing down
@hybrid lake thanks for jumping in buddy! So let's say that I wanted my keyboard to only ever put out a value of 70 regardless of the depth of the key, would I be using [0, 114, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] followed by the rest of the array being filled with my desired value?
Yeah that will work
Amazing, thanks for clarifying it! One last thing that I am not sure was answered, why does the value of 69/70 render as such a high value on the GUI representation? Looking at the graph a value of 70 in the array renders as 191ish on the graph.
The display is inverted. The voltage of the switch goes from high (not pressed) to low (fully pressed)
@hybrid lake OMG, I should have realised that hahaha! Thanks again
Just wanted to say that I got everything working the way that I was expecting thanks to your input guys. Thank you
Awesome. I do wonder what the advantage for you in the end was by doing it with the array, is the exact value this important?
Ahh so with CS if your velocity is < 135 units, you will move without footstep sounds.
There is a walk key that depending on the weapon currently held, will cap your velocity to a specific value. This value is always < 135. However with the ability to fix my analog value being sent to 70, in game that sets my velocity to 133.82 regardless of the weapon specific walk speed.
Weapons that make you move slowly when you walk (So there is no footstep noises) are now all the fastest speed possible without making noise. The Negev when walking is 78 units. With this new profile though, the walk speed is 133.82. Which is significantly faster
If anyone wants to generate something like this where you will only ever get one fixed analog value here is the code:
// Constants
const analogCurveArrayLength = 127;
const analogCurveArrayDeadZoneLength = 13;
const analogCurveArrayUseableAreaLength = analogCurveArrayLength - analogCurveArrayDeadZoneLength;
// Functions
const generateArrayFullOfValue = (length, value) => [...Array(length)].map(v => value);
const generateAnalogCurveForFixedValue = desiredAnalogValue => [1, analogCurveArrayUseableAreaLength - 1, ...generateArrayFullOfValue(analogCurveArrayDeadZoneLength - 2, 0), ...generateArrayFullOfValue(analogCurveArrayUseableAreaLength - 1, desiredAnalogValue), 255];
// Usage
console.log(generateAnalogCurveForFixedValue(70));
You put it in your browsers javascript console
You're not a developer Fleimi?
Hahaha
Well it is the dev channel
Sorry
In its current form it's more for Developers to use to generate an array that they'd then copy and place into the beta_profiles.json file
Are you interested in the CSGO profile that I generated from this?
Because I can send you the final result instead of the code used to generate it
Ahh right. Let me add some documentation to the top of the code to explain it for you
/**
* Fixed Value Analog Curve for Wooting Keyboards
*
* The array is constructed in the following way
* [a, b, ...c (11), ...d (114)]
*
* a = X position of second analog curve dot on graph
* b = X position of third analog curve dot on graph
* c = Dead zone. This is a length of 11
* d = Values between and inclusive of 0 - 255. 255 = No pressure. 0 = Fully depressed.
*
* Note that the whole array is read backwards. So if you do end up writing anything that
* isn't just for a fixed value, pay attention to that.
*
* The generated array should be placed into "%appdata%\wootility\beta_profiles.json" for
* the profile you wish to edit. I'm not sure of the path for macOS so feel free to let
* me know and I'll update this. The array should be used for $PROFILE.analog.analogCurve
* where $PROFILE is the profile you wish to edit.
*/
// Constants
const analogCurveArrayLength = 127;
const analogCurveArrayDeadZoneLength = 13;
const analogCurveArrayUseableAreaLength = analogCurveArrayLength - analogCurveArrayDeadZoneLength;
// Functions
const generateArrayFullOfValue = (length, value) => [...Array(length)].map(v => value);
const generateAnalogCurveForFixedValue = desiredAnalogValue => [1, analogCurveArrayUseableAreaLength - 1, ...generateArrayFullOfValue(analogCurveArrayDeadZoneLength - 2, 0), ...generateArrayFullOfValue(analogCurveArrayUseableAreaLength - 1, desiredAnalogValue), 255];
// Usage
console.log(generateAnalogCurveForFixedValue(70));
@meager seal that should help you understand a little bit more around what is happening.
I'd write a node script so you could choose the Profile and fixed value, but you'd need node installed and I feel like it's such a niche thing that I've done that I'd just be wasting my time
ES6 has made so many of my utility functions so much smaller
I'd never write something like that to explain what I'm doing though, but for this instance it's fine
Yeah it's very good, I just don't get why it's empty without the spread operator
Array(10).fill(0).map(_ => 10)
Just a quirk in how Arrays are created
This is also good
So true, but .fill(x) is longer than ...
Just a speed thing really. Although you could make it a snippet
Yeah true
Anyway, thanks again @hybrid lake, legend!
@smoky vortex make it in c that way anyone can compile it on their platform without node 
Halp I can't stop being insane when it comes to working on my sdk fork >_>
const { Keyboard } = require('wooting-sdk'), { Toolkit, lockLayer } = require('wooting-sdk/toolkit'), { Layer, Renderer } = require('wooting-sdk/layered');
class bgLayer extends Layer { tick() { this.setColormapNoAlpha(this.kb.leds.profile.map); } }
let kb = Keyboard.get(), tk = new Toolkit(), renderer = new Renderer(kb), layers = [ new bgLayer(), new lockLayer(tk) ];
kb.leds.mode = Keyboard.Modes.Array;
kb.leds.autoUpd = true;
kb.leds.init();
tk.use(Toolkit.Features.AllLayered);
tk.enable();
tk.init(kb);
layers.forEach((l) => renderer.addLayer(l));
renderer.init();
// at this point, seemingly nothing changed except that now scroll lock can be toggled and kb.leds.profile.fnLockColor/scrollLockColor/numLockColor/winLockColor/capsLockColor (just arrays, [ r, g, b]) can be used to control the toggle colors (all of the non-standard ones default to whatever the profile has set for capslock)
_>
Currently working on a proof-of-concept background process (with an IPC-based API) for reading analog/controlling LEDs
const { serviceEmitter } = require('tserv-service'), fs = require('fs'); // tserv-service is a basic-ish IPC module I wrote for another project ages and and have been updating of late
let client = new serviceEmitter();
client.setIdentifier('test client'); // identifier is 100% arbitrary but *must* be unique
client.connectTo({ name: 'wooting', port: fs.readFileSync('./services/ports/wooting.port') });
client.on('ready', () => client.api.on('ready', apiReady));
function apiReady() {
// for the sake of not having to explain how tserv-service works, just take for granted that client.api exists XD
class clockLayer extends client.api.Layer {
constructor(uid, isTwo) { super(isTwo); this.uid = uid; }
// snip the layer's logic from all over
tick() { /* blah blah blah */ client.api.updateLayer(this.uid, this, true); }
}
client.api.registerLayer('clock').then((uid) => { let l = new clockLayer(uid, client.api.isTwo); setInterval(() => l.tick(), 500); });
}```
So far works great. The background service itself is pretty small (weighs in under 90 lines at the moment, but has no settings/config interface yet) and the boilerplate for using it, as shown above, isn't exactly much
client.api is an automagically loaded script from <cwd>/services/api/wooting.js (as well as other possible search paths, but this is the primary) on both ends of the connection automatically. It's a local TCP socket with a basic JSON protocol on top of it 'cause this thing was designed before ProtoBuf existed and it's just been easier to keep as-is. Chose a local TCP socket for a couple reasons.. was too lazy to figure out named pipes and such for cross-platform and deal with the different got'chas each have, and it being TCP means you could potentially set up a "service" that can be accessed remotely which was beneficial in the project this was originally designed for. All you'd need on the client end is the port to connect to and a copy of the api script. Bonus is that being JSON-based and the API being external, it's not difficult to access/use it from any language that can make a TCP connection
Man either the keyboard or the Wootility is really not fond of multiple things connected to the LED/Configuration HID interface
@boreal nest Yes, with the current method only one application can connect to it.
Yeah, but when 2 things do .. the results aren't pretty. Wootility goes nuts. One of the two resets the keyboard's internal LED profiles back to factory default (but oddly not bindings). Loses the mapped A1/2/3 keys. Fn/Mode keys stop working until their binding is cleared + rebound...
(The Wootility still shows Fn and Mode as bound but they're non-functional. I think the Mode key is actually reset to Scroll Lock as per the One's default)
You need a RGB reset command in order to restore the original RGB colour. But if two or more application have access the result is bad.
Yeah, but the Wootility doesn't use the SDK commands - it'll happily try to spam the keyboard with LED mappings using the Wootility's interface instead
But if you switch the profile you don't need a reset anymore.
You still do. The keyboard itself completely loses all 4 LED maps internally - they're reset to factory defaults
And the Wootility uses the commands. I got the command list which is pinned here from the Wootility.
My digital profile gets reset to the rainbow at full brightness. The analog ones back to red/green/blue at full brightness (I have A3 customized)
The Wooting have 4 colour profiles stores plus one on the memory.
With the reset it justs loads the RGB from the current profile again, I guess.
I mean the Wootility doesn't use RgbColorInit or RgbColorResetAll - it uses RgbMainPart/RgbColorsPart over the .write() interface rather than .sendFeatureReport()
By changing the current profile the RGB isn't change, you need a second command to load the RGB again.
A completely separate set of commands independent of the SDK's usual LED set
But it uses the same interface.
usage page usage usb endpoints function
-----------------------------------------------------------
4919 1 0x85, 0x04 Configuration & RGB
The order goes like this:
- Something using the normal SDK is loaded. RgbColorInit is called
- Wootility starts. It sends RgbMainPart and a pair of RgbColorsPart (as it sends the map in 2 parts)
- Keyboard doesn't like this one bit. Colors go weird
- After a few seconds, the leds go full brightness + rainbow. The default one from the factory rather than the Wootility's rainbow
- Close whatever is using the SDK and also the Wootility. RgbColorsResetAll is called
- Find out A1/2/3/Fn/Mode stopped working
- After remapping them in the Wootility and switching around the profiles, find out all 4 LED profiles are back to factory default
- Fix them in Wootility
- Try not to do that again
Oddly doesn't lose the analog bindings throughout this, so it's not a full internal reset. Something in that series of events must corrupt the keyboard's EEPROM section the LED profiles are stored. Firmware notices + resets it back to defaults. I think
If the camera on my phone didn't suck, I'd get a video of it happening
I don't had looked into the Wootility for a long time, but all the functions unsing the same interface just with differents call funtions.
So you get a reset on all data?
All LED-related data, yeah
Sounds weird...
And the "global digital settings" bindings for A1/A2/A3/Fn/Mode, which makes no sense to me
These settings are lost as well. A1/A2/A3 become blank. Mode/Fn remain populated, but Mode no longer works. I THINK it's getting reset to the Wooting One defaults
Maybe... Until now I don't got an unintentional reset on any data.
Think I might have an idea of what goes wrong. The interface replies to every call made over it.. but there's no ids or anything to link it back to what call the reply is to. This means that if there are 2 applications sending commands over that interface (regardless of if RgbColorsInit/RgbColorsResetAll being called), they'll read replies from eachother .. and this will almost certainly confuse the hell out of both applications. For instance, something as simple as GetCurrentKeyboardProfileIndex could end up with a reply of 246 instead of 0..3 depending on what calls something else made in the meantime
Likewise, the Wootility expecting to get back a map of LED values (GetRgbColorsPart1/2 for instance) could end up with a reply of nothing but 0s if the other app called GetCurrentKeyboardProfileIndex first
Yes, the result of the reply don't include the command. So applications which are read the commands get confused quickly if the order isn't correct or mixed up by other apps.
Really not sure what the best way to solve that would be other than either A) changing how the USB interface itself works to reserve one of the bytes as an incremented id, or B) a background service that has sole control over the interface and everything else must access it through that service
last one...
The service is certainly cleaner yes, but A works well short-term. I'm working on a service proof-of-concept.. I'll be putting "Wootility-focused commands" on the todo list, though they should remain largely unused. Or a least a command for "I want full control" and a raw sort of "send this data as-is and send the reply back"
I don't think it would be changed anytime soon.
For the RGB part there is a discussion already on the githut repo.
Drives me a little mad that the SDK repos still don't support Linux builds at all.
Yeah I know.
This is an aweful UI isn't it? The points are hard coded right now.
Alright.
I am confused.
The lib never seems to see my keyboard now.
HRM
OhYeAh
Fixed a bug.
There is now a delay that I have to deal with though.
A good 0.5s delay.
Any ideas?
Delay with what?
The analog input.
oh i noticed that too. i tried hooking the analog sdk in aurora to have decent effects on button presses and the analog reading is delayed by at least a second
actual delay. so if i press and release a button frequently within that time and then just look at the output, it really reproduces my input but with a delay
That needs to improve.
sadly cannot join you guys on the stream :/
hmm?
i usually lurk in twitch chat in most streams recently
and jeroen was in stream
so probably some conv bout software
I noticed that too. I think it's a software issue at the implementation level - the keyboard is pushing analog events and you're not reading them fast enough, leading to increasing delays as you're reading from the buffer rather than device. I had the same issue until I started using hidapi's data event (which pushes events as fast as the data comes in) and the delay vanished entirely
Or you're reading as fast as they're coming, but a second's worth came in before it started processing so it never catches up
@boreal nest
Elaborate on your fix?
I use NodeJS, specifically the hidapi bindings (same library the sdk uses). The Node bindings have a data event that pushes events whenever data comes in over the interface. Under the hood I'm not sure how fast it's polling to do this, but I was getting the worsening delays when I was trying to manually poll every 20ms
I'm sure it's not polling per-se, just working off of the bus events from the automatic USB polling.
I ought to just make my own library without using the SDK.
It does the reading for the 'data' event via an event loop of its own, separate to Node's from the look of it
It would have to do active reading. Not really any other way to do it. But by decoupling from Node's loop it's able to read far faster
It still relies on Node's loop to queue+deliver, but the actual reading is done outside of it
hm that could indeed explain it since i was just reading analog values like.. once a second
(i was reading it faster before though and had the same delay.)
@chilly oar modding the usb-c inside the twotting would only be possible with a custom connector cable thingy
cause it only exposes the usb2 lines
Can you please post a picture or the connecter.
i doubt anyone of us has taken the twooting apart yet
took it apart 10times by now
once to find all screws
8 times for the video
and yesterday for the usb-c mod checkout
Video?
i made a vid to take apart the twooting
at least the topplate
but after that its only 10 or so screws for the pcb
altho idk why theres like so many screw holes for the bottom shell and a few arent even screwed in
any doubts that the pcb is cleanable with isopropane if you spill water on it?
na perfectly cleanable
neat
more than any other pcb i have ever seen
I had assumed that the Two would be similar like the One, so that the connecter is replaceable.
https://img.purch.com/r/711x457/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9UL0wvNjkzMTI5L29yaWdpbmFsL3dvb3Rpbmctb25lLTE5X3Jlc3VsdC5qcGc=
like isopropyl and a toothbrush can clean everything
@chilly oar yes
its the same style aswell
just with a usbc
i even have isoprop in a spray bottle
So even if the connecter don't have the pins it would be easily replaceable with a new one that would have the right CC pin.
Kind of 😄
i assume it's just a regular usb c connector you can get anywhere. you just have to solder the wires onto it
so either a custom connector to the pcb or a "deathdapter" externally
i will try to build both solutions with a guide so anyone with the skills can build them
i wish they'd sell the cables in the wooting store
both type c for twootings and micro for ones
easily doable yourself cause the connectors are standard
i guess you could place the usb-c in the one
idk if the pcb connectors differ
well
usb 2 wiring is usb 2 wiring
does not matter what connector you use
you could even turn it into a mini usb or type a female
no i mean like
as they come rn
idk if u can actually just plug the twooting cable into the wooting one pcb
i'd say.. yes you can but you just have to change the connector
the twooting does not use usb 3
just a type c connector
Because only the USB 2 pins are wired in the Type-C connecter you can't use a Type-C to Type-C cable because the CC pins is missing. Because it's not wired correctly 😦
So many times "because" 😄
For the USB Type-C solution, two pins on the connector, CC1 and CC2, are used to establish and manage the Source-to-Sink connection. Functionally, the con
i guess this is what you talk about
looks the same as the twooting one
idk if the pcb side is the same and would allow wooting ones to become usb-c aswell
cause rn all of them are micro usb right?
technically the twooting is micro usb with a type c connector
So theoretically the One can be upgraded to a proper Type-C in the future and only need a little bit of shaping of the hole for the connecter.
i'd even say you could downgrade the twooting to micro usb
But who want this 🤔
weird people
usb 3 A to c aswell as c to c don't work because the connector on the twooting does not do the cc stuff
thus a cable that assumes the type c device is slave has to be used. (pretty much all usb 2 A to c cables that exist)
@proud oasis This must be, because Type-A male is always to put into a Type-A female and this is always the host.
So please prove me wrong
i use a usb 3 A to usb 3 A cable (male to male) on it
i also have a type c to 3 A cable that i can use to use this usb hub with my phone
anyway the best way to solve this imo is an internal cable with a small bit of logic to detect the voltage on cc1 and cc2 and only put a resistor inbetween cc1 or cc2 if both cc1 and cc2 arent low due to a cable that already has a resistor build in like the twooting cable
so c is in my phone, A is in the hub, works
but again.. that's usb 3.0
in usb 2 one always has to be slave and one always has to be master by design
in usb 3, slave and master are interchangable
micro usb master is called OTG
There are cables for A to A, but these are for debuging and special purpose, so only data are applied and no power. A even saw a few devices which are not really 100% USB IF complaint and have a USB-A OTG thing. But even with this my statement is true.
if you are talking about usb 2, then i approve that
if you are talking about usb 3, i recommend reading the spec again
usb3 has a to a connection with a male to male cable for external drives etc aswell
nothing new
ye cause the drive / usb hub / ... announce themselves as slaves
which is how usb3 works
yep
if you have a phone with proper type c support it even asks you if you want to go into master or slave mode
so you can connect two phones with a type c cable and select wich one is master
Can you please post the name of the hub.
technically same cause... my boss paid
but i will soon get a new switch cause i need more ports
i'd say choetech is in the same range as anker in terms of product quality
but ya like i said imma invest some time and resources into making a good mod to enable true usb-c capabilities
pretty solid chinese brand
ya so far it didnt disappoint except amount of ports
sadly alot of stuff i tested is not in production anymore
Did your Wooting Two cable work with it?
it would not work cause the twooting cable is usb 2
usb 2 A to c always assumes the A side is master and the c side is slave
always
Sure that the cable from Wooting is only 2.0?
yes. 100% sure
I don't get why a Type-C to Type-A cable isn't always 3.0 😕
cause less wires
Yes a few cents cheaper but not really interchangeable.
@wide nymph could we organize for me to receive a bottom shell, topplate, spare usb-c to pcb cable or 4 (the one inside the wooting) and the spacebar with the wooting logo?
3 A has 9 pins and also usually forwards the shell of the A connector as separate cable
2 A has 4 pins and also usually forwards the shell as separate cable
thus you have 4 or 5 cables with usb 2
and 9 or 10 with usb 3
probs. it's not really a necessity to be present
I fully agree with your comment "usb 2 A to c always assumes the A side is master and the c side is slave". So whats my I'm surprised to see that cable on your hub.
that hub is usb 3
But the hub is the slave for the PC, normally.
don't confuse a usb 2 A connector with a usb 3 A connector
yes cause it tells the pc it's the slave when it connects
@chilly oar so? with a usb3 cable the hub and pc dont care what connectors are used
through cc
from my understanding
with usb 3 the devices have to negotiate who is master and who is slave
with usb 2 it's obvious
So your cable must be different, because the C side is comes from the slave and not master, so it need the opposite CC from a normal C to A cable.
Even USB 3.X has no CC.
well it's something different then cc then
if i connect it to my LG G5 it will not work
if i connect it to my Huawei Mate 10 Pro it will work
if i use usb 3 A to usb 3 A with my pc it will also work
na usually usb-c uses the cc lines
then why does my hub work
usb3 magic
i literally just bought a amazon basics usb 3 A to usb 3 A cable to use it with my pc
Your cable is different.
prob sinks a cc pin internally
and the pc then assumes host anyway cause it never does slave usually
Pull-up on CC identify the host and pull-down the client.
isnt cc high anyway and waits for pull down
A normal C to A cable has a pull-up on CC so the client device with the C connecter knows that it is connected to a host.
i'll try the twooting with a usb 3 A to c cable when i come home.
So in your cable from the hub it is the opposite I guess. That could be the reason that it don't work with any device.
again, i bought a separate cable for it
it shipped with 3 A to c
and i bought 3 A to 3 A separately to use it on my pc
Yes but the C side musthave CC.
I don't know anything about your hub yet. But I assume your cable that was in the hub is different than a normal / other C to A cable.
ok i'd say.. the hub follows the usb 3.0 spec
and cc is usb 3.1
take it with a grain of salt though
Every Type-C has a CC pin.
I don't differ 3.X anymore... To confusing...
And because Type-A and B don't have CC the cable must provide it.
c to c is usb 3.1
There isn't USB 3.0 and 3.1 anymore, is renamed to USB 3.2 Gen X×X
k. then usb 3.2 gen 1 and usb 3.2 gen 2
"USB 3.1 Gen 1" is now "USB 3.2 Gen 1×1" and so on...
Mapping USB 3.2 nomenclature to USB 3.1 and USB 3.0 nomenclature:
• Gen 1x1 = SuperSpeed —> USB 3.0 —> USB 3.1 Gen 1
• Gen 2x1 = SuperSpeedPlus —> USB 3.1 —> USB 3.1 Gen 2
so.. usb 3 A to c is gen 1x1 and c to c is gen 2x1 or 2x2
I think so...
A Type-C to C cable should be always support "USB 3.2 Gen 2×2" I guess because of the doubled wires.
tl;tr
Maybe will read it later.
i assume you can find cheap usb c to c cables with 2x1 from china
essentially half the wires
depending on the device you use it's all you need
That would be stupid again. But you can find a lot of bad cables out there.
I hate to search for a correct Type-C to C cable. With the power support stuff and so on it's really annoying.
i wish the surface pro 6 would have usb c
Max speed cable with 100W support are really expansive.
btw the docking station from lenovo for my T460p is using a usb 3 A cable too
to connect two monitors, lan and other peripherals
I bought this for 14€ https://www.amazon.de/gp/product/B07CNS8PHL
You need just a cable with full wiring and good isolation.
thats what the lenovo dock uses: https://amazon.de/dp/B00NH144GK
and that's what i use on my hub: https://amazon.de/dp/B00WHZ746E
But not for charging or?
yep. not for charging
I will look into the USB cable thing again and hint you when I'm finish.
this is the kind of cable that ships with the twooting: https://www.amazon.de/dp/B07CJJHVKX
usb 2 c
Ok I know now why a USB 2.0 cable can be better over 3.X sometimes, because it can be longer...
another major difference between usb 2 and 3:
usb 3 can mess with radio devices that use 2.4 ghz
so.. if you connect your logitech dongle or a wifi stick to a usb 3 port you might get a horrible connection
just fyi
fixable by using a usb 2 extension cable
i assume you could use this c to c cable with the twooting: https://amazon.de/dp/B01GGKZ0V6
@quiet root
the cable i linked is a usb 2.0 c to c cable
I confused about the picture of this cable. I only see one line of pins, ok so far, but the two pins in the middle are not there, but these are for USB 2.0.
Hmm... I didn't realize my Two's fn key map got buggered up during a keyboard freakout (Wootility + something using SDK) .. fn lock toggle was Fn+G, media previous was Fn+right arrow, A1/2/3 were fixed in Wootility, and Windows key toggle was surprisingly still correct, but everything else was unbound. let buf = new Array(123); buf.fill(0); buf[110] = 1<<2; buf[61] = 2<<2; buf[30] = 3<<2; buf[31] = 4<<2; buf[46] = 5<<2; buf[62] = 6<<2; buf[47] = 7<<2; buf[14] = 8<<2; buf[13] = 9<<2; buf[107] = 10<<2; buf[108] = 11<<2; buf[109] = 12<<2; buf[81] = 13<<2; buf.unshift(/* KeyDescriptorDataProfile */ 6); kb.sendCommand(buf); .. such a weird command. Bonus is that now Fn+Mode is the fn toggle rather than Fn+Scroll Lock. Format is buf[<analog key index>] = <function index> << 2 (function index meanings being, in order: fn lock, media next, previous, play, mute, vol up, vol down, rgb brightness up, down, select analog profile 1, 2, 3, winkey toggle) .. in case anyone here has similarly strange mapping and wants to fix it or swap their fn lock
Decided to do it that way rather than a restore 'cause that means setting up profiles again, and would still have fn lock as Fn+Scroll Lock lol
@proud oasis
Here the basics, just for information and for the same understanding... Found on the "Universal Serial Bus Type-C Cable and Connector Specification" documentation. https://www.usb.org/document-library/usb-type-ctm-cable-and-connector-specification-revision-13-july-14-2017-and-ecns
Because a Type-C connecter don't have an orientation a proper device with this connecter must provide the CC pin to set the alignment for the attach / detach detection. As long as the source don't detect the CC pin to be terminated to GND, it don't provide any power (page 24). A pull-up resistor (Rp) stands for the source (DFP the host device typically the PC) and the value of it informs the sink (UFP the client device) how much power it can use (page 197). A pull-down resistor Rd identify the sink (page 197).
Marginalia... Because the CC pin in the Twooting is open, the resistor value is higher than 126 kOhm, so it acts like an self powerd device or a device in the disabled or error recovery state and is undetected by a source (page 198).
What is new for me is that every Type-C plug (and so all the cables) has only one pair of USB 2.0 wires (open B6 & B7 pin) (page 22 and from 66). I thought they are mirrored too. So it makes the proper connector for the Twooting a litle bit harder and both CC pins (page 134) should need a pull-down (Rd with 5,1 kOhm). So the CC pins in the receptacle aren't fix and the cable defines it. I don't understand Vconn yet and how it's handled on both sides within the cable...
Under "Initial Power (Source-to-Sink) Detection and Establishing the Data (Host-to-Device) Relationship" (page 24) it's mentioned that Type-A and B inherently establish the relationship of USB host and device ports. I don't find any official informations that handle it differently. Yes I know there are some client devices out there which are using a Type A receptacle, but I assume these devices aren't proper devices how it's intended within the USB specification. Again, feel free to prove me wrong by any official documentation... Because as far as I know the A to A cables are for special host to host (debugging) purpose and not intended for devices which are only clients / sinks. Everyone can create a non standard cable and device...
A hub has normally one upstream port which act like a client to the other side and multiple downstream ports which act like a source to the connected clients.
A standard Type-C to A cable is normally intended that the side A is for plug in to the host and C for the client, because CC is wired in the cable to Rp, so the C plug becomes the source to its receptacle (page 68) and it's the same for a 2.0 or 3.0 cable. Because of that I don't think your cable (your hub cable!) is like this cable, otherwise the host would think he is connected to a host and not to a client, because the upstream hub port is a client, and so the PC don't provide power to the hub. Because host-to-host is a safe but a nonfunctional state (page 24 & 133) and handled as an unattached state (page 176). So I assume in your cable the CC pin isn't wired as a Rp but as a Rd, so the host can provide power. Or is the hub powered external? This would be explain why you can't use this cable for every other device in the then swapped direction of transfer, unless the client device ignores it anyway like USB 2.0 devices which don't use the CC detection like the Twooting. So the question is can you use the Twooting cable for this hub? I would assume not. But even if, I don't know how the Twooting cable is wired.
So Vconn seems to provide power from the host to an active cable (5 V, 1 W), it uses a diode on every side or two SOPs to prevent power lose from the opposite side (page 195).
i'm writing this message using a usb 3 A to C cable with the twooting on my lenovo thinkpad T460p
guide:
- plug in the cable
- profit
again i'd think this cable would work: https://amazon.de/dp/B01GGKZ0V6
now this is a really really weird cable
it seems to have an IC in the usb c connector that can figure out if the A side is a host or a slave
and unless i replug the type c plug into my phone, the state will not change.
it's working well with both usb 2 and 3 devices here.. pretty interesting
also interesting.. my hub does not seem to work with my phone. neither with that cable, nor with a c to 3 A female attached to the 3 A to 3 A male nor with the 3 A to c cable that shipped with the hub
also.. the twooting cable works with c to 3A adapters on my phone while the 3A to c cable that shipped with the hub only works on my laptop. not through a c to 3A adapter for my phone
if i reverse that cable it does not work obv
hm. i assume my phone is not 100% spec compliant either
as i said yesterday.. usb 3 is fucked up
@chilly oar the usb3 a and b connector have the same pins right? so why would usb a not be possible by default. i dont see why a special cable is needed
for a to a that is
@proud oasis So maybe I'm right with your hub cable. And which cable do you mean at https://discordapp.com/channels/167181566978555904/453072453435129856/559645489323048960
@proud oasis @quiet root Why both you think that I belive that a Type C to A cable should not work with the Twooting??? I never said such a thing.
Because the Twooting only has Vbus, GND and the D+ & D- and ignores CC. It makes no sense at all to belive that this devise would not work with any C to A (male) cable.
@proud oasis I bet your mentioned USB 2.0 C to C cable don't work with the Twooting too, because this cable don't handle the CC pin and just wire this contact from one side to the other (page 67).
I bought this now https://www.amazon.de/gp/product/B07GZKMPJ8 and after I get it I will try to make an W1 mod for proper USB Type-C usage. Easy to use and this breakout board even has the Rd for both CC pins on board, just ready to use.
I'm confusing about all your cable mixxed up naming. One time it's a C to A and the next time it's A to C, normally these are identically because on a standard cable with these two connecter the C side is wired with Rp. So the A side is to put in the host only and the C to put in the client only. Or do you mean with adapter a A female?
i just think its bs that male a to male a is for debug only
cause the usb3 b has the same pins as the a
exactly the same
so i shouldnt matter at all if i use an a or b connector for the slave
or host
Yes, A and B have the same pins and normally the connecter type which is not C defines the host.
so why would a to a only be for debugging with usb3
With a A to A you can damage your PC when you using it to connect two hosts.
Because both would provide power...
It depends, because the USB IF don't want this, they don't have an official standard for this kind of cable. Only one without the power pins.
Because if the cable exists it should work. I don't woud say that it would be a user error if someone try it.
kind of is.... ask a specialist or google before just attaching 2 wall adapters or a wall adapter to a pc/notebook via usb
I got my breakout board for USB Type-C today. So now I still need the connecter to the board, a cable and a soldering iron. And of course the pin assignment for the connecter on the board from @hybrid lake .
gnd and vcc arent hard to find out
plus werent they black,red,green and white
first thought about an internal solution aswell
but this way i can also use that same small adapter/converter for the switch etc
prob could modify my current board with 2 screw holes to be mountable inside aswell
I have an idea for a project that would require USB type-C switching.
Hmm.. have a simple background service prototyped. Someone talk me out of doing what I expect to be fairly simple and non-invasive changes to the Wootility for it to use the service as a real-world test for it
@boreal nest can you share some of it in private, see what I can do?
I don't have it right now, should be easy to figure out if you have a multimeter, just bleep the PCB and cable @chilly oar
Thing is, in its current state, I'm not sure it's "ready" for a proper inclusion. I mostly wanted to see if integrating would end up being trickier than expected and what would need to be adjusted to help, or any got'chas like reading analog that I hadn't fully considered
I've... dug around in the Wootility's prettified minified code already to better understand how things work along the way so I have a good idea of where the changes can be made for testing. On a side note, I'm not sure what changed in the build process between 3.1.2 and 3.1.3 but the main script file in 3.1.2 was something like 200kb prettified. 3.1.3 is over 8mb
Hmm I didn't add anything extra, I'll look into it
There's a main and app bundle, the app bundle is the bigger one
Do you need the inclusion to test though? It should be able to run without wootility right? Or do you want to use the wootility usb functions?
The service is entirely independent and has been tested+working. It has a mode specifically intended for the Wootility (and similar apps) that gives sole control of the device over, with a 1:1 raw set of calls to send arbitrary commands+receive the responses
id wish for a non obfuscated wootility
The Wootility is obfuscated now??? The last time I looked into it it wasn't. Just the regular little junction due to the Proton Electron stuff.
it's electron 👀
It is electron from what I remember.
I honestly expected the Wootility to be open source.
I get why it isn't though.
I always confuse about the coorect thing and forget it 😆
What's proton?
valves thing to run games on linux
Oh yeah.
That thing is super cool.
I wish there was a front end that let me install stuff from CDs.
No, with this https://proton-native.js.org/#/
Looks less trash than electron.
It's not really obfuscated for the sake of obfuscation. It's part of the build process, I think.. much of the code is bundled into a single source file and run through a minifier. Extract app.js -> open in Chrome -> ctrl+J -> Sources tab -> Pretty print button (the { } button) -> save the output somewhere. Re-introduces line breaks, white space, and indenting
My guess is to lower start-up time as it removes Electron's need to access a dozen script files. Same strategy that browser bundlers employ
@placid ledge Sorry for the ping, but have you considered re doing your website in bootstrap?
You could save a lot of space via bootstrap and have a cleaner design.
im somewhat sad its php
finally build a small js script that can fetch profile jsons from the wooting stuffs
@chilly oar do you know which usb-c pin accepts vconn in the twooting or if they use vbus?
@quiet root Vconn is only to provide a little bit power to a cable or an USB gadget where the cable is directly attached to the device. For an USB Type-C device which is only client and don't provide power and has a receptacle both CC pins must be connected with GND through a pull-down with a 5.1 kΩ resistor but separately. Don't short them.
but isnt vconn 5v 1a
Vconn can be between 3.0 to 5.5 V.
You can't use Vconn on a receptacle just provide it.
You can only use Vconn if the USB Type-C plug is directly fixed attached to a device.
It only provide power to the plug see "4.2.4 Power and Ground Pins" page 123: "VCONN is applied to the unused CC pin to supply power to the local plug."
tweasked my own pcb a bit cause i got really confused when i researched further into the cc thing
Can you please just post a picture of the circuit, the video is to fast for me 😦
and yes the reach around from B5 on the left one is unnecessary
but this way it kind of represents the actual pcb layout
Ok, this isn't a correct circuit for your purpose. Only A1, A12, B1 & B12 is ground, not A2, A3, A10, A11, B2, B3, B10 & B11. Because the left side is a plug and not a receptacle it must only provide one CC pin, not both. Because your adapter don't need power for itself you can just let the second CC pin open. The next thing is if you want to use A5 for CC then you must only use A6 & A7 for the data and don't short it with B6 or B7. If you want to use B6 for CC it's the opposite. So your left side is supposed to connect it to a host and the right side for a client. To make an proper adapter you must short the A6 & B6 on the right side and A7 & B7 and you need on both CC pins on the right a pull-up with 56 kΩ. So the adapter works as an proper short extension.
i read up somewhere that this would infact work
and that its a good option to just ground all unused transmission pins
which is what i did
shit im dumb anyway
na wait im not
still an easy fix that doesnt really require much pcb design work
since well
grounded pads arent wired by me
thing is with the pull up
i think depending on the resistance the volatge varies
obviously
On your video it looks like your grounded pads are connected to ground.
yes cause rn they have 1 line in the schematic that connects them
deleting said line literally makes em floating pins
this is smth thats fixed with 2 clicks
nothing major
No, depending on the voltage for the pull-up the cable informs the device how much power it can provide.
Not how much power it provide.
theres an entire table for it tho
Because a cable for power delivery must have better (thicker) wires if it is supposed to handle 3A instead of only less than 1.
no shit
???
And a device need do itentify if the cable is capable of handle it.
😆
Pull-up and pull-down informs which side it is, host or client. And for your purpose you need this information in the cable.
The whole reason is that the Wooting Two is missing it, so your purpose is to provide it.
theres 0 reasons for it
the twooting is missing the dumb pull downs
to make it a sink
which is what the cable provides
Yes! But if you want a proper adapter out of it you must fix not only your left side, you must fix your right side to.
So for your adapter the left side simulates a client and the right a host. But yes the side of your adapter isn't permutable anymore.
u know that i can place anything on the right side right?
this is just cause the twooting happens to use a c connector
and i just provide the appropriate shit on the appropriate pins
Like I said if you want to create a proper adapter, and no, a correct USB Type-C 2.0 device has a CC detection.
- this will be only for the twooting
- this will prob be smth for tinkerers anyway and not massproduced
anything thats usb-c 2.0 can do this shit on its own whicht he wooting cant
If your only suppose it for the W2 it's fine, but because of that I give you an advice how you could make a proper extension out of it for not only the W2.
proper usb c 2.0 that is
i dont have anything thats usb-c 2.0
except well the twooting which kind of is usb-c 2.0
all my other devices are 3.0
or 3.1
or 1x1
or whatever its called by now
3.2 gen X x X (X can be 1 or 2)
didnt they all get dumb YxZ names
@quiet root For fixing the Twooting thing externally, I think it would be the best to implement an universal adapter with a dedicated client and host side. By doing it this way you can use the adapter for any other device too I think.
If it is just for the Twooting and to test it if it's possible to fix it, for the next hardware batch, yes you don't need a pull-up at all.
@chilly oar do you have the exact spacing/distance of the screwholes of the twooting connector?
no
crap i dont have anything precise enough to measure it
I don't have a good tool for measurements.
same
i wish i had calipers
i dont want to ping founders either altho they can tell me exactly how far apart
I'm just want to make a proof of concept for now. Not a qualitativ good hardware updgrade.
same but id also like to be able to properly mount it
altho i could just reorder a new pcb ver
Aside from TCP sockets, what's available for IPC that properly supports cross-platform? I don't mean a library that uses Unix sockets on Linux, COM on Windows, and whatever Macs would use, but a lowest-common-denominator IPC so that something running in Wine would be able to connect via IPC to a Linux service
If it's for the wootility a cross OS solution shouldn't be a requirement right?
For a background service that runs independently, it should be. The service I've been working on is akin to Aurora in that apps wanting to use the SDK would instead connect to the service to do it instead of over HID to the keyboard directly. That way everything can play nice as right now, as it stands, only one application can be using the RGB at a time or everything breaks and can potentially crash the keyboard's firmware. So, having something that can work in Wine that's able to use the version of the service running on Linux itself is preferred. That way a game or whatever can do RGB effects and it Just Work
That's why I went with TCP originally, but I do understand it's probably not the fastest. But if the difference between the fastest and slowest is sub-milisecond, it might not be worth worrying about
Have it down to...
const { wootingClient, Layer } = require('wooting-ipc');
let kb = new wootingClient();
kb.connect();
kb.on('ready', () => {
let last = 0, layer;
kb.registerOwnLayer('space').then((uid) => { layer = new Layer(kb, uid); });
kb.watchAnalog(); // causes analogUpdate events to be fired as fast as the service can read from the keyboard
kb.on('analogUpdate', () => { let x = kb.readKey(kb.Analog.Spacebar); if (x != last) { last = x; layer.setKey(kb.LEDs.Spacebar, 0, 0, 0, x); kb.updateOwnLayer(layer); }
});
(slightly re-arranged version of the analog example)
Just timed it. Analog events fire roughly every 12.5ms, or 80ups. Which, within a margin of error, is as fast as node-hid can read it. Bare sdk comes out at ~12.27ms or ~81.5ups
@hybrid lake How would you go about detecting multiple Wooting keyboards/finding the configuration interface for each? @ https://github.com/WootingKb/wooting-rgb-sdk/blob/d2b5dcc6a45dcb37c66f03bb76cbcfefe0d9a6a4/src/wooting-usb.c#L73
@boreal nest tcp is your best shot thats also how discord does it with RPC
@bright narwhal Not sure it's possible at the moment. The interfaces don't expose the serial number or other identifier so unless your HID library groups the interfaces it finds together by the device they go to, kinda out of luck at the moment
@quiet root That's what I figured, thanks
tcp is the easiest to implement in general noth just as crossplatform but on any platform cause theres libraries for any lang
I wish Discord's RPC had a notification clear event to match the create. It's less useful for things like a blinking indicator when you can't determine when to stop blinking
@bright narwhal There's two parts: finding the right device and finding the right interface. Finding the right device is just a matter of using the USB Product ID. Finding the right interface there are two main options: interface number and usage page. I did interface number in the SDK because I remember there being some issue with usage pages in linux
I do need to look into it again, because usage page in the end is more suited
We can't force another device to use the same interface order, that's what usage page is for
I think the issue is more that there's currently no way to distinguish between two Wooting Ones connected to the same computer. Something that, while niche, does happen as they're still cheaper than stream decks and have better macro possibilities with DKS
Yes true, that's what we need to add serial numbers for
I worked a bit with rocky suggestions, but we need to setup an alpha to test them properly. There is some driver interactivity involved that I want to make sure we get right
I think there's still issues with usage page on Linux, at least via the hidapi library
Lemme do a scan real quick
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw3',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 1 },
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw4',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 2,
usagePage: 6144,
usage: 914 },
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw5',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 3 },
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw6',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 4 },
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw7',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 5 },
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw8',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 6 }
Yep. Interfaces 2 has one but 6 does not, and 2's isn't 0x1338
Oh damn that was larger than I expected it to be
6 should have 0x1338, looking at it
Would have to fork and fix it manually. hidapi has unfortunately not been updated since 2016 and seems dead, despite the fix being in the PRs
I think it will work if you use libusb instead of hidraw
Oh sorry the other way around
"By default as of node-hid@0.7.0, the hidraw driver is used to talk to HID devices. Before node-hid@0.7.0, the more older but less capable libusb driver was used. With hidraw Linux apps can now see usage and usagePage attributes of devices."
hidraw is used by default anyway, but it's still missing
(all the paths above are /dev/hidraw*)
Yeah, hidapi/linux/hid.c has no mention of usage/usagePage. You've already got hidapi forked as part of the SDK, so it's probably less of an issue to fix it there?
Would unfortunately (or fortunately?) also require forking node-hid to include the modified hidapi code so the Wootility can use it
Can take a crack at getting the.. 8 year old hidapi PR that fixes this applied to the existing fork and verify it works
Yeah we could add the fix to my fork then
The patch works, assuming 0x1338 in the sdk is a typo for 0x1337 (4919)
{ vendorId: 1003,
productId: 65282,
path: '/dev/hidraw4',
serialNumber: '',
manufacturer: 'Wooting',
product: 'WootingTwo',
release: 273,
interface: 2,
usagePage: 4919,
usage: 1 },
Yeah that seems right
I'll set up a PR for it later today
Submitted a PR with the patch. Fixed the one complaint upstream had with it back-in-the-day that I felt actually mattered (C99 dependency.. should be irrelevent for this but it also makes it consistent). The other 2 complaints... first one I don't even get and the second one is "this patch does more than just add the feature [even though some of the extra it does is because it's needed to make things clean]" .. bah
Hmm.. in the sdk, the usage page for analog (0x1337, or 0x1338.. whichever is actually correct) is on the config interface with the analog one being 0xffff .. unless this is an error in the lib somewhere? I don't have access to a Windows machine to verify
@chilly oar (or anyone else), do yo have a KVM to test with the wooting keyboard?
Anybody interested in java: https://github.com/atcurtis/wooting-java
@hybrid lake What did you mean? If you mean a KVM-Switch I don't have one if you mean a Kernel-based Virtual Machine from linux I don't use linux as much. I use linux in a virtual machine within VMware, but maybe I can set up a nested one.
Sorry, I mean a KVM-switch
Can't help you with that.
If there are some problems with KVM switches I bet it is because of the double keyboard interfaces, maybe a KVM switch only works with the boot interface but because this is kind of disabled the whole keyboard can't work. But I can't really tell, I didn't used a KVM switch for a long time.
I have a KVM somewhere
KVM switches are great
Is there anything special I would need to do to repro issues with a KVM?
Just plug in the keyboard and try to type basically
I've been looking for a bit now and I'm afraid I'm too much of a newb when it comes to USB/HID; does anyone have any resourceful links/explanations as to how to interpret the usage page variable?
I was reading up on https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf but I can't make sense of it
e.g. in Emonas's message the usagePage is 4919, which is hex 0x1337
however that doc only describes 0x01-0x40 with huge gaps
so do I interpret it as lower/higher halves? so like 0x13 and 0x37
or is anything this high vendor defined?
At first the usage page 0x1337 is out of specification, this number is reserved so normally that number shouldn't be used at all.
from this source file https://github.com/smokris/usb-hid-usage/blob/master/usb-hid-usage.c and a couple others it would seem however that 0xff00-0xffff is reserved for vendor-defined 'protocols'
So I'd assume that currently the light control interface of Wooting's keyboards use 0x1337 simply because "l33t" 😅 ?
..and I'm not crazy for thinking "where the heck does it define 0x13 or 0x37 or 0x1337"
so then when I'd want to differentiate between multiple Wooting keyboards' lighting controls hooked up to the same computer I'd use the path to differentiate the devices and look for userPage == 0x1337 to get the lighting control interface?
I assume too the number was just for "leet" :-)
You can read the valid usgae page number on page 14 & 15 from the document from USB IF.
On page 15 you can see that 0xff00 to 0xffff is vendor defined.
so we blame @hybrid lake ? 😼
I already did 😃
foei foei foei
jk, but anyway, am I correct to assume that 0x1337 is the lighting control interface, pastaj?
Kind of, it's the interface to control all the keyboard settings and RGB too.
I pinned the known commands for it here: https://discordapp.com/channels/167181566978555904/453072453435129856/498500381509419030
But without the parameters...
Here is the interface list with Xinput enabled...
interface usage page usage usb endpoints function
-------------------------------------------------------------------------
0 1 5 0x81, 0x02 Xinput Xbox Controller
1 1 6 0x83 Keyboard 6KRO for Boot
2 4919 1 0x85, 0x04 Configuration & RGB
3 1 6 0x86 Keyboard nKRO
4 12 1 0x87 Keyboad Media Keys
5 1 5 0x88 Dinput Game Controller
6 65535 1 0x89 Analog Reader for RAW data
ah okay, makes sense now
If Xinput is disabeld the first entry is not present and the numbers for the others are minus one.
Because the first entry beginns always with 0.
yes, starting from 0 is the best kind of starting
so on feature report with commandId = GET_VERSION it reports: D0 DA FF 88 01 18 03, D0 DA is the magic word, 01 18 03 the firmware version, but what does the FF 88 entail?
D0 DA is the magic stuff, ff are kind of nonsense, I don't know what 88 stands for but indeed 01 18 03 is the version (in dec like 1.24.3).
The FF (buffer[2]) is unused (even the Wootility ignores it) and 88 (buffer[3]) is a success/failure return for the command. 0x88 for success, 0xFF for failure, 0x66 for unknown command
Should also check buffer[126] and buffer[127] against a checksum of bytes 0-125 the same way as is done when sending buffers to verify integrity. Not completely sure it's needed honestly, but the Wootility does it so I figure there's a reason to not always trust the HID interface's accuracy
(buffer[127] << 8 | buffer[126])
The usage page is just some old lame joke gone wrong. The problem is, even if I change it, I'll still have to keep sorting for it in the wootility
I should though, be nice to the USB gods
Checksum i'm not so sure if it's necessary either. The USB interfacing was written by an embedded developer, where it's standard practice for every form of communication
Eh, it really can't hurt to have an extra layer of integrity checks. Hopefully you can patch the copy of node-hid that the Wootility uses and be finally able to use usagePage on every build. Less work, but traded by having to keep building node-hid for Win/Mac/Linux on your Electron version locally rather than relying on node-hid's prebuilds. Dunno which is more work in the build chain
Luckily node-hid itself doesn't need patching - just the single file in hidapi, which node-hid pulls+builds into it. Since hidapi will likely never change, it shouldn't be too difficult. Would only need to think about it whenever the Electron version changes, or if you want to keep node-hid itself up-to-date over time
I'm using an unmodified node-hid on Windows and it does report usagePage though 🤔
But not on Linux...
ah I see
Yeah, back in 2011 someone submitted a patch to hidapi (the library node-hid uses to actually do hid stuff) and it was never added. The comment on it 3 years later was that it "did too much" and introduced a dependency on C99 that took all of 5 seconds to fix
USB is supposed to sorry correct errors unless you use the "throw all the data at me" mode.
https://www.beyondlogic.org/usbnutshell/usb1.shtml
This is a really good resource.
Introduces the Universal Serial Bus covering the various chapters of the spec and what is required to be read.
That's easy until you realize you have to deal with non-rectangular keys.
also not hard
can just copy the wootility code for it

founders will thank me for stealing code
I mean, that's js right? That's not a great choice for much of anything.
adobe, ms and a shit ton of other companies would like to disaggree with you
i mean all adobe products are electron now
Yeah that's normal for me.
the fact that they are huge companies doesn't make their choices correct
What?
vscode has proven to be super unresponsive to me
and just node-gyp with dlls for the magical stuff
Same with Discord...
wanna do anything? wait a couple of seconds
You need a boat load of RAM.
i thought everything is supposed to work better on windows
heck even full VS starts faster than atom
as in, bigger userbase
and most other IDEs
I've got some Windows programs that work better on WINE than Windows.
lol full vs starts in half a second
It starts in like a half minute.
VS code takes a couple seconds.
the only thing that takes time for me is loading the docker addin but that is done asynchronously so i can work while it loads
Idea takes a while to get going, but once it is going (and ate 4GB) it is super fast.
The 4G is a guess, since it trashes some on my 6G laptop.
That's because it indexes less stuff.
my firefox uses more in 2 tabs than vscode
I think.
The emoji thing is kinda bleh for me.
welp is the easiest way to keep the links short and increase character pool
But they use more than one byte and some things don't like emoji at all.
everything i tested including my 3ds worked
so ya
dont use internet exploder i guess
I don't.
I've seen some services that strip all emoji.
just cleaned it like 4 months ago or so
some random dick still uses jpeg with my service
Fix: super jpeg compress the images.
ah no wait
that was the backup webserver
woops
in this case i should backup the current one asap
ya thats more like it
I don't speak Dutch(?).
na Dutch is Nierderländisch or to trigger them Holländisch
Deutsch is german in german
Okay.
dw got confused when i learned english aswell
most people dont speak german
outside of germany that is
and austria
idk why they speak german
the program was more a small POC anyway to see if i could fetch the jsons from their db
cause iirc all current wooting profile websites need you to tell them the colors etc
going insane
i think imma continue this next weekend
this is what its supposed to be
Oh baby
Welcome to the Steam Client Beta group. Opting in to the Steam Client Beta lets you see the latest features before they're released. You can find out how to opt in to a beta here: https://developer.valvesoftware.com/wiki/Betas You can see the latest Client Beta updates on thi...
Added the ability to blacklist individual DirectInput and Xinput devices in the controller settings menu. This is intended to be used when a device either erroneously shows up as two devices or shows up as a controller but isn’t one.```
@chilly oar I think this is right up your alley
@hybrid lake I definitely will have a look into it, but can't tell when... My Wooting is still apart because of my plan to create a USB Type-C adapter.
🤔 does the recovery mode put a wooting kb into atmel/flip flashing mode or does it still have a layer of firmware on top?
probably second as there's no actual single physical button dedicated to putting it flashing mode but still wondering
I think the Atmel MCU bootloader supports flashing by USB out of the box.
But can't tell if Wooting using it or just replace it with a custom one.
It's a custom one, so we can just use generic USB drivers
I tried to test the new Steam feature to blacklist controllers but I don't found any new settings for it.
u do use steam beta tho right?
well one never knows
Thx man...
But it really only works for Dinput and Xinput interfaces. Even my DS4 has a Dinput interface but Steam hides it anyway like the W1. So I had to connect an old joystick to test it because my W1 is still apart.
This means that the W2 users can block the Dinput interface of the keyboard now I think, but I can't test it on the W1 because Steam hide the Dinput interface from it always.
The Xinput interface should be possbile to block on both keyboards.
finally done
all of this for a POC to maybe implement a good Profile Code Website
just need to implement a handler for profiles that use rgbArrays that were originally only for W1
Pretty cool. The RGB array looks good
Super long shot, but is anyone here familiar with the more technical side of how compilers work? Specifically CLR/LALR design
i mean did write a fictional compiler for an equally fictional lang but just copy and pasted a pmuch ready made parser
rip. I wrote a full CLR(1) parser but it explodes with s/r and r/r conflicts from grammars it should have no issues with, and I don't know where I went wrong with it. It's been bugging me for a long time lol
Intend to build it to a LALR(1) later.. but that's after it can actually build states properly >_>
In this tool-assisted education video I create a parser in C++ for a B-like programming language using GNU Bison. For the lexicographical analysis, a lexer i...
i found this series very helpful
Very nice post summarising the USB type C thing
The factory is working on it now
Trying to get them to understand why it's necessary lol
@hybrid lake So you improve the cable for the new W2 batch, it would be awesome...
I don't get why you refer to this post but as long as they implement the pull down correctly I don't bother.
This fact isn't really true: Initially, if no connection is made, the host side sees high voltage on CC pin, and the device sees low (zero) on its CC pin.
The correct fact would be: Initially, if no connection is made, the host side has high voltage on CC pin and look for a drop of it, the device has low (zero) on its CC pin and look for a raise of it.
The next date for a rapair cafe event to built my cable is next week. I have to wait for it because I don't have a soldering iron.
Anyone happen to know the analog scanning frequency used for the analog API?
@knotty night trying to run the WootingAhk Analog example scripts and they tend to crash on startup, the keytester scans like 4 keys then crashes
I have not run it on the latest firmware, could well be problems
I will try to remember to repro tonight when I get home
Are you ANSI or ISO?
iso
I pre-package the DLLs into the project, as I had to use non-standard ones
So it's entirely possible there is now a mismatch
I would expect it to crash if you hit a key which has a different ScanCode in ANSI than to ISO
WootingAHK is currently only meant to support ISO
I'm not pressing any of the keys, I simply hit run and it scans a few keys then crashes
But for most keys it should still work
oh strange
Ahh hang on
the current tester tries to subscribe to all keys
so I am guessing maybe when it polls, as soon as it tries to poll a key that is ANSI-specific, it crashes?
I dunno
Not got a wooting here at work, so cannot test
It may even go boom before that point, when it tries to look up the Wooting code for one of the ANSI keys
Does the Simple Example.ahk work?
no it does not, same thing where it quickly crashes
W1
I guess that is a potential failure point too then
Is the Analog API the same for the W1 as for the W2?
no idea :/
Looks like I can move back to the Wooting.NET NuGet package now, as he merged in my PR
But it does not look like it has changed otherwise, so it is not that...
I suspect it may be the wooting-analog-sdk.dll, which is a custom version I got from @proud oasis
@proud oasis - would you expect your custom analog dll to fail for an ANSI W1?
theres 0 reasons to save a few kb in the profile jsons
this attitude is the very reason why poopy code exists
if you complain about 10 freakin kb
yes
jesus u must have problems
with thousands of users that adds up
like i get that if we talk smth like xbox kernel code
ok
but
i have tons of gigabytes
saving "a few kbs" is important
if wooting has enough customers that they could notice these couple kb they wouldn't complain
aws dynamodb is metered by reads and writes
not how much u read and write
idk if they have storage capacity but the thing is.... the old profiles dont get updated if it should change
now there's an argument I'll take
the profiles before w2 dont even have key arrays that long and the wootility basically repeats the same keys over and over
as in key color
yes it would harm backwards compatibility and yes you would need to run a conversion on everything
they dont
even if, they'd need an insane amount of profiles to save anything noticeable
this isnt a "you are only getting 2gb of transfer a month" kinda thing
i found an example of theyre charges on some data limited services
198gb in a month
cost like 17.82
jesus so expensive
thats 19800000 profile transfers
I've yet to see why somebody should invest the effort to rework the code to make a new type of profile system
that person likely earns more in that time
considering the "dev team" is pretty limited that isn't worth
like.... tbh.... (nothing against arena) but i think hes one of those people whod optimise every bit out of anything
literally every bit
yea
can shave of a bit of storage? better invest 20hrs of time into it
80/20 applies heavily in this case
and not have it pay off
plus arguments like "but the server connection might be metered" are crap when we know how the system works
well, the customer needs to account for those extra 10 kb
i could send the login data right here for the wooting tables
and you could just load and write anything in there
I meant the one downloading it
i could read all profiles and write back profiles in the new format
ya but who cares about 10kb
the german telekom 
