🤖│community_dev

[strong siren]

hm no even then it behaves as I would expect

[quick bough]

Yeah was gonna say, some effects seem to have brightness sliders of their own

[young frigate]

Ah, gotcha. I was setting brightness via an effect. Not the global brightness

Can confirm having it set to static effect works as expected

[strong siren]

most things that use this api tend to write the entire buffer, overriding the effects completely

what you're trying to do with it is not very common

[young frigate]

Yeah, I noticed that in the Wootility app source code. Was hoping to avoid added complexity.

Is there a way to relinquish control of lighting back to Wootility? After I change a key, and even when Chrome is closed, the Wootility app says a 3rd party app is controlling RGB and doesn't permit changes. I have to power cycle the KB to get back control

[strong siren]

command 32 should do it

[quick bough]

WootDevResetAll (32)

Huh, there's also WootDevResetColor (31), which I assume is for a single key

[young frigate]

Super, thank you all! Kinda surprised how easy it was in the end.

[strong siren]

correct

[quick bough]

also did you know you're supposed to use WootDevInit (33) before sending WootDev colour commands?

(practically not needed but lol)

[young frigate]

Ha, I haven't been doing that

[strong siren]

yeah it tries to set it up for you on the fw side

[quick bough]

Optimise WootDevInit to a no-op if you haven't already

[young frigate]

Ok, WOOTING_RESET_ALL_COMMAND is needed. WOOTING_SINGLE_RESET_COMMAND successfully resets the colour for a key, but Wootility still claims a 3rd party is claiming control. But that's no worries for my purpose.

[quick bough]

Yeah, WootDevResetAll exits the WootDev mode

I wouldn't expect WootDevResetColor to do the same

[young frigate]

Hi again! I'm now trying to write a whole buffer using the RAW_COLORS_REPORT (11) command. Excuse again my ignorance with this basic stuff.

When sending a single key colour, the colour is encoded as three consecutive bytes. That works.

How do I pack the colour when sending all the data at once, since it's not possible to send a Uint16 array?

I've tried sending each component on order, ie: r,g,b,r,g,b... and that doesn't work at all.

By way of example, the first few elements of the array sent for setting the first two keys to blue:

0: 208
1: 218
2: 11
3: 255
4: 0
5: 0
6: 255
7: 0
8: 0

[quick bough]

I think the encoding is described somewhere, but for reference:

(colour.r & 0xf8) << 8 | (colour.g & 0xfc) << 3 | (colour.b & 0xf8) >> 3

To pack it into a Uint8Array, you can do push(encoded & 0xff); push(encoded >> 8); or similar

[young frigate]

Ah, thanks I'll try that

Beautiful, thanks - worked a treat

[quick bough]

Damn, turns out my firmware was not up-to-date

A bit cursed but whatever

[strong siren]

if you want a cool side project, I'll just say there is a program that can be written that makes it so you can use Firefox, and Wootility would work with it with no code changes

I'm surprised you haven't figured that out already :p

[quick bough]

Yeah, I do see http://localhost:50051/wooting_device_communication_service.KeyboardBackendCommunicationService/ListDevices

but "WebHID for Firefox" is useful beyond just the Wootility

plus I do think you are gonna release your own port 50051 service eventually and it would be silly if I stole it from under you, so to say 😛

[strong siren]

silly doesn't sound like a good reason to not do something

And yeah, webhid in general is obviously more useful

[quick bough]

I may like to reinvent the wheel, but you haven't even released your wheel yet

I'm sure this time you'll have picked a mature language like C++ and not Rust again

And it'll be open-source so we can suffer with you

I actually wrote some Rust again recently... pretty, no?

Things like checked_sub, wrapping_add, etc. feel like a weird kind of "security". C++ just went "standard now says integers are two's complement" and that's it, suddenly all assumptions were valid.

[rocky wharf]

I’ve currently paused my project for now. The json structure of profiles stored in the browsers local storage is to different to easily (with not much time) convert them into the structure I need. I might just request all profiles from the keyboard + swap them out for inactive ones,… and directly store them as there own json that can be directly deserialised into the data I need to send. With that, I only need to implement the remaining commands and would be done to be able to switch transient profiles for certain games.

If I find some time again (looking at you Arc Raiders)

[young frigate]

Hi! Sharing my library for browser-based control of RGB lights. Also borrowed some bits from Sainan's AnalogSense.js to support analog input too. I only have a Wooting Two, so not sure how well other devices are supported.
https://github.com/ClintH/woot

[quick bough]

[strong siren]

same here :p

[young frigate]

I only have an ancient Wooting Two, I thought the Two He ARM PID was 0x1230?

[quick bough]

it's pid & 0xFFF0 == 0x1230

The last nibble indicates the gamepad mode

[strong siren]

correct

[young frigate]

Ah! Hmm, at the moment I'm doing a simple lookup for keyboard metadata based on the numeric PID

Does the & 0xFFF0 apply to all keyboards? I could look up based on the direct PID and then try again with & 0xFFF0 maybe?

[strong siren]

just do & 0xfff0 always

that's the canonical representation

[young frigate]

So whatever the WebHID reported PID is, do & 0xFFF0 and use this as the basis for my lookup?

[strong siren]

Yes

the wooting one is also missing :p

(i'm testing on that one because it's what i happened to have on hand that has a firmware that should work )

[quick bough]

The OG firmware used to have a different VID and different PID scheme, but these firmware versions are probably way too ancient to bother with ATP

[strong siren]

yeah, we want to remove them from the rgb sdk at some point

[young frigate]

Ok, I've published an update with that change

[quick bough]

[quiet root]

we want a new rgb sdk at some point period

[young frigate]

It applies & 0xFFF0 when looking up the PID, and draws from https://github.com/ClintH/woot/blob/main/src/magic-numbers.ts

[quick bough]

My firmware is pretty recent, so it shouldn't use small packet size transfers

[strong siren]

technically there is one which is what we used at gamescom

[young frigate]

Sainan, yeah that's described in the README

[strong siren]

oh you can basically ignore small packets as well

[quiet root]

rust rust rust rust rust rust

[quick bough]

You should know no one reads these

[young frigate]

I'm basing the small packet sizes thing from the keyboard metadata in the RGB SDK: https://github.com/ClintH/woot/blob/main/src/keyboard-info.ts

[quick bough]

[quick bough]

No, that's wrong. You need to detect it based on the input report size.

[young frigate]

Fair, but this is just a quick thing primarily for my own purposes. I just figured I'd publish it after the help you guys have offered -- and apparently there's zero code out there to show how to do what I wanted to do (or at least, within the browser)

[strong siren]

it's appreciated :)

the source you were referencing doesn't make your life that easy, a lot of it is legacy code

[quiet root]

we just stapled on the new stuff to an already kinda bad rgb sdk

[young frigate]

Do I understand from your earlier comment that it's likely safe enough to ignore the flag entirely? All the extra code to properly send small packets is out of scope for me, since my own keyboard doesn't need it at least.

[strong siren]

this check will break soon fyi

[quick bough]

How so?

[strong siren]

new protocol revision

[quick bough]

Will it introduce yet another way RGB reports should be sent?

[strong siren]

the strucuture of the rgb data is the same, but the usage page will change and we will have dynamic report ids now

[quick bough]

Dynamic report ids?

[strong siren]

wootility has had support for this for a bit

[strong siren]

the first byte in a usb hid report as per spec

[quick bough]

Yes, I know what a report id is

Dynamic how?

[strong siren]

depends on the total size of the packet

[quick bough]

Hmm, I see

[young frigate]

I just pushed an update that treats the small packet size flag as a warning. Maybe it will work, maybe not 🤷🏽‍♂️

[quick bough]

Well, it seems to be working now

but the analog input display seems to not show anything

[young frigate]

Yeah you might need to refresh and click 'Scan' again

[quick bough]

Interesting, now it works, but it also did the 'demo buffered output' after the scan

[young frigate]

Yep. That's on purpose.

Anyway, handy that the packet size thing can be ignored.

[quick bough]

Well, it depends on the firmware version

Initially they did that for the ARM-based keyboards

Also, this note is clearly wrong

[strong siren]

It's correct for all intents and purposes

Unless you want it to say chromium instead?

[quick bough]

Oh, so it will work on my Android device running Google Chrome?

[strong siren]

Ah that's what you mean,fine

[young frigate]

@strong siren would be great if Wooting made some chunks of Wootility reusable as published npm packages. That Wootility itself used. So there's an always-up-to-date implementation.

[rocky wharf]

I already implemented it I think but don’t know if it is already usable with the current firmware.

[lyric gulch]

yo my wooting 80he just stop working idk what to do

[rocky wharf]

You’ve wrote this in 4 different channels except #1019755933959733258 where your best chance is, if you describe your issue and things you have done further.

[lyric gulch]

How do i get the role to submit one.

[soft fractal]

you don't need one, most likely you've missed to select a tag

[gleaming silo]

I'm curious about the rate at which a device reports the analog values to the Wooting analog SDK. Is there some pre-defined rate for that? I'm currently working on something, but the rate at which the numbers update feels only mildly satisfying

it seems to happen every couple of milliseconds

[strong siren]

It should be at scan rate iirc. Enabling tachyon mode might help. Should also be faster on 8k capable boards

Does the rate at which you're getting data line up with what wootility predicts the scan rate to be?

[gleaming silo]

The rate at which I'm getting it is somewhat infrequent. I am using the C# wrapper, and I pretty much read the whole buffer at whatever the CPU clock can give me at the moment. Hundreds of consecutive readings stay the same, my code is definitely not the bottleneck. The data returned by the wrapper/by the sdk seems to be somewhat infrequent though. My deltas between detecting a change in the analog value of a key look something along the lines of:
3, 3, 3, 4, 3, 3, 3, 3, 3, 3, 3, 5

