[SOLVED] Trying to acess the onboard memory of a gaming mouse

83Gibbo · 01-09-2014, 05:36 AM

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

Pearlseattle · 01-09-2014, 03:06 PM

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

83Gibbo · 01-09-2014, 05:58 PM

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.

Pearlseattle · 01-09-2014, 06:25 PM

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/
total 0
drwxr-xr-x 2 root root    100 Jan  9 21:53 by-path
crw-r----- 1 root root 13, 64 Jan  9 22:29 event0
crw-r----- 1 root root 13, 65 Jan  9 22:29 event1
crw-r----- 1 root root 13, 66 Jan  9 22:29 event2
crw-r----- 1 root root 13, 67 Jan  9 22:29 event3
crw-r----- 1 root root 13, 68 Jan  9 22:29 event4
crw-r----- 1 root root 13, 69 Jan  9 22:29 event5
crw-r----- 1 root root 13, 70 Jan  9 22:29 event6
crw-r----- 1 root root 13, 71 Jan  9 22:29 event7
crw-r----- 1 root root 13, 72 Jan  9 22:29 event8
crw-r----- 1 root root 13, 73 Jan  9 22:29 event9
crw-r----- 1 root root 13, 63 Jan  9 22:29 mice
crw-r----- 1 root root 13, 32 Jan  9 22:29 mouse0

...and after plugging it in you see...

Code:

ls -lh /dev/input/
total 0
drwxr-xr-x 2 root root    100 Jan  9 21:53 by-path
crw-r----- 1 root root 13, 64 Jan  9 22:29 event0
crw-r----- 1 root root 13, 65 Jan  9 22:29 event1
crw-r----- 1 root root 13, 74 Jan  9 22:30 event10
crw-r----- 1 root root 13, 66 Jan  9 22:29 event2
crw-r----- 1 root root 13, 67 Jan  9 22:29 event3
crw-r----- 1 root root 13, 68 Jan  9 22:29 event4
crw-r----- 1 root root 13, 69 Jan  9 22:29 event5
crw-r----- 1 root root 13, 70 Jan  9 22:29 event6
crw-r----- 1 root root 13, 71 Jan  9 22:29 event7
crw-r----- 1 root root 13, 72 Jan  9 22:29 event8
crw-r----- 1 root root 13, 73 Jan  9 22:29 event9
crw-r----- 1 root root 13, 63 Jan  9 22:29 mice
crw-r----- 1 root root 13, 32 Jan  9 22:29 mouse0

...then chances that it will work are good. If you see no change then forget it.

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

83Gibbo · 01-09-2014, 06:51 PM

When the mouse is plugged in there are 3 new 'eventX' files and one new 'mouseX'.

83Gibbo · 01-09-2014, 07:18 PM

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?

Pearlseattle · 01-11-2014, 09:54 AM

Hi

Thank you for checking.
1
===

Quote:

When the mouse is plugged in there are 3 new 'eventX' files and one new 'mouseX'.

Mmmhh, this could become a problem - so far I assumed that each single device listed by "lsusb" shows up as a single "/dev/input/eventX"-entry (a 1:1 mapping).
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
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 138a:003f Validity Sensors, Inc.

After having plugged it in:

Code:

 lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 003: ID 046d:c510 Logitech, Inc. Cordless Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 138a:003f Validity Sensors, Inc.

2
===

Quote:

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'.

You're right - this might be a worst-case-scenario for you.
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?

Open 3 "root" command shells (so that at least for the tests we don't have to worry about privileges) and in all of them go to your "/dev/input" directory.
Plug in your mouse and in every single console do a "cat eventX" where eventX is one of the 3 eventX that show up when you plug in your mouse.
At the begin the "cat eventX" will just hang there and do nothing but then press your mouse buttons and see if for every single button (even the ones that are not programmed) you see in one of the 3 consoles some weird characters showing up

If you don't see anything showing up then your mouse really does fully disable the buttons which are not programmed

and that's on hardware level and in that case we're back to your original question.

3
===

Quote:

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?

Maybe - not sure if I understood correctly the question.
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

83Gibbo · 01-13-2014, 04:11 AM

When the mouse is plugged in lsusb only shows one new entry

Code:

lsusb
Bus 002 Device 002: ID 1038:1320 Ideazon, Inc.

Assuming the new eventX files in /dev/input/ are event0, event1, event2 and mouse0.

Code:

cat /dev/input/eventX

event0 registers mouse movement and 'normal' button clicks
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

zhjim · 01-13-2014, 07:00 AM

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.

83Gibbo · 01-14-2014, 01:16 PM

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.

Pearlseattle · 01-14-2014, 04:37 PM

You're welcome!

But I'm still sorry that it did not work...

What you wrote...

Quote:

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.

...would probably be absolutely fantastic - never thought about doing anything like that - it would be great if you would manage to somehow get the raw stream of binary data that goes from your mouse-utility to the mouse when you save your programmed settings, even if at first you'll have no clue what that data means. Did I understand correctly that you already manage to do it?

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
do nothing for button 1

2)

Code:

do "u" for button 1
do "ui" for button 1

3)

Code:

do "j" for button 1
do "p" for button 1

4)

Code:

do nothing for button 1 and do "c" for button 2
do "f" for button 1 and do nothing for button 2

...by comparing the "sniff"s you might easily be able to see what are the parts that give commands...
(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

...and see if then (on event1?) the commands react as you told it to do (just a wild guess - as event2 never seemed to do anything it might be some kind of weird interface ready to accept inbound data to be used to program the mouse?) - could most probably be easily tested with case #1.

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).

83Gibbo · 01-14-2014, 06:08 PM

Quote:

Did I understand correctly that you already manage to do it?

Using a second, 'standard' mouse and leaving the Steel Series mouse plugged in but idle I isolated just the data sent to the Steel Series mouse when I click 'Save On-Board' in the Steel Series Mouse Application. I found it hard to explain what I get so thought if I uploaded the screen shots it would be easier.

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:

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

'event1' already works as a mouse/keyboard in that anything the Windows program assigns to the unusual buttons is output in Linux the same as if I hit that key on the standard keyboard. The issue is I want to be able to program the mouse in Linux without needing Windows at all and also the keybindings in the Steel Series application are very limited and I was hoping to be able to keybind anything.

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.

Drakeo · 01-14-2014, 06:25 PM

here is a nice article on using all the buttons in the X11
http://unix.stackexchange.com/questi...-in-xorg-gnome

83Gibbo · 01-15-2014, 05:25 PM

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.

83Gibbo · 01-16-2014, 02:03 AM

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