Logitech Linux Mouse Support

flattr this!

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

49 thoughts on Logitech Linux Mouse Support

  1. Pingback Tweets that mention Andreas Schneider » Blog Archive » Logitech Linux Mouse Support -- Topsy.com
  2. 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.

  3. 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 0×1201 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?

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

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

  6. @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?

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

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

  9. Pingback Recopilación de enlaces de interés. 8ª Semana de 2011 : KDE Blog
  10. 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.

  11. I have a Marathon 705.

    It shows the following:
    vendor 0x046d product 0xc52b version 0×1201 has 3 applications and is on bus: 3 devnum: 97 ifnum: 2

    But I could not get it working.

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

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

  14. 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 :-(

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

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

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

  18. 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 0×10, 0×01, 0×81, 0x0d, 0×01, 0×00, 0×00 needs to be sent and then a sequence 0×10, 0×01, 0×81, 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.

  19. 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…

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

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

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

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

  24. 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!

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

  26. @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.

  27. 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 0×5701 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!

  28. I buy a G400 and it’s not supported in Linux. Just my luck. :D

    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?

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

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

  31. @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

  32. @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!

  33. 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 0×21, bRequest 9, wValue 0×0320, wIndex 1, wLength 2, Data: 0×2001)

    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.

Leave a Reply


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post comment

What is Persona?