🤖│community_dev

[bleak oyster]

...now that im reflecting on this i kinda wanna give it another go

[placid ledge]

Ahaha, that's fair, it's not a simple project and does have some tricky parts to it. Even if you don't want to keep working on it, it seems like there were some good improvements you were doing in the Rust code (like dealing with the annoying SDKResult) which would be nice to get into the codebase. Let me know what you decide to do 😁

and ye, hidapi is a bit annoying, there's been a lot of talk in the issues for a while of eliminating the C hidapi library dependency and having pure rust implementation which would be a lot cleaner. Doesn't seem like that's gonna happen anytime soon tho

Looks awesome 😍 What are you using for the UI?

[meager rose]

urgghhh... I tried like 3 before landing on egui Rust GUI still sucks to this day

[bleak oyster]

oh right there was also the sync vs async question. i was considering to make an async wrapper around hidapi. then i looked into how to do both without dupicate code, and ended up reading about the keyword generics initiative of rust (a language feature that would allow you to be generic over async-ness and const-ness), which unfortunately isn't usable yet

but yeah i'll try to do the result type fix at least

man i really have a problem with perfectionism

[placid ledge]

Yeah, Rust GUI is still very lacking, I quite like egui though, I've been using it for a couple of internal tools, the plotting stuff is really nice

[placid ledge]

yeah, it is a tricky one, IIRC someone had a rough hidapi-async going for their own project, but I don't think it really moved beyond that

[placid ledge]

Ahahah, yea, sometimes it's not reasonable to get things to the level you want and you just have to settle with something

[lucid iris]

Is there any plans to possibly implement 8000hz or a new keyboard form factor also is there going to be a keyboard announcement soon

[placid ledge]

We are exploring the possibility of >1KHz polling for future products

The main thing we need is to actually have a higher scan rate for a higher polling rate to actually make any sense, and we are looking pretty good in that regard 👀

[lucid iris]

Thanks could you possibly give a rough estimate of how long it will take to release I understand that your still exploring the possibility but how long do you think that will take?

[unreal marsh]

would it 100% require a hardware upgrade or would the 60HE, UwU and Two HE owners be able to enjoy some type of firmware update when it comes to that

[floral crane]

I'd guess ARM boards only

I use my G502X at 500hz cause it causes games to lag and stutter at 1khz, so 1k polling might just cause problems in general

[quiet root]

needs a hardware change

[floral crane]

tony your game update is being worked on

EDIT: prost-build removed their vendored builds so I need to include prostc in my github actions workflow (or someone rewrite game-scanner to use a better protobuf library, preferably pure rust)

[quiet root]

all our keyboards so far including the uwu are usb high speed. thats limited to 1khz

for 8khz we need usb high speed. our current aim is more 2khz or 4khz though. thats something we can try to target for scanning speed as well

we wont implement 8khz unless we can also scan all keys at 8khz

makes no sense to have a polling rate higher than the scanrate is. basically wastes cpu and usb controller resources for nothing

[meager rose]

USB High Speed?

I released the first version of my overlay thingy anyhow.

https://github.com/SirWaddles/wooting-overlay

[floral crane]

I wonder if that overlay could be done just using webusb like wootility web

wait obs probably doesn't support webusb

[meager rose]

Here's a clip of it (in the #archived_wooting_uwu channel)

#archived_wooting_uwu message

[floral crane]

where's the overlay

[meager rose]

the green bit on the bottom right

[floral crane]

Oh, it matches the game

just looks like an overlay osu would have

[meager rose]

thanks 😄

(although the key counter stuff is an osu!lazer element)

[floral crane]

@quiet root 2.1.0 is out with your game rule setup prompt

[strong widget]

i got stuck in an infinite install loop would install then trigger install again and again, where are setting files so i can remove setting to not allow auto updating

[floral crane]

Thats weird

appdata

[strong widget]

ok ty

[floral crane]

You might have used the exe which installs to the users appdata instead of system program files, and the auto updater installs using the msi which installs to the system program files, you might have two installs

[quiet root]

might wanna fix that

[quiet root]

thanks now we can steal it and rebrand it

jkljk

@placid ledge @remote junco might be interested in what the profile switcher app turned into

especially since it works on linux macos and windows from what i gather

Link to Shays profile switcher

[floral crane]

cant, tauri problem

tauri alpha problem*

tauri made the updater plugin async even though tauri is sync, so I gotta spawn a thread and block just to check and install updates, to ask the user for confirmation first would require doing it twice

I'd rather be using tauri stable but tauri-egui targets alpha, and the old version that still kinda works with tauri stable uses an outdated egui version, its all gonna be kinda hacky until tauri v2 alpha gets more polished

[quiet root]

but you can auto detect this

either by passing an updater arg or make the updater check both locations

also wouldnt the updater have a working dir thats the same as the install path of the app

so 3 ways

unless you dont control the updater stuff

[placid ledge]

The project is looking very interesting atm, especially given how many of the libraries are similar to what we're using . It makes me want to get the background service & expanded SDK going a lot faster to unlock all the extra potential 👀

[floral crane]

The updater plugin is very unfinished, I basically just have access to check for updates, then install the updates. Which just means download the MSI file and run it

Afaik it just checks the current version against latest.json, downloads the MSI to temp, spawns another process to spawn the installer process, then exits the main process to free up resources. It always defaults to program files and that was the case with tauri stable too

Last big update is to add inactive profile switching but that's waiting on that becoming accessible

[strong siren]

I'm rewriting the component that artemis and aurora use to read razer chroma data from games, took the opportunity to write a small tray app that targets wooting keyboards specifically. if anyone is interested: https://github.com/diogotr7/RazerSdkReader

It's a bit rough atm since it doesn't check if any chroma game is open or not (just sets all keyboards to black in this situation) but it does work quite well from my brief testing :)

consumes about ~45mb of ram which isn't amazing but it's what i get for using forms

¯_(ツ)_/¯

[quiet root]

does artemis even do games yet?

i feel like aurora is still better

[strong siren]

Idk where you got that idea, artrmis has had games for ages. What's missing Is good defaults and good profile sharing tools (which are being worked on)

[quiet root]

i didnt even see a game thing in artemis

thats where i got the idea

[strong siren]

They're separate as plug-ins (which will also have better sharing tools soon)

Anyway this app I linked doesn't depend on Artemis or aurora for the full chroma effects so if there's interest I can make an installer and clean it up a bit etc

[quiet root]

oh no dont get me wrong it just reminded me of aurora having chroma and supporting games as well. that then reminded me that i never saw it in artemis. makes sense though if its all separate plugins

[strong siren]

Yeah I ported a bunch of crap over

Aurora seems like it has more games but a good amount are old af games that work with the Alienware rgb thingy (that I also ported over)

[bleak oyster]

@topaz quiver https://github.com/WootingKb/wooting-analog-sdk/pull/53

there is so much more i want to clean up, i really had to restrain myself to only fixing the thing that caused consumers of the sdk a headache. still ahven't given up on rewriting the whole thing

[topaz quiver]

Lol thanks but that was forever ago

[quiet root]

i thought they tagged the wrong simon

i thought they tagged the wrong simon

[bleak oyster]

omg i did, but somehow it still worked out xD

@placid ledge see above

[placid ledge]

@bleak oyster Thanks for the PR, am quite busy, but will give it a review when I get a chance

[floral orchid]

Anyone here know what button 673 up on the Two HE is?

it's always firing, even when the keyboard is disconnected

[quiet root]

@placid ledge

[placid ledge]

In what context are you seeing this?

[floral orchid]

Using a software called HID Macros which can detect inputs such as keyboards and mice

[placid ledge]

Does it give more context on what HID report/page that it's coming from?

[floral orchid]

Uhmmmm possibly. It's a deprecated software technically but I might be able to find something

[wicked root]

any method that can rapid spam a key like turbo mode on steam controller?(rapid full press a key in very short amount of time)

[umbral walrus]

a macro with wootomation

[wicked root]

Wootomation is not working for what i want, I posted the issues in wootomation channel already.

[lusty breach]

not sure what channel to use but i've been wondering why there's such a stark split with input reading and rgb having sdks while the configuration side is so locked down even profile codes are obfuscated

[quiet root]

the configuration side isnt really locked down in any sense. you could take any json formatted profile and send it to the keyboard using the analog sdks USB class. profile codes also arent obfuscated but just a GUID so they can uniquely be stored and retrieved from the cloud

profile codes arent generated from profile content or anything but just a random GUID

[lusty breach]

oh didn't know the sdk has write parts

