-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing Tilt Button support in Razer Naga #44
Comments
Working patches are welcome. |
I have looked at this for my Razer Naga, and apparently it's not handled by the firmware: I did not see any USB calls when changing what tilting the scroll wheel left/right does with Synapse on Windows. So the handling must be done on the PC side. By default (and so on Linux), each tilt the wheel will generate scroll wheel events, with no way to configure it. And since tilt left/right don't act as specific buttons, remapping them with 'xinput set-button-map' is not possible. I guess Synapse filters those events based on time when changing the default actions. |
Yes, the naga does not have such a razer specific event. It emits standard HID messages. In fact, naga is not a synapse mouse (even if Razer claims that). The naga has its own proprietary protocol. |
OK. How do you remap those events with xinput? I did not find a way to do so last time I looked at it. |
Your favourite search engine brings up lots of answers on that topic. |
This does not use xinput. Just to be clear, from X point of view, there is not difference between scrolling up the wheel and tilting the scroll wheel left (I also get the same output with usbmon). Tilting continously generate scroll wheel events until release. So I can't filter solely based on button number (or I will change the behavior of the scroll wheel scroll up/down events). And again, I could not find a way to change the button mapping with xinput. |
Yes, well. However razercfg cannot do anything about that. If there's no way to remap certain HID events, you need to contact X and kernel HID people. The mouse events do not go through razercfg. So it cannot remap anything, even if it would want to. Thanks a lot for your contribution to razercfg. Closing this issue, because it's not really razercfg related. |
I know, that what I was saying all along. |
For note, I already started working on the protocol a few days ago, figure out a way to 'clear' the Tilt setting so it sends nothing, trying to figure out how to get it to send something else, I am thinking it remaps to the keyboard interface. Just need to figure out how to set it... Regardless though, this is not an X or kernel HID issue, this is something that has to be set on the naga itself, just need to figure out the protocol part of it... Any chance on re-opening as this is not an X or HID issue but rather a firmware naga configuration issue, which is, I think anyway, what razercfg is for? |
I am trying to get a hold of a Windows laptop from someone in the next week or so to capture the packets, so will see then... |
And yes, I did confirm on Windows remotely that changing the Naga 2014 Tilt to send a keyboard key does cause the mouse to send a keyboard event, so it does seem to be something on the mouse. |
I have also somehow accidentally got it sending data over the USB interface that does not correspond to key presses now...
That is from the USB packets themselves, I am not quite sure how I caused that, but it is new and useful information instead of the mouse sending the same data for Tilt as for scroll, the data USB packet I fed the mouse was:
Using the SET_REPORT byte of 0x09 to setup the request, a value of 0x0300, and an index of 2. I am fairly sure this clears the existing mapping data and the mouse seems to work fine otherwise except the Tilt not working as scroll now (and is not mapped by evdev as anything, I think this is 'new' data specific to the naga/razer for Tilt? Perhaps for the windows-side mapping program). At this point I could make a USB listener to listen for those data chunks specifically and handle them to do my own key mapping, too much work for tonight though, and it would be great to get it in to razerd anyway. |
And yes, to confirm, if I reset the mouse (unplug then plug back in) it maps the Tilt back to scrolling again, which in the USB capture spams the scrolling up/down packets identical to the scrollwheel, but rapid-fire, and when I send that packet again that I detailed above, then the Tilt changes to being the new data I documented above. It seems quite reliable, tested a multitude of times now and the mouse still functions properly. So, I think I found it... |
razerd will never listen to data packets from any razer device. That is not what razerd is supposed to do. It is the task of the kernel and X HID drivers to handle the data stream.
Well, please send me a Wireshark USB dump of the configuration sequence that does the reconfiguration. Make sure to keep the amount of HID data low in that dump. |
That's great, I'm glad I got it wrong. |
Understandable yeah. Do you have any ideas for how to get the linux HID interface to see those as tilt then as it apparently does not? The mouse does not seem to report the mapping for the tilt buttons at all. I think it was designed only to be read by the synapse software nonsense... Easy to read, just nothing does it by default as the mouse is not reporting it...
Done: http://overminddl1.com/Razer/RazerNaga-0.3-0.5-Init-6TiltLeftDn-7TiltLeftUp-9TiltRightDn-10TiltRightUp.pcapng
Before the command if I press tilt it just spams the identical packet as scrolling, but instead of once per click like the scroll wheel it spams it continuously and rapidly while the tilt is held down. I uploaded the compiled program that should work on linux 64-bit generic systems to: LINK TO BINARY ONLY PROGRAM REMOVED. Please provide sources. --mb
So it should work about anywhere with the right libs if someone wants to try my hacked together test, compiled from haskell so excuse the size, make sure your user has write access to the proper usb device as it scans for 1532-0040 specifically (Razer Naga 2014 that I have), or run as sudo'd (never recommended, but eh...). All it does is send the packet sequence to the device/mouse then exit.
@benoit-pierre If you have an idea on how to remap its HID button signature, which is completely ignored by the linux HID and evdev systems as the mouse does not tell it about its existence in the first place, I would love to hear it. |
The mouse interface reported does not appear to have changed any between when the tilt is acting as a scrollwheel and when it has its own buttons (no diff result), it is always this:
|
Yeah I cannot seem to figure out how to get the HID interface to pass those on. I see them fine when I |
Ok, well. I always accept patches, as long as they adhere to the contribution rules http://bues.ch/cms/resources/contribute.html However, the interpretation of the button event message is not solvable in razerd. That must be done in the driver. The kernel HID provides interfaces for device specific packet interpreters. |
OvermindDL1: If you want to provide proof of concept code or such, please show the sources. Binary only blobs are not helping the development of razercfg and we are not going to distribute and execute large binary-only blobs in the Open Source community. |
Is somebody working on a patch/pull request with an initial implementation for this? |
I love the razer naga trinity because of this feature (the side wheel click/tilt) Maybe someone knows how to reset my old mouse so that it behaves like out of the box??? |
Synapse currently defines these buttons of:
However it is also missing the HSCROLL Tilt buttons, which by default map to scroll up/down on most(all?) Razer mice and the mouse needs to receive configuration information to remap them to something decent, however the synapse driver does not expose this information, nor how to configure it.
The text was updated successfully, but these errors were encountered: