Trying to acess the onboard memory of a gaming mouse
I have a Steel Series: World of Warcraft Cataclysm, gaming mouse that mostly works perfectly.
The Mouse has 14 buttons, the unusual ones can be programmed as macros or as several particular keystrokes in windows and if you save the settings to the on-board memory (an option in the software) they work perfectly in linux aswell. You can even back up your settings as an XML file make changes and import it back into software before saving it to the on-board memory My question is, how would I go about accessing the onboard memory in linux as far as I can tell there is no storage type device associated with the mouse when I use lsusb. My goal is worst case, being able to change the button bindings in linux and never boot Windows again. Best case being able to change the button bidings to any keystroke I like, the Windows based software only allows for a limited range of bindings, eg 'q' and 'e' for strafing but not '~' for say Push to Talk. I am currently using arch linux, running Openbox, the mouse driver is just evdev. I am not really sure where I should start to try and access the on-board memory. Any advice would be appreciated |
Hi
A mouse with 14 buttons? Incredible... . In order to be able to implement your approach you would probably have to be able to write a program in some language (C/C++) and discover how to "talk" to the memory controller of your mouse => quite difficult I think. What about installing "Wine" and trying to run your windows-mouse-configurator-utility in that (non-)emulator and see if when you try to save the settings the program or Wine does not crash and your mouse remembers whatever you saved? Otherwise, if nothing works and you get very desperate : I'm programming since a couple of weeks a utility that would be used to map "buttons" of (hopefully) any USB-device (joysticks, mouse, anything) to any sequence of programmable keystrokes and forward those "key-events" to whichever window is currently in focus - e.g. when you press button3 on your usb-controller the key-press events for the key "l" would be forwarded to whichever game/whatever you would be playing which has its windows focused, if you press button6 of the usb-controller the key-press events for the keys "xjfkw" (kind of macro) would be forwarded to the console/whatever currently in focus, etc... . All you would need to do is to configure in the game/application/whatever what the keys like "l", "x", "j", etc... would have to do. Non-key related events of the device(s) (e.g. when you actually move the mouse, the stick of the joystick or whatever...) would not be touched. Would something like this be interesting for you? Cheers :study: |
I am not a programmer by any stretch of the imagination but can manage a bit of python, I wrote a script that parses an Allen Bradley plc web server in my quarry and shows bin level information on a gtk window in our trucks as they drive around but am unlikely to pull off anything more complicated.
I tried getting the mouse software to work in wine, it runs but cannot detect nor write to the mouse, I assume due to the usb driver issues in wine. The program you are working on sounds like a great alternative and would do exactly what I am after, obviously just a different solution to the same problem. I would be very interested to see it. The mouse saves a few different variables to it's internal memory sensitivity and led colour but I have no real interest in changing these other than you would if you could. |
Ok!
I programmed something in Python only once - liked it, but in this case it might lack some high-level libs to make it possible to talk to the USB-device in a simple way. Concerning "my program", the only question if the program would work with your device is if when you do an "ls -lh /dev/input/" you do or don't see that an additional "event"-file pops up in your "/dev/input/" directory. E.g. if before plugging in your mouse you see for example... Code:
ls -lh /dev/input/ Code:
ls -lh /dev/input/ Asking this because I don't know myself how/why those file-based-interfaces show up. I decided to use them because so far they always showed up with the few devices I have to perform my tests but I don't know if it's just because of something I have in my system or if it's the general behaviour of USB-devices in Linux. So, do you see at least 1 new "eventX"-file showing up when you plug in your mouse-usb-receiver into your system? Cheers |
When the mouse is plugged in there are 3 new 'eventX' files and one new 'mouseX'.
|
In case it's relevant, when using 'xev' before saving a profile to the mouse on-board memory only the normal mouse buttons register at all.
After saving a profile to the on-board memory any button that was assigned to a function will register in 'xev'. One of the issues other than I am after a native solution is the functions are pretty limited and clash with normal keyboard keys. I assume your program looks for the button press itself and not the function assigned to it? |
Hi
Thank you for checking. 1 === Quote:
Just to doublecheck: you do get just a single new entry by lsusb after having plugged in the mouse, right? Example: Before plugging it in: Code:
lsusb Code:
lsusb 2 === Quote:
I can imagine that maybe your mouse just disables internally all buttons that don't have something assigned to it and that the mouse itself won't then generate any kind of event for them when they're pressed. Could you please test it?
3 === Quote:
What my program/utility would do is to open one of those "/dev/input/eventX" files and wait for them to generate some event. Such event is generated when a button on those devices is pressed or released => when that happens I get a sequence of bits (e.g. "00101001010...") where each bit is linked to one of the buttons of the device and shows its current state => by comparing what I got before (e.g. 00101) and now (e.g. 00100) I can understand which button has changed state and if it's now on/pressed or off/released => I then look up in a table what that specific button is supposed to do for that specific state, which in my case are always single or series of characters, which I then take and for each of them I generate a simulated keyboard key-press event for the window which the user has currently in focus. So, I just map the buttons to single or multiple characters which act as they were pressed using the keyboard. Cheers |
When the mouse is plugged in lsusb only shows one new entry
Code:
lsusb Code:
cat /dev/input/eventX event1 registers unusual buttons only if they were keybound in the windows program event2 registers nothing as far as I can tell mouse0 registers the same as event0 I assume this puts me back to square 1, I am really grateful for all your help. I had a bit of a look at pyusb and it looks promising although probably a bit out of my league, mainly becasue I am worried I will brick my mouse trying to write to it before I get promising results =D |
That could be intresting: https://wiki.archlinux.org/index.php...uttons_Working
Maybe this one: http://lifehacker.com/384698/btnx-cu...ouse-for-linux Else you need to get your self a device driver written. |
Thanks Zhjim I have tried both those before and a few similar methods, I think the problem lies in not having anything bound to the button presses in the first place so there is nothing for utilities like btnx, evrouter, easystroke etc to bind to.
I have looked further into pyusb which is essentially libusb for python and contacted the manufacturer 'Steel Series' for the USB protocol documentation (worth a try). Hoping to set the button bindings up at a hardware level, it might be the only way this'll work. Other than that I threw a USB sniffer tool on at work Installed the 'Steel Series' drivers and application on and took a screener of what happens when you tell the application to 'save to the on-board memory' hoping I can somehow emmulate it. |
You're welcome! :D
But I'm still sorry that it did not work... :mad: What you wrote... Quote:
Assuming that you would manage to get 8 pure raw binary "sniff"s/traces of what the windows utility ultimately transmits to the mouse when programming some very basic and similar macros/shortcuts like... 1) Code:
do "h" for button 1 Code:
do "u" for button 1 Code:
do "j" for button 1 Code:
do nothing for button 1 and do "c" for button 2 (which would look the same in both cases - exception would be if they tell the mouse the length of the command/macro but which you would catch with #3 vs. others as #3 would have all lengths/sizes set to the same size) ...and the ones related to what you want the mouse do (all the rest that does not look identical between the "sniff"s) => that would give you the base to easily be able to write your own program to program the mouse. Before doing and in-depth analysis of the above mentioned comparison you could first of all do a... Code:
cat <yourbinarysniff_1_or_2_or_3_or_etc...> > /dev/input/event2 If all this works then you'll have done in the worst case at least 1/3 of the work, which is the base part that decides about success or failure. In the best case you'll just configure in Xorg "/dev/input/event1" to be an additional mouse and you would have those macros available immediately (ok, you might have already done it - most probably I did not understand this part of your problem). :study: |
Quote:
https://drive.google.com/file/d/0B2K...it?usp=sharing https://drive.google.com/file/d/0B2K...it?usp=sharing https://drive.google.com/file/d/0B2K...it?usp=sharing https://drive.google.com/file/d/0B2K...it?usp=sharing 'Save On-Board' uploads a whole profile to the mouse including anything not assigned by the look which is what I assume the majority of the '00' portions are. Only guessing but maybe the first string of data sent is keybinds and the second is polling rates and LED colors etc.? Quote:
There are alot of people that have been trying to acheive this with this particular mouse but no-one has come up with anything yet. Your idea about 'event2' being an interaface waiting to accept inbound data sounds promising. I'll try sending the raw data to it, see what happens and post what I find. |
here is a nice article on using all the buttons in the X11
http://unix.stackexchange.com/questi...-in-xorg-gnome |
Thanks Drakeo, the problem isn't at that level, if you manage to assign key functions to the mouse buttons at a hardware level the X11 evdev driver works perfectly.
I can't seem to write anything to an eventX file at all, I tried a few different methods and got various errors. Instead I finally managed to bind some random keystrokes to some of the unusual buttons with a script I wrote in python that sends a similar data string to the mouse that the windows application does. It looks very promising so I'll try to isolate the various keybinds and get back later with how I go. |
I can now change any of the keybinds to any of the standard ones in the Windows Steel Series Utility and can see how to do everything else I was looking for.
Thanks everyone for your help especially Pearlseattle I'll throw up a link to the basic Python 3 Script that saves keybinds if anyone wanted a look, I assume it will work in Python 2 aswell there was nothing specific from memory. It requires libUSB and PyUSB libraries to run. It binds strafing to Buttons 4 + 5 and 'z' to Button 13 it is only for testing at this stage so won't make much sense. https://drive.google.com/file/d/0B2K...it?usp=sharing Marking the thread as solved, I'll keep going until I have a script that's easy to use and does everything then make it available for anyone else that uses this mouse in linux |
All times are GMT -5. The time now is 06:22 AM. |