tried to look through it and couldn't find it

[quiet root]

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

they arent publicly in the sdk as you literally send raw usb commands and data

they can be found in the wootility minified js

[lusty breach]

oh right forgot wootility web exists

[quiet root]

the installed version also has minified js

its just electron running a website

its the reason why we can even offer a web version

we also refrain from encouriging sending over custom configs as it might render the keyboard unusable until its factory reset

[lusty breach]

i've never touched electron so i can look into the web version easier

ok so dks tick rate really is just an enum in the wootility's side, does it get converted to press duration when sending over usb or all inside the kb?

[quiet root]

the actually reading of the config is inside the kbd

the config gets send as is

well i think it might get converted into a raw stream of bits reprensenting the config

[lusty breach]

dammit

[quiet root]

anything that is freely adjustable is also shown to be so

if it has only a set selection of options thats most likely due to it having those fixed presets in firmware

[lusty breach]

where's the best place for feature requests then?

[quiet root]

https://github.com/WootingKb/wootility-issues/issues

[lusty breach]

thx

[tranquil flame]

Heya folks! 👋

I was wondering whether the firmware for the keyboards is open source as well. I couldn’t find it on GitHub. Could someone point me in the right direction?

[tardy frigate]

The firmware itself isn't open source

[quiet root]

We will most likely never open source the firmware as it contains the key features that make our keyboards our keyboards.

PCB and firmware are basically non negotiable in that regard

wootility may or may not be open source in the future but most likely not as most things people wanna do with wootiltiy also would require changes in the firmware meaning there is almost no point in disclosing the source code

[tranquil flame]

Gotcha, that makes sense. Thanks for the replies @tardy frigate @quiet root!

Know of any keyboard firmware that is open source?

[quiet root]

qmk

and basically anything qmk based prob

[tranquil flame]

Great, thank you!

[floral crane]

I don't know if something changed with the firmware or somewhere else, but now my program doesn't load the RGB effects when changing the profile, every command freezes RGB but the last 1/2 doesn't start it again now

[hazy scarab]

i tried remaping some of my keys with mouse binds but none of the mouse binds work. could this be due to the new firmware?

[quiet root]

#1019755933959733258 and please include screenshots of the wootility keymap etc

[quick bough]

Hello, I've been messing a bit with the low-level stuff of my Wooting Two HE and I noticed that some of the reports it sends have duplicated keys, for example here is me pressing and releasing the 'A' key

Compared to the 'D' key

It seems to only be the 3 leftmost keys in each row that are double-reported or something like that.

[torpid fox]

Am I allowed to show off something WIP here?

[quick bough]

Another issue is that pressing the [Fn] key seems to be drowning out other keys. For example, at this point the other key is still being pressed, but the HID is reporting it incorrectly. I think this was broken in a firmware update maybe over a year ago at this point.

Speaking of firmware update, I should've done one... now the double-reporting is gone, and while pressing the [Fn] key no other keys are being reported at all.

[torpid fox]

Isn't that just because you're on a new layer?

[torpid fox]

Whatever, I'm just going to do it.
I'm working on Analog SDK bindings for Godot! It's already usable! And it even has an option to interface with Godot's input map.

[quiet root]

pretty sure the fn thing is wanted as you are on a new layer and new to repress

[quick bough]

Yeah, I did figure the "new" [Fn] behaviour is intentional because of layers, but I found it to be slightly confusing/bothersome once it started rolling out

[quick bough]

Epic! I think more games should integrate the analogue SDK. I think so far only Fugl does?

[balmy iron]

Very cool can I steal that module or however you did it

[torpid fox]

I agree!

[torpid fox]

I’ll be placing it on the assetlib once I think it’s ready for that!

You’ll be able to get it soon 👍

I could maybe also do some testing within the wooting server 🤔

So yall could have earlier access

[barren galleon]

Very very cool!

[torpid fox]

Thank you!

[floral crane]

Does anyone know why RGB effects are failing to load, it seems recent firmware related because I haven't changed anything since I got it working other than updating my firmware

[quick bough]

Can you not achieve this using the RGB SDK? That would be more portable since afaik there's 2 different protocols for them.

[torpid fox]

Would you like to try out the bindings when they're ready for testing?

I could probably make use of some certified Wooting community testing™️ before the bindings go on the assetlib

[balmy iron]

Maybe maybe not

[torpid fox]

Would you like me to at least let you know?

[quick bough]

I'd be curious to know what games (or other applications) even use Wooting Analog SDK at the moment

Last I checked, there was only Fugl and since then, there's not even a public listing of projects anymore

[flat wigeon]

Hmm...

The keycodes are different for key configuration and RGB, is this correct?

[quiet root]

depends on what mode the sdks are in

normally they use VKcodes

while the keyboard itself uses scancodes

[flat wigeon]

On the hid interface

I want to answer on this issue: https://github.com/WootingKb/wooting-analog-sdk/issues/12

[quiet root]

not reliably possible

[flat wigeon]

The scan codes range from 0 - 110?

[quiet root]

even if you have the mapping of the keyboard and the scancodes you run into the simple fact of fn layers and even nicer the fact people can map the same scancode multiple times

[flat wigeon]

This is confusing with all the different key mappings...

[quiet root]

the simple fact is the most reliable solution would be the rgb sdk having a special mode where the keyboard sends the position

cant really think of a way to otherwise solve this as the remapping basically breaks all ways to reverse map the keys

[flat wigeon]

The RGB SDK isn't affected by remapping

The analog SDK is

I have written an accessibility program to control certain stuff like mute Mic/Headphones and managing RDP windows

Actually I don't care about remapping at all except, for the issue, that for using the analog SDK I need the special keys mapped, which I don't want

I currently use the configuration interface used by Wootility to query the key states

[quick bough]

Is WOOTING_SINGLE_COLOR_COMMAND/WootDevSingleColor dead? Seems like it's not doing anything other than responding with D0DA1EFF >.<
WootDevInit & WootDevResetAll seem to work fine and respond with ...88
My code for reference:

[flat wigeon]

Looks like I use a different buffer layout

Try putting the keycode last

Wait, I don't even use this

https://github.com/WootingKb/wooting-rgb-sdk/blob/master/src/wooting-usb.c#L576
https://github.com/WootingKb/wooting-rgb-sdk/blob/master/src/wooting-rgb-sdk.c#L121

The order of the parameters is reversed in the report buffer

[placid ledge]

Are you on the beta firmware? If so, then it won't load cus the RGB effects system was rewritten

[floral crane]

I may be on beta firmware, I did install beta at some point but stable wootility shows v2.6.22 firmware

stable wootility is able to apply effects still

[placid ledge]

Hmm, if you're on v2.6.22 then it should be fine with existing commands, nothing would've changed until you are on v2.7.* firmware

[strong siren]

has anyone looked into the usb hid LampArray spec? allowing the rgb to be controlled that way would be nice since that's what the new windows rgb menu uses

[placid ledge]

We're planning to support it when we get some time / before it reaches Windows stable (it's not in Windows stable yet?)

[strong siren]

ah cool, sounds promising

yeah i dont think it's in stable yet

we're looking into that as well for artemis :D

[quick bough]

Ah damn I didn't even notice that, thanks!

[balmy iron]

Ah nice very cool to hear it, finally some proper standard for RGB lighting

[quick bough]

Maybe in 10 years we'll have analogue keyboards in the HID spec with Windows & Linux supporting it at the kernel level and providing APIs for it.

10 years might be too optimistic tho.

[balmy iron]

One can dream..

[quick bough]

It's a real shame because most game input systems are desined to be fully analogue due to controllers, but I guess Wooting alone is just not enough to convice these companies to have their engine devs add support for it.

Welp, got the single colour command working now, but I think mapped this incorrectly, everything except for escape seems wrong.

[flat wigeon]

The issue starts with the fact there is no proper input library and no proper os level support.

Seriously, we have touch and pen support. It's still not working in many games despite an actual compatibility layer (because you can't force it).

The game devs still need to know, what they are doing. And generally... they are not

[quick bough]

Of course there is OS-level support; just enumerate HID devices, find usage page 0xFF54, then poll the reports in your update loop.

[flat wigeon]

Exposing HID is not proper os level support 😄

[quick bough]

Yeah I know

DirectInput already uses a byte array for input, but they only set 0x80 when the key is pressed. But they could easily add a new option to make it return a value between 0 and 255...

Also figured out the mapping, seems to be same as the array but with 32 columns per row

[flat wigeon]

