Closed fuckgithubanyway closed 6 months ago
Hi, I'm back! Sorry for the delay. Thanks for the dumps. I've only found one little problem
charge control | ✓ | |
usb share | - | thanks for documenting it |
webcam | ✓ | |
fn/win | ✓ | |
cooler boost | ✓ | |
shift mode | ✓ | |
super battery | ✓ | |
fan mode | ✓ | |
cpu | ✓ | |
gpu.rt_temp | ~❌~ ✓ | the first dump reports 00 at 0x80, seems wrong unless you're using the laptop outdoors this winter =) edit: it is 0 when the gpu is inactive |
gpu.rt_fan | ✓ | |
LEDs | ✓ | |
backlight | ✓ |
Noticed discrepancy in items
../fn_key
and../win_key
. The states indicated in them are in fact inverted.
It's a known proplem on laptops that have win key on the left and fn key on the right
Other than the gpu.rt_temp_address problem, everything else looks good
@teackot I think MSI software somehow deals with inverted WinFn switch, because toggle for this is present in software, but always false, at least on server or middleware side
~If I remember correctly, the switch in the MSI app just controls whether the keys are swapped or not. It doesn't care about the actual placement of the keys on the keyboard.~
~Our driver, however, specifies the placement of each key explicitly - 'left' or 'right'. It assumes that Fn is physically on the left and Win is on the right, which is not the case for Katana 17.~
~If we want to keep the current explicit behaviour, I think we'll have to either specify the "invertedness" for each model in our configs, or determine it programmatically~
~Or, we can simplify things for us and do it the MSI's way, but lose the explicitness.~
Forget what I just said, MSI app also shows the placement explicitly
But it supported only on model where this settings could be obtained from reading some UEFI var. Also it is kinda spaghetti code. I don't know can I share on github part of decompiled C# code, but you can check file from MSI NBFoundation Service
folder OmApSvcBroker.exe
OmApSvcBroker.CS.WinAndFnChange
Class.
Hello comrades. Regarding the temperature of absolute zero on the GPU, the situation is as follows:
Here is a screenshot of the MSI center in the absence of a significant graphic load. Probably at such moments the graphics module of the central processor is used.
And here is the result after launching the video player.
The same behavior is observed in Linux.
+task manager indicators
@glpnk
but you can check file from MSI NBFoundation Service folder OmApSvcBroker.exe OmApSvcBroker.CS.WinAndFnChange Class.
Good idea. I guess I'll install a Windows VM and take a look (I couldn't install the dragon center with wine :(, )
@fuckgithubanyway
That explains everything! I guess the PR is ready to be merged
@teackot Nah don't do it, I can send it to your email. Also I'm now working on MSI software analysis and post reports in #98. Also in NoteBook Fan Control mentioned that we just can analyze DSDT table .
But software analysis is useful to check for similarities and diffs
Also I'm now working on MSI software analysis and post reports in #98
Great! I see I missed a lot while I was away
Something went wrong with the previous pull request. I'm duplicating it here.
device:
MSI Katana 17 B11UCX-897XRU
-family:GF
-version:REV:1.0
motherboard:
MS-17L2
*-firmware:E17L2IMS.317
CPU:
11th Gen Intel(R) Core(TM) i5-11260H @ 2.60GHz
iGPU:TigerLake-H GT1 [UHD Graphics]
dGPU:GA107 [GeForce RTX 2050]
EC firmware version:
17L2EMS1.108
EC_dump in default state:
EC_dump in
charging
+cooler_boost
+micmute_led
is on +kbd_bl
is off +webcam
is off :After several weeks of use, no critical problems were noticed. The functions documented by the driver work correctly.
Noticed discrepancy in items
../fn_key
and../win_key
. The states indicated in them are in fact inverted.