My code for reference (If you can understand C#):

Dictionary<short, float> buffer = rawBuffer.ToDictionary(x => x.Item1, x => x.Item2);

foreach (KeyValuePair<short, float> keyState in buffer)
  if (!_lastBuffer.TryGetValue(keyState.Key, out float analogValue) || keyState.Value != analogValue)
    _frames.Add(new(_scanIndex, (int)_watch.ElapsedMilliseconds, (VirtualKey)keyState.Key, keyState.Value));

foreach(KeyValuePair<short, float> keyState in _lastBuffer)
  if (!buffer.ContainsKey(keyState.Key))
    _frames.Add(new(_scanIndex, (int)_watch.ElapsedMilliseconds, (VirtualKey)keyState.Key, 0));

_lastBuffer = buffer;

rawBuffer being the pairs of keycodes and analog value, turned into a C# dictionary for the sake of simplicity

[strong siren]

I'm speaking only for firmware, I don't know how much overhead the SDK might add

I do know the c# ffi glue code does a lot more copying that it needs to but I doubt that by itself causes a lot of difference

[gleaming silo]

It could, that's pretty much why I am asking. I've tried looking through the source of the sdk but my very, very limited ability to read rust doesn't make this quite easy

The speed at which calls over the FFI happen should not be an issue, as I get hundreds of buffers back with the same values

Which leads me to the assumption that whatever updates the buffer inside the SDK is the bottleneck

[strong siren]

I'll poke people internally that are looking at the SDK at the moment

[gleaming silo]

I did find https://github.com/WootingKb/wooting-analog-sdk/blob/develop/wooting-analog-plugin/src/lib.rs#L189, which seems to spawn a thread on which the device is continuously polled via hid and then written into the buffer, but I can't see anything that would define some kind of interval. Maybe the speed of the raw hid communication is the bottleneck?

[strong siren]

You can use something like hidsharp on the c# side and read the bytes directly

Find the interface with usage page 0xFF54 and read chunks of bytes :p

I'll look into this tomorrow, it's 1:30am rn

[gleaming silo]

I could try to figure out communication for reading myself, maybe. The SDK wrapper does seem handy though (and is already fully integrated into my software), since enumerating devices etc. is pretty straight-forward

[gleaming silo]

2:28am here ^^, I'll look into this again tomorrow as well

[gleaming silo]

hmm, I wrote a quick script using HidSharp:

Stopwatch watch = Stopwatch.StartNew();
long lastChange = watch.ElapsedMilliseconds;

while (watch.ElapsedMilliseconds < 10_000)
{
    byte[] buffer = new byte[48];
    stream.ReadExactly(buffer, 0, 48);
    if (Enumerable.Range(0, 48).Any(x => lastBuffer[x] != buffer[x]))
    {
        Console.WriteLine(watch.ElapsedMilliseconds - lastChange);
        lastChange = watch.ElapsedMilliseconds;
    }

    lastBuffer = buffer;
}

with stream being the current HID stream. This resulted in printed ~2-5ms numbers, averaging at pretty much the same as what my SDK calls did. That means it seems to be a firmware limitation in how fast it reports. Would love to get that somehow confirmed though. And if so, is there any way to get this more frequent?

[gleaming silo]

Oh, it does seem like tachyon did bring it down to 1ms, and that pretty consistently

[strong siren]

That's expected, nice.

Did you verify this with raw reading or with the sdk wrapper?

[gleaming silo]

both

[strong siren]

to get that any higher you need an 8k board :D

[quick bough]

8k board is easy. but a reliable usb cable that can actually deal with that speed? lol

[quiet root]

also easy

just usb2

[quick bough]

When do we get a ethernet port in the wooting keyboards? I find cat 5 and up cables to be far more reliable than usb cables

or actually PS/2 serial ports, so I can use it with a Windows XP era PC

[gleaming silo]

Interestingly, without tachyon I mostly seem to get reports to update very 3-4ms, suggesting it runs at 250hz-333hz rather than 500hz/2ms

[strong siren]

which keyboard is this on?

[gleaming silo]

A wooting 60HE

[strong siren]

there's like 4 different models :p

I assume it's a arm non-plus?

[gleaming silo]

Yes

[strong siren]

that sounds low to me

do you have an rgb effect running on it?

[gleaming silo]

Yes, but shouldn't 500hz still be guaranteed? I thought that's why it's being disabled on tachyon, because rgb would be fundamental to the step from 500hz -> 1000hz

[strong siren]

Tachyon is more than that

So generally speaking we would expect

Dynamic Rgb effect > static non-tachyon > tachyon

And yes, the more keys the RGB causes to change per tick, the more influence it has

You can verify this by changing the speed of a cycle RGB effect for example

[gleaming silo]

Interesting, I wasn't fully aware of it being that restrictive, but on a hardware level it makes sense

[gleaming silo]

Seems to work very nicely on 80HEs with 8khz polling as well!

[alpine socket]

What is this?

I wanna test Latency on HE keyboards is there anyone who can help me with this?

[quiet root]

look at how optimum does it or even rtings. basically the simplest is a solenoid, high speed camera and simple game/app that does some easy to see change as soon as the press is detected by the PC.

Otherwise (i think how rtings does it) is to use a usb analyzer and solenoid/high speed camera to get values without the PC and then e2e latency

just be aware that e2e latency is only comparable to the exact same setup haware and software stack wise as they all play a role in e2e latency.

[alpine socket]

Ah

Thank you

The USB analyzer thay have is

1300

jesus

[quiet root]

yeah a good analyzer costs a chunk of money

but they do more than just keyboards so it makes sense

[alpine socket]

Mhmm

So just the optimum/Rtings do it until I feel like dropping a band on the USB analyzer?

[neon shard]

finalmouse xlat

if you’re somewhat skilled with micro electronics

[alpine socket]

I am not.

I do own an xlat just not sure how to use it completely with HE keyboards.

I'd love to know how exactly wooting did their display.

[quiet root]

with an xlat

and a solenoid

basically we implemented keyboard support into the xlat firmware/software and upstream improvements if we find some

the solenoid then just needs to complete a circuit when it touches the keycap and the rest is the magic xlat work

@indigo mantle might be able to give you some hints as they worked on it the most

[alpine socket]

Ah.

[alpine socket]

I should've figured the firmware was different. I spent all night trying to figure out how you were using it.
I was hoping the stock firmware Finalmouse released would be able to do it but it was designed for mice soley.

Thank you.

[quiet root]

we did upstream the changes as i said so it should also work at some point with finalmouse firmware

we wont gatekeep stuff like this

i think you might need to build the firmware yourself rn though

[alpine socket]

Time to learn I guess.

[indigo mantle]

@alpine socket Finalmouse added basic keyboard support but you need to compile it yourself as they don't created a new release for it yet. Our version doesn't contain the latest changes they added.

As the setup has to much stumbling blocks we discontinued the plan to offer complete kits for reviewers. There are a lot of small things which can easily throw off the results. For example any slightly movement of the solenoid can already change the outcome significantly. Also a ground loop can mess it up heavily, so it's very important how the solenoid and XLAT is powered.

You can read how to set it up from the Finalmouse repro. If you want to use our version you can download the binary here.

[alpine socket]

Ah, thank you.
Sorry for my dumb questions. I am just getting into all of this.

[indigo mantle]

Please keep in mind that we abandon the project as it would be to time consuming in order to provide guidance how to use it and to teach about all the pitfalls. Meaning we stopped it as we can't really provide support for it.

[alpine socket]

I know. I will figure it out.

[atomic kernel]

Hi there! Dumb question but one of my software engineer friends was skeptical when I showed them the github. I don't know how any of it works but they said to steer clear because the github base sdk hasn't been updated since last year (v0.1.1) and that can lead to buggy software, yet I'm seeing in this discord that the current version of Wootility is v5.1.1 so I'm confused. Can anyone explain so an idiot like me can understand?

[sweet peak]

That sdk is so you can write your own software to use the analog sensing or rgb.

This has nothing to do with wootility which is updated frequently.

[atomic kernel]

I had a feeling that was it, but my software friend put doubts and said I should look at name brand keyboards for more reliability

[sweet peak]

as a software dev, i find wootility to be very well done.

i know it is one of the pilars of the company.

[quick bough]

Definitely get a wooting if you're looking for an analogue keyboard

I see so many people buying cheap chinese crap and then being disappointed

[quick bough]

Sorry, I mean a snap tap-enabled hall effect keyboard with the latest SOCD, rapid trigger, and double tap features

[alpine socket]

Wooting best there is. Geonworks the only other company that comes close imo

[golden glacier]

Hey there, I'm wondering if there's a way to set the rapid trigger press further than 2.35, maybe by tweaking somewhere hidden in the code files. I have a 60he, don't know if that makes a difference. If it's not a difference, then i put it as a suggestion, a full range rapid trigger would be useful. I'm currently using for osu! with continuous rapid trigger and I'd just a little more like 2.8

[quiet root]

my main question would be how youd benefit from more than that

because with over 2mm its already questionable why you dont just put your actuation point closer to 1mm or 2mm

setting it that high basically negates almost all advantages RT gives you

also just as a sidenote this isnt the right channel and the firmware checks the value set as well so editing it in wootility or such wouldnt make it work

[quick bough]

Wow, that's at least 8 bytes of needless instructions

[golden glacier]

of sorry what's the right channel ?

[quiet root]

prob a post in #1141096226884956181 with what you want and why you want it. as in give examples how it would benefit people

[golden glacier]

okay thanks

[junior harness]

is there a good way to shut off the keyboard backlight from the os? Like when I lock my screen?

or do they only expose an api for setting permanent backlight configurations

[lunar portal]

is there any good way to use 1 keyboard for two PC and switch between them not loosing pooling rate , I do not need 8k pooling, 1K stable would do the job !

would cheap USB switcher do the job ? https://www.amazon.co.uk/UGREEN-Desktop-Controller-Aluminium-Keyboard/dp/B0CH7T76RX?sr=8-6

[junior harness]

anything usb3+ should work. You'll probably find it way more convenient if you get a switch that has its own power supply

this way when you do switch it doesn't reset power to all attached devices

[junior harness]

I guess is the settings api documented anywhere, like to adjust the keyboard's builtin sleep timeout?

[quiet root]

the keyboard has a sleep setting to dim the backlight when its unused

[cinder wharf]

can i have two 60he+ boards plugged in at once with wootility (web or installed)?
i'm using a 60he right now as my primary keyboard but i'm also building my own case for another 60he (wooting module).
i just want to copy over my entire config (all profiles etc) from my main one to the module

[quiet root]

you can plug in as many as your pc can handle

you can also just copy profiles, they then should automatically be inactive profiles.

inactive profiles are stored on the pc and available no matter the keyboard connected

[cinder wharf]

cool ty

[robust raft]

was the LED bar customization command added to the rgb-sdk? i searched this chat for it, seems like someone figured out how to send rgb to LED bar but never posted the code.

[rocky wharf]

It doesn't look like its available in the SDK yet from what i can see in the commits (Quick looks).

[robust raft]

any chance you can make your code available?

[rocky wharf]

I don’t think so, it contains a lot of reverse engineered data.

[strong siren]

we're making some significant rgb-sdk related changes and want to have this available soon.

while we don't have it publicly available, it would be interesting to know your use cases for the lightbar so we can design the api well

would updating just the ledbar and leaving the rest of the keyboard alone be useful?

as in, would them being completely independent from each other make sense

the absolute easiest way on our side would be to allow you to send a different report that sets the entire lightbar and that's that.

but this way you lose the background-service information which is kinda crappy

[rocky wharf]

I mean, for third party rgb software that already implements the keyboard, it could be useful for certain informations like now the discord one.

Like the keyboard rgb, if you enter wootdev, you loose the native rgb stuff for that time being.

[strong siren]

one way I thought of to do this was to add an effect layer to the keyboard and another for the lightbar, that once added, would display whatever the rgb sdk wants. so if you remove this effect layer you essentially remove support for the sdk.

this would solve a lot of issues but it's difficult enough to understand that I suspect most users wouldn't understand how to use it

for some more details, the "significant changes" are mostly allowing concurrent updates of multiple keyboards

[rocky wharf]

This seems to be a really interesting approach to be honest.

[strong siren]

this is a limitation I only really realised once I was implementing the software we used at Gamescom with the rgb wall

the current sdk cannot do this, and I'd like it to be able to

[rocky wharf]

It would require new firmware first right?

[strong siren]

it would not

well the lightbar part yeah

concurrently updating multiple keyboards would not

[rocky wharf]

But the only apply the Color to the effect layer part?

[strong siren]

yeah

would be a firmware change

but as I said we're getting ahead of ourselves as it might never actually be done

[rocky wharf]

Sure, but still a interesting approach to the whole sdk part.

But you/team already wrote something custom for the gamescom wall?

[strong siren]

yeah, and I'm working on a new sdk with the findings from that

roughly looks like, as a consumer: (all very WIP)

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_get_device_ids(Span<ulong> device_ids_ptr, ulong capacity, out ulong actual_device_count_ptr);

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_get_device_info(ulong device_id, out WootDeviceInfo device_info_ptr);

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_init(ulong device_id);

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_scan();

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_close(ulong device_id);

  [LibraryImport(sdkDLL)]
  public static partial WootResult woot_rgb_update_keyboard(ulong device_id, Span<WootRgbColor> rgb_matrix, ulong byteLength);

  [LibraryImport("sdkDLL")]
  public static partial void woot_rgb_set_log_callback(LogCallback cb);

[rocky wharf]

I was just about to ask if again in C/C++

[strong siren]

instead of the weird

select_keyboard(idx);
update_keyboard(idx);

which of course you can't do concurrently

[rocky wharf]

If I remember correctly, I do save all available endpoints in a vec so if I’m not wrong, I could update them concurrently but can’t test it obviously.

[strong siren]

not really public facing, but if you're curious: https://github.com/DarthAffe/RGB.NET/pull/427

[rocky wharf]

I will take a look shortly

[robust raft]

thats a good point. i think i would like it to be separate however loosing access to background service is a big downside tbh. since its written in C im sure there are ways to recieve system notification information and system data, but probably a pain to do.
my use case is just for notifications (not just discord), mic input on the LED bar, system audio out on the bar etc.

[strong siren]

you should be able to get all of that with background service i think

well mic input would be discord specific and not system wide

notifications we might be able to add, do you mean WIndows notifications?

[robust raft]

mic input
im generally looking for system mic input, so i can see how loud mic gets. not just in discord. im just i can do this in C without background service, but i'd have to look
notification
yes general notifications that come up in windows, like calendar notifications

[gleaming shadow]

hey im trying to get the profile switcher on arch linux but it needs the wootility-lekker package, i have wootility installed and i cant find the lekker package anywhere, anyone know what it is lol

[balmy iron]

Sounds like an outdated PKGBUILD, since you have such problems you probably got it from the AUR. And because you're using the AUR you should know how to mend PKGBUILDs

[gleaming shadow]

tbh the only reason im on linux is because windows is annoying, im not good at it lmao but that makes sense to me, ty ill probably figure something out

[balmy iron]

In that case you are probably using some AUR helper, far as I know all of them have an option to edit the PKGBUILD, so choose that option and just change the dependency to wootility instead of wootility-lekker

[gleaming shadow]

okay, tysm

oh yea

i found it

yep that worked, tysm

[quiet root]

the other option would have always been to not use arch based distros but smth more beginner friendly

[paper saddle]

Would it be possible to make the Discord mute integration work while Tachyon mode is enabled? The Caps Lock indicator still works in Tachyon mode and it seems like a similar type of feature, so it would be amazing if the Discord mute status could also be supported there.

[tiny olive]

1

[floral crane]

How does the background service work? Should I commit to rewriting my profile switcher or are you working on that?

[quick bough]

I'm pretty sure profile switching based on open games/programs is one of the goals of this background service

[floral crane]

That would be nice, but what's the timeline on that? It's been years since rust SDK and background service were planned, I can rewrite my program in like a month.

[quiet root]

@strong siren is the man

[quick bough]

hahahaha. Yeah, if you want it asap, do it yourself.

[quick bough]

I can't believe Wooting used to use MicroUSB

Also shipping with such outdated firmware smh

[quiet root]

you can in theory use the usb-c from a wooting two(he) and enlargen the hole in the w1 case to have it usb-c

[lunar portal]

I wondering is there any way to change color profile based to what PC keyboard is connected . PC1 =red static , PC2 =Blue static

[quick bough]

<-- dis u?

[quiet root]

why. should be true

they both use the same pcb connector and if i recall right also mount exactly the same way in the bottom case

left is w1 and right is w2 (technically LE but same same)

so yeah only real difference would be the hole in the bottom case

[quick bough]

I'm not gonna destroy my brand new Wooting One

[quiet root]

was just saying you could do it

[quick bough]

ah man, the minimum actuation point is 1.5 mm

[quiet root]

yes

ofc

its flaretech

[quick bough]

tbh using this does feel like a downgrade

but it's so much better for ergonomics

why u no TKL

[quiet root]

use an 80he problem solved

its tkl

[quick bough]

and don't say 80HE I'm gonna

https://tenor.com/view/swankaids-aidan-uni-cat-explosion-gif-13067557236003860591

I mean I do have a 80HE, but... first I gotta use the One for a bit

need to get used to not having a numpad

[quiet root]

idk why you wouldnt jump to 80 straight from a 2he/fullsize

[quick bough]

because it's a garbage layout ???

Like with the One, it's a proper layout, just no numpad

very easy concept for me to understand

I'm so having such a hard time typing because I need to press the keys further down than I had to before

[quiet root]

how is 2 missing keys garbage layout lol

[quick bough]

Would you honestly say the only difference between these 2 layouts is '2 missing keys'

I count 4 missing keys

and some squishing

[quiet root]

idk never use right control and oither than that only 2 keys from the home cluster are missing

so imo 2 missing keys

and yes you can just remap mode to scroll lock and move them all one over or smth so no theres no key missing in the f row

at best if you really use all right hand modifiers a lot you are missing 3 keys with right control

anyway all of this isnt a discussion for here to begin with

[quick bough]

I like my home and end keys 🙁

[quiet root]

fn layers exist and again not really a discussion for this channel to begin with

[quick bough]

but it's okay, I've probably got a TKL razer somewhere in my collection, just need to duct tape over the shitty lights they have you can't turn off

[quick bough]

Ah yeah also somehow with the newer firmware, the Fn layer no longer has passthrough

I solved this ages ago by just putting the underlying keys on the Fn layer as well, but maybe that should be a default?

Like sometimes when I'm gaming, I want to control my media, but then I press W and it doesn't register until I let go and press it again

[sweet peak]

this sounds like a subject for #1019755933959733258 or #1141096226884956181

[quick bough]

Don't minimod me

[sweet peak]

if you want help ¯_(ツ)_/¯

[quick bough]

I know Wooting staff read here

I don't expect anything to be done about it anyway

This was very clearly an intentional change they made in the firmware quite a while ago

[sweet peak]

yeah i know you know.

[quiet root]

this sounds like a subject for #1019755933959733258 or #1141096226884956181

[quick bough]

Don't minimod me smh

In my experience with companies, the only time I get them to do something is when I can get a ticket directly into their JIRA or whatever it is they actually pay attention to for pending work items

So it really doesn't matter to me which void I scream into otherwise

[quiet root]

im not. im telling you as an actual mod.

im am 100% sure we have told you in the past this channel isnt your playground to do with how you please.

[quick bough]

[torpid glade]

@blissful island nimm ma fa an

[quiet root]

english only also not the right channel for this

[flat wigeon]

https://github.com/WootingKb/wooting-analog-sdk/issues/12 <<--- I'm confused that this still isn't solved. This works over the configuration interface since day one, it's just slow and sluggish

[strong siren]

actively being worked on fwiw

[flat wigeon]

"Actively", what would that active be over the span of years. All I need is a unique identifier for the key like in the RGB SDK. I can add layout data myself.

[quick bough]

Yeah well, maybe you just need to be invited into their Jira or Notion or whatever 😛

I mean for Wooting in particular, the fastest way to get something done is to PR it yourself and ping Simon asking him to merge it

Of course doesn't work for the closed-source software like the firmware & Wootility

[soft fractal]

This is the wrong place to ask for help. Either create a thread in #1019755933959733258, or use the support wizard on the wooting website.

[gleaming silo]

Is anyone able to explain to me what exactly the "Wooting Restore" device is? (extra chip on the board? just a different usb device reporting?)

I'm curious if it is possible to brick your keyboard, or whether "flashing" is taken care of by the ROM bootloader which should just flash fine depending on the boot pins

or how the flashing process works in general (what communicates with what on hardware level), if anyone happens to know something about that

[kindred skiff]

If it shows Wooting Restore, that's the emergency bootloader kicking in to reflash the main firmware through Wootility.

A true bricking shouldn't be able to happen, but tech doesn't always work like that.

[strong siren]

Restore is the bootloader, and should be practically impossible to overwrite it

when the keyboard starts up the bootloader tries to load the main firmware and if it fails you get the E and R key leds lighting up red and it gets into this "restore mode"

[gleaming silo]

What if the firmware does load, but the firmware is eg. empty? Would it still go into said restore mode? And by "the bootloader", do you mean the ROM bootloader of the MCU or an extra thing specifically for the keyboard (eg. an extra chip?)

[quiet root]

pretty sure that would fall under corrupted firmware when it goes into the ER led restore mode

and afaik we have a custom bootloader on the mcu

i mean you can just disassemble your wooting and see for yourself

we cant really hide this

[gleaming silo]

I see, interesting. Custom made MCU with a custom bootloader? Or genuinely an extra controller? Sounds like that would then verify the existence of a proper firmware in some way

[quiet root]

no custom mcu

you can just flash custom bootloaders to the stm32 mcus for example

and i think its the same for the avr mcus we used

[gleaming silo]

Interesting, i thought they are readonly

[strong siren]

if you stick a debugger into the pins on the pcba you could wipe the bootloader (don't do that)

[gleaming silo]

o i see

That makes a lot of sense now

[quiet root]

i think we never flash the bootloader either during firmware updates. i dont know if we could but prob mostly we dont wanna risk bricking a device

[gleaming silo]

Do have one more question, what exactly tells the bootloader to go into flashing mode? I assume Wootility sends a certain command to the MCU that boots to the ROM bootloader to flash?

[strong siren]

where is the gist tony

[gleaming silo]

Pretty sure that shouldnt be possible and require another way to connect to the chip physically?

[quiet root]

https://gist.github.com/BigBrainAFK/0ba454a1efb43f7cb6301cda8838f432

https://gist.github.com/BigBrainAFK/2d80b702fe27eb26e45ca29faa44fcd2

idk which of the 2

also they might be outdated

[strong siren]

yeah you can figure it out from there

[quiet root]

but they were updated for LE or 60he i think

[gleaming silo]

wait theyre public?

interesting..

[quiet root]

so somewhat up to date

[strong siren]

theyre not public anymore as of recent

[gleaming silo]

oh so i suppose theyre not intended to

[quiet root]

as wootility is a javascript based this was publicly accessible for ages

[gleaming silo]

I've been.. digging around so to say

just out of curiosity and hobby, nothing i intend to publicize

[strong siren]

yeah them being readable was more of a side effect than an intended consequence

[gleaming silo]

pretty much have an up to date list of that above

[strong siren]

there are some implementations of some things

https://github.com/meeuw/libwootility

for example

[quiet root]

must resist linking dota from basshunters

[strong siren]

oh cool it supports the new protocol already

[gleaming silo]

damnit people were first

Although the new protocol would be d1 da?

[strong siren]

yes

[gleaming silo]

dang really thought I'd be first to dig around in it

[strong siren]

some of it we publish ourselves

[gleaming silo]

got a fully deobfuscated wootility and already started making protobuf files for all the messages

[strong siren]

our rgb sdk is open source and i've contributed to openrgb with some protocol related things too

you're definitely not the first to do it

[gleaming silo]

shouldve figured

[strong siren]

but yeah bootloader is not intended to be updated after the keyboard is produced

[quiet root]

unless you got connections to diogo the man

who custom flashes your preproduction keyboard so you can keep the serialno

[gleaming silo]

i was just worried because perhaps we got to the point we IDA'd half the firmware and managed to flash custom versions

and were curious in what way one could brick the keyboard by flashing bad stuff

[strong siren]

if you do it like wootility does it i would be surprised if you brick it

it's probably not impossible though.

[gleaming silo]

I see

[gleaming silo]

We did flash it via wootility yes

We also found some kind of way to flash a local firmware locked behind some woot dev mode?

havent looked much into that

[strong siren]

that is probably stupidly easy to enable

[gleaming silo]

afaik in theory it checks isWootDevEnabled on the heartbeat

[strong siren]

thats not it

wootdev is the rgb sdk

[gleaming silo]

ah it's separate things?

[gleaming silo]

ohh

huh

[strong siren]

check in the gists

[gleaming silo]

iirc my friend figured out some command to enable/disable this wootDevEnabled thing

[strong siren]

for wootdev

[gleaming silo]

i think along the lines of D1 DA 09 01

ah wasnt 09 but close

[strong siren]

https://github.com/WootingKb/wooting-rgb-sdk/blob/98364bcd85aa267ee1cd657197f5d886175251f1/src/wooting-usb.h#L97

[gleaming silo]

the protobuf for the rgbbins is where i started to lose motivation and call it a day

I believe we did see some kind of other mode you can enable

that broadcasts debug data through some usage page? not sure i remember correctly

(not talking about FF54)

[strong siren]

uhhhhh

[gleaming silo]

@quartz vector do you remember what i mean

[quartz vector]

not exactly sure which one ur referring to, was it the one we found when reversing the firmware?

[gleaming silo]

i think so

This was probably just rgb stuff? lol

Although 09 is uh

[strong siren]

im pretty sure that one is deprecated actually lol

[gleaming silo]

probably

[rocky wharf]

That will take some time 😄

[quiet root]

im expecting a 40c3 talk now from all of you

[toxic yoke]

Hey... so 1st question. Is it known that the analogue sdk on git hub is in a state of not compiling?

[strong siren]

It's probably dependent on rust version if i had to guess, I saw your github issue. we'll look into it

[toxic yoke]

that's excellent. I'm looking forward to it.

my rust version is 1.91.1

and my cbingen version (was required) is 0.29.1

[limber owl]

Sorry for that 🫣 (that repository is mine)

Would be really nice to have the protobuf specs though! I did this by reverse engineering (and it was pretty similar to the old protocol)

[limber owl]

I'm glad you noticed! Can I get this merged? https://github.com/WootingKb/awesome-wooting/pull/8

[sly cave]

I recently started messing with the Analog SDK and RGB SDK using this rust wrapper (https://github.com/ShayBox/Wooting-RGB) since it was in the official developer portal place. But I updated my 60HE (ARM) firmware and the library doesn't work anymore. (It doesn't detect my keyboard) Is this an SDK version issue?
The Analog SDK works fine though.
Is there any more up to date rust wrapper or some other way to communicate with the RGB SDK? There aren't any official rust bindings for the RGB SDK right?
I'm still kind of a newbie with programming stuff.
(Ping me when replying)

[strong siren]

the rgb sdk has been updated recently, and it should be compatible with the same ABI as before. it looks to me like the rust wrapper needs to have its submodule updated

[sly cave]

I see. I guess I have to try and recompile with an updated submodule or just pray that this gets updated. Thanks for helping

[sly cave]

Yeah updating the submodule fixed the issue.

[gleaming silo]

I am once again curious about something; FF55:0016 (i believe? endpoint id 2) is sending an URB_INTERRUPT packet every time a key is pressed/released.

A payload of length 28 with no obvious meaning (but kinda looks like a bitwise keymap?) and the IRP ID changes between 0xffffbf8a78ad7720 for presses and 0xffffbf8a78ad20d0 for releases.

What is this for, is there any obvious use-case I am missing?

[strong siren]

i dont recognize it immediately, is it on any keypress?

that's the usage page for the interface used for configuration (wootility, rgb sdk) so it doesn't immediately ring a bell what that would be

yeah it's probably just nkro, it's not on ff55 though, you probably have it mixed up

[gleaming silo]

that could be

ohh yeah it probably is nkro, not 100% sure how nkro works

i stumbled across it while testing some stuff with UsbPcap

[digital pond]

I might be missing something, but I’ve seen a lot of discussion about "WootDev" and I’m not entirely sure what it refers to.
Could someone explain what it actually does and what exactly is that? I have a basic background in electronics and programming.

[quiet root]

wootdev is just a role for people from the community who made software using our SDKs/communicating with our keyboards

thats it. nothing to more nothing less

[digital pond]

Oh okaaaayyyy ty 🤣 not gonna lie I was lost 😆😆

[quiet root]

unsure how though as we havent spoken much about wootdev in ages

unless you meant wootdev mode in the firmware

if you meant that its just rgb sdk mode basically and nothing youd normally concern yourself with if you just use the rgb sdk

[digital pond]

yeah exactly that’s what i meant I meant both…

[quick bough]

I wasn't even aware there was a role like that

I still miss my valentine's day role

[floral torrent]

Can somone explain the beta feature of applying the installed switches to my keyboard via the software?
Like for example.. I got Geon Raw HE with 3.4 mm travel range.
What do I win, when keyboard knows the exact travel time instead of its standard 4mm?

[quick bough]

You make an autist very happy and another person's happiness is a win, yes?

[quiet root]

more accuracy. there is a slight drift due to the mismatched range of the switches

[quick bough]

so pretty much what I said

[light chasm]

@quiet root i like your github image

[quick bough]

Literally 1984

[thick osprey]

Got my hands on a 80HE and thought I'd pimp the Fn-layer reveal a bit. This is combining the analog SDK and RGB SDK

[sly cave]

That is such an amazing idea. It never even crossed my mind to animate something like that. And based on the analog signal too! (I assume)

[lavish schooner]

Any chance you'd share this?

[thick osprey]

I made it with Artemis https://artemis-rgb.com/
But at the moment there's an issue with the Wooting plugin where the keyboard stops updating after a while. Still being looked in to.

[sly cave]

Flappy Bird with RGB SDK and analog SDK (For detecting pressed keys, no analog input).

I made it using a custom effect engine I also made. https://github.com/LuuppiChan/rgb-engine

[quiet root]

sadge not an artemis plugin

oh also 60he only

[quick bough]

damn, no Wooting One HE support?

[sly cave]

The issue is with the input system which has translations from scan codes to rgb matrix positions. I don't really know how to translate them so I just hardcoded them for now. I believe that this flappy birds works on any Wooting since it doesn't need that.

[sly cave]

I uh... I'm dumb because I found out about Artemis 24 hours ago. (The message above mine by Robert)
I will have to give Artemis a try since it looks amazing.

[strong siren]

artemis is cool but it's not the most user friendly 🙃

it is pretty developer friendly though if you want to add functionality with plugins

[sly cave]

Surely it's easier than creating a full engine and creating effects with code? 😂
I had fun creating that though and I learned valuable lessons.

[sweet peak]

Those are the best projects

[lavish schooner]

A very simple project using ArtemisRGB n.n it swaps between an effect if muted on discord and music synth

[kindred skiff]

No such product exists.

The Wooting One and Two are not HE based. They used optical switches.

[quick bough]

You could fix this

[kindred skiff]

We did. It's called the 80HE.

[quick bough]

This is Ins/Del/Home/End/PageUp/PageDown erasure

[paper crow]

Keyboards are like ogres

They have layers

[quick bough]

Imagine a situation where I am using WASD to move, arrow keys to look, and Home/Del/End/PageDn to rotate (as opposed to Numpad 8/4/5/6)

How are function layers going to help me with that

[lavish schooner]

This is not the place to be yapping about your old keyboard :|

[quick bough]

No minimodding please

[lavish schooner]

You keep yapping and it's very annoying for us trying to actually do stuff. It's not minimodding, it's expressing my annoyance

[quick bough]

How are you being impeded in your ability to do stuff?

[lavish schooner]

This is not the place to discuss the things you're discussing. I stand by that and I will not reply to you on this further because it feels incredibly ragebaity.

[sweet peak]

#🤖│community_dev message

[quick bough]

Btw did anyone notice they hired a new person, jimvdl who's like basically not active on the Discord at all

But at least we got Jira tickets with K- prefix, let's go !!!

[quiet root]

idk what youre on about with that one but seems unrelated to wooting

[quick bough]

How does talk about Wooting seem unrelated to Wooting

[quiet root]

we have no jimvdl nor do we use jira

[quick bough]

Then maybe check why he has permissions in the Wooting org lol

And yes I know you don't use Jira, but still, you have a similar ticketing system

[quiet root]

if github is your idea of ticketsystem sure

[quick bough]

So something like K-1234 means nothing to you?

[quiet root]

why would it

[quick bough]

[quiet root]

at least the jim part i figured out now but still no clue why theyd use some ticket style number stuff

[kindred skiff]

Only a fraction of Wooting staff ever visit Discord. Nothing new there.

[sly cave]

Is there a way to extract data from a config such as 045a0673980efcf95b5f5b6c959eb63b0f9f?
From what I can see it seems the config isn't stored in that string and that's just a key to the config which I assume to be on a server.

[kindred skiff]

It's just a link to our server. No actual profile data.

[quick bough]

https://api.wooting.io/public/wootility/profiles?code=045a0673980efcf95b5f5b6c959eb63b0f9f

I can tell you on target.device, 0 is for Wooting One assuming they use the same enum on the firmware update endpoint

and 5 obviously for your 60HE

[sly cave]

Thank you very much. Although. How do the values work? How can I translate them to something that the Analog SDK can understand? I tried, but none of the KeycodeType enum results match what's in the config.

[quick bough]

Reverse-engineer it. Shouldn't be too hard since you can upload any config you want and then see how the data looks.

[sly cave]

Alright, thanks for helping.

[wanton granite]

i would like to flip the activation of a given key: fully pressed (255 raw) -> reads as non-pressed (NoMapping) and when not pressed, it reads as fully pressed.

Also, is it possible to obtain ALL analog values, not just between 0 and 1.0? (0 to 255 in raw I guess!)

[quiet root]

i mean the first one seems quite simple just take the absolute value of the raw press - 255 which should give you the inverted range you want

and for the second the 0-1 is all analog values

i dont think the mcu has access to more than that either currently

[strong siren]

we're increasing the resolution soon actually 👀

but it's really a tradeoff between how much data you send per keypress and how many keys you can send at once

[wanton granite]

Thank you Tony!

[wanton granite]

If i plug in my 60v2 with a key pressed, that key does not work. Therefore, I assume when the keyboard is plugged in, each sensor assumes the current magnetic field as default, and does not act on weaker magnetic forces. i would like to reverse the force, i.e., use weaker magnetic forces as a "press" (such that the weaker the force, the more the button is pressed). The reason is, im trying to replace the spring of each switch with a magnet.. that needs to rest close to the sensor. as i push the key to the sensor, im assuming the magnetic force on the sensor decreases; i'd like to act on that. would it be possible to, through the plugin, allow for weaker magnetic forces to be read? or is this much higher level than i can do with the plugin? I was able to write a plugin that reverses the float value read, but unfortunately, as soon as i place the magnets near the source and turn on the keyboard, it does not work.

[quiet root]

you cant change how the keyboard works with the sdks

[wanton granite]

I opened a request on github 🙂 thanks!

[quick bough]

Things are getting テンズ

[grand flax]

trying to make more reactive (and non reactive) effects :)

So far here is the noise one but pressing down causes a local hotzone around ur finger

Fire effect (i loved it on my razer ornata)

then just a rain, sparkles, and an accidental analog based purple sparkle

[grand flax]

this one's a little experimental lol but it it takes into account pressing depth and release speed. Lower presses result in shorter dimmer ripples that only last a few keys before disspearing and full presses haev ripples go across the whole board. Similarly, slow releases have slow expanding ripples and quick ones are quick!

[grand flax]

Joystick effect - perfect for visualizing your movement in games or to simulate an eye 👀

[floral crane]

It needs more testing, but I decided to do a final* release of WPS because I couldn't wait, and there were more people with new v3 report/response size devices than I thought.

It works on Wayland now, but still only XWayland windows due to no lib implementing the wayland foreign protocol.

This will likely be the final release unless more breaking changes come to the firmware/sdk/wootility before Wooting's profile switcher releases.
https://github.com/ShayBox/Wooting-Profile-Switcher/releases/tag/3.0.0

You guys should consider updating the firmware to make v3 devices still respond to v2 reports with v2 responses for backwards sdk compatibility, also consider updating the sdk or making a new sdk to include all the undocumented features that Wootility uses that I've had to reverse engineer, or consider releasing the background daemon and adding an API to it for everything instead of the SDK, since only one program can use the SDK at a time. That would probably be the best option so firmware/sdk changes don't cause breaks and the API can be fully documented automatically with protobuf or openapi and have multiple language bindings generated easily.

[lavish schooner]

Might I bother you about the noise + hotzone setup?

[grand flax]

Sure thing!

[lavish schooner]

Sent you a DM, thank you

[dreamy pawn]

Just got a 80he and was trying to set the fn key to behave like it does on my MacBook, no dice. Any chance of that being added in? I’d prefer to not try and remap with external software.

[kindred skiff]

Apple uses some weird non-standard stuff for their FN keys. It is a separate thing to what we do with ours. Our FN key only exists within the keyboard. I am not sure if an Apple "fn" key can exist within our keybinds, since it uses a signal over the USB cable, not an actual keybind if memory serves.

[twilit ore]

Hi folks!

Recently we've been working on a bit of a structural overhaul for the Analog SDK. Instead of having a wrapper call the locally installed system SDK we now have a wooting_analog_sdk_dist that can be distributed alongside your apps so they can run completely standalone, without the need for your user to have a local installation of our SDK. The wooting_analog_sdk_dist will still try to delegate calls to the system SDK if the version is compatible (like before), which means as long as we don't introduce breaking changes to our FFI then developers don't have to upgrade to the latest SDK as often. If the user decides to update their local SDK your apps will automagically be able to use any patches or bug fixes we've applied.

We've tried to keep the breaking changes to a minimum, so it should be as simple as a drop-in and replace. If you want to give it a try you can use the migration guide that is included in the 0.9.0 release candidate:
https://github.com/WootingKb/wooting-analog-sdk/releases/tag/v0.9.0-rc.1

This latest release candidate also has support for our upcoming analog protocol revision which brings extra context per key press, such as physical position on the keyboard and its actuation state. Once the firmware is available you'll be able to install it via Wootility and try it out.

Please share any feedback or issues you encounter in the thread or feel free to open an issue on GitHub.

[quick bough]

The man, the myth, the legend

[quiet root]

as i said i figured out who jim is

[quick bough]

[quick bough]

Well, technically even if they did, malware (i.e., software running directly on your machine) could simply downgrade your keyboard firmware if it really wanted to read your keyboard's S/N.

[quiet root]

also unsure how the serial helps anyone but you

[quick bough]

Maybe to take over a Wooting Hub account, if that's a thing they'd use to verify your identity?

I mean, I can imagine people trying to get that just for the silly Discord roles

[quiet root]

we dont use them for that

because people can easily post images of the SN anyway

[quick bough]

Yeah fair

[quiet root]

also im pretty sure while not plaintext all those other keyboards have a way to read the SN meaning if the vendor software can do it malware also can easily do it

[quick bough]

Just like a SSN, it's not for identification

[sweet peak]

Fingerprinting?

[quick bough]

Possibly a concern (in addition to other identifiers like serial numbers on your SSDs/HDDs), but 'rootle' was specifically talking about 'infostealer malware'

[quiet root]

well i obviously cant go into detail but thats not something id be worried about given what i know about how this data is stored/accessed internally

[quick bough]

I think maybe it would be a good point for user privacy to just put it in an HID protocol response as opposed to the 'standard' field for it given how easy it is to enumerate blindly as described

even if it is the user's own fault for getting themselved malware'd

[floral crane]

That would break my software, serial number is required to access the associated data in Wootility, or some form of parts of the serial number, there's like 2 formats of serial number internally that I have to support. Serial number is safe to share afaik it doesn't matter, if you have the keyboard physically they can't steal it from you.

Also the generic hid reported serial number doesn't match, it's a different format you have to know how to convert into the standard serial number using other info like device type.

The downside would be permanently breaking Wooting Profile Switcher because I can't reverse engineer Wootility anymore, the JS minifier is too well obfuscated now, even basic strings are encoded and hidden.

[limber owl]

I have many devices / components in my machine that report their serial number in a generic way. I think wooting is fine as is and I think you're paranoid.

Anyway, to continue on the paranoia path, Windows keeps a record on any connected device (i think this includes the serial number)

[little kindle]

Hey, was just wondering if there's any support via any mechanism to programatically generate and import custom RGB profiles? Want to try out a few things for static like gradients/etc. in various colors, but don't want to have to manually click in all the colors...

[quick bough]

https://github.com/WootingKb/wooting-rgb-sdk ?

[lavish schooner]

You can code one using the rgb sdk

[strong siren]

If what you want is wootility to accept colors, no unfortunately. We want to allow users to generate nicer gradients within wootility, but importing externally generated colors is also not out of the question

We will be improving the RGB tab in a future update, and it's possible that we can define a format for you to Ctrl + v a json array or something into the page to set all the colors at once

[little kindle]

Yeah, saw the sdk, but wanted to be able to save them to the keyboard as well

[little kindle]

Yeah, that's what I'm looking for

[strong siren]

If anyone has suggestions for such a format I would love to hear them

Otherwise json is the most likely for us to use

If you want, you can also edit the local storage json blob manually (change the colors of an inactive profile) but it's not super easy

[quick bough]

Base64-encoded messagepack

[strong siren]

Protobuf surely at that point

[little kindle]

Just make sure it's an old version of protobuf

But yeah, I think JSON works, and I'll look into the localstorage stuff in the meantime. Thanks!

[little kindle]

PoC Tampermonkey script if anyone's interested: https://github.com/LegionDevelopmentGroup/wootility.tampermonkey/blob/master/blue-green-gradient.js. Look at the README for details before using.

[strong siren]

Very cool

[little kindle]

Thanks for the hint about localstorage and an inactive profile, otherwise that would have taken me a bit to reverse-engineer 😜

[strong siren]

Haha no problem, just be ready to patch your code when the json format changes soon :)

[little kindle]

lol

that's why it's only a PoC 😜

[floral crane]

What Json format change

[light chasm]

what are you reverse engineering, the messages? it's just vendor hid, no?

[light chasm]

if the host can already read usb descriptors from the firmware you have more privacy issues to worry about than stuffing wooting's provisional serial behind a hid response

lol

[floral crane]

https://github.com/ShayBox/Wooting-Profile-Switcher/blob/master/src/lib.rs#L45-L297

I could have not made Device which turns into DeviceID for Wootility and DeviceSerial, and just fetched the serial directly, and converted the bytes into the id directly.

[light chasm]

oh i see your doing windows hooks and sending hid to change profile based on your focused application

a service would be cool in this case, maybe optional product download from wootility that could expose a simple rest api

[strong siren]

Shouldn't be too bad, small structure change. We will also bump the version so you could work with both in wps

[gleaming shadow]

oh hey i had no idea you updated this to work again, i appreciate your work 🙂

[rocky wharf]

Thank god I haven’t mapped much of the json structure so far, only the ones I was experimenting with.

[floral crane]

That should be fine. I can just use Json to serde to generate structs for the new version and read the version to determine which one to use.

[light chasm]

yes that's how you use json with rust.

[floral crane]

You could not use structs and just dynamically access everything, checking it it exists

[light chasm]

you could also use a different language that isn't rust in your case.

i don't know why you'd write that in rust tbh

[quick bough]

Embed Lua for the very important business logic of parsing JSON

and now if you think embedding Lua in Rust is too complicated, then make the switch to the far more mature option of C/C++

as they say, "rewrite in C/C++"

[light chasm]

embedding lua in rust complicated?

i just got done writing a full lua sdk (mlua) in rust

it has feature parity with autohotkey

i dont think rust is complicated i think you should know what to use for what you're doing though, if you're making a simple profile switcher just use a high level language like python

your task isn't performance critical and it will reduce your loc by 90%

[quick bough]

You are khvzak?

[light chasm]

i don't understand what you're asking me

[quick bough]

:^)

