-
Notifications
You must be signed in to change notification settings - Fork 11
Configurator: Move to browser-based UI #66
Comments
Hello, |
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++) |
I will see if I can free up some time to work on it. |
I'm interested in this portion too: 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. |
@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 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:
(Standard disclaimer, IANAL.) |
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 😊
The text was updated successfully, but these errors were encountered: