Feat: Rewritten Windows Bindings - #5
Conversation
…win-bindings-new
| typedef struct { | ||
| char values[WMI_MAX_FIELDS][WMI_FIELD_LEN]; | ||
| } WmiRow; |
There was a problem hiding this comment.
This could be turned into a typedef without being encapsulated in a struct. Is there a specific reason for it to stay inside of a struct?
Also, I think you meant to do char values[WMI_FIELD_LEN][WMI_MAX_FIELDS]
There was a problem hiding this comment.
@Mahasvan please fix this as well: you meant to do values[WMI_FIELD_LEN][WMI_MAX_FIELDS]
| // VT_BSTR fast path. | ||
| if (bstr) { | ||
| int len = WideCharToMultiByte(CP_UTF8, 0, bstr, -1, nullptr, 0, nullptr, nullptr); | ||
| if (len > 0) { | ||
| if (len > dst_size) len = dst_size; | ||
| WideCharToMultiByte(CP_UTF8, 0, bstr, -1, dst, len, nullptr, nullptr); | ||
| dst[dst_size - 1] = '\0'; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Wouldn't it just be easier to move this into the initial if condition block?
There was a problem hiding this comment.
apparently not, according to claude
There was a problem hiding this comment.
Why not? It seems to be doing the exact same thing when analyzing control flow?
…win-bindings-new
Episode 2 - Attack of the Clones
kernel-dev
left a comment
There was a problem hiding this comment.
I forgot to check this before, my bad on the oversight
| typedef struct { | ||
| char values[WMI_MAX_FIELDS][WMI_FIELD_LEN]; | ||
| } WmiRow; |
There was a problem hiding this comment.
@Mahasvan please fix this as well: you meant to do values[WMI_FIELD_LEN][WMI_MAX_FIELDS]
It's not nested in the way you think, this is the correct code 😅
Bug description: `display.py:68-73` + `README.md:122-129` +
`main.cpp:199`: 🔴 bug: EDID lookup key contradiction. The README states
`get_edid` matches on `pnp_device_id` (`MONITOR\SAMxxxx\{...}`) and
explicitly warns that passing the CCD `display_path` will return "not
found". But `display.py` passes `connector.display_path` first (the
`\\?\DISPLAY#...` path). The C++ `get_edid` (`display_info.cpp:229-230`)
does bidirectional substring matching against the SetupAPI `DevicePath`,
which is also `\\?\DISPLAY#...` format — so `display_path` is what
actually works, and the full `pnp_device_id` (`MONITOR\...`) does NOT
match (`MONITOR\` ≠ `DISPLAY#`). The C++ self-test at `main.cpp:199`
calls `fnEdid(m.pnp_device_id, ...)` which would return 0 (not found).
Fix the README to match the code, and fix `main.cpp` to call `get_edid`
with the display_path or the split segment (`SAMxxxx`) so the self-test
actually exercises EDID retrieval.
No description provided.