[Xiaomi Redmi 1S] thewisenerd:
as you might know, and as it will be around in a couple of days, yes,

balika011 open-sourced his kernel,

( sources here: https://github.com/miuihu/android_kernel_xiaomi_armor/tree/master )

my primary 'concern' here is with d2w though for others like @rebelos it should be

concerned with how he got camera working with kk stack :wink: :wink:

one feature that everyone wants, without any sort of battery drain, or other 'problems'*[1].

it was rumour-ed that balika011 ported d2w from a host of different devices with

native d2w*[2] like lg g2, g3, bq, etc, etc,

on-chip d2w*[3] was successfully implemented, blah, blah. all can be put to rest now.

truth is:

q:balika011 implemented d2w?

a:yes.

q: native?

a: yes.

q: on-chip?

a: no! as said before (i've been trying to, in irq, fb, etc), this needed

loading a custom touch scren firmware, doing which is hihgly improbable to do.

if there's an elephant in the room, address it:

q: is the implementation better?

a: of sorts. i'll explain at the end.

for now, here are the differences between current touch driver (from xiaomi) and balika011's implementaion of d2w.

1. kicked out fb notifier||earlysuspend to earlysuspend || native enable/disable calls

2. import #include <asm-generic/cputime.h> for timer cputime64_t

3. create new ft5x06_touch_data (unaligned, __packed) to store touches (from fn ft5x06_collect_finger)

4. add cputime64_t to ft5x06_finger

5. add early suspend to ft5x06_data

6. add struct input_dev * power_input to ft5x06_data

7. add power_finger of type ft5x06_finger to store prev finger touch

8. modify ft5x06_charger_state_changed to take bool param to enable/disable

9. ft5x06_power_supply_event: ignore calling ft5x06_charger_state_changed regardless of !ft5x06->in_suspend

10. use struct ft5x06_touch_data for ft5x06_collect_finger

11. ft5x06_report_touchevent: let cur touch be tch, prev touch be prev_tch

~~if in suspend

~~~~if tch.time - prev_tch.time > 200

~~~~~~if tch.time - prev_tch.time < 500 && abs(tch.x - prev_tch.x) < 50 && abs(tch.y - prev_tch.y) < 50

~~~~~~~~pwr_key_send

~~~~~~~~memset 0 prev_tch

~~~~~~else

~~~~~~~~prev_tch = tch

~~else

~~~~send_input_sync()

12. ft5x06_suspend

~~enable_irq_wake

~~use FT5X0X_POWER_ACTIVE mode

13. ft5x06_resume: disable_irq_wake

14. define ft5x06_input_disable, ft5x06_input_enable (since we don't have earlysuspend, iirc.)

15. misc changes with diffdata, test data, etc, etc, not required.

16. ft5x06_probe

~~memset 0 prev_tch

~~allocate ft5x06->power_input

~~ft5x06->input->enable = ft5x06_input_enable

~~ft5x06->input->disable = ft5x06_input_disable

~~add IRQF_NO_SUSPEND to request_threaded_irq

--------------------------------------------------------------------------------

that said, i'll get straight to the facts (though it isn't my place to be talking about this):

point 1: we do not have early_suspend. yes, we don't.

switching to native enable/disable calls. these calls are made every time a suspend

request is made to cpu *iirc*

so, that just kicked out need for a FB_notifier, thus essentially all those 'problematic'

issues are now likely gone.

point 3: creating a new structure ft5x06_touch_data for collecting all variable defines from ft5x06_collect_finger

is that good? maybe. keeps all data at one place, and it is __packed, so, memory *might* be used less.

what's the 'problem'? unaligned access. though it is supported, performance is debatable. not more into this

since i ain't much clear about it myself.

point 4: add cputime64_t to ft5x06_finger

not really going to affect us. since packets are sent/recieved in packet_data struct, this doesn't

really change anything

point 5: we don't have early suspend, so. it isn't even included. in short, we don't have

to worry about early suspend/resume issues till we have it in the first place.

point 6: creating new input_dev power_input. i'm really sort of 'against' this; but again, i don't think there's a choice for now

till someone figures out how to send keypress events through the touchscreen device itself. i recently worked on native d2w for Xperia L, and faced a 'similar' problem.

for what reasons am i against this? why an extra device? the input device itself can be used to

send in key presses.

also, if some 'stuff' is hardcoded to input devices in a particular order, it might break

a lot of stuff, like it did the recovery key combo (eventually fixed today) on xperia L.

tl;dr: extra input devices manually define: bad (sort of).

*note* : devices with native d2w mostly send keypress events through the touchscreen driver itself.

point 7: at this point, i would like to really take a timeout and point out at how similar

this d2w implementation is to the current one, but no. that's for the end.

as of now, know that this is just for storing the previous touch key press.

point 9: i'm not exactly sure why this change was made, but i guess i'll have to look

into it later.

point 10: refer to point 3

point 11: the d2w implementation. pretty self explainatory

in this; there's one thing that caught my attention. according to this implementation

what happens is: during touch screen suspend, NO input events are sent to the touchscreen.

copy-paste'ing my 'amusement' from irc:

<thewisenerd> eloimuns, also
<thewisenerd> balika ignore touch event send
<thewisenerd> i never thought of this tbh
<thewisenerd> awesome
<thewisenerd> not exactly helpful, but awesome
<thewisenerd> since touches with screen off are ignored, but who would have thought of this!?

point 12, 13: ft5x06_suspend

as usual implementation, same as we do now for d2w

point 14: the native enable/disable calls defines

point 15: misc changes, i don't think really necessary, but i shall look into it later

doesn't seem to be much important, and moreover, does the same thing, in a different way

point 16: same implementation as current d2w.

--------------------------------------------------------------------------------

now, how similar is this to current d2w?

1. both are not on-chip implementations

2. both use cputime64_t

3. both use custom input_dev

4. both store previous touch data in memory

5. both use very very similar suspend/resume implemetation

6. both use IRQF_NO_SUSPEND

so, it shouldn't be 'wrong' to say: 3/4th of it is similar.

what's different?

1. both store previous touch data in different places (not sure what 'effect' this

is going to cause, since eitherways, the ft5x06_finger struct isn't __packed or anything)

2. current implementation is modularized keeping d2w code out of touch panel, this is native.

3. current implementation supports all three panels supported by xiaomi, this supports just ft5x06

4. current implementation uses MONITOR mode, instead of ACTIVE mode when screen is suspended (i suggest

you look it up in the datasheet, the difference between the two)

5. current one has a switch

--------------------------------------------------------------------------------

adressing the other elephant in the room:

q: will this be used?

a: point 1, 3, and others strictly relating to d2w will be implemented. points 9, 15, etc will be ignored.

so, there'll be native d2w for ft5x06 while other two panels will continue using modular d2w.

that's about it with d2w and updates.

4am now (again); i guess i'll go catch up some sleep.

note: questions are welcome, i miss the discussion that used to be on XDA.

note to moderators: since balika011 has open-sourced his kernel, i guess some of the

infractions can now be lifted. also, xda is, was, and will be about

'development' and sort of hope it stays that way.

*[1]: will add later

*[2]: will add later

*[3]: will add later