I think I misunderstood what you meant

Rust is certainly usable, but I don't enjoy using it

[light chasm]

i love me some rust when it's giving me gains and its not just rust for the sake of rust

[quick bough]

I guess it's for when you graduate from being a sociopath to being a psychopath :^)

[sweet peak]

ive never written something in rust, but parsing json in go was fairly straight forward

[quick bough]

the first thing I think about with Go is the lack of exceptions

Of course, Rust has the exact same bubbling problem, but at least it has syntax sugar for it

and yet, Rust has no syntax sugar for 'if expressions', like, say, ternary expressions

[light chasm]

oh go is probably just faster to write than rust and easier to read in most cases

i just don't use it, mainly all bun/typescript for web and scripting and then rust

and c++ for stuff like firmware ofc

[quick bough]

tbf I've been doing a good bit of TypeScript myself

but I'd only be willing to admit to writing C++ and Lua/Pluto haha

[light chasm]

pluto looks cool i haven't messed around with it

lua is a great embedded language

one day when i retire i will just code all the complicated things in rust and just expose lua for everything it will be great

i dont have time for that yet but it will happen

[quick bough]

You may not like it, but this is what peak performance looks like

[light chasm]

i am not mad about that

XD

only so much ts because i wrote the api server with bun/hono and it's a monorepo with a bunch of different customer facing stuff in there, spas