Technically the whole remapping in firmware makes only sense if you actually change the keycaps accordingly, to match the actual "hardware". For all other intends and purposes this should really be implemented by the os. Like the firmware tells the os, what is the key supposed to mean and the os decides (by user configuration) what is supposed to happen.

[quick bough]

You're not wrong, but given that there is no OS support for such things, remapping it on the firmware seems like an okay stopgap solution.

[flat wigeon]

In my opinion remapping in firmware is generally okay/useful, given the fact you can physically rearrange the keys, not just as a stopgap solution.

[floral crane]

I was on 2.6.22-beta before it was released as stable but I updated to stable when it released. I didn't notice the issue because I use Artemis but someone brought it to my attention and it also happens on my keyboard. I'll also have to support the new lighting when it becomes stable if the commands have changed.

[floral crane]

Windows does have a sort of remapping functionality now with a tool in PowerToys, and Linux has Xmodmap and probably other tools.

You can even remap the Windows/Super key

[quiet root]

the remapping in firmware is certainly not a stopgap solution.

[floral crane]

I prefer firmware remapping, it doesn't require software setup on every device just the one

[quiet root]

thats the point correct

[quick bough]

Hmm, I'd prefer it if the firmware just always reported what keys were pressed. I'm already a bit annoyed by the FN layer disabling all the keys.

[floral crane]

What key is pressed depends on the keycaps, I replace some numpad keys with volume buttons and all the F1-12 keys with F13-24 in the FN layer

Caps with F13 for my dropdown terminal, swap back the printscr and scrlck keys cause they were reversed on my keyboard

[quick bough]

Well, my use case being a keyboard visualisation, and I'd rather it be physically correct than logically correct

but I understand it has its uses, certainly not complaining about more features. 😄

[quiet root]

well that absolute positioning can be done via firmware though

[floral crane]

Is there a way I can revert to older firmware for some testing?

[quiet root]

uh

yes

[floral crane]

Hmm it may be related to the commands being sent from a different thread, doing the same in a test app works fine. the main command works but the last that loads rgb doesn't. more testing required.

yeah the rgb loading command fails to work in a thread but works in the main thread... that's strange

[quiet root]

most likely because of multi access

and how the rgb sdk basically isnt setup for multithreading

[floral crane]

I only ever access the rgb sdk within its own thread, otherwise I exit the program after accessing from the main thread

I was wrong, it's this command to get the active profile index, it causes RGB effects to stop

I'll just set after get since it's only once at startup

[quick bough]

If you do send_feature_with_response using commandId 32 (WootDevResetAll), it should restore RGB effects

I noticed myself that certain commands (such as WootDevSingleColor) have the same effect as WootDevInit, causing RGB effects to stop, as well as breaking caps lock and num lock indicators.

This state perists until the corresponding WootDevResetAll command.

(Or you unplug the keyboard and plug it back in.)

[quick bough]

Does anyone know why I can't have 2 wooting keyboards plugged in at the same time?

If it's relevant, I'm on Windows. I have a Wooting Two and Wooting Two HE. If I try to plug in a second one, the lights go on for like a second, then it turns off, doesn't respond to inputs.

[flat wigeon]

Sounds like overload

[unreal marsh]

test it on the latest wootility and firmware update for 2HE

[quick bough]

firmware is up-to-date for both of them

unless a new one came out in the last 24h

[quick bough]

PSU is rated for 1200. mobo is Z790 aorus elite.

[flat wigeon]

Not the PSU

[unreal marsh]

beta one I meant, mb, forgot to clarify
https://discord.com/channels/167181566978555904/1156992558984077333

[flat wigeon]

I read something about the USB controller can cut off the device if the power draw is too high

Maybe it works if you reduce the brightness

[quick bough]

both set to 30%

beta looks like it might fix my issue, will try

Nope, same issue still 😄

nevermind, different usb slot fixed it xD

maybe the power draw was too much in that row

silly hardware

[unreal marsh]

ay, thats good

[quick bough]

Rewriting part of the Analogue SDK in C++ is proving fruitful so far, no more lag on wooting_analog_initialise or wooting_analog_uninitialise.

[flat wigeon]

I thought the phrase was "Rewrite it in Rust" 😄

[quiet root]

thats what wed wanna do

[quick bough]

My phrase is "Reinvent all the wheels in C++" 😛

I mean I don't think the language really matters, but I think the init does some blocking stuff on the main thread and hence the lag I was experiencing. Unsure about the lag at deinit, tho.

Basically all I'm doing right now is providing a very lazy drop-in replacement for the wooting-analog-plugin.

Maybe if this plugin was actually compliant and properly reported all keyboards, it might be laggier to init. Don't see that hugely impacting deinit, tho.

[torpid fox]

OH now that you mention it I am in fact experiencing a big stutter when the plugin initializes
Any clue as to why that stutter happens in the actual plugin? Maybe a fix could be merged in (because if you can do it in C++ I don't see why it couldn't be done in Rust)

[quick bough]

No, I didn't really look at wooting-analog-plugin, so I can only guess as to why.

[torpid fox]

Hmmm I'll have a look

[quick bough]

but I would recommend disabling "wooting-test-plugin" if you don't need it, as it also seems to have quite the lag on init, probably the most noticable one.

[torpid fox]

Oh, how would I?

[quick bough]

I just made a folder called "_disabled" in C:\Program Files\WootingAnalogPlugins and moved it there

[torpid fox]

mhm because the users of my application would obviously like to do the same

[quick bough]

Well, try it for yourself and see if it works. If it does, you might write it in your README or whatever.

[torpid fox]

Is Wooting Analog Test Plugin just a random dev thing? If so why is it being shipped

[quick bough]

Yeah, it's more of a dev thing. I guess it's shipped for convenience.

I'm currently stuck downloading this 😄

Which is somehow bigger than a whole-ass web browser 😄

[torpid fox]

...convenience? For who?

[quick bough]

Developers

[torpid fox]

What would I be doing with it?

[quick bough]

Like, if you don't have a wooting keyboard

[torpid fox]

What does it do?

[quick bough]

but want to integrate analogue input

[torpid fox]

Is it some kind of analog input emulator?

It doesn't have a readme at all

so much for letting developers know they can support these keyboards without having one to test with

[quick bough]

Yeah, I think that's what it's used for

I never tried it myself tho

Well, I'm pretty sure these are my Wooting keyboard given that /dev/usb didn't exist before I attached it to the VM, now I just have to figure out how to do thing on Linux

[torpid fox]

Anyway, what I actually came here for is the fact that if I unplug and replug my device and call set_keycode_mode my entire application hangs (presumably it's blocking the thread?)

[quick bough]

Well, usually you would do that shortly after calling wooting_analog_initialise, no?

[quiet root]

because its chromium and some extra

unsure why youd download wootility instead of using the web version

[quick bough]

I downloaded chrome in ~1 minute, this wootility took ~20 minutes.

Well, the chrome version didn't work because of Linux' asinine permission system

Although now that I followed this guide (https://help.wooting.io/en/article/wootility-configuring-device-access-for-wootility-under-linux-udev-rules-r6lb2o/), it does seem to work in chrome as well.

[torpid fox]

The maths don't work out, I say skill issue

[quiet root]

because both use chromium

[quick bough]

Slower download server 😄

[quiet root]

and the DL is not from our server

its github or amazon

not sure which

[torpid fox]

Pretty sure it's GitHub?

[quick bough]

Github would explain it, their servers are slow af

[torpid fox]

?!

[quiet root]

its amazon aws

[torpid fox]

Guess I was wrong

[quiet root]

had to check myself

[quick bough]

I periodically pull raw GeoIP data from raw.githubusercontent.com, and that usually takes 1-2 minutes. xD

[torpid fox]

Oh yeah it's not downloading from the github releases

[quiet root]

we dont have public wootility github releases

or a github

wootility and firmware are behind closed doors

[flat wigeon]

I just wanted to test that, but my Firefox refuses to download Chrome ^^

[torpid fox]

Guess I'm just dumb! Extreme apologies

[quiet root]

anyway no reason to use the installed version really

the webversion allows for offline caching as well

so it works without internet

[quick bough]

Yup, PWAs are nice

[quiet root]

both installed and web work 99.99% the same sans the device connection

device connecting is automatic on installed versions

[flat wigeon]

if there was "no reason" then nobody would use it

[quick bough]

Unfortunately, the device connecting doesn't work on Linux' browser of choice (Firefox).

[quiet root]

well theres only some subjective ones like distrusting the web

[quiet root]

its a firefox issue

or a google issue i guess

depends on what side of the coin you look at

[quick bough]

I figured as much, yeah

[flat wigeon]

Subjective doesn't make it wrong

[quick bough]

I don't blame Firefox for not supporting an API as niche as HID, but oh well

[quiet root]

well yesnt. all reasons i have personally heard so far are sort of eh as the installed version just install chromium and then loads the website

so

¯_(ツ)_/¯

[quiet root]

nothing about niche they wanna support it

Apple and Mozilla approached Google and their whitepaper for the spec and wanted to talk with them about implementing core security features and stuff.

google just said no

so yeah

[torpid fox]

Well, now I'm only calling it once during init, and now it crashes in the next function call that's after where set_keycode_mode used to be, which is read_full_buffer

[quiet root]

only chromium has it

but as basically all browsers out there are chromium

its a high amount of the market

[quick bough]

I've only had read_full_buffer crash very rarely, I think that may have been bad timing with an off-thread call to wooting_analog_uninitialise

[flat wigeon]

Install a browser, I don't want? Or use a standalone package that at least behaves like a an installed application?

[unreal marsh]

i went with the second choice

[torpid fox]

I went with the second because it didn't work in my chromium-based browser anyway, it probably blocks it ¯_(ツ)_/¯

[torpid fox]

I bet 20 bucks that it'll just crash on the next call in line if I comment this out. I think it just blocks on the first function call after a reconnect

[quick bough]

I'll try reproducing it with the official analog plugin

but my drop-in works like a charm

[torpid fox]

I'd rather not, thank you
Mainly because I am making bindings

[quiet root]

in both cases you install a browser and in one of them the browser is less useful

[torpid fox]

So it should work with the official DLL

[flat wigeon]

But it behaves differently

[torpid fox]

if it doesn't that's a lot of user effort to set up your shady DLL

[quiet root]

because we instruct it from a nodejs app

[torpid fox]

plus I also have no reason to trust you enough to run your unchecked code on my machine, Sainan 👍

[quick bough]

well, I'm not replacing the "wooting_analog_sdk", I'm replacing its plugin for wooting keyboards, but yeah 😄

[quiet root]

nodejs app -> spawn chromium browser instance -> blur out a lot of ui -> navigate to page

thats what the installed app does

[flat wigeon]

Yeah, that's crap

[torpid fox]

Electron, everybody!

[flat wigeon]

But at least it looks to me like a normal program

[quick bough]

Fair enough. I have already shared most of the source to this. I will open-source soon, too, once I'm confident in it.

[quiet root]

no other way to do easy crossplatform apps with similar UI

[unreal marsh]

tradeoff of having it as crossplatform

[torpid fox]

Doesn't help me though. I need my stuff to work with the official DLL. No way around it.

[quiet root]

well im actually happy as it means we are one of the first companies that offers a configurator fully from the web

and if android ever gets webhid

well you can even configure it from your phone/tablet

[quick bough]

Yeah, just a way to test it, I guess ¯_(ツ)_/¯

[torpid fox]

Except if it's an Apple device :D

[flat wigeon]

I can start it normally from the start menu with an application window and I don't have to bother with an actual fully featured Browser window

It's really primarliy about the perceived behaviour

[quiet root]

well has to do with the mentioned unwillingness of google to talk with apple and mozilla

[flat wigeon]

Like I like to put certain stuff on my A1 - A3 and the Mode keys

[quiet root]

so apple and mozilla refused to implement the "standard"

[quick bough]

Oh yeah unplugging keyboard with the official plugin is bad 💀

I had debugger attached, but uhhhh

[torpid fox]

Yeah unfortunately

[quiet root]

wed love to be able to have firefox users use it

and safari users

sadge its not possible

[torpid fox]

I think it's time for a GitHub issue...

What do you think?

[unreal marsh]

firefox would be cool, could just uninstall my wootility but im fine with it rn

[quick bough]

I reckon it's time to rewrite it in C++ 😛

Nah jk, def. open an issue

[flat wigeon]

Great idea!

[torpid fox]

what if they someday invent their own standard? would that be possible?

[quick bough]

although I think unplugging a keyboard isn't exactly "common usage"

[quiet root]

could happen but then theyd need google to agree

[torpid fox]

Except it should be handled correctly because set_device_event_cb exists no?

[quiet root]

its basically all chromium and then safari has 26%

firefox is so small they prob couldnt even get google to do anything

its basically 29% vs the rest when it comes to standards for the web

[torpid fox]

unfortunately....

[quick bough]

Yeah, in theory. Maybe it is your responsibility, but in reality, the SDK should abstract away the fact that there could be 0 to infinite keyboards if you just call the plain read_full_buffer function.

[torpid fox]

mate I've tried to tell you that it's not just the read_full_buffer function

[flat wigeon]

I know

[quick bough]

Ah yeah I forgor you had it with set keycode mode too

Sorry doing like 3-4 things at once right now lol

[torpid fox]

I bet way more functions do this too

read_analog probably does it too

[quick bough]

but that is curious

it's possible it's a deadlock

[torpid fox]

a deadlock?

like it's infinitely waiting for a no longer connected keyboard?

[quiet root]

one day we might have a nice rust based desktop app

[quick bough]

Like, the only "blocking" thing that set keycode mode seems to do is obtain a lock

[quiet root]

in like 10yrs or so

[quick bough]

so, if that lock will not be released by someone else who can hold it, that's a deadlock

[torpid fox]

oh I just used the term blocking because the thread seemed to not respond, the term doesn't say anything about if it'll ever get out of it

[torpid fox]

[quick bough]

Well, the problem clearly is that the analogue SDK is blocking, it didn't seem to throw any exception

[torpid fox]

okay I'm going to go make that GitHub issue

[quick bough]

very nice in a game update loop if you call read_full_buffer every tick 😄

[torpid fox]

I mean, are you not supposed to?

[quick bough]

¯_(ツ)_/¯

it's what I do, but clearly not going well when unplugging the keyboard

[torpid fox]

You sounded sarcastic

You know what, I'm going to test if this happens with read_analog too

Yep

It does

Oh shit

is_initialised hangs too

[quick bough]

FWIW, using my replacement for wooting-analog-plugin doesn't have this issue, so at least we know where it's failing

[quick bough]

def. deadlock

[torpid fox]

That unwrap seems suspicious

[quick bough]

That's just Rust boilerplate

[torpid fox]

Could it be panicking?

[torpid fox]

No it isn't?

I am literally writing Rust code right now

[quick bough]

idk what a Rust panic does, but my exception logger didn't catch anything

it would also catch if abort were called

which would be the way of raising an exception while pretending that exceptions don't exist

[torpid fox]

a panic is a fatal exception that usually unwinds the stack
unwrap panicks if called on an Err (or None in the case of Option but this is a Result) value

[quick bough]

a fatal exception that unwinds the stack... that almost sounds like an oxymoron

[torpid fox]

unwrap is basically "assume this value is okay to use and if it's not just die on the spot"

I'll see if version dies because it doesn't touch the mutex

It doesn't

[quick bough]

lmfao, I just compiled an empty .rs file and the resulting .dll is 5 MB

Anyway, yeah, I would've caught an exception

Rate my Rust code

fn deez() -> Result<u8, u8>
{
    return Err(0);
}

#[no_mangle]
pub extern "C" fn i_will_panic()
{
    deez().unwrap();
}

[torpid fox]

Probably mostly debug symbols

and panic handling

You can get rid of all of that

[quick bough]

I don't like having to pass --crate-type cdylib to the compiler instead of simply --shared

[torpid fox]

not per se, depends on how it's compiled

[torpid fox]

that's why you usually put it in your Cargo.toml

[quick bough]

Cargo.toml is even more boilerplate for a 10-line project 😄

[torpid fox]

Bruh are you using rustc

[quick bough]

Of course

[torpid fox]

Bruhhhhhhh 💀💀💀💀

[quick bough]

I want to compile, I call the compiler

[torpid fox]

So I assume you don't use Rust then

Ever

[quick bough]

Nope 😄

[torpid fox]

Explains this behavior

[quick bough]

This was me reading the analog sdk code yesterday 😄

ChatGPT was quite helpful tho

[torpid fox]

"Damn why is this so hard" refuses to do it the normal way

[quick bough]

I mean, I'm like fairly certain using a crate for this would've been harder than simply passing --crate-type cdylib to the compiler

It's just even easier with C/C++ compilers, only having to pass --shared

[torpid fox]

No and also you're still using a crate even though you think you're not

[quick bough]

Anyway, not here to argue for or against Rust, it's just not a language for me

[torpid fox]

Yes but the thing is Rust does more than "just compile to a DLL"

[quick bough]

I don't want/need it to do more than that 😄

[torpid fox]

That's a you problem

[torpid fox]

Okay so can we then return to the actual issue at hand

[quick bough]

Cwash

Someone already raised a related issue: https://github.com/WootingKb/wooting-analog-sdk/issues/16

Although in our case it seems to be a deadlock instead of a panic

and easier to reproduce

[torpid fox]

That someone being Tony

[torpid fox]

I had a look and that is a completely different issue

[quick bough]

Weirdly enough, I can't get a standalone repro

Ah wait, it might be because my other Wooting is still plugged in lol

[torpid fox]

Oh, could it be that it only happens when no devices are plugged in?

[quick bough]

Nope, just got this error for each unplug

everything else fine

[torpid fox]

What if you set the cb

maybe it only happens if a cb is set

[quick bough]

Well, the only thing I do differently in my game usage VS this repro is calling set_keycode_mode

[torpid fox]

Hmmmmmm

I mean you could try doing that

[quick bough]

I have no idea what I just did but it no likey

[torpid fox]

I think you passed an invalid keycode

[quick bough]

Oh, I pressed num lock

[torpid fox]

Shouldn't that still work?

[quick bough]

Yeah in theory...

[torpid fox]

0x90 != 83

[quick bough]

I know, 83 is the HID scancode/usage id

it failed to map it to the VirtualKey

[torpid fox]

Wait, is it maybe that the keyboard keeps its keycode mode after replugging and the SDK doesn't expect that or vice versa?

[quick bough]

No, it's only an SDK setting

[torpid fox]

hmmm okay

[quick bough]

welp, I can't repro now even setting the keycode mode

[torpid fox]

Weeeird!

let's see what other calls exist

as in, what else gets called

in the game

[quick bough]

For some reason they have the PS/2 Scancode for Num Lock (0x0045) mapped in as HID_PAUSE

[torpid fox]

I call initialise, then version, then set_device_event_cb, and then I unplug and then I call is_initialised

[quick bough]

I guess I'm making my first PR to a Rust project today

[quick bough]

That's enough to deadlock for you?

[torpid fox]

Yeah

I think

I'll make a repro project in a bit

[quick bough]

I just realised this is a potential array overrun issue because the user can press the FN key and then it reports the scancode (0x409) instead of 0 as I would expect for a non-VK-mappable key

[torpid fox]

Wait a sec

I got a different output in my repro

or rather, I got this

wait

[quick bough]

Maybe we have to reimplement hidapi but in Rust

I'm making some decent progress with the HID stuff on Linux

[quiet root]

pls dont

hidapi has its flaws

[quick bough]

Well, that's why this wheel has to be reinvented

[quiet root]

or just fix up hidapi so everyones happy

otherwise you just run into this

[quick bough]

Well, it's all just implementing the HID standard, so we're not adding any new standards 😛

(Not even implementing the HID standard, most of that is done by the underlying OS APIs.)

[quiet root]

no but you split the programatic consumers

[quick bough]

No offensive but I don't get why languages like JS and Rust have these ecosystems with a monopoly mindset

I mean clearly capitalism is doing something useful

[quiet root]

well js deffo doesnt have that

[quick bough]

And you don't just have only 1 company offering you... just about anything. Always an alternative.

[quiet root]

theres like bazillion frameworks for everything

and they all do the same 10 things

[quick bough]

Well, I more mean NPM. I rarely see competing packages there.

[quiet root]

the issue is they all dont do it well because instead of combining their strenghs into 1 monolithic project they all do it mediocre

[quick bough]

As someone who is working on monolithic software basically every day, I can tell you that it's very hard to do everything well when you have to do a lot of things

[quiet root]

well hid api doesnt really do a lot

but for example for node theres koa, express and fastify rn which are sort of the biggest server frameworks

[quick bough]

But it's also somewhat a matter of pacing. If you allow yourself to take multiple days to ship a new feature, it may yet have hopes of being polished

[quiet root]

dont get me started on meteor, nest, sails and whatever else exists

[quick bough]

Never heard of any of these lol

[quiet root]

orms are also horribly split where you basically have to pick and choose what you want to be good and what you dont really mind being bad (in nodejs)

[quick bough]

Granted, I'm the kind of person to deploy .html, .css, and .js files to an apache2 or nginx server

because I learned web dev in the 2010s and it still works

[quiet root]

why not caddy

or tomcat or lighttpd

[quick bough]

refer to this

[quiet root]

ok caddy wasnt around then but the other 2 were

[quick bough]

This is cool. I've been meaning to implement this into my own C++ web server.

[quiet root]

but frankly this fragmenting happens a lot

[quick bough]

Welp, I wasn't about to experiment with like 5 different servers lol

I just sorta concluded "apache2 = dynamic content, nginx = static content"

[quiet root]

i mean i concluded apache2 sucks, nginx is ok for smallish things if youre used to it otherwise caddy

[quick bough]

Also jQuery still a smashing framework. I know we have fetch now, but Ajax still kinda better API.

[quiet root]

i hate importing ajax and lodash into stuff

[quick bough]

huh?

<script src="https://code.jquery.com/jquery-3.6.0.min.js" integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script>

it just works™

[quiet root]

but i could also just not import it and use either fetch or XMLHTTPRequest

and get the exact same feature set

[quick bough]

Then you have to make your wrappers around it to not lose your sanity 😄

Like I have this in like all my projects were I was dedicated to "vanillaJS":

function post(url, fields)
{
    let data = new FormData();
    for (const [key, value] of Object.entries(fields))
    {
        data.append(key, value);
    }
    return fetch(url, {
        method: "post",
        body: data
    })
}

[quiet root]

new formdata? what

[quick bough]

I'd rather my boilerplate look like this

[quiet root]

fetch(url, {method:"post", body: JSON.stringify(object)}))

[quick bough]

Great, now you're sending data that's not compatible with the backend 😄

[quiet root]

but it is

[quick bough]

(The backend is written in PHP)

[quiet root]

yeah well thats where you fucked up

[quick bough]

meh

[quiet root]

almost all backends i know and/or work with accept json

not formdata

[quick bough]

Well, you could do

$data = json_decode(file_get_contents("php://input"),true);
var_dump($data["whatever"]);

instead of

var_dump($_POST["whatever"]);

[quiet root]

dont do php as i wanna keep sane ¯_(ツ)_/¯

[quick bough]

PHP is the best scripting language I have ever used

[quiet root]

big doubt

[quick bough]

It has a dedicated concat operator, can you believe it

Destructors, too

Unheard of in JS

[quiet root]

php has destructors?

[quick bough]

Yeah, it's like proper OOP

[quiet root]

also yeah in js you dont concat all that much you probably just do template literals

[quick bough]

Concat being "Hello " + "world"

[quiet root]

no youd ```
const otherVar = "world";
const string = Hello ${otherVar};

and then youre done with it

[quick bough]

The fact that + turns the result in a string if either arg is a string is insane because it's very possible your function that expects an int was given a string and now the result of your addition is a string

Very funny when, e.g. using .value on an HTML input element

Of course you were supposed to use .valueAsNumber instead or something like that?

You definitely knew that 😄

[quiet root]

so now youre arguing about a lack of features more than anything

[quick bough]

I mean, lack of features is sorta a problem I have with JS

but I think the bad semantics it has as a result of the lack of those features is a bigger problem

[quiet root]

so use typescript and dont use any/unknown if you dont absolutely have to

[quick bough]

I tried it, it doesn't solve any of these issues

Just adds more boilerplate

PHP also has an insanely large standard library. You can get a lot done very quickly.

[quiet root]

idk all i have to add for converting most of my js projects is types

[quick bough]

My rule of thumb is that if TS benefits your project, you were not using JS for DOM, in which case, why were you using JS for that to begin with 😛

[quiet root]

hm counter argument we do a lot of dom even at wooting

and it still benefits us

[quick bough]

Like, if I need some functionality in my web app, such as generating a QR code, I will call into C++ code via WASM.

[quiet root]

id honestly just let imagemagik handle it

[quick bough]

So, you're calling into C++ code via WASM? xD

[quiet root]

no thats calling into code via an exec on the backend

[quick bough]

💀

Sure, that might work, but I prefer to do work on the client if I can

More scalable

[quiet root]

i dont

never trust the client

the client is just IO

[quick bough]

Well, if the client doesn't generate the right QR code, that's their problem?

I can trust the client in sofar that the client would not have a benefit from manipulating this stuff.

Because what you described is basically doing part of the rendering on the server.

[quiet root]

i for one dont like straying from not trusting the client

[quick bough]

...

I mean usually "trust" is used in a context of security?

Is the security of your web app impacted by trusting the client to render it correctly?

[quiet root]

who knows if imagemagik or whatever has a zeroday that could lead to a security risk

[quick bough]

If that were your concern, why are you running it on your server?

Worst case scenario, I get RCE your server and grab your whole DB

[quiet root]

i mean on a server one can do a lot of input sanitization

i mean with wasm this might not be an issue

but then you also have to rely on wasm working in whatever browser a client uses

[quick bough]

Now that's an actual concern... maybe

I don't care because C++ is the only correct option for me

Certainly won't be using JS for more than I absolutely have to lol

[quiet root]

u see i agree that JS is overused on a lot of "modern websites"

[quick bough]

For sure

[quiet root]

but i dont agree that c++ is the only correct option for anything

[quick bough]

The problem is JS doesn't have an alternative, even in the WASM Utopia, JS is still required as glue.

[quiet root]

well because js runs the web at this point

its a sort of chicken and egg thing

[quick bough]

I mean, well, with every language you make a trade-off. It's possible C++ has just the right trade-offs for me, hence it's "the correct choice" for me.

[quiet root]

as much as i loved writing c... rust is just more attractive to me

[quick bough]

[quiet root]

ok but will the cpp compiler make sure you dont fuck up any memory management or such

[quick bough]

Well, yes?

[quiet root]

memory safety and bonking me on the head for doing dumb shit is why rust is nice

[quiet root]

last i used cpp it gave me more than unhelpful errors

sometimes not even related to the actual problem

[quick bough]

If we look at the decompiled version of this function, we notice it has a call to free that wasn't in the code

This is RAII in action, automatically cleaning up memory we no longer need

I agree, the error messages with STL containers can be extremely unhelpful because it just gives you the entire stack trace and everything

[quiet root]

oh no it just pointed to completely wrong lines in the stacktrace for me sometimes

[quick bough]

I think some of this is already being addressed, just gotta wait for the support for the standards to roll out, I guess

[quiet root]

where the actual issue was undefined behaviour like 10lines up

meanwhile rust will ELI5 it for me

[quick bough]

Then you were probably writing C instead of C++

The fact that you can write C in C++ is good for compatibility and such, but then beginners get scared because they can easily write bad code.

[quiet root]

idk append and move seem like very cpp to me

[quick bough]

Hmm, yeah. Do you have an example of the issue you were having?

[quiet root]

uh i dont have the code anymore but it had to do with basically (on accident might i add) assigning to an object that was involved in a move/append operation and this cause issue way too late as it wasnt reused after the assignment too quickly

[quick bough]

I'm not sure what you mean. I know std::string::append, and that doesn't accept r-values, so you can't move a value into an append. (Well, you can, but it doesn't move it.)

[quiet root]

auto make_appender_move(std:: vector<int>88 suffix) {
    return [suffix = move(suffix)](std::vector<int>& items) {
        return append(move(items), suffix);
    };
}

void test_make_appender_mutate() {
    std::vector<int> suffix{3, 4};
    auto append34 = make_appender_move(move(suffix));
    assert((std:: vector<int>{1, 2, 3, 4} = append34(‹1, 23))); // 0K
    suffix[0] = 5; // Undefined behavior, because suffix was moved
    assert((std::vector<int>{1, 2, 3, 4} = append34((1, 23))); // Maybe!
}

from an article describing a somewhat similar issue (not exactly but it boils down to the same issue) as in their case is just didnt compile at all without any indication why

$ make test
c#-std=c+20-pedantic -Wall -Wextra src/safety.cpp-o target/cpp/safety
target/срр/safety
make: *** [Makefile:12: test_safety] Segmentation fault

dont have the exact code sadly as i dont work at the company anymore where i encountered it

and no its not common or anything

but sad the compiler is unhelpful for small accidents like this

[quick bough]

Ah yeah, std::vector::operator[], that's a smell

[quiet root]

might be that some ides would be able to catch it but vs didnt

[quick bough]

You wanna prefer std::vector::at

That does throw if you access out of bounds

which even [0] would be on a moved-away vector (which is basically the same as default-constructing a vector)

[quiet root]

it didnt though

granted it also want a too new cpp version

idk what were at

might be good now

also they could do a compiler warn for this being like maybe use X or Y instead

[quick bough]

Well, in Microsoft's STL implementation, they do throw a debug assert for out of bounds even in operator[]

but release build would obviously still run into out of bounds issues because you implied that you are sure it won't go out of bounds

(because you didn't use the at method)

[quiet root]

but yeah stuff like that made me fall out of love with c and cpp

[quick bough]

Somewhat understandable I guess

[quiet root]

although rust also isnt all that nice at least if you come from c and cpp with borrowing and such

[quick bough]

I'm the kind of person to write assembly, so I appreciate C/C++ for allowing me to go low and not hindering me

And of course C++ can still be incredibly abstract

[torpid fox]

@quick bough

Hmmm actually the ANALOG_SDK is public so I could check if the mutex is poisoned!

If it’s poisoned that would make for a way better github issue with way clearer details

[torpid fox]

Explains this, because you probably don’t get tracebacks like this from a thread right?

[torpid fox]

I think I might just build the SDK from source and make some modifications for debugging

[quick bough]

If a thread did panic and poison the mutex that would a) kinda sound like stack unwinding failure to me and is generally undesirable behaviour, and b) based on this description, should raise an error instead of deadlocking/blocking.

[quick bough]

If a thread has an uncaught exception, I would handle it, because usually that would result in program termination. Sounds like it might be different in Rust, tho.

[torpid fox]

kinda sound like stack unwinding failure to me and is generally undesirable behaviour
Stack unwinding is just default panic behavior

[quick bough]

"stack unwinding failure" = "the stack unwinding has failed"

[torpid fox]

Oh I thought you said feature

based on this description, should raise an error instead of deadlocking/blocking
I have a feeling that it might be blocking because something else somewhere is waiting for the mutex to unlock
But yes it should indeed return an Err(PoisonError), and since it's unwrapping that that panics

I don't actually know what panic behavior is configured though

for all I know it could actually block on panic

or some thread it's waiting for died because of said panic

[quick bough]

To really emphasise, my experience with handling Rust errors is basically non-existent. The only Rust code I use in production is the Wooting Analog SDK, and let's face it, that's a very cold path/basically none of the userbase would ever run that code.

[torpid fox]

If a thread dies it's not like your entire program dies

[quick bough]

Well, that is generally what happens

[torpid fox]

you probably just have a Result::Err that you have to handle somewhere

[quick bough]

If your thread throws an exception, and you don't catch it, that's fatal for your whole program.

[torpid fox]

But Rust doesn't have exceptions

That's one of the language's key points

[quick bough]

Which is why I said "Sounds like it might be different in Rust, tho."

[torpid fox]

It wouldn't result in program termination

you just get an err value

[quick bough]

And pretending like exceptions don't exist is frankly quite silly 😄

[torpid fox]

like something you'd store in a variable

[torpid fox]

No I am serious

the language literally does not have exceptions

[quick bough]

I mean it's silly on the part of the Rust designers

[torpid fox]

No it's not! It's one of the language's safety guarantees

[quick bough]

A "panic" is just an exception, tho.

[torpid fox]

It's not

[quick bough]

Kinda is tho

[torpid fox]

Instead of making false claims start doing research

[quick bough]

It's conceptually an exception by the way it's triggered. It's an actual exception in the way it's implemented.

[torpid fox]

panics are not meant to be recoverable

unlike exceptions

[quick bough]

Yes, I understand that part.

[torpid fox]

You can't always catch a panic either

[quick bough]

I just find not having exceptions leads to boilerplate. Instead of typing -> u8, you type -> Result<u8, u8>. Instead of typing println!("{}", myFn()), you type println!("{}", myFn().unwrap())...

[torpid fox]

You can tell Rust to abort on panic

so instead of unwinding the stack you just

stop instantly

[torpid fox]

No, you left out the error handling code in the first example

[quick bough]

Also is there a more concice way of printing a variable than println!("{}", ...)? That's kinda wack, even compared to std::cout << ...;

[torpid fox]

No actually because println implements formatting

[quick bough]

I don't have to handle the error if I don't want to. 😄

[torpid fox]

And in Rust you don't have to either!

If you're a masochist

Same in C++

[quick bough]

You still have boilerplate

[torpid fox]

you can just panic everywhere

[torpid fox]

not if you panic everywhere

you don't need result if you're an idiot and use panic everywhere

Rust is a language about safety

[quick bough]

Well, I guess, lol

but if I do want to catch it later, I couldn't

[torpid fox]

If you don't want to take advantage of that stop complaining

[quick bough]

I don't understand how not having exceptions improves safety

[torpid fox]

Because it has an alternative way of handling errors

[quick bough]

but I feel like you would not be capable of explaining, so there's no point further arguing about why Rust may or may not suck.

[torpid fox]

If the language really sucked no one would be using it

[torpid fox]

I think that instead you're incapable of listening

[quick bough]

I did not mean this as an insult, just an observation

[torpid fox]

Definitely sounded like one

Anyway

let's get to the actual point

[flat wigeon]

Can't you attach a debugger to catch the unhandled exception and inspect the program state from there?

[quick bough]

Well, this is what happened when I attached the debugger

I think it just deadlocked

[flat wigeon]

Does Visual Studio support Rust?

[torpid fox]

• The debugger deadlocks
• There is no exception, or at least not in the main thread, I don't know how I would inspect another thread

[quick bough]

Well, no, but it can catch panics.

At least if the panic is raised as an exception.

[torpid fox]

Doesn't seem like it

[flat wigeon]

You are debugging a C++ application which calls Rust code?

[torpid fox]

No, I am debugging an SDK written in Rust

I don't like C++

[flat wigeon]

How comes Visual Studio into play?

[torpid fox]

Sainan tried debugging with it (and failed, obviously) and you just mentioned it for the first time in however long

[quick bough]

Yes, that's how I am interacting with Rust.

[flat wigeon]

Ah okay, Sainen tried to debug with Visual Studio, but you didn't

[quick bough]

I'm gonna try to reproduce the bug without a debugger attached

Well, that's enlightening?

[flat wigeon]

That's an SEH exception

[quick bough]

Yeah, ACCESS_VIOLATION/SIGSEGV

I mean, I know C++ doesn't have the same safety as Rust, but I'm like pretty sure this exception must have happened in the Rust code, which, to be fair, does use a lot of unsafe.

Btw., can you catch/handle an ACCESS_VIOLATION in Rust? 😄

[flat wigeon]

As far as I can remember, you can in C++ ^^

[torpid fox]

It wouldn't be an ACCESS_VIOLATION because it simply doesn't exist
It would be an Err value
This error is not coming from rust code because rust doesn't do SEH

[flat wigeon]

Did you try to resolve the address, where the crash happened?

[torpid fox]

Unsafe is for when you're not ensuring memory safety

this includes doing FFI

[flat wigeon]

C++ doesn't really do SEH either

[quick bough]

Hence why you can still have an ACCESS_VIOLATION in Rust

[torpid fox]

No

An ACCES_VIOLATION would only happen if Rust code called C(++) code that caused the violation

not if rust code called rust code

[flat wigeon]

ACCESS_VIOLATION happens if you access a memory address, that is not mapped or the page is mapped with insufficient access rights

[torpid fox]

I believe unsafe is only used for FFI here meaning if there's an access_violation it'd have to come from somewhere else

[flat wigeon]

You can catch, SEH exceptions in C++, but you need try except (both with two leading underscores) and set a compiler flag to enable it

[quick bough]

I'm not good enough at Rust to make an example, but I'm pretty sure you can cause all sorts of issues in unsafe code.

[torpid fox]

you can but it wouldn't give an SEH exception

[quick bough]

also, no, you can use __try/__except always 😄

Despite C++ exceptions being disabled, this project uses tons of C++ exceptions and unwinding

Just MSVC Things

[torpid fox]

it'd give a Rust Err value (because std is built with Rust's stuff in mind)

That doesn't inherently halt or unroll your stack

[flat wigeon]

Rust does catch SEH exceptions and translate that to Err?

[torpid fox]

Is that a question or a weirdly worded statement

[quick bough]

my fingies hurt from all this keyboard unplugging >.<

[flat wigeon]

Sort of both

[torpid fox]

SEH is specifically a C/C++ thing by Microssoft, Rust does not go through C/C++

Rust does not need C/C++ to exist, it compiles itself

[flat wigeon]

SEH is a OS Level thing

[quick bough]

ACCESS_VIOLATION/SIGSEGV comes from the CPU when it has a fault

[flat wigeon]

If you violate memory, the os throws you an ACCESS_VIOLATION

[quick bough]

or actually maybe from the kernel

[torpid fox]

I see

[quick bough]

depending on whoever says "you can't access this memory"

[torpid fox]

well then yeah Rust translates it to Result::Err(SomeEnumMemberThatRepresentsAccessViolation)

[torpid fox]

So yes

[quick bough]

Well, I made it dump the whole stack, and it's still the lambda::_Do_call at the top of the stack

[flat wigeon]

Also you can install an unhandled exception handler to catch such exceptions and for example create a crashdump

[quick bough]

Tell me about it

[flat wigeon]

Umm... okay, is this portable?

[quick bough]

Absolutely not 😄

[flat wigeon]

I was actually referring to SetUnhandledExceptionFilter()

[quick bough]

My unhandled exception filter is written in x86 assembly

so I can handle stack_overflow errors

[flat wigeon]

Umm...

Not sure how x86 assembly allows you to do that

[quick bough]

I pass it on to a different thread and busyspin

I would've done like switching to a different fiber, but even that requires some stack space to be available

[flat wigeon]

Wasn't the issue, that if the stack overflows, there is no space on the stack to call the handler?

[quick bough]

No, that's not a problem, you can barely call an exception filter

but you can not use any additional stack space

hence why at that point I am only trying to get another thread to handle it for me

Ah, I figured it out

This assertion fails

and because num was negative, I was corrupting the stack 😄

[flat wigeon]

-1?

[quick bough]

idk what negative number, but one of them

[flat wigeon]

My last memory issue also was related to C API ^^

Luckily it just truncated

[quick bough]

It returned -1999

What a surprise

[flat wigeon]

Regarding ACCESS_VIOLATION in Rust... If Rust translates that to an Err, are programmers aware, that this is not a normal error but can indicate, that memory was actually corrupted?

[quick bough]

lol, I just bought Fugl just to find out it doesn't even use the Wooting Analog SDK anymore 💀

Please someone tell me there is at least 1 game out there somewhere that uses the Wooting Analog SDK

How else am I to test my plugin smh

Well, I guess I already validated it against my own usage of the Analog SDK, but that doesn't count for much >.<

[quick bough]

Okay, well, think I'm done with my plugin for now. Can use Razer Huntsman Analog keyboard with Wooting Analog SDK applications.

https://github.com/calamity-inc/universal-analog-plugin

[flat wigeon]

Umm.... isn't there something missing?

[quick bough]

What's missing?

[flat wigeon]

I don't think the main.cpp alone will do much

Ah nvm

[quick bough]

Yeah, most of the relevant code is in another repo lol https://github.com/calamity-inc/Soup/blob/senpai/soup/AnalogueKeyboard.cpp

I'm a bit disappointed, I also bought analogue keyboards by SteelSeries and Corsair but they only have "adjustable actuation," not really embracing the analogue-ness.

[torpid fox]

I have returned
I have an upgraded SSD
Still have some technical issues but at least I can continue to work on this now

I'll continue debugging the analog SDK to see why it's hanging

[torpid fox]

Okay so the lock does not seem to be poisoned
It really is just the lock not being released elsewhere. I think.

[torpid fox]

@quick bough my debugging stuff says the mutex last gets locked at line 209 before the deadlock
Which seems odd

[quick bough]

Do you even use the wooting_analog_clear_device_event_cb function?

Also, I figured out why VS froze when I attached a debugger... just the game I'm modding doesn't seem to like debuggers being attached to it :^)

[torpid fox]

I only call it when my Wooting object gets dropped; which is not happening because if it did I'd know

I have a println in there

I would know when it's dropped

[torpid fox]

[torpid fox]

you know, I'll even add an extra print statement to make sure

you can never be too sure

[quick bough]

The deadlock doesn't seem to happen consistently for me tho

[torpid fox]

Oh!

[quick bough]

Wdym by "gets dropped"?

Like the Rust "drop" method?

[torpid fox]

object being deleted when going out of scope

[quick bough]

Then that's your issue then, no?

[torpid fox]

The drop trait

[quick bough]

You shouldn't let it go out of scope

Certainly shouldn't attempt to use it after it's out of scope?!

[torpid fox]

That's under Godot's control not mine

[torpid fox]

I didn't make it go out of scope myself!!

[quick bough]

I thought Rust solved memory management

[torpid fox]

This is a Godot issue not a Rust issue

[quick bough]

Can you leak the memory?

Like, just on purpose

Can't go out of scope if it's leaked

[torpid fox]

I don't think Godot allows me to do that

Rust would allow me to do it but again this isn't under Rust's control

[quick bough]

Well, I don't know Godot and tbh my Rust knowledge is still pretty shallow

but definitely sounds like an issue with you attempting to use the analog sdk after it was free'd

[torpid fox]

The analog SDK isn't being freed

MY OWN object is being freed

[quick bough]

[torpid fox]

Godot is freeing my object which calls clear_device_event_cb() and then uninitialise() (!!! probably the culprit!) "in its destructor" and then Godot keeps tring to use it

God!! Dammit!!

[quick bough]

[quick bough]

tbh, I only use uninitialise myself

but I also don't use any device event cb

[torpid fox]

you don't uninitialize the SDK?

[quick bough]

I do

but I don't use clear_device_event_cb (because I don't have a device event callback)

[torpid fox]

oh

that's what you mean

I'm going to pursue down the Godot route now

maybe unplug a different keyboard to see if it randomly just decides to free an object when a keyboard is unplugged

[quick bough]

but it would be weird if Godot were to use-after-free your object

you don't use any threads, right?

Also, why would you unplugging the keyboard correlate with Godot freeing your object?

[torpid fox]

I don't, the only multithreaded part is within the analog SDK itself

[torpid fox]

I don't know! That's what I am trying to find out! There is absolutely ZERO reason why my object should be freed!

[quick bough]

Well, that I think would be a good question to try and answer

[torpid fox]

if you look at the top here, that is my bindings object thing I wrote being initialized

it literally CAN'T BE DROPPPED anywhere here

because the only way to do that is to overwrite woot and let the garbage collector collect it

but it's only being assigned once!!

[quick bough]

32 key events?

[torpid fox]

that's commented out

ignore it

[quick bough]

you are aware the HID only has size for 16 keys being pressed?

[torpid fox]

it's not the same kind of event

but that is interesting

[quick bough]

N-key rollover

Anyway, your Python code looks fine

[torpid fox]

that's not python

[quick bough]

I'm sorry what

[torpid fox]

That's GDScript

there are several reasons why this wouldn't be valid python code

[quick bough]

And they decided copying Python's garbage scoping mechanism was a good decision?

[torpid fox]

they... didn't?

it's a different language

oh wait

that's what you mean by scoping

if you mean indentation, skill issue

[quick bough]

1 language with indentation-based scoping was quite enough

[torpid fox]

it's more readable for most people

[quick bough]

Great, now you spend more time writing it

[torpid fox]

skill issue on your end, let's move on

[quick bough]

Well, your Python GDScript code looks fine

[torpid fox]

Yeah

But this is where it's getting dropped apparently

[quick bough]

What is the type that Wooting.new returns?

[torpid fox]

Wooting

that type is defined in my Rust code

it is something I wrote

[quick bough]

Well, yes, but how does the GDScript environment know the interact with it

[torpid fox]

GDExtension

[quick bough]

And this thing is aware that Wooting.new causes it to own a Wooting instance that has to be "dropped" once it goes out of scope (and only then)?

[torpid fox]

Yes because the garbage collector handles that

[quick bough]

Well, no, the garbage collector doesn't handle that because the GC is not aware of the native object

[torpid fox]

incorrect

that is you making an incorrect assumption

[quick bough]

Well, I know C++ and Lua

[torpid fox]

skill issue

[quick bough]

If I want to FFI with Lua, then I need to set a __gc metamethod that invokes a "free" method via FFI to free the native object once the script object goes out of scope

[torpid fox]

Yes but lua is stupid

[quick bough]

Lua has better OOP support than JS

[torpid fox]

As someone with more than enough experience in both of those languages I beg to differ

[quick bough]

Make a class destructor in JS

[torpid fox]

make a real class in Lua challenge (impossible)

[quick bough]

[torpid fox]

the fuck is that!!

that wasn't in my Lua

[quick bough]

We do a bit of forking

[torpid fox]

oh.

that means you're not using real lua

it means you're using a superset

which does not qualify for the real class challenge

anyway

[quick bough]

"Real Lua" still supports __gc therefore it's better OOP than JS in my book

Yes, anyway, I was just trying to figure out how your FFI thing is aware of the Rust object

because I don't trust abstractions

[torpid fox]

That's what I'm going to chase down

I'm going to chase down Godot-Rust

Hmm I wonder if I can get freed twice
In which case I know there is a clone in play

[quick bough]

A real FFI class in real Lua btw 😛

[torpid fox]

This is the shit I had to do

this is garbage

I hated this

[quick bough]

(This code has been generated by a PHP script I wrote)

[quick bough]

Shouldn't that be impossible unless you derive Clone?

(Unless the GCExtension can also magically clone your object instead of ref-counting like I would expect)

[torpid fox]

Maybe Godot-Rust is deriving it for me. I'll check

[quick bough]

Also, just a foundational question, wouldn't it be easier to just use "GDScript C#", link against wooting_analog_sdk, and do the FFI via C#?

As much as I like my native code, it would seem simpler to use a "write once, run anyway" kinda deal

[torpid fox]

It doesn't seem to be deriving clone

[quick bough]

esp. when it has proper native support in the engine as opposed to being like 2 abstraction layers away

[torpid fox]

No

[quick bough]

No?

[torpid fox]

No.

[quick bough]

Not elaborating on that?

[torpid fox]

The C# support in Godot works wildly different from GDExtension and doesn't actually allow me to define new classes like I'm doing now

I want what I'm doing right now to be an add-on anyone can use seamlessly and the current C# implementation doesn't allow that

There are official talks of moving C# support to GDExtension

C# support is kinda horrible in general right now which is one of the reasons for that

[quick bough]

I see

[torpid fox]

traceback

Godot is absolutely freeing (dropping) my object

But later it says this on exit which I find very interesting

[quiet root]

well js actually does have something close to that. the main issue is the lack of any GC semantics in the javascript spec. but afaik there is something that has passed or will soon pass ECMA spec called FinalizationRegistry

ok its in the spec and you can find it here under point 26 managing memory https://tc39.es/ecma262/multipage/managing-memory.html#sec-managing-memory

[quick bough]

That would be nice for my WASM needs

Right now I just made my own memory manager and have it manage scopes for me

which is a slight bit of boilerplate to declare where a scope is

but oh well

[quick bough]

I've infiltrated the Rust codebase and made their CI build fail

[placid ledge]

👀

it isn't just your commit, also my branch before the merge as well. I think cbindgen did a breaking update

[quick bough]

I know, just a funny 😛

[placid ledge]

well, your PR actually did cause it to fail, had to fix the tests after I dealt with the cbindgen stuff 😂

[quick bough]

lol

I really do wonder how the UwU would behave with the Analog SDK... won't be able to check myself >.<

[bleak oyster]

@placid ledge https://github.com/WootingKb/wooting-analog-sdk/pull/53 is ready for review

[placid ledge]

It's pretty similar tbf, currently the digital buttons also come through, but only with 0 or 1. Not entirely sure yet if I should have them be included or not. Also, you should be able to purchase, it shouldn't be possible to end up on that screen aha

[quick bough]

If it matters, I selected "Amazon Pay" because last time I provided my CC details, I was asked to verify with support which was a mild inconvenience I was trying to avoid. I guess I'll try with CC directly.

Yeah, I guess Amazon Pay method is brokey (at least for back-orders) because CC worked

Anyway, my main question is how the keys will be reported. I guess it'll be like that you configure whatever key you want it to be in the wootility, and then that's what the firmware will send?

[thick sigil]

Hi i need help trying to figure out something about my 60HE

[quick bough]

ACK

[vestal kindle]

[floral crane]

In the Wooting RGB SDK is device index stable, like does it change randomly or is it dependant on port or something?

or is there some sort of unique id I can use to link data to a keyboard reliably

I know the USB Meta has the model number which is better than nothing but it would still prevent multiple of the same type of device if I use that

Serial number would work but I don't see that in the RGB SDK so maybe there's a hidden command to get it I found the command, I'm gonna use serial number

[quick bough]

It looks to me like the RGB SDK only support a single device being connected at a time. Do you mean the Analog SDK?