Open mjtorn opened 8 years ago
Was looking around for a solution to rebind a couple of keys on my Orbweaver and SteamOS.
That's fine, as long as the key rebinding happens in the hardware. (So the hw needs support for that). Rebinding in Linux is not razercfg's job.
This project looks very fine, but I'm a bit worried about being limited to mice only.
Well, it actually isn't. The design does support adding non-mice devices. Currently there are only mice, though. So there is a lot of missing stuff for other devices, even in the generic parts. But the design is not restricted to mice. (That's why it's called razercfg instead of razermousecfg).
What would this type of project entail?
Yes, as long as it's only about reconfiguring the hardware (I don't know that piece of hardware). If you want generic key rebinding, the dozens of already existing tools should be fixed.
@mbuesch thanks!
Can you please take a look at this? https://gist.github.com/mjtorn/1cd64c501f278c6e4c32
I'll probably delete it later this year or sometime, but before that, I could use some help reading it.
I doubt it's any good news, though, because Keyboarding Master appears to use java.awt.Robot to fake the user input based on a keymap. I was hoping this to be a workaround for not knowing the wire protocol for configuring the Orbweaver and leveraging instead on its HID keyboard defaults.
Probably that's not it. Going the virtualbox+usbmon route, the bursts of output in usbmon did not correspond to my actions in VirtualBox/Synapse. Nor do I get the re-bound keys in Linux after I released the Orbweaver from VirtualBox's clutches. :(
But I'd still really appreciate a second opinion on that capture.
PS. Like I said, this is for SteamOS (on a Steam Machine), so I'd like to keep the "hacker crap" (like xmodmap in a terminal) down to a minimum and prefer apps like razercfg that are clean and integrate well enough. Just to gauge if this could be The Year of the Linux Desktop (and/or Linux Gaming Console) for more average users.
Cheers!
But I'd still really appreciate a second opinion on that capture.
is there any chance you could create a wirshark .pcap file? That would be way easier to read.
Like I said, this is for SteamOS (on a Steam Machine), so I'd like to keep the "hacker crap" (like xmodmap in a terminal) down to a minimum and prefer apps like razercfg that are clean and integrate well enough.
Yeah, well. I agree. But I don't think that doing yet another way to remap keys and that software being specific to Razer devices will help anything.
I'd also finally like to see some sane key remapping tool with a graphical user interface (either by fixing an existing tool, or by creating a new one). But I don't think that this should be integrated into razercfg, because that would be yet another tool only usable by a very tiny minority of the users (razer hardware owners). So we would not really improve the overall situation a lot. What is needed is a device and environment (window manager, desktop environment) independent way to remap hid events.
razercfg is supposed to reconfigure Razer hardware. No more, no less. I think we need a very good reason to change that.
@z3ntu That would be great, even if it doesn't support all of the features. If it did one feature well, that would already be enough for starters. (disclaimer: I don't know how many or even which features that thing has)
@mbuesch Umm, I'll have to look at Wireshark. Not a huge fan of its usability, as it's one of those programs I need to touch every other year or so and have zero routine in using and up until today didn't even know it can sniff USB :)
The problem with keymaps is that I wouldn't even know where to start, except maybe xmodmap. I remapped a couple of keys on my Kinesis Advantage on the hardware level because there's not a single one standard for this. A graphical UI for an app that just translates keycodes into other keycodes would be visual aid only to configure a hidapi-based daemon, and any kind of keyboard or keypad could be drawn into it. Which should satisfy most users.
Be that all as it may, I started looking into creating something like that, something that could pass the events onwards, but I'm having a bit of a hard time with lag/response time and modifiers and how much C I've probably forgot over the years. But here anyway https://gist.github.com/mjtorn/da746153f5e04ef35b1e - at least it doesn't leak memory!
I'll have to look at Wireshark
It's probably not that useful, if I look at the dumps, because I don't know anything about that stuff either. So we could just skip that.
The problem with keymaps is that I wouldn't even know where to start
I don't know that either. But there obviously are two (three) possibilities: Handle it in X11 -> Doesn't work on wayland. Handle it in kernel (possibly with userspace aid).
I started looking into creating something like that
Great. So you're already way beyond the point where I could help. :)
It's probably not that useful, if I look at the dumps, because I don't know anything about that stuff either.
Myeah, I guess it takes a lot more of effort to figure out what the protocol exactly is, besides which all other signs (exposing the device to virtualbox and configuring it and then having it forget its confs) point to this being failure.
Great. So you're already way beyond the point where I could help. :)
I'm going down the X route - added XTestFakeKeyEvent(...)
calls already. I'm sure that if SteamOS goes Wayland they'll have a compatibility layer there or maybe I can revisit this code.
Next up, though maybe not today or maybe never, would be figuring out how the device gets connected and disconnected with libusb, and then a conf file, and then maybe even a GUI for generating the conf file (optionally with profiles and stuff like that).
Fortunately when I added the "pass this stuff to X" code I noticed that the severe lag I had was gone! It probably came from the nature of printf()
and flushing stdout and whatnot. The X events feel a lot faster to respond to changes in keys, though the repeat rate is just silly (as it should be for games, I guess.. we'll see..)
Wanna close this issue or should I?
Thanks!
Wanna close this issue or should I?
Well, if the device does turn out to have some kind of hardware support for this, this can be kept open. Because those bits should then go into razercfg. In any case, if you got something working, I would like to hear from it, so I can point razercfg users to it. This after all still is the most FAQ (even if it's not in the FAQs on the page).
Fortunately when I added the "pass this stuff to X" code I noticed that the severe lag I had was gone!
Linux with X11 already have a massive round trip to go to get a key stroke being translated. It involves interrupts, several processes and some IPC already. So adding another process/IPC probably wouldn't worsen the situation a lot.
I'm sure that if SteamOS goes Wayland they'll have a compatibility layer there or maybe I can revisit this code.
I'm not so sure on this. Wayland does I/O really differently from X11. Inputs are not passed to all clients (windows) any more. So this possibly needs another approach there. If this stuff is possible via kernel-HID only, I'd probably go down that route. But I'm not an expert on either.
Adding a need-info label until we figured out the hardware protocol.
Well, if the device does turn out to have some kind of hardware support for this, this can be kept open. Because those bits should then go into razercfg.
It actually does! It has support for changing the lighting between constantly lit (with different settings for brightness) and pulsating. The BS app for configuring under Windows has profiles, though, so I'm guessing these are stored in files and then pushed onto the hardware. Maybe I'll revisit getting a Wireshark dump on this. Later.
Verified this by changing it to pulsate in VirtualBox Windows and moving it to the Steam Machine where it continued pulsating.
Linux with X11 already have a massive round trip to go to get a key stroke being translated. It involves interrupts, several processes and some IPC already. So adding another process/IPC probably wouldn't worsen the situation a lot.
Well, with printf()
it did, but whatever, terminal I/O is abhorrent anyway. I called it a day yesterday at some point, because very essential and basic things any library should have weren't found. Like "key went down" and "key went up" and "these two keys are down" and then I got a severe headache trying to map the modifiers to anything non-modifier. So basically crouching and moving in Half-Life would not move.
I know someone pointed out on the internet about reading the event device, but afaik that passes the original events through, whereas I want to capture them. If anyone sees this and can confirm or deny, I'd love that ;)
Most likely I have to look into rawhid and see if I get better granularity on what's happening on the USB bus - and/or libusb either way.
Let's cross our fingers that there actually is some hardware config for the keys, though I'm still doubtful there's anything beside the light bling.
It has support for changing the lighting between constantly lit (with different settings for brightness) and pulsating.
Ok, very nice. This feature should go into razercfg eventually. I'd be happy to take patches/pull requests.
For the keypad, why not use setxkbmap -id
with a custom keymap?
@benoit-pierre let me quote myself from above
Like I said, this is for SteamOS (on a Steam Machine), so I'd like to keep the "hacker crap" (like xmodmap in a terminal) down to a minimum and prefer apps like razercfg that are clean and integrate well enough. Just to gauge if this could be The Year of the Linux Desktop (and/or Linux Gaming Console) for more average users.
Having said that, maybe a GUI program could generate the custom keymap and load it with setxkbmap; it would certainly keep the translation stuff out, though maintaining these files and all that might prove to be a hassle. Oh and also it would be more elegant for the code if it didn't shell out to execute anything but use the actual libraries.
I may have the opportunity to look into Wiresharking some USB traffic later this week and/or some day. Let's see if anyone beats me to it!
It's certainly more pragmatic, and run-time efficient, than adding a new layer of translation. Nothing wrong with calling another program rather than re-invent the wheel. Note that AFAIK xmodmap
does not allow changing the keymap of only one device, something that is possible with setxkbmap
. I think a possible alternative is to use the XKB extension to modify the keymap of said device. Right now, I use a small shell script with setxkmap
/xkbcomp
/razercfg
/... to configure inputs, but I agree that it can be cumbersome (although using X11 keymaps is really versatile: sticky modifiers, 3rd layer with keys that work in games too, ...). I'm currently working on adding support for several extensions, including XKB, to python-xlib
, something that I might use to replace all of this.
I think this can be of interest, it even have a folder with the wireshark info:
https://github.com/thatguystone/lintartarus
I can try to capture similar information for the Razer Nostromo to compare if it is common for all the keypads devices. Also Nostromo have a mousewheel not available on other Rezer keypads so that probably works with some the protocol of some of the mouses already supported.
Hi!
Was looking around for a solution to rebind a couple of keys on my Orbweaver and SteamOS. There's Keyboarding Master but it's practically impossible to build, hard as balls to package and annoying to run requiring manual interaction on startup. So I gave up on it.
This project looks very fine, but I'm a bit worried about being limited to mice only. Is anyone considering support for keybindings on keypads?
The use case is very real, as I don't always bother having a keyboard hooked up and some games like Saints Row IV actually require the
Esc
key (games by Valve understand the backtick key left of1
and certain others understand gamepads etc). Now if I want to get out of the game, I need to temporarily hook up a physical keyboard in there.What would this type of project entail?
Cheers!