pluto is neat, i have some of these features in my sdk as well, http server, http request

[floral crane]

Rust has errors, it's just called a panic, and it even has runtime unwinding backtraces, but you're encouraged to bake errors as expected Results rather than rely on panic unwinding, which can be disabled to reduce binary size, but then you just get a segfault like C.

[quick bough]

Yes, I know you can technically catch panics, but you're supposed to do bubbling, which makes no sense. Error codes/returns make sense for expected problems, but exceptions are, by definition, not expected.

[floral crane]

Yeah, you can technically catch panics, but you're not really supposed to except to do things before a safe exit. Expected errors/exceptions should be handled with bubbling the Result/Error until you explicitly catch/check it or unwound into a panic.

It depends how you define exception, to me I think of Java, and that means intended or unintended. In java you try catch instead of match, but it's the same idea, you bubble the exception until it's caught or throws and crashes the runtime.

The difference is you have to explicitly bubble with ? on Result types vs not knowing there's a possible exception 10 functions deep and getting a random runtime exception for something that's expected but didn't know was possible.

But that's just Java, you can't even know whether or not something is nullable in Java.
Just about the only real unexpected exception I can think of would be like malloc failing, which rust std does just panic in that case, can't bubble if you can't alloc.

[light chasm]

i rarely have panics with my rust code thats actually the reason i gravitate towards using it instead of something else, the compiler is frontloads all the dickheadedness

