Please remove my name from the readme.md

[wern-apfel]

Thanks. No more comments from me.

[wern-apfel]

Actually, I did not want to say anything more on this subject.
For lack of time, I usually just skim the posts. Maybe I just misunderstood something. If that is really the case, I must apologize.

What do you mean by: (as he complained here) for some SSDTs for Qonfused's work ??
I have fixed the ScreenPad toggle and brightness adjustment, as well as the battery threshold and FN key lock. Even though the fix looks different, that doesn't mean it's from him.

[Qonfused]

The screenpad fix in my repo is not from you; please take a look here: src/ACPI/SSDT-SPLC.dsl

This re-implements the DEVS methods based off work from @Plippo in the asus-wmi-screenpad repository. I made a note of this here when you first mentioned it for your EFI. I have a breakdown of references + notes here that explains how it works. I've given another explanation of how these WMI methods work in his repo for other screenpad devices here based on this work, as his implementation is not yet complete.

The FN key lock however was documented by @hieplpvip in his AsusSMC repo. Additionally, based on your implementation for the keyboard SKBV method, I believe this to be your original source. I'm also upstreaming changes to that repo here if you want a better look at how DSTS + DEVS methods are used by the screenpad driver (windows).

I have given you attribution in my own repo here and @shiecldk's repo (fork/PR) here for not just the FN+Lock and screenpad changes; your work encompassed the ATKD functionality of the repo. I've since moved away from using ACPI patches to control ATKD methods and the screenpad in #40. The reason why your ACPI patches aren't more commonplace is that they're incorporated in projects like AsusSMC that work between kernelspace + userspace.

[Qonfused]

I've outlined the rationale for this in my #6 issue that I linked after you first mentioned/introduced your screenpad fix in #4. I discuss the reasoning for moving away from direct EC register writes here, and for why using DSTS + DEVS methods are preferrable across different devices + BIOS versions.

I have made no error in misrepresenting attribution or the source of own my work, and neither has @shiecldk.

If you're new to the open-source world, attribution is for giving credit based on people's work + time invested; rarely is there novelty in the kind of work done. There is no adversarial relationship here.