couriersud
Unknown monitor MPG27CQ - Steel series RGB support
DEBUG: Initializing HID lib
Unexpected id combination <001><V18>
Detected an unknown monitor. Please report the output of
'msigd --info --debug --query' as an issue and also provide
the ID (MAG...) of your monitor. Thank you!
Vendor Id: 0x1462
Product Id: 0x3fa4
Product: MSI Gaming Controller
Serial: A02017120100
Monitor Series: MAG32 Series
s140: <001>
s150: <V18>
DEBUG: Special 01 b0: 01 5a 67 00 00 00 00 00 00 00 00 00 00 00 00 00
DEBUG: Special 01 b4: 01 5a 02 ea 06 3c 00 00 00 00 00 00 00 00 00 00
DEBUG: Error 0 reading from HID device
DEBUG: Error receiving 01 d0 62 30 30 31 30 30 30 30 30 0d: 0
macro_key : '000'
mode : '000'
serial : 'FA3T038420211'
frequency : '144'
game_mode : '000'
unknown210 : '009'
response_time : '000'
enable_dynamic : '000'
hdcr : '000'
refresh_display : '000'
refresh_position : '001'
alarm_clock : '000'
alarm_clock_index : '000'
alarm_clock_time : '00l'
alarm_position : '000'
screen_assistance : '000'
unknown280 : '001'
zero_latency : '001'
screen_size : '003'
msigd: Error querying device on night_vision - got '56006'
Try 'msigd --help' for more information.
pro_mode : '000'
eye_saver : '000'
image_enhancement : '001'
brightness : '066'
contrast : '060'
sharpness : '001'
color_preset : '001'
color_red : '100'
color_green : '100'
color_blue : '100'
color_rgb : '0x949494'
unknown435 : '000'
input : '002'
pip : '000'
pip_input : '002'
pbp_input : '002'
pip_size : '002'
pip_position : '000'
osd_language : '001'
osd_transparency : '000'
osd_timeout : '020'
sound_enable : '000'
rgb_led : '000'
navi_up : '002'
navi_down : '001'
navi_left : '007'
navi_right : '005'
PS: Thank you very much for your work :+1:
Pushed commit to support the monitor. Can you please rerun msigd --info --debug --query to post output here?
DEBUG: Initializing HID lib
Vendor Id: 0x1462
Product Id: 0x3fa4
Product: MSI Gaming Controller
Serial: A02017120100
Monitor Series: MPG271 Series
s140: <001>
s150: <V18>
DEBUG: Special 01 b0: 01 5a 67 00 00 00 00 00 00 00 00 00 00 00 00 00
DEBUG: Special 01 b4: 01 5a 02 ea 06 3c 00 00 00 00 00 00 00 00 00 00
DEBUG: Error 0 reading from HID device
DEBUG: Error receiving 01 d0 62 30 30 31 30 30 30 30 30 0d: 0
macro_key : '000'
serial : 'FA3T038420211'
frequency : '144'
game_mode : '000'
black_tuner : '009'
response_time : '000'
enable_dynamic : '000'
hdcr : '000'
refresh_display : '000'
refresh_position : '001'
alarm_clock : '000'
alarm_clock_index : '000'
alarm_clock_time : '00l'
alarm_position : '000'
screen_assistance : '000'
free_sync : '001'
zero_latency : '001'
screen_size : '003'
pro_mode : '000'
eye_saver : '000'
image_enhancement : '001'
brightness : '066'
contrast : '060'
sharpness : '001'
color_preset : '001'
color_red : '100'
color_green : '100'
color_blue : '100'
color_rgb : '0x949494'
unknown435 : '000'
input : '002'
pip : '000'
pip_input : '002'
pbp_input : '002'
pip_size : '002'
pip_position : '000'
osd_language : '001'
osd_transparency : '000'
osd_timeout : '020'
sound_enable : '000'
rgb_led : '000'
navi_up : '002'
navi_down : '001'
navi_left : '007'
navi_right : '005'
By the way I tried setting the mystic lights I have but I get this:
./msigd --mystic 0xFF0000
ioctl (SFEATURE): Connection timed out
By the way I tried setting the mystic lights I have but I get this:
./msigd --mystic 0xFF0000 ioctl (SFEATURE): Connection timed out
This will be tricky to fix. The Win10 MSI app shows 9 leds which can be controlled. How many are shown for the MPG27? Alternatively: If you have a virtual Win10 machine and know how to use wireshark: Install MSI software in virtual machine, connect MSI usb interface to virtual machine and log usb traffic. Than change mystic leds a number of times. Stop logging and provide log.
You mean the MSI Gaming OSD 2.0 software?
I do have Win 10 VM with wireshark so I'll prepare the log.
You mean the
MSI Gaming OSD 2.0 software? Yes I do have Win 10 VM with wireshark so I'll prepare the log. I have used wireshark on linux to track the VM usb traffic. But may work out of Win10 VM as well.
I have used wireshark on linux to track the VM usb traffic. But may work out of Win10 VM as well.
Yes I tried it before and it works correctly.
About the MSI Gaming OSD 2.0, the thing is: I do not see any LED setting in this program.
It uses "Steelserie GameSense".
This is the mystic light app which is launched out from the MSI app. GameSense is not available. We may try a GameSense log, but I don't make any promises to make it work. In the best case it's the same protocal, in the worst case it is completely different.
I spent two hours trying to figure out why I couldn't control the lights from the VM and then from Windows... It's so dumb... It's because LEDs were disabled from the OSD.
On this monitor there are two usb devices used:
- "MSI Gaming Controller" used by GamingOSD
- "SteelSerie MSC" used to control the LEDs (usb VID:PID is
1038:1126)
Disabling LEDs from the OSD was making the "SteelSerie MSC" undetectable...
So now that I figured this out, I can control the LEDs from the Windows VM, but only from SteelSeries Engine 3
I'll retry on real Windows to see if the same happens.
In the meanwhile here is how it looks like :
And here is the capture log changing a led color a few times:
I had a look at your capture files. Thanks a lot for the effort!
Unfortunately the gamesense protocol seems to be completely different from the mystic rgb protocol.
I found the following documentation here on github: https://github.com/SteelSeries/gamesense-sdk
and some client example:
https://github.com/arxae/Gamesense
All of this seems to rely on some server (closed source) running on windows accepting json requests. The underlying hid/usb protocol is not documented.
gamesense.pcap seems incomplete. Couldn't identify the device. From mystic.pcap it looks like the gamesense device is 1.11 (steel series) and leds are controlled by report request control messages.
But without a real device it is not possible for me to develop a driver. If I would have a device, the route I would take would be to identify messages which set all leds to white, than black, red, blue, green. These 5 colors should be enough to decode the data format - or at least have a start. Control messages are
control_msg_write(0x21, 0x09, 0x300, 0, &data, static_cast<int>(sizeof(led_data)), 1000)
That's basically (0x300 instead of 0x371) the same call as the mystic light call.
Thismost recent commit has debug support for the steel series interface residing on a separatate usb manufacturer id and device id combo.
./msigd --test_steel should switch 8 LEDs to red. Can you please try to run this and post the output here?
In addition, the ouput of sudo lsusb -v for the steel series usb device would be helpful.
Thank you!
The interface for steel series mice is pretty well documented in this project:
https://github.com/flozz/rivalcfg/tree/master/rivalcfg
Hey that's really cool!
I was about to try to either try to generate a new pcap when using steelserie software or start to document myself on how to reverse engineer this properly given your first clues. Let me know if I should still try to do one of the above.
Here is the output of ./msigd --test_steel :
./msigd --test_steel
DEBUG: Initializing HID lib
I didn't notice anything different looking at the leds.
Here is the the lsusb output:
Bus 001 Device 011: ID 1038:1126 SteelSeries ApS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1038 SteelSeries ApS
idProduct 0x1126
bcdDevice 2.26
iManufacturer 1 SteelSeries
iProduct 2 SteelSeries MLC
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x003b
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 300mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 37
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 25
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 1
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
The test output tells me that the steelseries device is accepting the message. Good. Now the following would be helpful:
- Stop SteelSeries software completely. There may be some processes in the background which need to be killed.
- Start usb pcap
- start steelseries softwart
- turn all leds white.
- turn all leds red
- turn all leds green
- turn all leds blue
- turn all leds black
- Stop SteelSeries software.
- Stop usb pcap
Apart from the "0e" messages I have seen "0d" and "0b" messages as well. With the approach above we should be able to identify the color information fields and the start-up sequence.
Done, followed everything correctly I think but note I did it inside a VM.
Just committed extended test code.
./msigd --test_steel should now circle through white, red, green, blue (1 second delay).
Please provide output. If this doesn't work, a pcap would be helpful.
Just committed another text extension:
Using --test_steel after circling through red, green, blue switch front leds to yellow one after the other.
There should be 40 leds on the front in 5 groups.
And 4x10 leds on the back left and 10,9,4 leds on the back right.
Can you please confirm the front leds turn yellow and the number of leds?
I confirm your numbers and that the front leds turn yellow progressively (although not smoothly): https://imgur.com/ub8y5Yh
That's seems to be an issue with the firmware. I'll provide a different approach tomorrow. It looks like that every "persist" seems to cause some flicker. This is also visible on the transition from white to red, green and blue.
What you may try is to comment out the calls to steel.perist() and check if the color switching still works. That would be very helpful. Does the same flicker happen if you use the native app?
But at least we now have a starting point and can set individual leds as well as group of leds.
I commented all the steel.persist() calls but then the leds were not changing.
Feels like steel.persist() is a bit like a buffer flush.
With the native app, there is a "live preview mode". When enabled, it will not flicker when not changing all leds. I recorded a new pcap with the live preview mode enabled: steelserie-live.zip
What I did was start the software (live preview was already enabled) then change some groups of front leds to red two times. After that I toggled live preview off and then on and finally saved all the changes. Hope that helps!
Thank you for all your investment so far :)
Please try --test_steel with latest code again. This should be flicker-free now.
Indeed: https://imgur.com/y7MInx8 although I see some small flickering as if one led randomly turned off and on again in the group of blue leds.
It's either the first or one in the middle of a group. This seems really firmware related.
Yep it's firmware related as the same happens with the original software. It's just a very minor annoyance anyway.
I recorded a new pcap: steelserie_adv.zip I set the 5 front groups to the effect "color shift" which is highly configurable but here I just used the default settings. After enabling it, I toggled on "Wave mode". Finally I played with the "Global Illumination" slider which just sets the brightness of the LEDs. Note that I didn't hit the "save" button, everything was done using live preview mode.
There is also another mode called "MultiColor Breath" but I didn't use it in this pcap. Let me know if you want me to record another one with something done differently.
Also, because we are doing some experiments with this, maybe it would have been better to switch to a new branch as not to "pollute" the master branch with test commits.
I was able to identify global illumination now. For the other settings. When you enable colorshift, you have to change the colorshift colors and speed as well. The software only sends changes to the monitor. So you need to change colors and speed twice so it can be identified. Can you also please post a screenshot of the back view - I need this to confirm there are two groups at the back.
Here is what it looks like in the software:
And IRL:
New pcap: colorshift.zip
- Enabled ColorShift
- Set speed Max then Speed min
- Disabled then enabled wave mode
- Set wave mode speed to min and then max