is frontloading*

[quick bough]

That's great for you. I like C++. You don't have to. 🙂

[light chasm]

i don't but i also write firmware

kek

[quick bough]

Firmware is typically written in C, no? At least that's qmk uses, last I hacked around with it.

[normal aspen]

yeah yeah keep talking spanish brochacho

[quick bough]

Mariposa?

[light chasm]

i'm just an arduino king

i'm mostly doing stuff with teensy, pretty big bang for your buck with the 4x

hid throughput is goated with the sauce

[quick bough]

And Arduino supports Rust?

Aren't Rust's binary sizes alone way too big for these tiny boards?

[rocky wharf]

You can write firmware using rust that is almost the same size as firmware written in C, just depends on your skill and optimization as always.
you can even write firmware for esp32 and stuff.

[light chasm]

yeah and how much work you want to redo that's already been done

i wrote my flasher for teensy 4.x in rust though, its much faster than teensy-cli

maybe one day i'll suffer and try to port a web based updater reverse engineering halfkay

nah ill never do that nvm

i would however, ship a pre-provisioned unit and then just make my own function to be able to like webhid update

[light chasm]

i don't think yall realize what level of 🦀 i'm actually on ok you could call me

"GOATED with the sauce" and that would be accurate

[quick bough]

My estimated age for you just dropped by like a decade

