u know if it dumps logs or smth somewhere
#🤖│community_dev
quiet root
balmy iron
If only it was that easy
floral crane
if only it was as easy as running it in a terminal - dreams from linux
balmy iron
Time to add bloat and integrate something like breakpad so you get dumps without paying MS blood money for the privilege
floral crane
yeah thats what I mean, errors like that should log to the terminal
quiet root
yo shay
or ngh
whats the unit that sleep waits in
on linux
seconds or milliseconds
balmy iron
seconds I zink
quiet root
hm weird
balmy iron
I do believe you're supposed to use nanosleep or something nowadays tho for more precise sleeps
quiet root
so the problem why win takes ages is
that i wrote an std_sleep
not even sure why
but it takes seconds and since windows ucrt Sleep() is in ms i convert those
so it waits 3 seconds during the switch
i think we did the minor sleeps between usb commands so the keyboard doesnt get stuck key states
fixed it
trim cargo
oh so it should switch faster now?
quiet root
yes
trim cargo
thanks
huh, seems to crash whenever I select discord
though it is switching much much faster
quiet root
when u select discord?
trim cargo
oh my even if its anything else to discord
windows 10 pro version 2004 build 19041.1288
quiet root
running the switcher as admin or without
trim cargo
ok seems to not crash when run as admin
quiet root
hm
fathom karma
running it as admin turns off the rgb effects on the keyboard like the wave effects, but starting the application that it switches profiles to, and then closing that application, turns the rgb effects back to normal. and i wish i could find a way to make the wootingprofileswitcher a background app, because seeing it in my taskbar with the blue bar gives me anxiety for whatever reason. other than that it works
quiet root
its not finished yet
and for the rgb stuff i guess we could just not connect to the rgb sdk and pray just sending commands works
quiet root
got a mac version to compile
now i just need to figure out how to read the focused window
quiet root
@floral crane it here... macOS is now supported
floral crane
pog
quiet root
@floral crane u got a linux config for the profile switcher
floral crane
i dont, i dont even use it cause it occasionally resets my entire keyboard and layout
floral crane
i feel that
quiet root
not the normal stuff
but making it a proper gui app
that appoears in the doc and all
floral crane
oh lol yeah that too
i remember some stupid stuff last time I messed with that kind of thign
quiet root
the most annoying part is that its only really available in objective c
balmy iron
Thought you're supposed to do it all in Swift nowadays
floral crane
swift is mac only, so it'd have to be its own project entirely to be in swift
balmy iron
As far as I know it's intended to have good interop with all the other languages used on those platforms, including C
So just write the macOS specific parts in it pepeg
floral crane
up to tony, they're doing the mac stuff cause I got no mac, I only use linux
balmy iron
Swift is also officially available on Linux and is open source, although I can't think of any non-appley project using it
floral crane
yeah you'd have to write swift to c library/bindings to do anything non appley, cause everything on windows and linux api is in c
balmy iron
Yeah, but my point is it's probably more pleasing to use than objective C
quiet root
ill stick to objective-c
only use it for 2 functions really
main issue rn is that the entry point of the app cant be in macos objective c shit cause then the other 2 platforms no work
so i have to figure out a lot of stuff
balmy iron
Why not have the entry point be objective c, that then calls the analog switchers main and such, and then the other platforms have a main that calls that main.. basically make it work like a library
quiet root
eh already got it fully working except 1 thing and thats the window close event
quiet root
Got it implemented
so no swift or full blown obj-c
but works as it should
as soon as i got the textbox to show the usual console output im done
never wanna touch macos cocoa again
quiet root
@floral crane macos is now on the level of linux and windows. window with output and actual app bundle that can be found in the dock and spotlight
balmy iron
But it just works!!
quiet root
ya i noticed
when it crashed twice during setup
macos so gud
tomorrow i gotta figure out exact compile instructions for macos
quiet root
so i did some more cleanup, fixed compilation on windows and added some readme stuff
rustic edge
Is the wooting sdk available to the public, and if it is, are there... tutorials.. on how to use it? 😅
quiet root
wrong channel
quiet root
you asked about the sdk not dm
flat wigeon
Is it now possible to read A1 - A3, mode and fn by using the analog SDK?
I mean by the actual scan code, not by mapping F-Keys
hybrid lake
I mean by the actual scan code, not by mapping F-Keys
Yeah they have a special code @placid ledge
placid ledge
Don't think the changes are in beta, but its in the alpha currently released and be extension the beta that is aimed for the start of next week
0x0403 -> 0x0405 for A1-A3 and 0x0408 for Mode key
flat wigeon
Is this affected by remapping?
placid ledge
yes
the code reported by the analog sdk is whatever is bound to that key
holding fn will affect it as well giving you the bind on the fn layer instead (only in the upcoming update, current version only reports main layer bindings)
quiet root
so theres no absolute mode to just get all keys as they are no matter what was mapped to it?
placid ledge
not yet, it's something that I would like to have, but haven't been able to determine the best way to do it yet
flat wigeon
To be honest, I have an issue here. The analog SDK is crap for typical game developers for the very simple reason, that they have to go out and support it
Often I see the issue, that in games something like a pen just doesn't work, even if it should work without doing anything, because the OS emulates mouse input
For context: I read the bad reviews for the Wooting Two: "Not enough games work with this for it to even be viable."
This stuff belongs into the major game engines and input libraries. A way to use 1) non-standard hardware and 2) analog values on every applicable binding without much effort.
balmy iron
That's why it pretends to be a controller.
Too bad a lot of games don't handle simultaneous controller+mouse/keyboard input 😦
sturdy ember
I imagine the main issue is that there isn't currently a standard way of representing the outputs of such a device over USB.
I think joystick HID reports have some limit on the number of buttons they can represent, since it wasn't designed for joysticks with 105 buttons.
If joysticks could have 105 buttons, then the primary way of reading the analogue states should work the same way as a 105-button joystick (dunno what the actual key count is; it's probably greater than 105)
Extensions were made to the HID protocol to allow for n-key rollover as that became an important thing for keyboards.
sturdy ember
Actually, trying to understand USB HID quickly (so probably haven't understood it properly), it seems like it might be possible.
Since it already has the concept of array vs. variable fields, where an array would be more appropriate for a gamepad with many buttons. Looking at the report descriptor currently used by the gamepad, it shows that "variable" fields are used, so all states are meant to be sent in each report, but I wonder if the standard gamepad drivers will accept "array" fields there instead, where each field has an index, identifying a particular button/key.
flat wigeon
I don't think, that's the main issue. You can work around that.
We already have these issues with devices that do have a proper HID representation
Almost every game of which I tought, would be good to play with touch/pen, just didn't work at all. (bug in Unity >= 5)
So the main issue in my opinion that the game dev programs against hardware details.
Basically what you need is an proper input library, which doesn't expose hardware and allows for remapping via its control software.
sturdy ember
Sure, so in that case it sounds like developers should be able to use standard interfaces to work with the hardware, and presumably they're just not supporting it (or not supporting it properly).
Since you initially mentioned the analogue SDK, the analogue SDK is not a standard interface and I wouldn't expect games to interface with it.
Practically, a Wooting keyboard as an input is really just a gamepad with lots of buttons, so it should expose itself as that to games/applications that are not designed specifically for Wooting keyboards.
flat wigeon
Well my idea is, it should just work even without being designed specifically for Wooting keyboards
And for that you must take away control from the game dev
sturdy ember
It might be that the reports produced are already suitable as gamepad reports based on what I said before, and it might just be that it needs a proper report descriptor.
flat wigeon
Still I think the input library must be first, which should be the sole library needed to support all sorts of devices. Mapping should be done in configuration, not hardcoded. So if a new device comes out, you (as the user) can just map it without any hacks and glitches.
sturdy ember
I would usually expect the mapping to be done in the application, since you're usually mapping inputs to application/game-specific things.
eg, if you're configuring some button to mean "go left", that's a specific concept in the game. Outside of the game, that might just look like an "a" key.
up/left/down/right, crouch, laser, rocket launcher, sniper rifle .. not things that the input library should know about. The input library just returns an identifier when the user presses a key, and the game should allow the user to configure a mapping between those identifiers and in-game actions, by getting the user to press the key while configuring the action.
If it's meant to be configured outside of the game, the game would need to expose a set of actions such that an external tool can map them, so maybe you would find something in the OS' control panel that lets you configure what button activates "crouch", seems a bit funny to me though.
flat wigeon
Seems funny, but is a better solution then half of the devs screwing it up, by implementing it themselves. Also that's what you do with Gamepads in Steam.
Except that steam just emulates standard inputs and doesn't know actions
balmy iron
Actually Steam Input is all action based remappable by user, although not many games use it..
brittle bobcat
Is there a programmatic way I can trigger a profile switch?
brittle bobcat
https://github.com/ShayBox/WootingProfileSwitcher/blob/master/src/main.c#L120 <@...
This is perfect, thanks! And it's already in C, even better!
grizzled wolf
I guess it's worth asking,
Has anyone set up a AHK system or similar for simulating analogue movement with the WASD keys?
let's say holding a key 10% analogue range would mean W gets pressed every 200ms, 50% -> 50ms and 100% -> on at all times
quiet root
yes
quiet root
was posted in here iirc
grizzled wolf
ok
quiet root
idk if it is an exe or ahk script
grizzled wolf
has come to terms with the fact that windows security is running at all times anti virus or not
brittle bobcat
_has come to terms with the fact that windows security is running at all times a...
@grizzled wolf @quiet root I enjoy AutoHotkey as well, so this message caught my attention. I was hoping it would actually be compiled ahk or ahkdll wrapped up in C#. Decompiling the DLL reveals some very simple C# using the Wooting SDK and InputSimulator. Here's a dump of the DLL. https://pastebin.com/crWm7KcH and here's the repository for InputSimulatorStandard https://github.com/GregsStack/InputSimulatorStandard
grizzled wolf
oh, neat
tranquil pivot
Hey, I have wrote a very thin wrapper for the RGB SDK for python using ctypes. This can be found here, if anyone is interested: https://github.com/xiamaz/python-wooting-rgb
flat wigeon
I'm curios about the inputs with index 88 and 89 (from UP 0x1337). Do they have a purpose or are they not connected?
placid ledge
I'm curios about the inputs with index 88 and 89 (from UP 0x1337). Do they have ...
Are you referring to the HID interface with usage page 0x1337? If so then I think the answer to your question is just that they are not connected
grizzled wolf
Is it possible to compile and load a program into the keyboard itself? I wanted to imitate the built in profiles of a Royal Kludge keyboard I have, but from what I read apparently anything manipulating the RGB of the keyboard must reside in the operating system.
floral crane
wooting keyboards no, you gotta use rgb sdk, I wish they did
quiet root
if you want programmable rgb just use Artemis
its basically the one stop shop for rgb atm
grizzled wolf
https://artemis-rgb.com/docs/
Links to plugins 1, 5, 9, 10, are not found, and 404 too in GitHub's examples 🤔
Links to Core Services and UI Services are 404 too
quiet root
the docs idk about
i just installed it and its pretty self explanitory
plus it comes with wooting plugin in this case
grizzled wolf
uhm, download pulls an exe file
quiet root
oh wait are u on a non windows platform?
quiet root
either u gotta wait till they implement the new cross os UI which is the reaosn its win only
or you just work with wooting rgb sdk
grizzled wolf
I've seen examples that need Node, that's overkill... it's a keyboard
quiet root
grizzled wolf
lol
grizzled wolf
wooting keyboards no, you gotta use rgb sdk, I wish they did
😦
quiet root
well with the sdk u either have to manually talk to each led
or build rgb frame buffers essentially
artemis would have the benefit of a complete suit for unified rgb of the setup
so keyboard and mouse sharing the exact same effects
and reacting to for example os events etc
u can obviously do the same with the sdk just u have to code it urself
floral crane
theres also python bindings someone just made for the sdk
grizzled wolf
actually that's what I'm looking for... I imagined I'd end up coding a simple loop where with a 2D array of pointers I could manipulate each led
grizzled wolf
arghhhhh
quiet root
thats for analog reading
quiet root
https://github.com/WootingKb/wooting-rgb-sdk/
here
the rgb sdk is more useful
cause it also includes the wooting usb header
which is for sending feature commands
like switching profile etc
quiet root
oh
in that case
just remap them
with the wootility
no need for any extra software
grizzled wolf
with second and third I mean actually different keys, so I need to use f13+ as you mentioned
well, not need, but I would use them I think
floral crane
If you intend to use F13-24 on xorg you gotta remap them with xmodmap back to function keys, they send the equiv of laptop function keys
grizzled wolf
so they can act as extra modifier keys for even more shortcuts in my window manager
grizzled wolf
If you intend to use F13-24 on xorg you gotta remap them with xmodmap back to fu...
thx for that tip, took note
floral crane
keycode 191 = F13
keycode 192 = F14
193+ F15+ etc
xmodmap ~/.Xmodmap
grizzled wolf
will X interpret that right away? 😮
grizzled wolf
since you know about that... I expect them to act as extra modifier keys so I can compose them
like... ctrl+... alt+...
floral crane
you can do that, there's also an unused modifier in x for mac keyboards or something called hyper or compose or something
quiet root
first of all dont crosspost the same question, second of all wrong channel
exotic harness
Is there an easy way to write middleware for the Two HE? I.e. intercept keyboard inputs and replace them with other inputs before Windows sees the keystrokes?
exotic harness
Last I checked AHK didn't do analogue input
quiet root
there libs that use the analog sdk for ahk
wooting only offers the rgb and analog sdk
everything else can already be done with better pre existing tools
also i thought u wanted to interrupt a key not the analog controller inputs
so im unsure if you misunderstand how the keyboard works or if you worded it weird
exotic harness
No, I meant intercept
quiet root
the keystrokes are just keystrokes like on any keyboard then
exotic harness
Aha, so the keyboard never sends analogue input to the system. If I want to intercept analogue input it would have to be in the keyboard firmware
That makes sense
exotic harness
Right, and that SDK can prevent the analogue input from reaching the system=
?
And/or digital input?
quiet root
im unsure what you mean
the system only gets keyboard events from the kbd interface
and controller events from either the xinput or dinput interface
exotic harness
Right, but I want to be able to map the keys to something else in a program, and still have the analogue input
So I need to not only read the analogue input, I need to also prevent the system from seeing it
quiet root
the system doesnt unless you use an analog profile where you setup controller mappings
and even then the system gets the digital keys if you chose so
also explaining around an exact usage will prob be slower to reach the info you want than just state the actual thing you wanna do
exotic harness
Well, for example, I would like to be able to make a six-stage DKS instead of a four-stage one
quiet root
so use ahk
and the library for analog sdk in ahk
or if you dont want to use ahk you unmap the key to smth weird like f24 and then just write a c/cpp/c# app that reads the analog sdk
exotic harness
I see. Thanks for the info
quiet root
i would recommend also getting stiffer springs
or really nailing ur finger movements
(obv depends on where you set your actuation points on the 255 steps you get)
hope you succeed in your adventure
exotic harness
I suspect anything involving AHK will be far too janky to be useful. And there aren't enough spare F-keys to cover the whole keyboard in them
Ideally I was hoping for some kind of plugin support in the existing Wooting keyboard driver
quiet root
they dont have a driver
its all default os drivers
u could also just do all the key mapping in os with hooking and some good code
ud set it to an analog profile, disable all digital keys and then emulate keys urself
that way youd have full control over all keys
exotic harness
Yep, that's probably the best way to do it
exotic harness
This looks promising: https://github.com/0x2E757/InputInterceptor
Still would need something for simulating controller input, but it's a start
quiet root
just do what wooting doublemovement does
and use that gamepad emulator thingy
altho for gamepad you can still use the keyboard itself
unsure how youre expanded dks would interfere with it
stone locust
Yo
hazy crypt
it is Wooting software faceit anticheat save ?
balmy iron
Keyboard doesn't require the software to be running. Double movement app? Go to #archived_fortnite_double_movement !
flat idol
is it possible to bind arbitrary HIDs to keys from the wootility app, or just the pre programmed ones (basic+extended+special)
(if not the F13-24 keys will probably be enough anyways)
quiet root
only whats in theres and iirc mouse buttons may be in the work but dont take my word on it
basically limited by the fact that the remapping doesnt happen in software but the hardware
sage dragon
is there an auto profile switcher that can switch between more than 3-4 profiles? Kinda silly I can only switch between the profiles directly on the keyboard, when it seems i can activate an "inactive profile" immediatly by clicking on it in wootility
quiet root
its not active immediately technically. its only really active when you save it. theres currently no such tool
we might see native wooting support in the future tho since they did plan for more profiles on the keyboard starting with the lekker switch by including a ton more storage on the keyboard itself
sage dragon
I meant that in v4 of wootility I can click on one of the inactive profiles and its applied to the keyboard, I suppose it saves the profile to an additional slot on the keyboard, and the community doesnt have access to that (writing profiles to the kb)? That's really too bad, since it's the community compensating for a feature lacking in wootility. ty
quiet root
we can write profiles but clicking a profile doesnt save it to the keyboard just sends the data over temporarily
the wootility uses the same things the community can do with the sdks and some people are working on auto switchers etc
nocturne jackal
Double checking here, I'm working to make the wooting easier to get up and running in Fedora atm
I only have a Wooting one so I can't confirm
do all wooting keyboards emulate an xbox 360 controller? or has that changed?
glass radish
Double checking here, I'm working to make the wooting easier to get up and runni...
you can change the gamepad emulation settings in Wootility > Settings > Keyboard settings > Gamepad Mode
this is the wootility that the non-flaretech wooting keyboards use atm: https://wootility.io/
nocturne jackal
That much I know @glass radish , just double checking that "Xbox" always means Xbox 360
and not any other form of xbox controller
I'm writing a modification for the xpad driver in linux so I don't need to use xboxdrv, which Fedora no longer packages
nocturne jackal
Appears she works 🙂
@chilly oar I see you worked on this in the past, everything I did look OK to you? If so I'll submit a PR so this can get upstreamed https://raw.githubusercontent.com/KyleGospo/wooting-xpad-dkms/main/wooting.patch
nocturne jackal
https://copr.fedorainfracloud.org/coprs/kylegospo/wooting-keyboards/ <- Ready built version of the above here, one package for the patched xpad via dkms and one for the udev rules
quiet root
yes always xbox 360btw
nocturne jackal
Thanks
quiet root
unsure if its worth emulating xbone controllers
well emulating isnt even whats happening
nocturne jackal
makes sense to me, everything supports the 360
quiet root
correct and the xbone controller doesnt have all too many new features iirc
balmy iron
Trigger vibration, very relevant for keyboard
nocturne jackal
vibrating keys when
Well anyway, that patch is working great for me on a wooting one
if anyone with another keeb wants to try it out I'd appreciate it 🙂
quiet root
*and linux
nocturne jackal
Fedora specifically unless you want to build it yourself
quiet root
actually idk if its only fedora
nocturne jackal
the copr repo is prebuilt RPMs
and I only provided build scripts to make RPMs
so if you're on a debian distro you gotta do a bit of your own work
or arch btw
quiet root
am windows scrub ¯\_(ツ)_/¯
nocturne jackal
could also manually install since it's just dkms
balmy iron
Yeah I also tested patching xpad years ago and worked fine, am too antisocial to try to upstream it though. Only have a legacy two unfortunately
quiet root
do it pussy
nocturne jackal
Found someone with a newer wooting and Fedora, worked there too
I submitted that patch upstream
Should mean OOTB support for Wooting keyboards in future Linux kernel releases assuming they accept it
nocturne jackal
yup
quiet root
native wooting steamdeck
placid ledge
I submitted that patch upstream
Many thanks for doing that, it's been on my list for a while. I tested out patching the xpad module a while back, but for some reason I was running into weird mapping issues then
chilly oar
Appears she works 🙂
The legacy Wootings use the vendor ID from Atmel. So as far as I know the Atmel vendor ID also needs to be added.
XPAD_XBOX360_VENDOR(0x03eb), /* Atmel for Wooting Legacy Keyboards */
This is needed as a filter because the Xbox controller don't have a dedicated reserved HID class. So the driver only looks for the special class number if the vendor is listed as a potential Xbox controller producer.
The entry via the xpad_device[] element is only to provide a name if the device was successfully found as a Xbox controller. If that is missing the controller is shown as a generic Xbox controller. If only that is present and the vendor is missing the device should not be found. So I'm kind of surprised it's working for you.
As far as I know it's planed that the old Wootings get a new product ID with Wootings own vendor ID when they get the support for the Wootility v4. The IDs should already be added in the Linux udev rule. Due to this I personally would prefer to not add the Atmel vendor ID to the list of known Xbox vendors and instead only add Wootings vendor ID to it. Even it will may take a while until the old keyboards get the new firmware upgrade.
Sadly I don't really know how the mapping of the Xbox controller actually work. On a quick check it looks to me that the mapping happens somewhere else and that it may depends on the distributions how the Xbox controls are mapped to the generic Linux joystick. I checked it by changing the vendor and product ID of the Wooting to match the IDs which are used from the driver for other controller.
nocturne jackal
The atmel vendor is really generic and has a ton of different devices under it, so I added the Legacy keyboards in a different section by vendor and device ID
And then of course just did the entire wooting vendor ID
I can confirm that both are working, I personally own a legacy two
If the Legacy keyboards get a firmware update to give them the new vendor ID it should just work with that implementation too
@chilly oar under vendor id 0x3767 is another device implemented that way
chilly oar
So you have the Atmel vendor ID also added somewhere or is that missing for you?
As far as I know you need to add an entry for xpad_table, otherwise the device can't be found as a Xbox controller.
The entry for xpad_device is kind of optional and only needed to correctly show the name as a Wooting device.
nocturne jackal
Sorry, I'm mobile, but this is where that's defined
Check that other device ID I gave you, it's the exact same way
chilly oar
As far as I know it don't work if only that entry is present.
quiet root
If the Legacy keyboards get a firmware update to give them the new vendor ID it ...
the VID and PID are basically set in stone for wooting keebs
it would just be extra work to add some new ones to the SDKs and wootility
and then maintain the list
chilly oar
This isn't a question about the name or work.
quiet root
chilly oar
The probe function of the Xbox drivers checks the list of known Xbox controller by the vendor and product ID to show the deposit device name and to apply specific configurations if needed. The search for that happens here: https://github.com/paroj/xpad/blob/6460408f180dfa4e5cf3b6f88899aa3e3f2a03a6/xpad.c#L1984
In the case the probing didn't find a matching entry for the found device it uses the last entry stored within the xpad_device variable.
Then it uses the default configuration and Generic X-Box pad as the controller name.
But as mentioned this has no effect for applying the driver, that must happen before.
And again, as far as I know the vendor ID needs to be listed in the xpad_table so the driver can be applied to the device .
quiet root
@placid ledge whats WOOTING_ONE_V2_PID 0x1100 and WOOTING_TWO_V2_PID 0x1200 for?
chilly oar
The new product ID for Wooting own vendor ID (31E3h) I guess.
chilly oar
It's better this way. The newer models have a different product ID depending on the used analog mode.
With the Atmel vendor ID this is not possible. Because there they only own four product IDs (normal & restore mode for two keyboards).
nocturne jackal
{ 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
nocturne jackal
There is only one entry for 0x3767, which is that
is has no accompanying entry in xpad_table
chilly oar
Right now each Wooting can have four product IDs (three analog modes and the restore mode).
nocturne jackal
Could be that controller was implemented wrong, though that wouldn't explain why my legacy wooting works
quiet root
simon still leaves outdated comments i guess https://discordjs.moe/dpocotxboylg.png
nocturne jackal
Gamepad tester reports my keyboard as 03eb-ff02-Wooting Two Legacy with the patched xpad installed
chilly oar
There is only one entry for 0x3767, which is that
Yes, but this is of the type XTYPE_XBOX. So this is the first Xbox controller, the Duke. That is not a Xbox 360 nor a Xbox One controller.
These aren't detected by the vendor ID but by a special unofficial class.
https://github.com/paroj/xpad/blob/6460408f180dfa4e5cf3b6f88899aa3e3f2a03a6/xpad.c#L446
nocturne jackal
I can confirm unloading xpad disconnects the wooting controller on my Legacy two
gonna look at the init here myself
chilly oar
The correct way of detecting a generic Xbox controller would be by checking the Microsoft OS specific descriptor. But I doubt Linux devs want to add a check for Microsoft specific configurations just to apply the correct driver.
In short, the original Xbox controller (the Duke) are identified by a special class, sub class and protocol number (not USB spec conform because these values aren't approved by the USB IF).
The later Xbox controller (360 & One) are identified by a special vendor defined class value. Because it's vendor defined they need to add a filter for the vendor ID which is done in the xpad_table field.
nocturne jackal
Driver seems all over the place, this one is an xbox controller but unlike the example I gave you earlier they have an entry in xpad_table
{ USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */
I did have it so the legacy wooting had an entry in xpad_table at first but changed it when I realized how many devices where under the VID
may just change it back, even if it's working like that
chilly oar
I'm not so deep into that but that entry looks like garbage to me. The vendor ID is also added as a Xbox 360 and as a Xbox One controller vendor. So there is no need to add a dedicated entry for a single device. Also I barely remember that for the check only the vendor part is used and the other (device part) is ignored.
But please don't quote me on that. It's a while since I checked the code and the part there this module is loaded and applied to newly connected USB devices is somewhere else.
nocturne jackal
Restored the original patch I made, thanks for looking at this, it's why we do peer review 🙂
Not sure why the other way around worked for me, but this does seem more correct regardless of how many devices live under 03eb
I'll let the maintainer yell at me if we're wrong
chilly oar
This seems correct. It would be nice if the current models would be added so their shown name is correct but that is optional.
nocturne jackal
My original patch also had that, but their default PR message asks you not to unless the device needs special considerations. I'll re-add it so the name is correct
chilly oar
But I personally would not really want to have the entry for the legacy Wootings with the Atmel vendor ID.
But why are you made the hassle of creating a Github commit? As far as I know the Linux devs only accept code changes via e-mail.
Github is only to show the code, not for contribution.
nocturne jackal
The xpad maintainer accepts pull requests here and upstreams them in batches
chilly oar
Ok...
nocturne jackal
You can always email too
This is just another way to contribute
Alright let me add those device names
chilly oar
A while ago I shared the necessary xpad changes with the Wooting devs. But it lead to nothing due to a weird problem which I guess was unrelated in the end.
If the patch is added, the Wootings will also work on Android phones regardless of the analog mode. 🙂
nocturne jackal
{ 0x31e3, 0x1100, "Wooting One Alt-gamepad mode", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1100, "Wooting One 2nd Alt-gamepad mode", 0, XTYPE_XBOX360 },```These are the names from your udev rules
Is that correct, or is there a flasher one you'd want as the name?
chilly oar
???
nocturne jackal
or don't mention that it's in an alt mode
ignore the 1100 3x
Talking about this:
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1200", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1200", RUN+="/usr/sbin/modprobe xpad", MODE:="0660", GROUP="input"
# Wooting Two Alt-gamepad mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1201", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1201", RUN+="/usr/sbin/modprobe xpad", MODE:="0660", GROUP="input"
# Wooting Two 2nd Alt-gamepad mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1202", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1202", RUN+="/usr/sbin/modprobe xpad", MODE:="0660", GROUP="input"```The last number should be different.
nocturne jackal
right, just focused on the name
you want a customer to see "Wooting One 2nd Alt-gamepad mode"
Or is there a flashier public name?
chilly oar
But you only need to add the product ID for the Xbox mode.
You should not add the entries for the other modes.
nocturne jackal
cool
chilly oar
So the first three digits are for the model and the last is for the mode. The Xbox mode should have the 0 as the last digit.
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1220, "Wooting Two HE", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1300, "Wooting 60HE", 0, XTYPE_XBOX360 },
Can you please add "legacy" to the two old entries.
nocturne jackal
Sure
chilly oar
To avoid confusion with the new entries.
Maybe in parenthesize.
{ 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
nocturne jackal
Done
chilly oar
Great... 🙂
chilly oar
But now you know more...
nocturne jackal
true
Glad to see the legacy wootings are still getting some love, I really want to try a lekker/he at some point though
chilly oar
So it's late and I want to finally go to sleep. 😅
nocturne jackal
thanks again, have a great night
chilly oar
Glad to see the legacy wootings are still getting some love, I really want to tr...
It's kind of slow yes but Wooting at least provides updates. Hopefully Simon has more time when the ARM development is done.
nocturne jackal
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=03eb ProdID=ff02 Rev=00.92
S: Manufacturer=Wooting
S: Product=WootingTwo
S: SerialNumber=WOOT_001_A01B1927W021H00427
C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=400mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=5d Prot=01 Driver=xpad
E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl=8ms
E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl=4ms
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=04(O) Atr=03(Int.) MxPS= 64 Ivl=4ms
E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=4ms
I: If#= 3 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=01 Driver=usbhid
E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
I: If#= 4 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=01 Driver=usbhid
E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=16ms
I: If#= 5 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
I: If#= 6 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR)```Can confirm analog sticks, triggers, bumpers, and all face buttons are working for the legacy two on the newest PR
hybrid lake
@placid ledge should we already add the 60HE ARM PID while we're add it?
quiet root
yes pls
placid ledge
0x1310 is the PID for 60HE ARM btw
chilly oar
Will there be a W2 HE ARM too?
nocturne jackal
Let me make sure I have this all right
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1310", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1310", RUN+="/usr/sbin/modprobe xpad", MODE:="0660", GROUP="input"
# Wooting 60HE ARM Alt-gamepad mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1311", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1311", MODE:="0660", GROUP="input"
# Wooting 60HE ARM 2nd Alt-gamepad mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1312", MODE:="0660", GROUP="input"
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1312", MODE:="0660", GROUP="input"
# Wooting 60HE ARM update mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="131f", MODE:="0660", GROUP="input"```
^ UDEV rules, just the same as HE60 but incremented by 10{ 0x31e3, 0x1310, "Wooting 60HE ARM", 0, XTYPE_XBOX360 },
^ Name in driver, do you want to show it to the user as a 60HE ARM?
If that's good I'll close and re-open this PR so its cleaner/more concise for them to review and only a single commit with no force pushes
nocturne jackal
And any other fun future products? 👀 And the "AVR" version is 0x1300, correct? Should I update that to say AVR in the driver or leave it alone?
chilly oar
@nocturne jackal This is how you can chose is in the shop.
So maybe it can look like this:
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1220, "Wooting Two HE", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1300, "Wooting 60HE (AVR)", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 },
```*But Wooting should decide...*The driver for newer models should get applied by the vendor ID, the only downside is that the name isn't shown, which should be minor.
quiet root
ngl kinda glad wooting finally got their own VID
nocturne jackal
@hybrid lake @placid ledge Your call on AVR and ARM names
hybrid lake
<@123917469311041538> <@178235161857490944> Your call on AVR and ARM names
I think like this looks good. Haven't defined yet how we're gonna name the USB devices
quiet root
i think the arm avr at the end is already a nice identifier and putting it in parentheses makes it visually not part of the general keyboard model
nocturne jackal
One more reminder for everyone, if you're using Fedora Linux you can try out xpad with Wooting support by using my copr repo at: https://copr.fedorainfracloud.org/coprs/kylegospo/wooting-keyboards/
That handles the udev rules for you too
tough prism
@nocturne jackal wait, is there going to be issues with Wooting working on an Arch distro?
nocturne jackal
None, I'm just maintaining a Fedora repository of prebuilt dkms and udev packages
Once those xpad changes are upstream it'll work fine on arch, or you could build the packages I made for arch yourself and use them now
@tough prism
tough prism
Ah ok
tough prism
👍
nocturne jackal
In my case the udev rules needed a tweak to load xpad automatically
You could also just load it yourself
That's all
chilly oar
In my case the udev rules needed a tweak to load xpad automatically
Can you tell more about this? As far as I know you don't need to do anything with the udev rules if xpad is aware of the vendor ID and it will just work because xpad should be loaded automatically.
Of course as long as you haven't started xboxdrv with unloading xpad (via --detach-kernel-driver). Then you need to remove that behavior.
nocturne jackal
Can you tell more about this? As far as I know you don't need to do anything wit...
You're correct, disregard the above. The udev rule I made was simply to load xpad if a wooting keyboard is connected, but that was needed on my end because the COPR repo I used to get xboxdrv added a blacklist that wasn't removed on uninstall.
thanks for pointing that out, wouldn't have found that otherwise. Figured it was a fedora specific issue with not loading xpad at all by default
nocturne jackal
Added OpenSUSE and OpenMandriva to the copr repo as build targets if anyone is using those distros
warm mica
does wooting have support for custom keycodes?
(the keyboard not the software)
if so implementing that in software would be awesome
chilly oar
@warm mica Not really, the keyboards only allow a fixed set of codes but the range is kind of big.
placid ledge
It won't
The keycodes that Wootility configure is a number between 0 -> 255, which we map to keycodes for various different reports. e.g. first section is mainly standard keys that get sent over nKRO/6KRO. Then there's ones that map to the consumer control codes that are on a different interface, codes that are handled internally etc. With the limit to an 8-bit keycode it's not really that plausible to send arbitrary codes
To add more bindings that are possible through remap the firmware needs a mapping between keycode -> interface + interface keycode
It's theoretically possible that more arbitrary keycode support could be added through the AKC system (which is the extension of DKS for Mod tap), as that is designed to be able to do more complex behaviours that a simple remap keycode isn't capable of
Although, given that so many HID keycodes don't really end up doing much on most OS', the preferred strategy is to request bindings to be added if there's a good reason for it. If it's a keycode that does something useful on host machines then it may make sense to add, if it's just so you can listen for that input to do something custom in stuff like AHK then the first step is to make use of F13 - F24 and if that's not enough then having a proposal for a further set of bindings like that would be helpful
chilly oar
@quiet root HID has specific usage elements for different functions (like keys). In one way or the other a keyboard needs to inform the host which functions are supported. So in the end the possible set is always fixed on the keyboard side. The modern approach for the NKRO feature is that each element has an unique bit value in the report instead of a limited kind of keys which can be handled as pressed (like used for the old scan codes on the boot 6KRO interface). If I understood Simon correctly the Wootings internally uses a byte key code for mapping a key to a supported element (key) of the report. The internal RAM is kind on its limit. So to save memory only usefully keys should be supported.
chilly oar
Hmm interesting idea... Maybe possible to hack in one depending which ARM chip is used for the upcoming ARM keyboards.
Even that may have much more than the current AVR.
nocturne jackal
the Nintendo 64 expansion pak lives again
you heard it here first
4 more MB of ram baby
floral crane
Are there wooting sdk rust bindings?
placid ledge
yeah there is, someone made one for rgb sdk and old analog sdk while back. I've got a rough one for new analog sdk, but it isn't published on crates.io, ye need to use git linking
balmy iron
Already rewriting it in Rust I see
Profile switcher but yeah kinda just parroting what you said..
..
Just use unsafe blocks and access the C funcs!
placid ledge
rust gang
I write both c and rust, I'd much rather write only rust if it was viable
although, I do enjoy using C in an embedded context
anti c++ gang?
do love a good hair pull out of frustration from c
ye, not massively fond of cpp, modern cpp is pretty decent
but would easily take rust over cpp
lol
I headbash a million times more just trying to set-up a build environment on windows than anything else
rugged cedar
hey guys. would it be possible to use python to set RGB values to keys?
balmy iron
Yes, just write some simple bindings to the C funcs or I'm pretty sure someone has already published some
rugged cedar
@short flume Hello there 🙂 I've discovered your python bindings to the API. Could you give me a hint on how to extend it to support RGB commands?
quiet root
isnt already the rgb sdk?
also why did someone delete the link
so i checked the previously linked wrapper and it seems to be already having rgb functionality
so im unsure what more you need
@rugged cedar
quiet root
?
balmy iron
Why do you need that?
rugged cedar
In a nutshell the python code needs a dll
quiet root
already has rgb functions
quiet root
In a nutshell the python code needs a dll
u can download that precompiled
rugged cedar
and I didn't find any DLL laying around, so I assumed I need to compile one myself
balmy iron
You didn't read the README?
rugged cedar
I skimmed it...
balmy iron
Install Wooting RGB SDK first.
Follow the instructions for your given platform.
rugged cedar
okay, this is a silly mistake. I never learned how to find the [releases] button from the main github* project page
balmy iron
rugged cedar
Man! You just opened my eyes
...to the power of this awesome community apparently ❤️
balmy iron
And now you know
quiet root
why does it sound so sarcastic
rugged cedar
Cuz that's a rare thing
I don't expect to find good people, and it's so cool if it turns out this group is good
quiet root
while we might send some angry messages its usually not cause we hate people but are fed up with getting asked the same things or hearing the same things
usually were all chill tho
balmy iron
usually
rugged cedar
Perhaps the more niche a group is - the lesser is there a chance to find some ahole?
any group that leaves a bad taste on my mind was a general themed one
balmy iron
That sounds about right
balmy iron
Very cool
rugged cedar
I didn't really understand why the out-of-the-box solution didn't, but after some peering into the code, it started to jive
what can you expect from pre-aplha repositoty though 😄
quiet root
tbf wooting says not to ship the dlls
since they do change every now and again
a link and step to add the dll would be nice tho
rugged cedar
if something comes to shipping, then one would have to contact the devs any way
I'm just glad it all worked much easier than usually
god forbid somebody to try to work with something big. Like apple. Their revenue reports if you're an appdeveloper are a MESS
and you can't simply go and bug their developer to fix it
full shadow
will the wooting software ever have support for the elgato stream deck?
like pressing one button in the stream deck changes your keyboard profile
full shadow
yes but i generally forget to press then when i want to start playing
wanna put it into my steam setup mult action button
hybrid lake
will the wooting software ever have support for the elgato stream deck?
does it have a sdk?
quiet root
does it have a sdk?
hybrid lake
interesting
full shadow
wdu think?
quiet root
theoretically anyone can write a tool to switch to the keyboards profiles
the sdk of wooting is public and lets one switch profiles
unsure if woot staff will make a plugin for streamdeck themselves
full shadow
i dont know anything about coding sadly
quiet root
i dont have a streamdeck so i cant help
chilly oar
Basically only a little program is needed which can send feature request to the Wootings where the parameter for these are given as parameter for the program. By this the tool would be universal and the different functions can be triggered by changing the parameter of the call.
quiet root
thats what the sdk does tho
quiet root
@placid ledge any reason the analog interfaces cant abuse the REV identifier to give more space in the PID list
or alt id or whatever it was
placid ledge
Huh nani
quiet root
like i just thought that maybe u could use the revision id for the alt modes of the keyboard
instead of using an entire PID
was just an idea tho
unsure if anything would speak against that
tiny bolt
Howdy! I just joined this server, and I notice that your requested permissions include wanting to know what other servers I’m a part of.
I’m okay with you knowing about my subscriptions to bizarre, sexually deviant porn games and paid-access patreon communities, but not everyone will be. So that could impact the community you’re trying to build. (PS. None of my other servers request that info).
wet knot
huh
If you mean discord auth via the hub thats just discord api
it needs to see your server list to look for Wooting Guild ID
afaik you cant access the data itself, just gives the api the ability to handshake.
@quiet root
chilly oar
like i just thought that maybe u could use the revision id for the alt modes of ...
Now I got what you mean. They used the revision number before to separate the different modes. Before each mode got its own product ID that was even necessary to avoid problems with Win. Every time when the device structure or the report changes the revision number need to be changed to a new number otherwise Win can sometimes miss the changes which lead into weird problems.
The way it is now is kind of new and was done because of a recommendation from me. Mainly to avoid problem with the joystick ID. Otherwise even when the no gamepad mode was selected it can be that a game or Win thinks the Wooting is a joystick.
wet knot
here come the 20 edits xD
quiet root
Howdy! I just joined this server, and I notice that your requested permissions i...
if you are worried heres what a guild from the guild list looks like
{
"id": "80351110224678912",
"name": "1337 Krew",
"icon": "8342729096ea3675442027381ff50dfe",
"owner": true,
"permissions": "36953089",
"features": ["COMMUNITY", "NEWS"]
}
any respectable company which includes wooting only checks if you are in their guild which in this case is used to give you a role
tiny bolt
Sounds reasonable. I’m not personally worried, but I thought I’d share my thoughts because someone else might be. On my end, all I see is that wooting is requesting access to the list of servers that I’ve subbed to.
quiet root
dw i get it altho discord could also improve this on their end
also this is more for community dev
as in not official wooting devs
hybrid lake
Howdy! I just joined this server, and I notice that your requested permissions i...
Fair concern. I remember we discussed this when we were implementing it, but there was no other nice way to check if the user was in the server or not. We always try to minimise any data we collect or have access through via oauth
quiet root
@floral crane u got any issues with using qt5 for a slim os agnostic ui of the gameswitcher?
floral crane
I like qt, though I've only done it in python, it should be easy since you build it using qt designer and only write code to connect
Or you can hard code the ui, either way it's really simple
balmy iron
Qt... Slim?
floral crane
These days? Yeah, compared to electron cough
balmy iron
Yeah at least it's not electron.. yet, the qml stuff is pretty crap though
quiet root
Qt... Slim? <:thonk:568526682110296066>
statically linked
like everything else rn basically
balmy iron
Thicc binary
quiet root
rn its rather small
i did post a pic of current binary size
was 13kb or smth
here
bitter jewel
hello, I want to write something in Rust that uses (Lekker/HE) analog input, and since the SDK itself is written in Rust, I'm wondering, is it best to just interact with the C FFI, or is there a more direct way? (I'm new to rust and making applications, so I'm currently struggling with figuring out C FFI)
placid ledge
hello, I want to write something in Rust that uses (Lekker/HE) analog input, and...
I've got a WIP Rust wrapper that makes it a bit easier
https://github.com/WootingKb/wooting-analog-midi/tree/develop/wooting-analog-midi-core here's an example of it being used
You need to pull it in directly through git wooting-analog-wrapper = { git = "https://github.com/WootingKb/wooting-analog-sdk", branch = "develop" }
https://github.com/WootingKb/wooting-analog-sdk/blob/develop/wooting-analog-wrapper/src/lib.rs this is the interface it exposes
Main thing that isn't there is a nicer wrapper for set_device_event_cb that accepts closures, as well as it being published properly 😅
Let me know how you get on
late scarab
Does the RGB SDK has a Nuget Packet for C# like the Analog ?
If not, how can I import it to a project in C#?
late scarab
Thanks, that will be useful!
placid ledge
@quiet root could you have a look at the issue you opened on rgb sdk, I replied to it
placid ledge
alright
quiet root
ill also see if i can give u some replication steps for the 60he in a sec
only finishing ice cream
placid ledge
cool ty
quiet root
responded for 60HE seems to have been an anomaly or already fixed
bitter jewel
Let me know how you get on
I'll have a look at it, thank you!
nimble hamlet
Hi, I'm new to Rust & I'm trying to implement "canceling action when 2 btns pressed at the same time" for 2D game to two HE keybrd using wooting-sdk 0.1.1.
wooting-sdk: 0.1.1: https://crates.io/crates/wooting-sdk
Sample code below.
"analog::read_analog_keys": https://docs.rs/wooting-sdk/latest/wooting_sdk/analog/fn.read_analog_keys.html
BUT I've gottten an err 'Tracking issue for RFC 2289, "Associated type bounds"'.
https://github.com/rust-lang/rust/issues/52662
Is it possible to implement it using this crate? OR using analog SDK directry(NOT API) is better than above?
Please give me some advices or hints.
quiet root
Hi, I'm new to Rust & I'm trying to implement "canceling action when 2 btns pres...
without knowing ur code this is hard to diagnose
also unsure why this requires the analog sdk
this is smth ud implement using normal hid stuff
bitter jewel
Hi, I'm new to Rust & I'm trying to implement "canceling action when 2 btns pres...
Is there a reason why you're trying to use this version? The documentation for this crate says it supports Wooting One and Two (as it is over 2 years old), while you're trying to use it for HE.
If you look at the question I posed before you, you'll see a link to both an up to date WIP Rust wrapper to depend on + and example of it being used, if you wish to try to make an publishable crate however, I think you'll have to use the C FFI, since github dependencies are not allowed for that.
quiet root
Hi, I'm new to Rust & I'm trying to implement "canceling action when 2 btns pres...
rust wrapper by the guy who makes the sdk
nimble hamlet
Is there a reason why you're trying to use this version? The documentation for t...
@quiet root Thank you for your replies! What I'm looking at and using are different in the first place. My bad.
Please Let me get straight what I wanna do.
- to implement "canceling action when 2 btns pressed at the same time (Simultaneous Opposite Cardinal Direction Cleaner)" for 2D games (ex: Street Fighter 5).
- 2D games are worked on Steam, Xbox, PlayStation etc; first of all Steam.
- I understand that it does work in some games, doesn't work in some.
- I wanna play 2D games with HE keybrd that having 1. function.
ENVIRONMENT
- windows 11 Pro ver. 21H2
- rust: 1.61.0
- rustc: 1.61.0
- cargo: 1.61.0
- rsutup: 1.24.3
- LLVM: 14.0.5
What I've done so far is:
- Clone WootingKb/wooting-analog-sdk
- Follow the Installing part of analog-sdk repo.
- Installing wooting_analog_sdk-0.7.1-x86_64.msi: https://github.com/WootingKb/wooting-analog-sdk/releases/tag/v0.7.1
- WOOTING ANALOG SDK GUIDE
- Plugin Requirements: https://dev.wooting.io/wooting-analog-sdk-guide/plugins-overview/
- Tried using wooting-analog-wrapper, got Errors...
- I'll try fix them later.
Moreover I still have some questions like below.
- Is it possible to write the firmware? QMK has QMK-toolbox to do it. https://docs.qmk.fm/#/newbs_flashing?id=flashing-your-keyboard-with-qmk-toolbox
- If wooting-sdk has the same features as QMK, how to do it? OR there is need other tools?
quiet root
is this for your own game
or what
if a game already has it u dont need to implement it
theres nothing to implement then
quiet root
<@130036426912825344> Thank you for your replies! What I'm looking at and using ...
wootings firmware isnt qmk based at all
its completely custom
the analog sdk is meant for gamedevelopers and software devs to make software that supports the keyboards out of the box
or if the games have plugin systems that can go deep enough to add it via plugins
also unsure why rust was chosen
this would prob be easier in AHK or smth
or c#
nimble hamlet
Thank you for your reply. Is there any software or tools similar to "QMK-toolbox"? Note: QMK-toolbox is a tool to modify QMK firmware.
quiet root
no
the firmware isnt modifyable outside of wootility
also still convinced youre going about youre issue the wrong way
the analog sdk doesnt give u info about if the key is actually pressed as in HID code has been send
it literally reads the raw analog values
nothing else
also remapping the keys breaks the analog sdk
like i dont wanna hate on the project but i feel like youre either misunderstanding something or not fully understanding something
nimble hamlet
no
Thanks for your reply!
It is too hard to understand for me without basics knowledge both hardware and Compiler language in this field that is involved hardware for now.
I'll try it again about 5 laps of my life. lol
quiet root
na its ok
maybe start by explaining what you think should happen
and also mention if the game already has this function or not
as far as i understood you want to add this to games that dont have this function
or do you just want to do this in a game that already has it but do it with 1 button
nimble hamlet
na its ok
With QMK, it has achieved what I want to do (to be exact, what the client wants to do).
But I can't give you any more details.
I asked my client to comment on the details directry on this cannel, so I would be grateful if you could read any comments and reply them!
Anyway, thanks A LOT!!!
quiet root
u can do this for any keyboard by just using ahk or c# and then just hooking into the OS key events
replacing the presses with smth else
so if for example x is pressed it stops that and sends a/d for example
or w/s
ahk is prob the simpler option tho
as its main purpose is hotkey programming
if the goal is to just do this on the keyboard itself you could always use the DKS function
bitter jewel
I'd also keep the latency of whatever solutions you are considering in mind, it may be relevant for mechanics requiring very precise input
nocturne jackal
Those xpad changes are merged!
Next stop, kernel
I'll be watching the mailing list
hybrid lake
Those xpad changes are merged!
Awesome, thanks for pushing this
timid python
super nerdy question: anyone know what ARM chip is being used in the ARM 60HEs?
timid python
Awesome, thanks for pushing this
just read about the small issues you guys had; assuming the ARM chip is in the STM32 family (which seems likely) ST actually has a really thorough white paper on mitigating the issues I think you were seeing. Having worked with those myself for analog data capture, I can say it's very helpful.
timid python
they prob wont tell us till its out
That would be kinda surprising; that sort of spec info is pretty typically known for most keyboards (for those who bother looking, granted, which may just be weirdos like me) 🙂
quiet root
i dont recall them really stating what AVR mcu they used until the w1 came out and reviews just read it of the chip
timid python
I googled for a random example of kbs publishing this stuff, first one I found was this -- for whatever weird reason, brands will use the chipset as marketing fodder, for like the 3 of us that actually care lol https://www.facebook.com/117547488320354/photos/ducky-shine-3-is-powered-by-32-bit-arm-cortex-m3-microcontroller-holtek-ht32f175/540554736019625/
timid python
oh, it happens a lot... and nobody cares lol
I liked that this was the first example I found
didn't even have to try hard to find an example of a marketing dept that was SUPER PROUD of the info... and they got a whopping twelve comments out of it lolol
hybrid lake
super nerdy question: anyone know *what* ARM chip is being used in the ARM 60HEs...
GD32F303 (stm “clone”)
Have also seen the MCU marketing that nobody cares about lol
Its not a real clone, its a unique design but its based on stm32
timid python
I'm a little hazy on the Giga devices, but from the pn I'm guessing based off of the L4/L4+ STM32s?
timid python
yes, the M4 cortex is an L4 chip
edit to stick to the strict atmega pns so I don't get but-actually-ed... too much 😉
oh, nope, I'm wrong! Just looked it up, they're not L4s, they're MP15xs... man, I'm all messed up wrt pns.
Doesn't matter, applies for all of them -- as long as they're STM32 family (or design based on such), the white paper will likely be a help. @hybrid lake lmk if you want me to track it down, I'm sure the link is on my dev laptop, I can pm it to you in an hour and a half or so after close of business here.
May not end up touching on the issues you found, and it sounds like they're resolved already anyway, but may not hurt to check it out regardless.
quiet root
stm32f303 seems to be the base of the gd32f303
just some more ram and flash basically
timid python
okay, that makes a lot more sense 🙂 M3 chip
timid python
303 would be an M4
quiet root
couldnt find an exact match but both are m4
timid python
both should be way more than adequate for this, ofc
quiet root
the gd jeroen mentioned is m4 btw
timid python
I know the M3 better than the M4 tbh; pretty sure that's a 12-bit ADC, the M4 may have 12 or 16 -- don't know
timid python
right, if it's based off the Atmel F303 it's the M4 like I said
timid python
riiight
you rather I say ST? 🙂
3x12bit -- those are nice ADCs, I recall now. It is indeed actually 3 of them, and they can run in parallel.
quiet root
im unsure if st is owned by atmel
timid python
Kinda fun. Can do supersampling and other neat stuff w/them.
quiet root
i thought st was a standalone company
timid python
other way around, iirc
though don't quote me on it, those mergers were all a huge mess.
quiet root
atmel was apparently wholesale bought by microchip technology inc
explains why ive seen the logo a bunch lol
timid python
I think microchip bought atmel, and then ST bought the portion of microchip that had the atmel IP?
oh, you posted that just now, my bad lol
quiet root
ya no worries but ya mcu business is ugly
imagine nvidia would have gotten arm
lol
anyway ya its stm32f303 based
slightly slower clock it seems but more flash and sram available
and iirc the avr models ALL use the ATXmega128A4U
just checked yes
so we can only go up
timid python
I imagine clock won't be as important for them as ADC sample rate is, and multiplexed 2.6Msps is pretty chonky 🙂
I probably shouldn't use the term multiplexed here -- doesn't mean the same thing as it would prob mean to your typical kb person... :/
quiet root
well clock is important for the rest of the features the keyboard does
and flash being at least twice that of the avr models means more firmware space potentially
timid python
certainly, yes
quiet root
same for the SRAM increasing massively
timid python
I mean, it's important across the board too, can't just capture the data, have to store and process it too 🙂
huh, does the Xmega line use SRAM?
timid python
na just process it and overwrite
you kid, but even if you did that you still need a lot of proc power -- you're processing a lot of info all at once!
quiet root
dont recall the exact specs of the xemega used but im sure the arm easily handles it aswell
timid python
oh, I'm sure - two very different classes of processors there 🙂
quiet root
oh ya for sure
hybrid lake
Doesn't matter, applies for all of them -- as long as they're STM32 family (or d...
Appreciate it, yeah I would be interested. Its bed time here, but I’ll check it out tomorrow. Thanks!
timid python
sounds good, 'night!
coral portal
GD32F303 (stm “clone”)
Pog we finally know
nocturne jackal
Would you guys mind if I (publicly) repackaged Wootility as a Flatpak? It's currently the only AppImage on my machine and getting it integrate well into GNOME requires 3rd party software. Would do it as a simple script to download the official AppImage and then convert it so there's no funny business or out of date releases
(And I'll probably only do it when v4 supports all keebs anyway)
tacit holly
Based on scrollback sharing open source projects here is fine, so... Got my 60HE last weekend, but Wootility didn't seem to have profile switching based on focused application so made a little thing for that: https://github.com/Atte/woot. Only tested 60HE on Windows, but theoretically should work on all Lekker boards on all major OSs.
quiet root
there technically is https://github.com/ShayBox/WootingProfileSwitcher
balmy iron
Yeah but that's disgusting C! Rust makes everything better!
quiet root
Based on scrollback sharing open source projects here is fine, so... Got my 60HE...
also why dont u use the official sdk repo for the rgb sdk
its in rust
you can just add that and use it
tacit holly
To me all the SDKs seemed like C libraries with Rust bindings, may have missed something.
quiet root
the analog sdk is c
pure c
but simon the rust horny boi wants to remake it someday in 20yrs
and rgb sdk is pure rust
with c bindings
or did i mix them up now
oh boi
ya i switched em round
analog is rust with c bindings
rgb is c
id still recommend
free support for all wootings
tacit holly
If the analog SDK has a public interface for sending raw commands, yeah that would probably be a good idea.
obtuse crest
I don't know if it exists, but is there a functionality, where you can use the analog feedback to -let's say- decrease or increase the brush size in photoshop for example? (asked in wootility_feedback and directed here)
quiet root
ud prob need to make a photoshop plugin for that
also unsure how u imagine that working tbh
obtuse crest
one shortcut key combination for activating brush size decrease (like alt shift s) and then when you start pressing space bar or sth else it would start decreasing in size and if you put a bit up then increase
and the other way around for size increase
I don't know if that's the same, but thinking mx master logitech software where it recognizes the open app and changes the functionality of the side wheel and buttons, it can be a nice software addon, you can even use wooting like a da vinci resolve panel 😄
might not be as convenient as I think but, it feels like it would be a great tool for editors, music producers and so on. you can click fn + shift + 1 in ableton to change volume of track 1, doing live mixing analog on your keyboard 😄
quiet root
well the volume thing has been thought of an someone made it for windows volume
but
my personal opinion is its boderline useable on the 4mm you get
real mixing hardware or the software is way better
its basically almost as impractical as controlling brushsize by pressing on your graphics tablet with your pen
thats why they have those organic flow brushes
obtuse crest
yeah, it might not worth the effort, but I would have definitely tried and implement it in my workflow if existed...
quiet root
if you scroll enough you could find the volume control thingy
you could get a feel for such style of controls with that
obtuse crest
you could get a feel for such style of controls with that
first, wooting 60he arm version should be produced 😄
deft pendant
so i bought the arm version whats better about it
quiet root
nothing as of now and until 2024
it has double the advamced key slots which is very subjectively better
obtuse crest
if you scroll enough you could find the volume control thingy
I looked for it a bit searching stuff like <volume control> but couldn't find it... Is it something implemented in wootility?
quiet root
no
its a specially made tool by a community member
unsure if they also later removed it or used volume control in that specific case to describe it
grizzled wolf
Hello everyone,
I have read the FAQ but didn’t find what I need to know.
This might sound a little paranoid, but since the Software/Firmware on the Keyboard is accessible directly via Browser. Are there precautions in place to assure that no one from external can access and alter my keyboard memory? Especially not inject a virus/key logger into my ROM?
quiet root
that could happen on any keyboard
grizzled wolf
true
quiet root
most modern keyboards have patchable firmware
also way easier to put a keylogger onto your os
also the wrong channel as this is the community dev channel
grizzled wolf
So, is that a "no" then, or don't you know exactly?
I was thinking that "dev" stands for "developers" and that they might know such things. What channel would be the right one?
quiet root
yes
but this isnt wooting devs
just people from the community who developed smth using the rgb and or analog sdk
but it can happen and idk how you would prevent it except making it unpatchable
aka having a ROM
grizzled wolf
I don’t intend to start a discussion. But there are ways to protect your devices from unwanted external access, or at least make it harder for an attacker to gain access. An open HTTP Port :80 that listens to just any browser is pretty much an open invite for malware though. (Assuming that it is open, since I don’t have the keyboard yet and can’t tell for sure how it communicates, hence my initial question 😊)
quiet root
its not http
the data is basically send via serial coms
and you have to flash an entire firmware image
yes one could implement firmware signing in the bootloader but even that got defeated in the past and oresent on higher profile devices than the wooting
grizzled wolf
Thank you for the info so far.
I just have to disagree on the “if you can’t make it 100% secure it’s not worth trying” attitude. (no offence)
quiet root
well the thing is other manufacturers dont try either since its a non target basically
the only keyboards this would be worth trying to do it on is qmk keyboards
as the firmware is entirely opensource
on every other keyboard the effort to code a logger into the firmware (which wouldnt even be able to log much into the sram as its stuffed as is) and also code an interface that is exposed to the pc to have software on the pc that reads out the data from the keyboard
at that point you can just make a normal software keylogger and infect everyone instead of that 1 specific keyboard
i mean do you wrap you car keys in tinfoil and build antennas onto it to only send waves in a specific direction in case someone tries to steal the auth data on those?
grizzled wolf
i mean do you wrap you car keys in tinfoil and build antennas onto it to only se...
you don't?
quiet root
well in any case as long as windows and linux are both easy to abuse targets the firmware is the least worry
quiet root
Thank you for the info so far.
I just have to disagree on the “if you can’t mak...
no offence taken dw
and maybe one could argue that no verification of the firmware is a plus as technically everyone could write firmware for the kbd
so it never really becomes ancient firmware trash if someone really wants to make new firmware for it
grizzled wolf
I didn’t mean to start a general discussion about IT-Security. I was just asking if there are some security measures implemented, to at least ensure that no one else, except of me, is able to access the ROM on my keyboard and inject some malware behind my back.
I am perfectly aware that there is no 100% guarantee. Especially If you allow the user to update their firmware themselves and exchange all kind of profiles they created.
But, especially since the new Wootillity can access my keyboard via browser, without an installation of any Software. I am wondering how the keyboard knows it is me, who is accessing it.
I imagine that setting up a password might be a good idea, like you do for your Router e. g.
golden dust
A very easy idea is: just have a password on your device and internet.
And lock the door of your house
The average website isnt gonna inject anything, so avoid shady websites, and it should be pretty secure
Also: firewalls. That said, assuming there is no way to have 1 firmware fit every kb on the market, there is very little profit in even attempting that, unless it is targeted at you
obtuse crest
use chromium for just keyboard settings and another browser for everything else
golden dust
Why chromium?
quiet root
cause the wevhid standard is only part of googles chromium stuff
as they didnt make a real standard
its a pseudo standard and webhid itself has no real security features
its why mozilla wont implement it
quiet root
I didn’t mean to start a general discussion about IT-Security. I was just asking...
except most those are directly connected to the www
not through your OS to an already third party software that then makes your OS send packets to your router etc
in anyway making a keylogger out of a keyboard will require software that can get the data from the keyboard anyway thus its a so obscure target that i wouldnt imagine it ever being actually used to hack someone
quiet root
I didn’t mean to start a general discussion about IT-Security. I was just asking...
it knows its you cause you give your browser access
also still not a ROM
a ROM would make this keyboard secure from any firmware modification be it good willed or malicious
anyway as far as i know theres no checking as i highly doubt anyone who wants to steal passwords would go the route to reverse engineer the keyboard and how the mcu talks to the multiplexers and all that nor would they reverse engineer the compiled firmware as the attack surface is literally just users with 1 type of keyboard and the chance of attacking a user sith that device is so low the effort would effectively be void
btw wooting firmware is specific to a device type and layout
so iso twohe is a different fw than ansi twohe
and both differ from all other kbds aswell
the main reason why routers and IoT devices are a target is cause most run some flavor of linux
so the attack surface is infinitely bigger than on a given keyboard
tl;dr i understand the concern, theres no additional checks, why? the attack vector is a very high skill attack and a nano attack surface compared to anything else in your home or installed on your pc
sorry that i rambled on so much
golden dust
cause the wevhid standard is only part of googles chromium stuff
Ah, i understood it as chromium the browser, not chromium the engine, or at least i believe there was a browser named chromium, could be totally mistaken
quiet root
there is
and edge and chrome are chromium based browser
aka modifications of the chromium sourcecode
the js engine that enables this is v8
(not a version but its literally called v8 for the uninitiated)
golden dust
Yeah, i just thought the specific browser was meant and not the sourcecode and its modifications, which is why i was a bit confused.
quiet root
ah ya i see that
but generally any chromium based browser above version 89 can do webhid
and until google finally decides to work with mozilla or someone else on making an actuak thought out standard with security in mind we wont get it in another browser
quiet root
u know
i just realized a website is a way easier keylogger than anything
since they get key events
so making malicious ads is the probably easiest way to steal data
placid ledge
yeah, but websites will only get it while the page is in focus
whereas software running straight on the OS can generally get key events in the background
but it would really depend on what the target is
quiet root
@placid ledge have u thought about firmware signing?
i personally dont see a need to but i guess the question is warranted
placid ledge
Hmmm, it's not something I've really thought about yet. I would imagine that to implement it, it would need to be something implemented into the bootloader, so you wouldn't be able to add it retroactively. The attack vector there feels quite narrow, my understanding is that generally firmware signing is used by manufacturers to protect their firmware as well as to prevent users from putting their own firmware and unlocking limitations they've put in there (although it really depends on the device, like with phones a big reason is to make it harder for someone to steal your device and wipe it and re-sell it).
When it comes to our keyboard firmware, it would be quite hard to pull off. In terms of if someone wanted to put their own/edited firmware onto your keyboard without you noticing that would be quite hard. They'd have to trick you to get you to update the firmware on some other site (where you have to explicitly give them permission to interact with your device) or through some desktop software, even then you'd probably notice it happening on your keyboard as you'd see it turn off and such as it was doing it (so if you're worried about it at all you'd defo notice). Otherwise they'd have to do it with physical access to the device, i.e. targeting you specifically, in which case they'd likely have access to many other of your devices which would have better attack surfaces. Even then I don't think the firmware itself would be able to send much keylogging information e.g. over the internet, as all it can expose is USB interfaces, so you'd likely need some additional software or driver running on your PC as well for them to do anything like that (at which point why wouldn't they just do a software keylogger). And if they have physical access to your stuff then you're probably already screwed with all the way better attack vectors they'd have there
And that's not even talking about the challenge of them even being able to inject some custom stuff into the firmware. There's pretty much no way they'd be able to build their own firmware from scratch as they'd pretty much have to re-implement every single feature we have to ensure you don't immediately notice something wrong. So in that case it would come down to injecting some code into the firmware binary, which isn't unheard of, but would be very involved to actually do anything in the realm of something like a keylogger (see above paragraph), (just came to mind) they'd also have to deal with the same limitations, good luck trying to implement any significant attack in the amount of memory we have left on the chip without removing any features 😛
Some of my thoughts off the top of my head 😄
quiet root
oh on the topic of firmware
why doesnt the firmware reset try to get the wooting into update mode before it relies on the user putting it into recovery
and side question is rgb sdk backwards compatibility important for multidevice implementation
placid ledge
Oh, why doesn't the restore process attempt to automatically put it in update mode? Good point, I remember seeing someone else mention that lately, I think why it wasn't added before was due to the restore process being more intended for when something is seriously wrong (i.e. where it isn't able to be used properly in Wootility). But there's no reason we couldn't add it, it's a good one, you could open it as an issue on wootility-issues if you want
quiet root
i will
its just nice since sometimes people wanna do a restore with a basically functioning board
placid ledge
and side question is rgb sdk backwards compatibility important for multidevice i...
You mean still supporting v1 interface for current flaretech firmware? I would say that it it would be nice to have, but not a hard requirement as we really want to bring flaretech keyboards up to v2 firmware as soon as we have the time for it
placid ledge
its just nice since sometimes people wanna do a restore with a basically functio...
Yeah, the usage of the restore flow has expanded a decent bit so would defo be nice to put in there
quiet root
You mean still supporting v1 interface for current flaretech firmware? I would s...
no not breaking the functions by modifying their arguments
i have thought about it a lot and basically we could just add a few functions to select an attached keyboard and leave the functions for setting the rgb as they are
placid ledge
Ohhhh
quiet root
this would mean it would be completely backwards compatible and also support multiple keyboards if wnated
placid ledge
Yeah, I'd say that ideally having the same set of exported functions available would be great, then just adding on the additional ones for multi device selection would be perfect. It would mean that if we have the multi device changes as the base for future changes and we're adding support for a new board on that, then we'd still have the option to use it as a drop-in replacement for software that hasn't been updated in a while
quiet root
the main issue would just be no multithreaded ability
since the other approach that would make it easier to multithread and really push data is handing the device pointer to functions
but i doubt someone will have 10wootings and do some display style thing with them
or that it would really matter
balmy iron
What you're not going to plug in all your woots and do some stylish things with them?!
quiet root
i mean
i did think about using 4 wooting twos and doing smth with it
like some sort of game or smth
but i doubt its unresponsive or laggy even if i set them one after another
rn i can smash my single w2 with over 200fps
placid ledge
tbf, the idea of a wall of wootings with synced rgb has crossed my mind before 😛
quiet root
u know what
ill work on the device select thing
and maybe make a demo
and then PR
placid ledge
I think the bigger issue you'd run into with multithreading is HIDAPI lib not having multithread support
quiet root
so i can be the first
placid ledge
mamma mia
quiet root
lol
placid ledge
😂
quiet root
I think the bigger issue you'd run into with multithreading is HIDAPI lib not ha...
oh?
i thought it had multithreading
well
then i wont have to further think about it
ill just add a select function
and modify detection a bit
placid ledge
Well, I think more specifically you can only have one hidapi instance and you can't share it across threads really IIRC, although I have been able to get away with some stuff with the rust wrapper
placid ledge
Not entirely sure what the exact limitations are, but it wouldn't be easy to get it working well 😛 so yeah, better focus on non-multithreading first
quiet root
ya my goal now is multidevice in general
and maybe ill regather my rust braincells and do a new rgb wrapper cleanslate
at which point both sdks would be in rust and simon could die happily
placid ledge
rust gang 😏
quiet root
crab gang u mean
placid ledge
🦀
quiet root
ferris or whatever its called
placid ledge
ferris sounds about right
quiet root
anyway will pr the next few days when its also torture tested by artemis
strong siren
tbf, the idea of a wall of wootings with synced rgb has crossed my mind before �...
I wonder if this is doable with openrgb + artemis
I've done it with 3 diff keyboards before
late scarab
Is there a way, using the SDK, to retrieve the moment in which Rapid Trigger deactivates (key turns into red) and then write only one bind when that event happens ? @placid ledge
Kind of like DKS but instead of fixed 1.5. mm release, using the deactivation point of Rapid Trigger
Some games may benefit from it, like Valorant.
Whenever Rapid Trigger deactivates, i want to send the opposite input of movement key for counter strafing
golden dust
Careful with that, that might qualify as macro and be bannable
late scarab
Like: A... Deactivates RT... send D
late scarab
Careful with that, that might qualify as macro and be bannable
Kind of, but since you are the one who is unpressing the key, it will not be a fixed timer, so it is less prone to be detected
Nevertheless, it would be a nice integration between DKS and Rapid Trigger
golden dust
Kind of, but since you are the one who is unpressing the key, it will not be a f...
Considering it would be on a fixed timer relative to the release point, it would be rather easy to detect, if their macro detection is any good.
But either way, your risk
placid ledge
Hmmmm, that's an interesting idea. The SDK won't be able to give you the exact event but you would be able to implement the same logic and activate it that way. Although, it is something that I would be able to fairly easily implement firmware side if it was good enough to be worthwhile to include.
On the macro question, I would say that it would be quite detectable in terms of auto macro detection. But when it comes to if it should be considered a macro that would be more up in the air for me, as generally stuff like particular DKS configurations can be considered as not macros due to you having to do a particular movement to trigger an action, in this instance I'm not sure if it would be considered a macro or not
late scarab
Ok i will investigate myself on the SDK. where can i request that feature firmware side ?
late scarab
https://github.com/WootingKb/wootility-issues/compare/master...Aremian:wootility-issues:patch-1 there i created the request feature @placid ledge
placid ledge
https://github.com/WootingKb/wootility-issues/compare/master...Aremian:wootility...
You should create a new issue, what you changed is the templates for issues
late scarab
You should create a new issue, what you changed is the templates for issues
My bad. Done.
placid ledge
No worries