Refactor EVisionKeyboardController to support 128 LEDs and update pac…#91
Open
juampe wants to merge 1 commit into
Open
Refactor EVisionKeyboardController to support 128 LEDs and update pac…#91juampe wants to merge 1 commit into
juampe wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes the EVision keyboard controller (VID
0x320F, PID0x5078) Phoenix MK1 Elite so that all hardware lighting modes (Static, Breathing, Color Wave, Rainbow, etc.) actually take effect on the physical device. Previously, sending commands produced no visible result on the keyboard. The root cause was an incorrect HID protocol implementation discovered by reverse-engineering USB captures from the official Windows software.Changes
EVisionKeyboardController.hEVISION_KB_MAX_PACKET_SIZEcorrected from0x36to0x38(56 → 56+2 bytes, matching firmware expectation)SendKeyboardDatadata offset widened fromunsigned shorttounsigned intto support LE24 encoding. The protocol encodes the chunk offset across three bytes ([5],[6],[7]), making it a 24-bit field.unsigned shortis only 16 bits and cannot represent the third byte, sousb_buf[0x07]was never populated. Although current offsets (max6 × 0x38 = 0x150) fit in 16 bits, the type must be at least 24 bits wide to correctly extract all three bytes with(offset >> 16) & 0xFFEVisionKeyboardController.cpphid_read()calls replaced withhid_read_timeout(..., 100)to prevent the driver from hanging when the device sends no responseSendKeyboardDatacorrected from command0x11to0x12(WRITE_LIVE_COLOR_DATA), which is what the firmware actually accepts[5],[6],[7]), matching the observed wire formatSendKeyboardModeExnow sends the real compound 27-byte parameter (param0x00) wrapped inBEGIN/ENDpackets, as captured from the Windows driver. The previous implementation sent an 8-byte parameter withoutBEGIN/END, which the firmware silently ignoredRGBController_EVisionKeyboard.cppDeviceUpdateLEDsis updated accordingly:128 * 3bytes (one R, G, B byte per LED), and the loop andSetKeyboardColorssize argument match. The previous7 * 0x36 = 378byte buffer was 6 bytes short of the 384 bytes needed to address all 128 LEDs, leaving the last two LEDs always blackProtocol Details
The firmware stores lighting configuration in flash via a single
SET_PARAMETERcall carrying a 27-byte compound payload:This sequence persists the setting to flash. The color survives USB disconnection, OS reboots, and KVM switches.
Related Issues
Checklist
./openrgb --noautoconnect --device 2 --mode Static --color 6667AB— color applied and persists after rebootTesting Notes
Tested on:
0x320F/ PID0x5078Phoenix MK1 EliteBreaking Changes
None. All changes are corrections to match the actual hardware protocol. Existing behavior for all modes is preserved or improved.