[flat wigeon]

I suggest WebAssembly for light effects instead of hardcoded ones

Is there still someone working on the keyboard firmware?

[lavish schooner]

Yes, daily

[normal aspen]

yeah yeah muchacho keep speaking spanish

[paper crow]

English only please

[quick bough]

📘1️⃣ 9️⃣ 8️⃣ 4️⃣

[paper crow]

https://tenor.com/view/kid-unamused-whatever-oh-well-so-what-gif-10171209

[quick bough]

月

[light chasm]

quit hating bc im goated w sauce and learn to respect it ty

i will correct you like my pi drift algo corrects timing drift in a streaming macro sequence

[light chasm]

i will drop u like a hid message that doesn’t wait for an ack response

how dare u

[quick bough]

Why not just use UDP smh

[paper crow]

Drop the attitude, this isn't a school playground where you get to feel cool by being obnoxious. This channel has a function, and if can't respect that then you need to leave. Good grief

[paper crow]

And you, don't feed the trolls, don't antagonize.

[quick bough]

Okay, Sensei

[dull garnet]

can you guys make a chat about keycaps?

[sweet peak]

It's called #🔧│keyboard_modding

[lapis wolf]

Good morning! I'm developing provenance solutions and mapping out possible prototyping solutions for a PoT (proof of typing). I'm wondering if anyone can tell me how suitable this platform is for developing a stack that basically proves that text originates from a keyboard? I think the 80HE is a strong candidate because of the actuator data it seems to provide.

[quick bough]

You could certainly get some additional data from the keyboard that would 'prove' that someone is typing

[lapis wolf]

Yeah, what I'm thinking is to slightly modify the keys by adding capacitive sensors to them as well. But as a prototype this seems pretty optimal to start developing on.

[quick bough]

I mean, what exactly is your, uh, threat model here?

I don't think it would be hard to write a driver or even program a microcontroller to emulate the VID, PID, and general HID traffic

thtis kind of reminds me of anti-cheat. you're currently writing a kernel-level anti-cheat. soon, people are gonna write kernel-level cheats or use DMA cards to modify their hardware in ways your software can't even hope to detect.

[lapis wolf]

That's valid. It's not possible to air-gap that completely. But it is possible to increase the cost of generating noise, and by noise I mean a flood of AI generated text on platforms. The idea is not really to prevent artificial usage but to increase the cost enough so that we can filter out most of the noise if we want to. The actual adversaries can be thought out later and how to apply sensors to increase the cost to a degree where it's not really feasible unless you really really want to bypass something with high resources.

[quick bough]

right, but, your detection model is gonna depend on people buying a specific (maybe even custom) keyboard?

[orchid falcon]

If it is with custom hardware you have controll over you Can just use signing

[lapis wolf]

Yup, unfortunately. This is because our tech is not geared towards provenance but credibility. This is where we're way behind the tech itself.

[quick bough]

but is he gonna pay for that hardware and shipping to users so they can prove their humanity?

[lapis wolf]

That's another layer as well. This one is to test out whether it's reasonable as a development pathway. And yes, a device like that should ultimately have some sort of a TPM module that takes care of signing.

[quick bough]

incredible

[lapis wolf]

Text is pretty much the hardest one to do because there's is a severe lack of sensors and without them you can't verify anything.

[quick bough]

May I make a suggestion: People do already have webcams. At least some of them do. That is a way one could observe human fingers pushing on keycaps.

Microphones would also work for some additional data. You can use the sound of the keyboard for some reference.

[lapis wolf]

Ah, yes, but then you would have to also verify the webcam feed. This is something I'm working on though but to your everyday user it might be too many steps.

[light chasm]

what are you building exactly? you could probably do proof of typing as a single factor and make it more simple, based on something like keystroke interval to ensure that it's imperfect and not uniform etc. i wouldn't bank on detecting it at the software level. wooting would maybe be an exception because of the analog signals but just generally speaking.

[lapis wolf]

So, as I stated earlier there, I'm building provenance solutions and this includes verification. The main adversary is anything AI generated which saturates infospheres with exponential noise making it harder and harder to tell apart useful information. The current solutions are post-hoc analysis algorithms which produce too many false positives and are not fit for purpose because of that. This will remain the case because of the very development position of generative AI which is to replace human produced content not reliably but believably. This creates a cat-and-mouse game in which post-hoc verification software is always behind. The blunt solution to this is to gate platforms behind paywalls and use draconian ID verification services to at least tie online information to people, which is intrusive and restrictive.

Now that the wall of text is behind you, this is what I'm aiming for. In this environment the only logically sound way to prove something is real, is to cryptographically tie the content to a physical event. I've already created and launched a platform which does this for video, audio and still images reliably. The next one I am looking at is whether the same is possible with text. Solutions include what you already mentioned, "slow-type" - tag which gates typing speed in a text input field to the max possible speed of a human typist etc. But these are classic post-hoc analysis tools which can be bypassed too easily. The analog signal is the key here, and if that is paired with some other sensors such as a capacitive touch sensor then that's as good as you can get to prove a physical key-press.

All of these solutions are not claiming to eliminate faking of the content, but to raise the bar high enough to be meaningful so that any attacker will have to spend a disproportionate amount of resources for the outcome.

[light chasm]

that wouldn't have been my approach (speed limit) to determine between human or mechanized inputs.

i think you're getting around to ed255 signatures or something .this is why i asked you what you're building, there are potentially better solutions for what you're trying to accomplish. the dilemma you described is the same one that everyone is facing with generative ai content.

if you're going to gate behind a paywell, use LNURL-auth and gate it behind bitcoin's proof of work.

paywall*

[sweet peak]

signed keystrokes, sounds great for enterprise or education. but it would require firmware to do that 🤔

[light chasm]

you could do it through a loop using a custom driver, [signed hid command] -> [service] -> [back to device] output native hid -> pc

could be kewl if you had the keys and crypto in the firmware, driver could authenticate the device that way

[light chasm]

yall ever think about

wooting is great and all but maybe you just like shallow keys

low key

literally

lmk

[sweet peak]

Low profile?

[light chasm]

💯

[sweet peak]

#1141096226884956181 :p

[light chasm]

i have been applying snaptap to my shitty lenovo keyboards

[light chasm]

actually they aren't shitty they are usb composite devices

[lapis wolf]

Sorry if it came out that way, I mean the speed limit as one additional point after yours, not as your point per se.

These are some really good points otherwise. Thanks.

As a prototype there could be a Raspberry Pi as a middle-man. Run a USB from a Wooting keyboard to it and from it to the PC. Could even have the earlier idea of a webcam, but this would be a horizontal keyboard facing one that looks at hand positions and gives a second cheap signal of a key press.

Then again, capacitive touch sensors are dirt cheap and those could be modded to the keys. Would look pretty Frankenstein's monster but it's a start.

[light chasm]

like usb gadget/usb host

i've never done that kind of setup but yea

[light chasm]

when you do are doing your "real person" software do you have access to all the devices and the software like that? like can you send them them your frankenstein creation? lol

[lapis wolf]

It'll have to be a custom device and a whole lot of convincing people why it's a good idea 😄

It's a bit different from the stuff I've made so far that work on any modern Android. The stack is different.

[light chasm]

attach some EEG cables to them

[lapis wolf]

Haha 😄

[light chasm]

or whatever they are called lol

job done!

see how they respond to a hard problem, you can be like a portable polygraph

[lapis wolf]

It'll double as a lie detector at the same time

[quiet root]

have you considered we maybe dont record who we sold what sn to?

in the end if youre so paranoid about the serialno stuff i cant go into details either way so either you purchase one or you dont. idk what else to tell you

[quick bough]

buy it secondhand on ebay

[acoustic dune]

is ts dead

[quick bough]

No, many people still use TypeScript

[acoustic dune]

was asking bcs im interested to create something with ts

[quick bough]

Developer, we have a bug

Analog v2 interface support means analog v1 is just gone? That's a bit meh

Also, where's the source for wooting-analog-plugin hosted now? https://github.com/WootingKb/wooting-analog-plugin says it's in https://github.com/WootingKb/wooting-analog-sdk/tree/develop/wooting-analog-plugin but that's now a 404

also, is there any explanation for what the first byte is encoding in the new scheme?

it looks an awful lot like it might be encoding the position of the key

which makes me worry that it's not possible to disambiguate between the F key and the Fn key other than by their positions

also for some reason it replaced my main layer with the fn1 layer???

[quick bough]

I hope you go back to the drawing board on the analog interface v2 because surely this isn't intended?

[sweet peak]

I know this is your channel, but there are dedicated channels for this

[quiet root]

this is infact not sainans channel

and we do infact not look here first for bugs with out wootility

[sweet peak]

i missed the /s :p

[acoustic dune]

https://github.com/WootingKb/wooting-analog-sdk/tree/develop/wooting-analog-sdk ?

[flat wigeon]

Do you imply here that analog V2 can handle keys by position?

[strong siren]

it can

[flat wigeon]

Does it work with Wooting Two?

[strong siren]

Yes

[flat wigeon]

Does it also work for unmapped keys?

Was the configuration interface overhauled too?

[strong siren]

works for unmapped too iirc

the config interface was overhauled a while ago for ARM. AVR stayed the same

[strong siren]

what do you mean by this

[twilit ore]

yes that is correct

[strong siren]

  uint8_t column : 5;
  uint8_t row : 3;

  // scoped to key namespace
  uint8_t keycode;

  bool actuated : 1;
  uint8_t reserved : 1;
  uint8_t keyNamespace : 4;
  //higher precision
  uint16_t analogValue: 10;

The format is this, per key. The Analog SDK supports it already

[flat wigeon]

Oh nice

[strong siren]

parsing code: https://github.com/WootingKb/wooting-analog-sdk/blob/be67cbf479eb1e10e2859e71dbdcc12fff7ba266/wooting-analog-sdk/src/plugin.rs#L276

[twilit ore]

the analog SDK does support it with the caveat that it doesn't yet expose an API to get at the new data

[flat wigeon]

https://github.com/WootingKb/wooting-analog-sdk/issues/12 <<--- so this is finally solved?

[strong siren]

yes actually lol

[flat wigeon]

I just noticed, the left shift key doesn't fully register

[kindred skiff]

#1141096226884956181 (and no. Plenty of products already exist)

[flat wigeon]

The Wooting Two still sends AnalogV1?

[strong siren]

on beta firmware it should send v2

[flat wigeon]

Nice, thanks

Uh oh

The beta Firmware has issues with worn out keys.

[strong siren]

what is a "worn out key" ?

[flat wigeon]

On my keyboard Shift, A, S and D are unreliable and can overflow.

[strong siren]

what does overflow mean?

[flat wigeon]

Half pressed

Fully pressed

It goes from 1,5 to 1,8 mm then jumps to 3,4 - 3,6mm and ends at 1,6mm

[strong siren]

There's definitely something wrong with Flaretech. I'll look into it.

[flat wigeon]

The non-beta firmware instead caps out at around 2,6mm

Actually all keys have this weird jump

The jump back to 1,6mm is only on the worn out keys

[strong siren]

this is definitely some bit math mistake. Will be fixed.

[flat wigeon]

The issue with my favourite keys seems (partially) to come from hitting the keys off center. On older firmware they registered only as half pressed. Should I reach out for support directly if you have spare Flaretech switches or wait for the next firmware update?

[strong siren]

@flat wigeon the latest firmware beta version fixe the analog interface value reporting

[quick bough]

That's the SDK, not the plugin for Wooting keyboards.

[quick bough]

Well, I had a weird issue after the update to the beta firmware where the Wootility kinda showed the Fn1 layer where the Main layer should be and then I saved it to my keyboard and yeah that was not fun lol

[strong siren]

I have never seen this before, we'll look into it.

[quick bough]

Using an original Wooting One AVR keyboard haha might be not exactly what you're testing on

[quick bough]

Hmm, so it's in the lower 2 bytes. I suspected it might be something like this, but I was not able to observe values that made sense with that. I'll do some more testing.

[strong siren]

it's definitely not the daily driver that gets the most test time 🙃

[quick bough]

btw, this isn't valid C++ code at all. the way you wrote that would imply an 8-byte struct 😛

[strong siren]

it's pseudocode :^)

[bold prism]

Its CatCode pspsps

[quick bough]

Okay, that bitpacking works. All is right in the world again.

[strong siren]

i am actually testing it and while clangd agrees that it doesn't fit into 4 bytes, GCC is perfectly fine packing it into 4

i love C

clangd says 5 :)

[quick bough]

5 ?! that cannot possibly be correct. any sane compiler would have to align your uint16_t to a 2-byte boundary

but yeah in general you wanna use the same type for the same bitset. if you change the type, it will start a new bitset, so you're losing bits there

[strong siren]

clangd with #pragma pack(push, 1) says 5 yes

[quick bough]

eh, fair, sure, but not how I evaluate struct sizes

[strong siren]

details, details

technically speaking we should be using a u32 and manually bitshifting things into place

[quick bough]

hmm, idk about that

you could definitely use a uint32_t with bitset syntax to have the compiler do that for you

but it will basically compile to the same code anyway

This is my implementation

[strong siren]

you will want to look at the namespace because there's where things like fn and other such keys live. there should alsoi be a namespace for advanced keys

[quick bough]

As you can see, I am correctly tacking it at the high bits of the scancode

[blissful gate]

What is this sample code? And what does it do? I’m curiously interested

[quick bough]

This code ain't a sample, it's the main event

[blissful gate]

Tell me more about what’s going on please

I just joined

[quick bough]

I think the code is pretty self-explanatory, no?

[blissful gate]

The best I can tell is that it’s a translation code, it translates to something?

It also handles between media keys and standard ones

[placid ledge]

It's translating keycodes coming from the keyboard's Analog Interface into a more standard keycode (vk?) set

FYI @quick bough, here's the rest of the vendor (internal function) keycodes, all on the 0x4 namespace

enum {
  None,
  RgbBrightnessUp,
  RgbBrightnessDown,
  Profile1,
  Profile2,
  Profile3,
  Profile0,
  UNUSED,
  ProfileModeKey,
  FnKey,
  KeyLock,
  FnLock,
  Fn2,
  Fn3,
  ProfileCycle,
};

[quick bough]

Thanks

[balmy iron]

I like how the username changes, makes it even more legit

[soft fractal]

You can’t tell people, man! Now Wooting will start to just ask all sellers of recently sold keyboards for the buyers details because of you!

[viral ice]

There is no self advertising allowed in here

[bleak sphinx]

wonder what's the theoretical maximum number of profiles you can put on an arm board given that you can now have up to 14 profiles

[strong siren]

Depends on how big each profile gets, but it's a decent amount more than 14

[gleaming silo]

What is the reason for the usage page of analog value reporting being FF54 on the Wooting 60HE and FF53 on the Wooting UwU (and potentially other IDs on other products)?

[quick bough]

v2 interface is on page FF53

[strong siren]

correct, new analog interface format

it's supported on all devices provided firmware is new enough.

it could also be used to catch DKS and other advanced keys being abused if read properly :)

[gleaming silo]

Does it contain any information other than the analog values of each key?

[gleaming silo]

Odd, I'm pretty sure my 60HE got the latest firmware, or close to

[quick bough]

I think it's still only on the beta firmware

[gleaming silo]

huh, on my wooting uwu im not on the beta

[strong siren]

It does yeah, you can check for socd and dks for example. I posted the format in this channel

[gleaming silo]

ohhh

[serene harness]

Wootverlay isn't working for me any more (doesn't respond to key motion), does it need updating now?

probably the recent firmware change that did it

[quick bough]

hmm, yeah, you'd have to update your wooting analog sdk, I guess

[serene harness]

will try that!

All good, thanks again

[gleaming silo]

Is there any documentation on this? I've just been running into FF53, which broke my parsing

[gleaming silo]

oh i may be blind

[strong siren]

here's the parser too

[gleaming silo]

oo thats useful

im currently writing a low-latency userspace driver for linux that manually interprets the analog values in order to experiment with some stuff (eg. adding debounce)

[strong siren]

👀

interesting

[gleaming silo]

playing osu with it feels fine, practically no delay i believe

ohh having the matrix position is so cool

only receiving the analog value per hid keycode was a bit annoying to work with

[strong siren]

you also get actuated and rt state

if you use newer wootilities it will show you that type of thing

[gleaming silo]

thats rly rly neat

will the wooting analog sdk for c# ever get a bump to work with that info?

[strong siren]

