Hello author, I have made some extensions to your project

[cyxnzb]

The expanded content is as follows:

1. I have created a graphical interface using batch files to facilitate the use of the commands you provided.This batch file is called test4.bat.Meanwhile, I packaged it into an executable file.[Currently only available in Chinese]
2. I have translated your README.md file into Chinese.

I hope you don't mind my modifications, thank you!

[GeographicCone]

Hi, and thanks!

I don't mind at all. I appreciate the interest.

First of all, let's have the README.md in Chinese of course. Thank you for the translation.

I have my reservations about having a GUI. Here's why:

The first objective of this project was to reproduce all the calls made by the Omen Hub (now basically done).

Omen Hub runs on a lot of different platforms (laptop & desktop), and includes a lot of legacy code (even dating back to ATi, acquired by AMD 15 years ago).

Only some of these calls work on any given platform, and I can only verify it on the particular laptop I have.

For example: -SetFanTable only takes effect on some desktops I think. On my laptop, the fans are best controlled through the EC, which I'm working on right now. Or: -SetConcurrentCpuPower is only supposed to work on Omen 17 (2023) ("Cybug 23C1"), according to a comment in the decompiled Omen Hub source.

1. So, I think a GUI should only have a subset of OmenHwCtl's functionality. But which subset? I've been collecting feedback from other users (where you also responded) to kind of get an idea what is useful and what isn't.

2. Although OmenHwCtl should be safe in that the settings only persist until a reboot or power-off, I'd rather not have someone accidentally hitting some button and complaining about the results. A CLI makes people think what they want to do first.

3. I can't see myself having the time to maintain a GUI but if I did, I'd think of it as a separate project in its own repository. OmenHubLight could serve as an inspiration but could be significantly simplified, there's no need for that "HP Shim Library" it uses when one can just make WMI calls directly.

So for now, here's my idea of what next:

• Please create your own repository with what you wrote, and I'll link to it from here. I'll also put a message in Chinese at the top of the (English) README.md so that anyone looking for a Chinese version can easily locate it.
• Later today I'll create some issues regarding OmenHwCtl's future development plans and let's discuss.

[cyxnzb]

Thank you for your reply. I think we can delve deeper into your project together, as there are many users like me in China who are interested in your project.
Specifically, many Shadow Genie 9（like omen-by-hp-16.1-inch-gaming-laptop-pc-16-wf0000) users want to release the full performance of their machines by modifying relevant parameters, but HP does not have the corresponding permissions open, so they can only try to modify the Ru settings in the BIOS to release performance.
However, after BIOS version F05, HP prevented users from modifying the Ru settings in the BIOS, so users can only try other methods until they see your project, It's like seeing the hope.

[cyxnzb]

In addition, the omen gaming hub does have many unnecessary functions, especially in the Chinese Mainland version, which provides support for third-party game platforms. In my opinion, this is not what users need.

[GeographicCone]

In addition, the omen gaming hub does have many unnecessary functions

I agree. It's a piece of garbage. Takes longer than a game to load, and then occupies 1.5GB RAM just sitting in the background while extracting all kinds of data and sending it somewhere.

In my opinion, this is not what users need.

Of course. This is what HP needs to monetize the users even further. 😃

I think we can delve deeper into your project together, as there are many users like me in China who are interested in your project.

Great! Let's do it!

However, after BIOS version F05, HP prevented users from modifying the Ru settings in the BIOS, so users can only try other methods until they see your project, It's like seeing the hope.

I looked into unlocking the BIOS too. The mod to show the menu is definitely doable (maybe just changing AMITSESetupData is enough really). But if the HP_BBUpdate module is patched as well to ignore a modified BIOS, it won't boot at all due to Boot Guard ACM, and there's no easy bypass for this. I think it's still possible to patch that part, since AMITSE and Setup are not protected by Boot Guard directly, but it would need to involve recreating a valid signature to fool HP_BBUpdate, and that's more complicated.

In my case there's access to all the settings, even on the latest BIOS version (F.15, 2023-05). It's not very convenient but I can edit the Setup variables from EFI shell. I like using this utility myself: https://github.com/datasone/setup_var.efi instead of RU (if that's the one you have in mind).

If you can't edit UEFI variables anymore, then it still should be possible to downgrade the BIOS to a previous version where it worked.

To enable maximum performance OmenHwCtl, you can try -MaxGpuPower first, also -SetFanMode 0x31, and experimenting with -SetCpuPower and -SetCpuPowerMax depending on what you need: in -GetSysDesignData byte #5 is the default limit for -SetCpuPowerMax (PL4). In my case it's 0xD7 == 215 [W]. Depending on the specific situation, it might be worth it to also try flashing a different nVidia BIOS: https://www.techpowerup.com/vgabios/

[cyxnzb]

That sounds good.
I'll give it a try when I have time. By the way,I have also considered to downgrade the BIOS version, but it seems that HP does not allow users to directly downgrade from a higher version (for example, the latest version of my laptop's BIOS is F.11) to F.05 (perhaps I think because this version is quite special, it does not lock any parameters related to machine performance release in the BIOS).
Therefore, users can only use a programming tool or seek assistance from after-sales service to downgrade the BIOS version.
By the way, there is another issue, which is that when a user logs out of the Omen Gaming Hub, the power consumption of the CPU will be locked and cannot be unlocked by modifying PL1 and PL4.
It's like there's some communication mechanism between the Omen Gaming Hub and the BIOS, and once disconnected for a long time, the power consumption of the CPU will be locked in.

[GeographicCone]

Continuing the discussion, I've written a C# application called OmenMon as a successor to the OmenHwCtl script. It opens up a whole lot of possibilities as to what can be done. Maybe we could cooperate on this somehow if you're interested?

In any case, I tried to make it easy to translate: all it should take is editing an XML file: https://github.com/OmenMon/Localization