Closed glpnk closed 1 week ago
what you can say about this (WIP) ...
I like the format. Though the "EC generations, WMI version" section has to be more elaborate on what we consider to be generations, and the similarities between layouts.
we probably need to add option
SteelSeries
to keyboard dropdown in request template
Could you clarify what you mean by that?
You can merge this PR, because all WIP things I do in other branch. I just need to update data about latest added device before you merge this
EC generations, WMI version
Temporary name + WIP
Could you clarify what you mean by that?
SteelSeries appears to be USB only keyboard + KB backlights + RGB case light, and don't use EC backlight level. MSI Center writes backlight level to EC, but it seems to be not used by keyboard. Some keyboards have FN shortcuts highlighting. But after FN-WIN swapping, highlighting is not changed. I don't know how FN-WIN swap works and if it really works.
I probably found a way to check WMI generation from EC dump, WMI2 module upstreamed by Wer-Wolf have function which gets EC RAM version + checks Tiger Lake
flag. This value is GET_EC
[1] WMI method, which corresponds to 0x37
address.
On WMI1 devices, this byte is not used, but on WMI2 it mostly equals 0x81
=0b10000001
, so 7 bit is up, which is Tiger lake
flag.
Tiger lake is Intel 11 generation, but this bit seems be up on 11+ gen Intel and gaming 7 gen AMD, you can check this on:
I just need to update data about latest added device before you merge this
Sure
SteelSeries appears to be USB only keyboard + KB backlights + RGB case light, and don't use EC backlight level. MSI Center writes backlight level to EC, but it seems to be not used by keyboard.
The list of SteelSeries-compatible laptops is available here. We can just look them up on that page by the model name (just need to mention it in the template or docs).
We can add an lsusb
field to the issue template to see if the keyboard shows up as a usb device (mine doesn't and the backlight works)
On WMI1 devices, this byte is not used, but on WMI2 it mostly equals 0x81=0b10000001, so 7 bit is up, which is Tiger lake flag.
Great, also needs a docs mention. We might want some more additional ways to check the WMI version to check if there are any exceptions.
I'm thinking, how we should call device generations: WMI version or just generation. Because ACPI-WMI2 is name of MSI library, which was used in this Windows EC dumper https://github.com/timschneeb/MsiEcRamEditor
I've seen a reference to WMI namespace versions here, not sure if it is related. I think we can go with WMI versions or WMI layouts?
This is decompiled BMOF dump, which MSI share inside their programs. Basically, WMI2/generation 2 (call it like you want) have method Get_WMI
which returns WMI version, which equals 2.8
(for device DSDT dump of which I've used to create ImHex pattern), but only for new devices.
So WMI2 is simple name, but confusing. I can keep it
WMI version/layout is incorrect, I think, because WMI is secondary thing, EC layout version may be?
There seems to be only 1 correct way to check EC generation / WMI version - to compare exported WMI GUIDs/UUIDs with IDs from BMOF, because some EC bytes might be changed.
Also, some bytes are mapped identically for both generations, so we can always export them
EC layout version may be
That's roughly what we've been calling it, it does make sense
Srry for not participating in the discussion. Right now I will focus on merging all those PRs while I'm not burnt out and while I have time
@teackot, ready
Also, I've fixed conf2 - conf11
conflict https://github.com/BeardOverflow/msi-ec/issues/48#issuecomment-2179636418
Confirmation about wrong address from @serfreeman1337 https://github.com/BeardOverflow/msi-ec/issues/48#issuecomment-1652127970 + screenshot on fork page
FINALLY ready
Yay, merging
Done
Changelog:
mark conf 11 as todo for fixing mixed modelsDONEMore changes WIP: https://github.com/glpnk/msi-ec/tree/docs/more-docs/docs
we probably need to add option
SteelSeries
to keyboard dropdown in request template