good question ill look into it

[gleaming silo]

do i see correct that the resolution is 0-1023 now?

[strong siren]

Yes

[gleaming silo]

i believe to have found an issue

When I have two keys pressed and i fully release one of them, I get one singular report where no key is returned

here I have K (14) and L (15) pressed at the start. Then I fully release L (15). For one frame, the analog report gives me nothing at all, then it preoceeds to give me only K (14) pressed

This is an issue because the only way to tell a key is fully released is if it is not existent in the report

It's a bit weirder, it does not just happen with empty reports. Here I only released A (4), but for a brief moment 1 analog report also reported 7 (D) as unpressed (while still physically pressed), and on the next frame it reports D as 1023 again, as it should

This makes the data a bit unreliable to work with

[strong siren]

this is really useful. We'll look into it

[gleaming silo]

my model is a Wooting 60HE ARM from late 2022, latest firmware

[shy vale]

have not looked into detail on our end but double-check your impl: if a key from an early slot in the report is released, the keys pressed in later slots will move to the front, depending on how you implemented this might cause you to detect a release if you're not slot-agnostic

[gleaming silo]

I have not done anything with "slots". The code I used is roughly:

byte[] data = new byte[BUFFER_SIZE];
_fs.ReadExactly(data, 0, data.Length);

Dictionary<byte, ushort> values = [];
for (int i = 0; i < BUFFER_SIZE; i += 4)
{
  byte matrixPos = data[i];
  byte key = data[i + 1];
  byte packed = data[i + 2];
  byte value = data[i + 3];

  if (value == 0)
    break;

  if (values.ContainsKey(data[i + 1]))
    continue;

  byte keyNamespace = (byte)((packed >> 2) & 0x0F);
  byte valuePart = (byte)((packed >> 6) & 0x03);
  byte hidKeyCode = (byte)((keyNamespace << 8) | key);
  ushort analogValue = (ushort)((value << 2) | valuePart);

  values.Add(hidKeyCode, analogValue);
}

if (values.Any())
  Console.WriteLine($"Reading: " + string.Join(", ", values.Select(x => $"{x.Key}={x.Value}")));
else
  Console.WriteLine("Reading: none");

_fs is a filestream on linux to /dev/rawhid, which directly receives the analog reports

oh hang on

i just realized the issue i believe; I had values.ContainsKey(data[i + 1]) in due to issues I had, from before I understood that key is not the full hid keycode

Let me check if this is the issue

nope, the same issue still exists

my bad again, the exact same from above goes for my value == 0 check...

something is still off, im trying to figure out what it is

okay now I got it. A key can have an analog value of 0?

On FF54, my experience was that a key with an analog value of 0 is simply no longer included in the report

Does behave as expected when I consider that possibility 👍

Solution for me was to check if all 4 next-read bytes are 0, in which case I truly reached the end of the report

[strong siren]

I don't know the exact details but iirc. a value of 0 is allowed yeah

mostly because of advanced keys edge cases

[gleaming silo]

I extended my idea of a userspace wooting driver into something such as https://github.com/OpenTabletDriver/OpenTabletDriver but for analog keyboards

features like rapid trigger etc. would then be a "plugin" you can put on top

im curious, what does "key namespace" refer to?

[strong siren]

i dont have the list but essentially types of keys:
normal keyboard keys
function keys (bnrightness change, mode, profile switch etc)
gamepad binds
modifiers
advanced keys

[gleaming silo]

// https://github.com/WootingKb/wooting-analog-sdk/blob/be67cbf479eb1e10e2859e71dbdcc12fff7ba266/wooting-analog-sdk/src/plugin.rs#L276
//   Byte 1   |   Byte 2   |   Byte 3   |   Byte 4
//  RRRCCCCC     KKKKKKKK     VVVVVVVV     VVNNNN?A
//  ||||||||     ||||||||     ||||||||     ||||||||
//  ||||||||     ||||||||     ||||||||     ||||||||
//  ||||||||     ||||||||     ||||||||     |||||||+-- actuation state (1 bit)
//  ||||||||     ||||||||     ||||||||     ||||||+--- reserved (1 bit)
//  ||||||||     ||||||||     ||||||||     ||++++---- key namespace (4 bits)
//  ||||||||     ||||||||     ++++++++-----++-------- analog value (10 bits)
//  ||||||||     ++++++++---------------------------- HID key code (8 bits)
//  |||+++++----------------------------------------- matrix column (5 bits)
//  +++---------------------------------------------- matrix row (3 bits)

made a nice ascii diagram for it

[gleaming silo]

For some reason all my arrow keys send the same hid key code? They all send 02 D9 FF when fully pressed

and those are the raw bytes I observe via https://nondebug.github.io/webhid-explorer/

[gleaming silo]

okay I seem to get hid key code 2 on key namespace 6 for all my arrow keys, which seems to be related to the fact I use them with mod tap

[fossil aurora]

oh wootility has an AUR package? when did that come out

i dont need some random chromium based browser anymore 🙏

[quick bough]

does he know

[fossil aurora]

who

[fossil aurora]

oh the meme 😭

was gonna say im not a dude lol

[fossil aurora]

LOL

where tf did u pull that out of

[quick bough]

google results

[fossil aurora]

that was fast

[fossil aurora]

lol

[quick bough]

anyway yeah I'm pretty sure the native wootility thing is just a chromium thing

there's no real native port

not that I blame them, they probably have enough tech debt with wootility as-is

[fossil aurora]

no yea im sure its just a chromium based electron app but still

nice not to have a browser other than electron packages installed

was getting sick of using brave for it

[quick bough]

I'm sorry what

I generally prefer browser apps over 'native' apps

[fossil aurora]

electron is the package on linux for making web based apps

if thats what you meant

[quick bough]

the web platform enforces some restrictions that generally make apps better because the developers can't just [inappropriate anectode expunged]

[fossil aurora]

i prefer it cuz i can pin it to my taskbar or otherwise to run it that way

yeah ofc but i mean seemingly in wootilitys case i dont see any restrictions that a web version offers that the AUR dosent so

seems like a win here

[fossil aurora]

well yea assuming i use a chromium based browser as my daily driver

which i dont

[quick bough]

obviously the great thing with firefox is that there's no official implementation of the webhid api

but, you know

[fossil aurora]

wait you have it working on firefox? 😭 or am i blind

[quick bough]

sorry, can't type

[fossil aurora]

lmao

idk how tf you pulled that off ngl

[quick bough]

https://github.com/Sainan/WebHID-for-Firefox

[fossil aurora]

o

i didnt know there was an implementation for it

.exe.......

well then

[quick bough]

yeah so thankful to whoever wrote that implementation

I mean, there is a linux build + source code because you're probably a masochist anyway

[fossil aurora]

slight issue with that

oh

[quick bough]

also wine exists

[fossil aurora]

oh yea i can just build it from the source code good point

[fossil aurora]

mm im not on a debain based kernel so ill prob have to do it from source

[quick bough]

idk if that build works on Arch linux, I guess it depends on glibc version

[fossil aurora]

yeah ill defo look into it at some point

thanks for the link

[strong siren]

Why do you need a taskbar icon to change settings once in a blue moon?

[fossil aurora]

well i only change it for osu and browsers still inherantly take up more system resources with all the tabls open i like to keep so its nice to have only that containerised because i am kind of an osu-perfomance-hypermaxer so i try to keep my frametime litterally as low as i can so its a convinience

[strong siren]

Placebomaxxer I see

[fossil aurora]

yeah i mean i wont argue the differnce between 0.10ms and 0.12 is going to give me much of a increase in gameplay at all but its just nice to keep my browser closed when im not using it

[paper crow]

No self promo

[candid walrus]

All good 👍 just bought wooting

Made a funny video. Sharing everywhere for fun and wtf

[paper crow]

You're welcome to occasionally share gameplay clips in #🎮│game but definitely not in #🤖│community_dev, this is for community development discussions

[candid walrus]

All good! Im an operations lead aswell 😄 thanks for the board boys. This shit is amazing !

[normal aspen]

No problem sir

[gleaming silo]

I still cannot figure out why this happens

[quick bough]

What is mod tap?

[quick bough]

Wasn't this called DKS once?

Or I guess it's different?

I think I understand a bit better now how developers at a keyboard company spend their time haha

but anyway sounds like it might be a firmware bug if this feature kinda breaks the analogue report?

[warm mica]

are you thanking yourself?

I was looking into implementing webhid for firefox and it seems the three github projects doing the same are just implementing enough to get wootility working lol

Are the keyboard firmwares signed btw

I don't even want to expose webhid if my keybard can accept unsigned firmware

[quick bough]

:^)

I mean, the WebHID server itself does ask your consent first so it's not like just any website can even get access to your HID devices

[fathom reef]

/avatar

No bot command 😫

[quick bough]

What did you expect? You can click "Edit Profile" on your own profile if you want to edit your profile.

[fathom reef]

I need to check my profile picture

[fathom reef]

How you have 10y discord role , when you joined dc 3 yrs ago

[viral ice]

The 10y role was to celebrate this discord being 10 years old

[quick bough]

I kind of wanna not have this role anymore but I think the colour goes nicely with my pfp lol

The icon a bit meh tho

[fathom reef]

Ohh

[winged steeple]

https://github.com/WootingKb/wooting-rgb-sdk

anybody know whether the 80HE lightbar LEDs are existent in that matrix?

[strong siren]

They are not

[winged steeple]

aww

thats sad

[waxen briar]

Somewhere I can dump some cl*nker code? Autohotkey wrapper from 2019 did not work right with new sdk, so I had Google churn out a lightweight analog value reader, works with any key. Or did someone make something like this already, did not find anything?

[hybrid lake]

Welcome to the wootdev channel! Most things are still a work in progress, but feel free to mess around and ask any questions you have. Contributions are very welcome.

https://github.com/WootingKb/awesome-wooting

Active community projects:

• .NET wrapper by @placid ledge (https://github.com/simon-wh/Wooting.NET)
• MIDI piano by @nimble whale (https://github.com/microdee/WootingPiano)
• Python wrapper by @sharp patrol (https://github.com/BattleCisco/pyWooting)

[wicked grove]

Love it :D

I have a good experience with node.js and specifically discord.js

[placid ledge]

@hybrid lake Any chance of getting linux makefiles/builds?

[hybrid lake]

Yeah I’ll make them, I need to figure out some platform specific things first though

Like how to filter the keyboard

Had some issues with usage pages before

[placid ledge]

Ah, okay

[wicked grove]

Jeez I don't even know how to properly build the DLL

[placid ledge]

Make sure you've selected release when building

[wicked grove]

Uh ok

I see

[placid ledge]

That sort it for you?

I wasn't able to get it to build when debug was selected

But worked pretty much straight off when I changed to release