Logitech Linux Mouse Support
Maybe you ask: Why is there still no new version of lomoco to support the latest Logitech Mice?
The answer is that I still don’t know how they detect a mouse connected to a receiver. Maybe they just have a table which defines which mice come with which receiver and then try some commands. If it fails it is mouse X and if not it must be mouse Y.
I already wrote some proof of concept for the new protocol and sometimes people contact me and the proof of concept is enough for them. So here is a list of small proof of concept utils:
g_hack.c
This is a tool to change the resolution on some gaming mice like the G5, G7 and G9.
http://git.lomoco.org/projects/lomoco.git/tree/proof-of-concept/g_hack.c
lomoco_battery.c
Battery information for a lot of cordless mice like MX, VX and VX Nano.
http://git.lomoco.org/projects/lomoco.git/tree/proof-of-concept/lomoco_battery.c
lomoco_reconnect.c
This allows you to reconnect your cordless mouse to the receiver. This is for MX, VX or VX Nano.
http://git.lomoco.org/projects/lomoco.git/tree/proof-of-concept/lomoco_reconnect.c
Hey, loks good. Could you possibly port your lomoco_battery.c file to upower so that the battery status is available in GNOME and KDE? Thanks.
Hi Richard,
if I find some time I can try to port it. The plan was to create a library for logitech mice. I need to invest more time in reverse engineering to figure out the final bits.
got a vx nano and the usb id is
046d:c526
I thought lomoco was dead. Happy for these news!
Me and my mx5500 are waiting.
Francesco
Hi,
I’ve tried lomoco_batery-c on my Anywhere MX mouse. First I had to add product 0xc52b to identify the mouse. But the batery status is not shown. Probably different sequence is needed:
$ sudo ./lomoco_battery /dev/usb/hiddev1
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Battery information:
query result: 00 00 00 00 00 00
How can I help to identify the correct sequence?
Tried with my Performance MX mouse. No success in either reading battery status and changing resolution of the mice. It was required to patch in USB PID to 0xC52B as this is what my mouse receiver has. Probably the software isn’t working just because of the fact that is wasn’t designed to work with mouses over Logitech “unified” receiver. Anyway, thanks a lot for your work, looking forward for any improvements.
The G hack is for the G series not for the MX. The battery status didn’t give any information on the first call on my MX1100 but at the second.
>> Battery information:
query result: 01 81 0d 55 1c 31
battery status: 85%
could be electric current: 28
HI! I have MX620 and would like to help with development. Contact me, if you need help
@Alexey Loukianov: your PID is the same as I have on Anywhere MX .
@Andreas Schneider:
I don’t know what is G-series and what not. But I can confirm, that battery info works on my second computer with VX Nano.
Your workaround for MX1100 mouse does not works for my Anywhere MX mouse.
For weekend I’m planning to install the Logitech software and USB sniffer on windows and try to catch the correct sequence for MX mouse. Any hints, how to do?
what bugs me is that Logitech recently joined the Linux Foundation.
What a bloody joke
Does the MX3200 mouse work with your code?
I don’t know if mouse XYZ works. If you want to help you can provide traces or buy a mouse and send it to me.
Here are some hints:
Install Windows in kvm and the Logitech software. You have to add the mouse to the vm and create traces with a full battery and an almost empty battery.
How to do the traces:
modprobe usbmon
mount debugfs
start wireshark
From here it is comparing the logs and a lot of try and error.
Hi,
I did some tests and the result is:
1) the query sequence used for G-series is the same as for MX-series
2) the problem is timing. The result is shown only for a really short time. After sleep(1) it is too late. The result is not there anymore.
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Battery information:
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 01 81 0d 4b 64 30
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
You can see line: 01 81 0d 4b 64 30 – it equals to 75% and it is correct.
I updated the code – I’m querying in loop until buf[3] != 0 or loop limit reached. But from many, many tries, only several were successful. 🙁 There is probably some better way, how to catch reply from mouse.
$ sudo ./lomoco_battery /dev/usb/hiddev1
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Battery information:
query result [500]: 00 00 00 00 00 00
$ sudo ./lomoco_battery /dev/usb/hiddev1
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Battery information:
query result [500]: 00 00 00 00 00 00
$ sudo ./lomoco_battery /dev/usb/hiddev1
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Battery information:
query result [8]: 01 81 0d 4b 64 30
battery status: 75%
battery: running on battery
could be electric current: 100
Personally, I’ll be ecstatic if you figure out how they sync up; it would be nice to hack together some wireless HID devices other than the paltry fare that Logitech and others put out now a days.
I swear they put out less devices now than they did twenty years ago.
I think 20 years ago the first mice just came out. You didn’t really need them on a UNIX or DOS command line 😉
I have a Marathon 705.
It shows the following:
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 3 devnum: 97 ifnum: 2
But I could not get it working.
I’ve looked to the libusb library. It should be the right way, how to communicate .with mouse. Unfortunately, it is long time ago, when I programmed in C and I did not found simple example for this library.
Well, libusb is what lomoco is using to control the old Logitech mice, but the new mice use a new protocol and this is only accessible through raw hiddev up till now.
Aha, in this case, this is not good 🙁
I have only one idea. I can compare usb logs of VX nano and Anywhere MX. Maybe there is another sequence that have to be sent to specify length of reply.
That’s the only way to find out how it works 🙂
I played a little with it, no positive result till now 🙁
I’ve created two logs. One is for VX Nano, second for MX Anywhere. Only two steps: plug the receiver and start the Logitech SW. I don’t have windows installation disk, so I used already installed windows on dualboot and SnoopyPro for tracing. The logs and my current test code I uploaded to there. There are “.usblog” files – native of SnoopyPro, exported “.xml” – doesn’t contains much details and current “lomoco_battery_mx_any.c”.
If you can look on it and have some suggestions, will be great. If it is not enough, I’ll try to install windows to kvm and use debugfs. But it will take a week or two 🙁
You need to create two logs with the same mouse, one with an empty battery and one with a full one. Then you can find the value which is different…
I already did it. The request and response for MX Anywhere and VX Anywhere are the same and are the same as for G series. The catch values equals to Logitech SW values. So no problem in this point. But If you need these logs, I can upload them tomorrow (now I’m on second computer).
The problem is a timing, as I wrote in #13. In these logs I wanted to find out the sequence to extend time of query on “gate”. No luck till now, I just find out one sequence causing I’m not able to do click in Kate, but I can elsewhere. I have to turn mouse OFF and ON to fix it.
I’m thinking about “brute force” attack 🙂 – Sent request in loops (max 100) and try to catch the reply (500 tries max). Currently I’m successful in about 1 to 30 manual runs.
Logs: mx_anywhere_batery_logs.tar.bz2
And I know, what is missing. To avoid the timing issue, there should be some buffer. But I have no idea, how exactly USB works and how it is implemented in kernel.
What about libhid? I think, this could be a solution. What do you think?
Why should libhid be better than what we do now. Do you think the problems will simply vanish?
Hi,
First, I know almost nothing about the whole usb stuff – how it works, how it should works.
Second, I really want to have reliable way to see my MX mouse battery level.
Third, I thing, the current approach – sent a request, wait some time, read response (and hope it is still there) – is not correct. At least for my MX mouse.
Fourth, I think, there is something missing – buffers or queue on the hiddev device. Simply, sent the request and then check the device buffer or queue and read response from there.
I hoped, in libhid (and probably in libusb) could be a solution. At least, they should use bufferes or something similar to don’t lost device responses.
Fifth, maybe userspace is not good place for it, I think, special kernel driver will be great. Get the battery status will mean a simple read from a file from /sys/ directory. Unfortunately, I never tried to make a linux kernel driver. I looked for some resources on internet, unfortunately it is not easy for me. See first point.
So in short, I know nothing about USB, I know C a little, but I’m not programming in C, but I’m thinking about it and I hope it will help.
Do you understand that this is a proof of concept code? Sorry if I’m being rude but making assumptions about libraries without reading the code or kernel divers without understanding the stuff is nothing which helps.
How to fix it can probably found in the protocol logs.
I understand, but this proof of concept works for me only sometimes, approximately once per 30 runs.
As far as I know til now, sequence 0x10, 0x01, 0x81, 0x0d, 0x01, 0x00, 0x00 needs to be sent and then a sequence 0x10, 0x01, 0x81, 0x0d, xxx is expected. I can confirm, that this works for my MX mouse, the returned value is correct. Do you expects something else?
What I want, is to run the code and get the battery status without need to run the code many, many times until I got the values.
Sorry, if I’m confusing you.
Did you look at the code? Do you see the sleep(1);? A sleep is never a solution so to find out what’s the right solution you have to read the logs from the Logitech software. Check the timing and check if they send the request multiple times or if they wait a certain amount of time. Maybe they send the request and send pull for the result like you do. However the Windows software will tell you what to do…
Yes, the sleep(1) is a problem. I tried nanosleep, but not change. And pulling in loop does not look as a solution for me – the response is there much shorter time. Many times is the response missed. If catch, it is usually in first ten tries, sometimes between ten and twenty, but I saw also try nr. 86 and 127. So I don’t think, they are waiting for specific period. I still thinking about the buffer/queue.
Regarding to logs, you can analyze them as well. Are in reply #24. What I can tell is, that there is not only one query for battery status, I see two requests and responses there. I’m not sure about timing, I don’t know, how interpret these logs.
First of all I’d like to than Andreas Schneider for posting this and Marian Kyral for explaining how to use SnoopyPro. I still can’t believe it myself, but it looks like I got it working with my G500! Luckily, I also have a G5, so that I could compare the output of SnoopyPro for the G5 with the instructions g_hack sends to the mouse.
Well, I must admit, that compared to G500, G5 is a very easy thing. As far as G500 is concerned, SetPoint uses not only 7 byte but also 20 byte buffers and it sends way more instructions. There are some initialization instructions which must be sended to a G500 before it can be programmed. After that, SetPoint seems to send all the driver settings to the mouse, which means a
lot of bytes. As of now I’ve figured out how to do two things:
1) revert G5 to the standard behavior where DPI buttons change DPI and the three DPI values are 400,800 and 2000 (revert_g_hack, http://pastebin.com/vRwpgB8N)
2) make DPI buttons mappable under Linux and change DPI to some values (400,800,1600,1800,2000,3200,4000,5700) (mod_g_hack, http://pastebin.com/iY9u77d2)
That’s actually all I wanted to have, so I’m quite happy now. I hope it helps you guys in developing lomoco. Thanks again!
PS: In fact, I only tested this with MY G500. Thus, I can’t guarantee that it will work with other G500’s and I’m not liable for any damage that may happen when using the modified code. However, as far as I can tell, even if a G500 stops working, you can still resurrect is by booting back into Windows with Setpoint. SetPoint kind of resets the mouse each time and then configures it according to the SetPoint settings.
PPS: the original g_hack works also with G5 Refresh. The product_id is 0xc049
Thanks for the code. I will look at it when I have time and add it to the lomoco repo.
Bombenbach: Congratulation
Could you help me to understood the SnoopyPro logs? How can I identify inicializing sequences? What I should looking for? My logs are in post #24.
My Anywhere MX mouse has no DPI change possibility. Only what I want is to get the battery status.
To avoid confusion, since I posted my previous post under another
nickname: For some reason I considered that nickname to be unique but
some googling has revealed a lot of people using the same nick, so I’d
rather use my first name, which is Vlad.
Last week I spent some more time investigating the communication between
G500 and SetPoint until I finally managed to configure most of the
settings provided by the original SetPoint. Subsequently, I decided to
release the code as g500_control. The fancy name shouldn’t hide the
fact that it’s based on Andreas Schneider’s g_hack.c which I stated in
several places. Since g_hack.c contains the line “License: GPLv2 or
later”, g500_control is also GPLv2. So far I can not only set arbitrary
resolutions in x an y directions but also change USB repeat rate and
enable angle snapping. The code is located here:
Everything works really great
on my G500 but I’m still a bit worried if this will work on other
G500’s too. For instance, the initialization sequence might be S/N or
firmware specific. Although I personally don’t believe that a wrong
initialization sequence might brick the mouse completely, I
nevertheless have placed enough warnings in the code an in the readme.
Well, let’s wait for some brave testers 🙂
@Andreas Schneider
I’m not really that keen on actively developing g500_control, so if you
want to integrate it into lomoco I have absolutely nothing against. After
all it’s FOSS. Unfortunately my code is not particularly elegant so
cleaning up and rewriting would be mandatory 😉
@Marian Kyral
Although I don’t think that I can understand SnoopyPro’s logs any better than
you, I’ll simply describe what I did in hope that it might help you or anyone
else. The procedure is actually quite simple: boot into Windows, install
SetPoint, plug in the mouse, run SnoopyPro as admin, open the USB devices
dialog, select File->Unpack Drivers and File->Install Service which should
change the status from “Snpys bridge is not available” to “Snpys bridge is
present and accessible (0 out of 32 entries used)”. Now right click on the
VID/PID corresponding to your device and select Install and Restart. Try
not to move the mouse you’re investigation, otherwise you’ll quickly get
a lot of packets you’re not interested in. Now open SetPoint in tray and
watch the packet counter. Prior to opening SetPoint I usually have already
over 100 packets (including the initialization sequence). Opening SetPoint
gives sth like 8 additional packets. Now you may start changing one setting
at a time and hitting apply. Every time I change something and hit apply,
SetPoint flashed my G500 with a new profile which makes about 60-70 packets.
At the end of the day you hit stop and start examining the log, trying to find
out which bytes correspond to which changes. Brown lines are what SetPoint
send to the mouse and green line are what the mouse responses. An important
thing to look at, is the length of the transfer buffers, i.e. the line
“TransferBuffer 0xxxxxxxxxx (XY) length” One of the main differences between
a G5 and a G500 is that G5 uses solely 7-byte buffers whereas G500 user both
7 and 20 byte buffers. It took me some effort to understand how to expand
the original 7 byte buffers in g_hack.c to 20 bytes but there’s actually nothing
difficult about that. Now let’s examine a sample SnoopyPro log for my G500:
At t=0.952 SetPoint starts talking with the mouse. That’s the begin of the initialization sequence which ends at t=4.103. In g500_control source code I plainly copy that sequence to make a G500 think it’s communicating with SetPoint. It’s very important not only to “bomb” the mouse with buffers but also to give it enough time to respond. For that I use nanosleep.
Between 13.510 and 46.504 there are 8 packets exchanged which comes from
opening SetPoint window from the tray icon. Between 46.504 and 59.608 a
new profile is flashed. From now it really goes about comparing the bytes
and finding their true meaning.
Nice work and welcome in the world of USB hacking 😉
If you send me the code or a patch I will add it to the lomoco proof-of-concept code directory. If I find some time this year I will start to rewrite lomoco nicely.
Btw. if you’re running SetPoint in a virtual machine you don’t need SnoopyPro. You can use wireshark with the usbmon kernel module!
The code is actually publicly available but somehow the links I included mystically disappeared. Probably because of wrong tags. So here they are
Link to g500_control: http://code.google.com/p/g500-control/
Link to the example log: http://www.megaupload.com/?d=QC7TFNCX
Just in case the links still won’t appear: It’s on googlecode, the project is
called “g500-control” It’s still not available via search, but it’s the common url
for google code projetcs: …/p/g500-control
@Vlad: Thanks. I did it as you described, but my problem is still the same. The reply is almost always blank 🙁
sudo ./lomoco_battery /dev/usb/hiddev1
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc52b version 0x1201 has 3 applications and is on bus: 6 devnum: 2 ifnum: 2
>> MX Anywhere (Logitech USB Receiver) detected!
>> Init
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: ff 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
query result: 00 00 00 00 00 00
>> Battery information:
query result[0]: 00 00 00 00 00 00
query result[1]: 00 00 00 00 00 00
query result[2]: 00 00 00 00 00 00
query result[3]: 00 00 00 00 00 00
query result[4]: 00 00 00 00 00 00
query result[5]: 00 00 00 00 00 00
query result[6]: 00 00 00 00 00 00
query result[7]: 00 00 00 00 00 00
query result[8]: 00 00 00 00 00 00
query result[9]: 00 00 00 00 00 00
query result[10]: 00 00 00 00 00 00
query result[11]: 00 00 00 00 00 00
query result[12]: 00 00 00 00 00 00
query result[13]: 00 00 00 00 00 00
query result[14]: 00 00 00 00 00 00
query result[15]: 00 00 00 00 00 00
query result[16]: 00 00 00 00 00 00
query result[17]: 00 00 00 00 00 00
query result[18]: 00 00 00 00 00 00
query result[19]: 00 00 00 00 00 00
query result[20]: 00 00 00 00 00 00
query result[21]: 00 00 00 00 00 00
query result[22]: 00 00 00 00 00 00
query result[23]: 00 00 00 00 00 00
query result[24]: 00 00 00 00 00 00
query result[25]: 00 00 00 00 00 00
query result[26]: 00 00 00 00 00 00
query result[27]: 00 00 00 00 00 00
query result[28]: 00 00 00 00 00 00
query result[29]: 00 00 00 00 00 00
query result[30]: 00 00 00 00 00 00
query result[31]: 00 00 00 00 00 00
query result[32]: 00 00 00 00 00 00
query result[33]: 00 00 00 00 00 00
query result[34]: 00 00 00 00 00 00
query result[35]: 00 00 00 00 00 00
query result[36]: 00 00 00 00 00 00
query result[37]: 00 00 00 00 00 00
query result[38]: 00 00 00 00 00 00
query result[39]: 00 00 00 00 00 00
query result[40]: 00 00 00 00 00 00
query result[41]: 00 00 00 00 00 00
query result[42]: 00 00 00 00 00 00
query result[43]: 00 00 00 00 00 00
query result[44]: 00 00 00 00 00 00
query result[45]: 00 00 00 00 00 00
query result[46]: 00 00 00 00 00 00
query result[47]: 00 00 00 00 00 00
query result[48]: 00 00 00 00 00 00
query result[49]: 00 00 00 00 00 00
query result[50]: 01 81 0d 2d 64 30
battery status: 45%
battery: running on battery
My current code.
is there support for ls1 laser mouse?
here is the information …
http://pastebin.com/NWY3FZ8W
works for me under Mandriva 2010.1:
[root@alfa logitech]# ./lomoco_battery /dev/usb/hiddev0
VX hack version: 0.0.1
hiddev driver version is 1.0.4
vendor 0x046d product 0xc521 version 0x5701 has 3 applications and is on bus: 5 devnum: 2 ifnum: 1
>> VX Nano (Logitech USB Receiver) detected!
>> Battery information:
query result: 01 81 0d 50 5c 31
battery status: 80%
could be electric current: 92
Great job!
I buy a G400 and it’s not supported in Linux. Just my luck. 😀
FYI, the device id for the G400 is 0xc245. I hacked g_hack.c to recognize it, but upon running it, ioctl(HIDIOCSUSAGE) in send_report() returns EINVAL. Blah. Any suggestions?
@Richard Tollerton
Just changing the device id in g_hack.c won’t help at all. Your only chance is to do the same I did, which means sniffing the communication between Setpoint and G400 and modifying the code accordingly (see my comment No 35).
I manage to change dpi of G400. It’s turn out that communication with G400 is completly diffrent. It don’t send raw commands but uses second HID interface to send command instead. Sample code http://bitbucket.org/extaliones/g400_hack/src use libusb to detach kernel HID driver and claim interface before sending commands.
I wasn’t able use dpi change buttons, but it’s some fishy stuff since logitech’s LGW sends dpi change command (to actual dpi) when clicked even if binded to other functions.
@Ext
Interesting. I guess the main difference is that G400 is more like MX518 or G5, i.e. it doesn’t have internal flash memory but must be configured each time it is powered up. By looking at your code I also see that there are not that much DPI options as advertrised in the specs of the mouse. That’s probably because SetPoint is interpolating the values inbetween. But the second HID interface is really very odd.
I’m realy wondering what’s the case for G600 MMO, since I surely could find a use for all that buttons 😉
Btw, someone has already posted a nice guide on mouse hacking using g_hack.c and WireShark: http://askubuntu.com/questions/117149/disabling-remapping-logitech-g400-mouse-dpi-buttons
@Ext have you been able to remap the dpi buttons to something else? I would love to be able to remap these buttons on my G400!
@Vlad the AskUbuntu post doesn’t actually solve the puzzle that is the G400 (and was actually intended for the MX1100). I’ve tried to figure out the URB_CONTROL out frames but wasn’t able to fix it. There are only two:
(after remapping the dpi+ button to LMB click I get the following two output frames)
//
0000 c0 d8 53 d3 01 88 ff ff 53 02 00 04 02 00 00 00 ..S…..S…….
0010 be 03 bf 51 00 00 00 00 39 98 04 00 8d ff ff ff …Q….9…….
0020 02 00 00 00 02 00 00 00 21 09 8e 03 01 00 02 00 ……..!…….
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0040 8e 04 ..
0000 c0 d8 53 d3 01 88 ff ff 43 02 00 04 02 00 2d 3e ..S…..C…..->
0010 be 03 bf 51 00 00 00 00 ab 99 04 00 00 00 00 00 …Q…………
0020 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(after remapping the dpi+ button to Ctrl+1 I get the following two output frames)
//
0000 80 71 a2 9e 01 88 ff ff 43 02 00 04 02 00 2d 3e .q……C…..->
0010 cd 02 bf 51 00 00 00 00 04 94 04 00 00 00 00 00 …Q…………
0020 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0000 80 71 a2 9e 01 88 ff ff 53 02 00 04 02 00 00 00 .q……S…….
0010 cd 02 bf 51 00 00 00 00 67 92 04 00 8d ff ff ff …Q….g…….
0020 02 00 00 00 02 00 00 00 21 09 8e 03 01 00 02 00 ……..!…….
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0040 8e 04 ..
There doesn’t seem to be a pattern that emerges that I can exploit. Having sad that, I’ve never tried this before 🙂 Hope you guys can help!
I modified the g400_hack code from extaliones in order to work with a my new G400s. http://pastebin.com/grZPxRDu
I modified Corubba’s code a bit further, to make it possible to toggle driver and native modes of the G400s mouse. In driver mode you can remap the DPI+/DPI- buttons (xev sees them as buttons 11 and 12 respectively). See http://pastebin.com/zK8jH2A1
Apparently the new Logitech Gaming Software puts the device in driver mode when it starts up and detects the device (and sets the DPI to some default – 400dpi in my case), then puts it back to native mode when you quit the tool. With Wireshark I was able to capture the control packets.
The G400s request to switch to driver mode as I captured it is this:
0000 80 ed 3f 5d 00 88 ff ff 53 02 00 03 03 00 00 00 ..?]….S…….
0010 dd 4d ef 53 00 00 00 00 c5 2b 0e 00 8d ff ff ff .M.S…..+……
0020 02 00 00 00 02 00 00 00 21 09 20 03 01 00 02 00 ……..!. …..
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0040 20 01
(bmRequestType 0x21, bRequest 9, wValue 0x0320, wIndex 1, wLength 2, Data: 0x2001)
Going back to native/device mode:
0000 80 67 10 06 02 88 ff ff 53 02 00 03 03 00 00 00 .g……S…….
0010 1f 4e ef 53 00 00 00 00 80 08 0f 00 8d ff ff ff .N.S…………
0020 00 00 00 00 00 00 00 00 40 02 8e 00 04 00 00 00 ……..@…….
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
That’s like any other DPI request on the G400s, but using dpi_idx 4 instead of 131 and up.
I suppose it’s all quite similar for the G400, but as I don’t have that I have no way to try it out.
I’m searching for a way to lower(!) the polling rate of my G400. But it seems this mouse doesn’t obey to the usual commands for this (neither under Windows nor under Linux). Do you know of any way?