Steelseries Arctis Pro Wireless OLED

[Samondel]

I've been poking at putting sensor information onto the OLED display on the Arctis Pro Wireless tansmitter using the Gamesense SDK. I have a working prototype, but I just realized that AIDA64 has support for the Apex keyboard displays, and that SDK doesn't seem to make a distinction between the keyboard OLEDs and the one for the Arctis Pro Wireless. When I attempt to enable it in AIDA though I get 'Error: HID device not found'. I'm hoping that this might be as simple as adding the device ID to your list supported devices alongside the Apex keyboard displays. 

I'm fairly certain the one you'd want is USB\VID_1038&PID_1294&REV_0112&MI_05 which has this endpoint: HID\VID_1038&PID_1294&MI_05&COL02\C&157B00E6&0&0001

I may be wrong though, so a full USB dump is attached.

Any chance we can try this out? If you don't have one of these devices handy, I'm happy to test for you. I happen to have a spare one of these transmitter/OLED units (sans headset) that I could send you for debugging as well. 

Thanks!

usbdump.txt

[Fiery]

11 hours ago, Samondel said:

I've been poking at putting sensor information onto the OLED display on the Arctis Pro Wireless tansmitter using the Gamesense SDK. I have a working prototype, but I just realized that AIDA64 has support for the Apex keyboard displays, and that SDK doesn't seem to make a distinction between the keyboard OLEDs and the one for the Arctis Pro Wireless. When I attempt to enable it in AIDA though I get 'Error: HID device not found'. I'm hoping that this might be as simple as adding the device ID to your list supported devices alongside the Apex keyboard displays. 

I'm fairly certain the one you'd want is USB\VID_1038&PID_1294&REV_0112&MI_05 which has this endpoint: HID\VID_1038&PID_1294&MI_05&COL02\C&157B00E6&0&0001

I may be wrong though, so a full USB dump is attached.

Any chance we can try this out? If you don't have one of these devices handy, I'm happy to test for you. I happen to have a spare one of these transmitter/OLED units (sans headset) that I could send you for debugging as well. 

Thanks!

Judging by the HID device information, this one uses a different USB protocol to transmit bitmaps than the Rival 710 mouse or the Apex 5/7/Pro keyboards.  So it's not straightforward to add support for this.  We would either need to know what HID packets we need to send to the device to transmit the image data, or have a device here to use as test unit.  I'm not sure how skilled you are about such deep stuff: do you think you could find out the packet structure to give us specific guidelines on how to talk to the device to transmit the image data?

[Samondel]

I'm far from an expert in these things, but here goes...

I'm including a copy of the structure of a packet below, along with a Wireshark capture of a few more. There are three writes included in the wireshark logs: an all-black screen, followed by an all-white screen, and finally the screen with the pattern in the picture below, which will hopefully make sense in a minute.

Looking at the USB packets, it seems like the payload for writing to the screen always begins with d200. That's then followed by 768 bytes of image data (screen is 128x48, so 6144 monochrome pixels -> 768 bytes). The packet is zero-padded out to 1024 bytes.

The data isn't a pixel-by-pixel raster, however. It seems like it's divided up into tiles of 8x8 pixels, each of which is described by an 8-byte block. Each byte of the block represents a column of pixels in the tile - byte 1 -> left column, byte 2 -> second column, ..., byte 8 -> right column. 

The tiles themselves are rasterized left->right then top->bottom, 16 tiles wide and 6 tall. The pattern in the picture is three white tiles in the picture: white tile, 2 black tiles, white tile, 12 black tiles, (new line) black tile, white tile, then black for the rest, which looks like this:

ffffffffffffffff00000000000000000000000000000000ffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000ffffffffffffffff0000000000000000...

Hopefully this makes some amount of sense; I get the feeling I'm lacking the terminology to properly describe what I'm talking about. Let me know if I can clarify or investigate anything further.

Thanks!

Sam

Frame 2: 1060 bytes on wire (8480 bits), 1060 bytes captured (8480 bits) on interface wireshark_extcap3124, id 0
USB URB
    [Source: host]
    [Destination: 1.12.0]
    USBPcap pseudoheader length: 28
    IRP ID: 0xffffe60a9aa8b010
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b)
    IRP information: 0x00, Direction: FDO -> PDO
        0000 000. = Reserved: 0x00
        .... ...0 = Direction: FDO -> PDO (0x0)
    URB bus id: 1
    Device address: 12
    Endpoint: 0x00, Direction: OUT
        0... .... = Direction: OUT (0)
        .... 0000 = Endpoint number: 0
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 1032
    Control transfer stage: Setup (0)
    [bInterfaceClass: Unknown (0xffff)]
Setup Data
    bmRequestType: 0x21
        0... .... = Direction: Host-to-device
        .01. .... = Type: Class (0x1)
        ...0 0001 = Recipient: Interface (0x01)
    bRequest: 9
    wValue: 0x0300
    wIndex: 0 (0x0000)
    wLength: 1024
    Data Fragment: d200ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff…

The raw hex for the packet that wrote the pattern in the picture is here:

1c001040e9aa0ae6ffff000000001b000001000c00000208040000002109000300000004d200ffffffffffffffff00000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Which produces:

Arctis Pro Wireless OLED only.pcapng

[Samondel]

Forgot to mention, for each byte defining a column in a given tile, the most significant bit is the top pixel, the least significant bit is the bottom pixel.

I should also mention that I was wrong about which device to write to in the initial post. It's actually HID\VID_1038&PID_1290&MI_00\C&36DEF645&0&0000.

[Samondel]

Finished up the python prototype using sensor data from AIDA64 via WMI. The code for remapping a normal bitmap bytearray into the format that goes out over USB is here (Python, which I'm certain AIDA doesn't use, but it's clear what's going on):

def remap_image(image):
	return_bytes = bytearray()
	for tile_row_offset in range(6):
		for tile_column_offset in range(16):
			for column in range(8):
				byte = 0
				for row in range(8):
					pixel = image[row * 16 + (tile_column_offset + (tile_row_offset * 128))] & 2**(7 - column)
					if (pixel):
						byte += 2**row
				return_bytes.append(byte)
	return return_bytes

Then using hidapi I send a feature report, consisting of [0xD2] + (image data from above) + [0x00] * 256.

[Samondel]

One last update here - despite the Gamesense SDK only supporting this as a 128x48 display, it's actually 128x64, and will support a full 1024 bytes of image data over USB (i.e. [0xD2] + (1K image data)).