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: ghack.c This is a tool to change the resolution on some gaming mice like the G5, G7 and G9.
Lomocobattery.c Battery information for a lot of cordless mice like MX, VX and VX Nano. Lomocoreconnect.c This allows you to reconnect your cordless mouse to the receiver. This is for MX, VX or VX Nano. Hi, I’ve tried lomocobatery-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./lomocobattery /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? 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! I played a little with it, no positive result till now ð I’ve created two logs.
Logitech Setpoint Linux Mint
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 for tracing. The logs and my current test code I uploaded to. There are “.usblog” files – native of SnoopyPro, exported “.xml” – doesn’t contains much details and current “lomocobatterymxany.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 ð. 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.
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. 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. I understand, but this proof of concept works for me only sometimes, approximately once per 30 runs.
Logitech
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.
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. 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 ghack 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 (revertghack, ) 2) make DPI buttons mappable under Linux and change DPI to some values (400,800,1600,1800,2000,3200,4000,5700) (modghack, ) 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 ghack works also with G5 Refresh. The productid is 0xc049. 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.
Logitech Options For Linux
Subsequently, I decided to release the code as g500control. The fancy name shouldn’t hide the fact that it’s based on Andreas Schneider’s ghack.c which I stated in several places. Since ghack.c contains the line “License: GPLv2 or later”, g500control 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 g500control, 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 ghack.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 g500control 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. Original eboot ps3. 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. @Vlad: Thanks. I did it as you described, but my problem is still the same. The reply is almost always blank ð sudo./lomocobattery /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!
@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 ghack.c and WireShark.
@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 URBCONTROL 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. 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.qC.- 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.qS. 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. 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 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 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.gS. 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 dpiidx 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.