Configurator: Move to browser-based UI

[zllovesuki]

Current test/alpha/beta implementation of the Configurator is using a Terminal based UI. However, development has been proven difficult, and it is not very flexible nor very beautiful. Since the underlying protocol is gRPC, the UI can be moved to a JavaScript Single Page App, accessible via browser.

No Electron as it is a pain in the butt 😊

[x864]

Hello,
why not make a native gui for it, instead of being web-based? I've used https://github.com/lxn/walk in the past, it's really high-level and easy to use. I don't have that much time otherwise I would've submitted a PR...
also offtopic, why does using this void my warranty? (as written in the README)
anyway, keep up the great work you've done!

[zllovesuki]

Your warranty is now void. I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in this ROM before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.

---

on a more serious note, you are welcome to contribute a native GUI using lxn/walk. I found it less intuitive to use (might as well use VS C++)

[x864]

I will see if I can free up some time to work on it.
On a side note, if I want to make a clean Windows install, which Asus component should I install? i.e which software comes with Asus Optimization (which then comes with the required atkwmiacpi64.sys driver?)

[updawg]

I'm interested in this portion too:
On a side note, if I want to make a clean Windows install, which Asus component should I install? i.e which software comes with Asus Optimization (which then comes with the required atkwmiacpi64.sys driver?)

Also one of the goals of your project was to remove that dependency - is that on the radar?

Regardless thank you for all your hard work. I love having a bloat-free laptop.

[zllovesuki]

@updawg unfortunately, I won't be able to do it myself without violating some copyrights, since I've already done the reverse engineering for the driver, it won't be a clean-room development. So for now, you will still need the atkwmiacpi driver. On top of that, I won't be able to sign the driver even if I write it (since I need an EV certificate for kernel driver). However, https://github.com/zllovesuki/G14Manager/tree/main/system/atkacpi should contain enough the specification for someone else to write the driver.

[x864]

@updawg unfortunately, I won't be able to do it myself without violating some copyrights, since I've already done the reverse engineering for the driver, it won't be a clean-room development. So for now, you will still need the atkwmiacpi driver. On top of that, I won't be able to sign the driver even if I write it (since I need an EV certificate for kernel driver). However, https://github.com/zllovesuki/G14Manager/tree/main/system/atkacpi should contain enough the specification for someone else to write the driver.

any more details? what would be copyrighted ?
I thought about the driver issue too. Only ways are indeed:

• test mode (can't play games with anticheat)
• sideloading with vulnerable driver but can be detected by ACs and think they are r0 cheats
• expensive cert from M$

[zllovesuki]

@updawg unfortunately, I won't be able to do it myself without violating some copyrights, since I've already done the reverse engineering for the driver, it won't be a clean-room development. So for now, you will still need the atkwmiacpi driver. On top of that, I won't be able to sign the driver even if I write it (since I need an EV certificate for kernel driver). However, https://github.com/zllovesuki/G14Manager/tree/main/system/atkacpi should contain enough the specification for someone else to write the driver.

any more details? what would be copyrighted ?
I thought about the driver issue too. Only ways are indeed:

* test mode (can't play games with anticheat)

* sideloading with vulnerable driver but can be detected by ACs and think they are r0 cheats

* expensive cert from M$

I can write code independently (like G14Manager) that communicates with the kernel driver using the same protocol that Armory Crate uses. This falls under fair use for API (see Google LLC v. Oracle America Inc.), so that is fine.

However, if I were to write a kernel driver that uses the same protocol (basically compatible with Armory Crate/G14Manager), I have to have someone else writes the specification (e.g. Send IO code 1234 to device X with data package ABCD, then fan curve changes), then independently, without looking at the implementation of atkawmiacpi64.sys (e.g. no reverse engineering by me), then develop a kernel driver. As stated earlier, I've already reversed the kernel driver, so I cannot write a kernel driver that is compatible with AC/G14Manager (as currently implemented).

For full disclosure, G14Manager was developed under steps similar to:

1. Step up IO capture
2. Does thing in Armory Crate
3. See what IO packet comes out
4. Look at the ACPI (DSDT) table
5. Implement in G14Manager

(Standard disclaimer, IANAL.)