[DEV][SUGG] On dock lid states and kernels

[K900]

So the thing is, most JB ROMs for TF101 (I think that's actually all ROMs but AOKP) use a userspace hack to invert the dock lid state before propagating it to the power management code in the framework. It is, of course, a solution, but it's rather ugly and it clutters the global framework with code that's actually needed for one or two devices in total.
So I suggest that instead of messing around with the userspace, we need to fix the bug in device specific code, i.e. the kernel. I've made a kernel patch long ago for AOKP, but now I'm experiencing problems with other kernels on unmodified userspace, so I decided to post it here and see if other developers/ROMs accept it.
There is already a framework for 'inverting' the result in the kernel, so I reused that, and that made a very simple patch. All it does is check for any switch input (a.k.a. the dock lid) and set its active_low flag to 1, which makes the kernel invert the received data. Since the code is in gpio-keys, it's very unlikely to conflict with any external devices.
The source for the patch is available on my GitHub, it should work with kernel, though I built it for AOKP kernel, which is stock .39 + bcmdhd.
So, framework hacks vs. kernel hacks, discuss.

 

[RaymanFX]

So the thing is, most JB ROMs for TF101 (I think that's actually all ROMs but AOKP) use a userspace hack to invert the dock lid state before propagating it to the power management code in the framework. It is, of course, a solution, but it's rather ugly and it clutters the global framework with code that's actually needed for one or two devices in total.
So I suggest that instead of messing around with the userspace, we need to fix the bug in device specific code, i.e. the kernel. I've made a kernel patch long ago for AOKP, but now I'm experiencing problems with other kernels on unmodified userspace, so I decided to post it here and see if other developers/ROMs accept it.
There is already a framework for 'inverting' the result in the kernel, so I reused that, and that made a very simple patch. All it does is check for any switch input (a.k.a. the dock lid) and set its active_low flag to 1, which makes the kernel invert the received data. Since the code is in gpio-keys, it's very unlikely to conflict with any external devices.
The source for the patch is available on my GitHub, it should work with kernel, though I built it for AOKP kernel, which is stock .39 + bcmdhd.
So, framework hacks vs. kernel hacks, discuss.

Nice to see you again, old friend.

I have already developed like the same hack for my new CyanogenMod kernel, just that I am using a seperate c class to perform the switch each time the native asus code does receive a signal requesting to change the dock status.

So, generally, I would say this is a good idea and the way this problem should be solved.
The whole problem should stay in a low-level kernel space and never ever even require a userspace fix.

We just have to keep this on track, and maybe do a collection of how to-compile-kernels and some collection of tweaks, e.g. I can share my governor's code and so on. This should be a sticky then, so no developer for the TF101 can ever miss it.
If people request this I can do this. Just need some opinion.

So, after all, +1 to your (and mine, not yet shared) solution.

 

[K900]

I have already developed like the same hack for my new CyanogenMod kernel, just that I am using a seperate c class to perform the switch each time the native asus code does receive a signal requesting to change the dock status.

The logic's already there, just use my patch, seriously. Also, that's why you read kernel docs before coding stuff, toldya
Also I never really disappeared, you have my GTalk and I have the thread on Rootz. Don't want to post it here though, because XDA is, well, messy. And Rootz, at least for now, is less messy. Kinda. That's what I was thinking. Also keeping close to AOKP official forums.