Looks good, I was thinking of porting stratosks dT2w since it only allows you to tap the middle of the screen and prevents unwanted screen wakelocks. But nonetheless nice port from showp's dt2w.
stratosk's implementation of dt2w is a native implementation on the lge_touch_core panel driver. Also, could you please explain how allowing a tap in the middle of screen prevents unwanted wakelocks? Again, just which part of showp1984's or straosk's implementation do you think holds wakelocks?
In the first place, as far as I know, there is no wakelock being held in either straosk's implementation, or showp1984's implementation.
stratosk's implementation however holds a wakelock once a touch is made for 700ms which is the same as the DTW_MAX_INTERVAL, 700ms. stratosk himself said in
[email protected] that this is to prevent the kernel to suspend once a touch is made.
this might actually be a safety harness. why? because touch_power[_off|_on] functions check if d2w is enabled, all queued work is cancelled; ts_events released, and enable_irq_wake called on the i2c_client ( touch_power_off), or if touch_power_on, again if any wakelocks held, are released (the 700ms wakelock), disable_irq_wake called and all queued work cancelled, and ts_events released.
once a touch is made with the panel in supposed suspend, a wakelock for 700 ms is held.
what's to be looked at here, is that everytime touchscreen_suspend is called, stratosk chose to reset the touch variables. this is primary reason why he has a wakelock in place to actually hold the previous touch data for at least 700ms till the next touch.
this was the primal reason for the wakelock with stratosk's wakelock. however, showp1984's implementation of d2w does not need this wakelock since previous touch events are not erased with every ts suspend (main reason: maybe not intended, but: lesser memory writes).
thus, even if irq wakes kernel from suspend, a touch is detected, kernel can go back to sleep, safe and sound, and will be waken next time irq is recieved.
so, 'unwanted screen wakelocks' (in your very own words):
stratosk: 1
showp1984: 0
I think however that you got this the other way around.
Now, that's 'my' understanding of how the wakelocks work; i'd be glad if can 'enlighten' me how they work otherwise.
Also, about the 'tap the middle of the screen' to wake; I am not so sure about it. It is just four more cpu cycles, un-needed.
IMO, there should be just 3 checks in the d2w func; the abs(delta(x)), the abs(delta
), and time_interval; and that's all that's needed. Unfortunately, this is not the case in many many d2w implementations, except the one that I'm writing right now, in works.
-----------------------------
'nice port'? heck no!
the actual challenge with porting d2w to a device is figuring out the workflow of the touch panel, whether they use the System Sleep model or the runtime power management model (Devices that have early suspend/resume usually use the latter), and correctly hooking into the _suspend|_resume functions to keep the touch panel awake. I do not need to explain how or why d2w does not drain battery 'unnecessarily'; and I'm tired of having to explain how the entire thing works across the forum on every device that I've ported d2w to.
However, I'm tempted to give a quick gist, since everyone seems to be worried about 'wakelocks', and 'battery'. Wait. I just changed my mind.
The main reason for the deep sleep issues with d2w is every time a touch is made; the irq needs to be handled. This is because of native d2w or modular d2w; but with on-chip d2w, this is not the case where irqs are sent by the chip itself iff a d2w touch is made. native d2w has 'some' advantages over modular d2w; however I'm not going to explain all of it now, and don't find any reasons for doing it thou.
I saw your post on the other thread in the same forum;
Dude I wont risk instability and break sensors with dt2w, I had a look at that port and I tell you now, you'll have a lot of issues.
If dt2w were to be stable, it should've been in this kernel before.
and would like to know which part of d2w do you perceive to be causing instability? Yes, it is currently instable. As I said, heck no! this is not a nice port. I do not have access to a hackable mi3, the reason why I'm not able to fix the issues with the atmel _suspend|_resume as quickly as I would've if I actually had access to logs, a lot of them, to figure out the workflow of the runtime power management in atmel.
Also, could you please explain how is d2w going to break sensors? Which part of 'any' d2w implementation has broken sensors, even unintentionally? While you're doing that, also list out the issues that we're going to face.
Finally, since you said that if dt2w were stable, it'd have been in your kernel. So, I'm guessing you've already tried to port d2w, in which case, could you be kind enough to help us with the current _suspend|_resume issues we're facing with atmel?
Thanks and regards,
thewisenerd.
