[Samsung Galaxy M12 SM-M127F] Touch breaks and must be reinitialized after every wakeup

[ap4ss3rby]

Per the title, the touchscreen breaks or more accurately is not reinitialized every time the screen turns off. I captured the attached log from stock while d2tw was turned on. These logs do not appear on phh v400.h , phh v313, as well as Andy Yan's lineageOS 19 (20220114). To revive the touchscreen the following commands have to be sent on every wakeup echo check_connection > /sys/class/sec/tsp/cmd cat /sys/class/sec/tsp/cmd_result Afterwards the touchscreen works normally until the next display power off sec_input_dmesg_stock.txt

[febeslmeisl]

I can confirm this issue on a Samsung Galaxy XCover 5 (G525F) also with v410.

Further analysis from my side:

• using "getevent" in adb shell: no events for touch are coming up after wake up
• using the plain ASOP image (aosp_arm64-exp-S3B1.220218.004-8242181-cfef6f25.zip from here) has same effect

At least I found an ugly workaround to use the device for now, with two shell scripts:

• install_handler.sh (piping getevent to wait for powerbutton release): getevent | grep "/dev/input/event2: 0001 0074 00000000" | ./recover_screen.sh
• recover_screen.sh (waiting for a new line (from piped getevent above) to perform the mitigation mentioned in post of @apass3rby): while read LINE; do; echo check_connection > /sys/class/sec/tsp/cmd; cat /sys/class/sec/tsp/cmd_result; done
  • executinginstall_handler.sh & as background process via adb recovers touchscreen after power button events.

Would be nice to have a real fix here, but at the moment I'm afraid have no time to dive deeper into kernel. Does anyone know how to fix it?

[ap4ss3rby]

I have read from some dev work that there is a certain function in dtb. So some work has to be done in phh aosp to account for it. I would link to the commit to the kernel used to fix this but the work is currently private and I am not the owner of said work.

[febeslmeisl]

I did some further investigation on the weekend and analyzed kernel logs of wake up on XCover 5: WakeUp_XCover5_dmesg.txt

I'm not sure if it is the same issue as originally reported for M12, because I definitely see the input_sec trying to download firmware to (in in case XCover 5) nt36525 controller, but failing the subsequent CRC check. If I compare to kernel logs to triggered "check_connection", two firmware files are downloaded:

• NVT-ts spi1.0: [sec_input] filename is tsp_novatek/nt36525_xcover5_mp.bin .....
• NVT-ts spi1.0: [sec_input] filename is tsp_novatek/nt36525_xcover5.bin -both passing the CRC-check: "nvt_update_firmware: Update firmware success!"

I'm relatively new to android GSI topic, so I'm afraid I'm lacking some information what role the GSI (or respectively the stock system image) plays in the display wake up process that could make a difference on the kernel or dtb (that GSI and stock image share). But trying my best to catch up, if I find some time the next days... Also hope anyone has more information to get this fixed...

[phhusson]

@febeslmeisl so you see the kernel trying to download a firmware every time you wake up the screen?

[febeslmeisl]

@phhusson That would be my interpretation of the dmesg logs attached above. It tries to download but then failing with the CRC check (but my hardware is the XCover5 not the M12 of the orginal post, but they seem simlar, because the open source kernel package from https://opensource.samsung.com for the G525F (XCover 5) also contained the M12S firmware files for touch). It shows error, retry=11, buf[1]=0x00, 0x00, 0x00, 0x00, 0x00 what I can see from the kernel code (\drivers\input\touchscreen\novatek\nt36525\nt36xxx_fw_update.c) is that only "0"-bytes are received via SPI from the controller after Firmware (and that of course fails the CRC). It seem a bit strange because it works later with same kernel method (nvt_ts_fw_update_from_mp_bin), when called via mentioned echo check_connection > /sys/class/sec/tsp/cmd may some timing issue/race condition after wake up? Not sure...

[phhusson]

Well, I would guess that loading firmware is an issue in itself, loading a firmware is pretty slow in the first place, it should happen only on boot, not on suspend.

Can you check from kernel source code whether touchscreen is put on reset during suspend, and if that's the case, if there are cases where it's NOT put in reset?

[febeslmeisl]

Thanks for the valueable hint. I could not find any explicit reset so far, but after some further digging in the kernel logs, I saw that the firmware update after reset might be just a fallback due to a previous error. There a lot of log items after wake up like

[  228.475726] NVT-ts spi1.0: [sec_input] i2c/spi packet checksum not match. (point_data[65]=0xFE, checksum=0x80)
[  228.475886] NVT-ts spi1.0: [sec_input] FE FE FE FE FE FE
...
[  228.476125] NVT-ts spi1.0: [sec_input] FE FE FE FE FE

finally resulting in

[  228.480120] NVT-ts spi1.0: [sec_input] Recover for fw reset, FE
[  228.480167] NVT-ts spi1.0: [sec_input] filename is tsp_novatek/nt36525_xcover5.bin

Kernel code (drivers\input\touchscreen\novatek\nt36525\nt36xxx.c) for this is

#if NVT_TOUCH_WDT_RECOVERY
   /* ESD protect by WDT */
   if (nvt_wdt_fw_recovery(point_data)) {
       input_err(true, &ts->client->dev,"Recover for fw reset, %02X\n", point_data[1]);
       nvt_update_firmware(ts->platdata->firmware_name);
       goto XFER_ERROR;
   }
#endif /* #if NVT_TOUCH_WDT_RECOVERY */

From comments I guess this code is normally for physical ESD issues, but actually in our case the first i2c/spi packet checksum not match occurs directly after downloading firmware for the first time (after boot or check_connection):

[   51.981743] NVT-ts spi1.0: [sec_input] nvt_update_firmware BUILT-IN Update update_firmware_release
[   51.981820] NVT-ts spi1.0: [sec_input] check_connection: OK
[   51.981989] NVT-ts spi1.0: [sec_input] i2c/spi packet checksum not match. (point_data[65]=0xFF, checksum=0x40)
[   51.982002] NVT-ts spi1.0: [sec_input] FF FF FF FF FF FF
...
[   51.982089] NVT-ts spi1.0: [sec_input] FF FF FF FF FF
[   51.982302] NVT-ts spi1.0: [sec_input] i2c/spi packet checksum not match. (point_data[65]=0xFF, checksum=0x40)
[   51.982314] NVT-ts spi1.0: [sec_input] FF FF FF FF FF FF
...
[   51.982399] NVT-ts spi1.0: [sec_input] FF FF FF FF FF
[   51.982849] [sec_input] sec_cmd_show_result: check_connection:OK\x0a

But here upload will be reported as success and touch still seems to work (perhaps because first tsp_novatek/nt36525_xcover5_mp.bin is flashed before tsp_novatek/nt36525_xcover5.bin on start, while only nt36525_xcover5.bin is flashed on recover?!?) until it goes to sleep. Also after wakeup all read bytes changed from FF to FE Before sleep: [ 51.982314] NVT-ts spi1.0: [sec_input] FF FF FF FF FF FF After sleep: [ 228.437975] NVT-ts spi1.0: [sec_input] FE FE FE FE FE FE

So for me actually the most unclear points with this issue are:

• Why does touchpanel work even if there are already "i2c/spi packet checksum not match" errors
• Why does the raw data leading to checksum error change from FF to FE after sleep/wake up

• Why do we have two firmware files flashed (mp/normal?!?) after each other in a lot of cases: See e.g. kernelcode of check_connection() in nt36xxx_sec_fn.c:

      //---Download MP FW---
  nvt_ts_fw_update_from_mp_bin(ts, true);
  
  ret = nvt_ts_open_test(ts);
  
  //---Download Normal FW---
  nvt_ts_fw_update_from_mp_bin(ts, false);

  or function run_self_lpwg_rawdata_read():

      //---Download MP FW---
  nvt_ts_fw_update_from_mp_bin(ts, true);
  
  if (nvt_ts_lpwg_rawdata_read(ts, raw_buff))
      goto err;
  
  nvt_ts_print_buff(ts, raw_buff, &min, &max);
  
  //---Download Normal FW---
  nvt_ts_fw_update_from_mp_bin(ts, false);

  (and many more occurences like this, where first the _mp.bin is flashed, some operation is done and later "normal" firmware will be flashed)

[phhusson]

Could you attach drivers\input\touchscreen\novatek\nt36525 ?

[febeslmeisl]

Sure ;) nt36525.zip

[phhusson]

Ok, so let's start by trying to enable aot. give the content of /sys/class/tsp/sec/cmd_list

[phhusson]

(aot will prevent the driver from putting the touchscreen into low power mode, which uh, might have some effects)

[febeslmeisl]

Thanks for your support: List of command follows:

1|:/data/data # cat /sys/class/sec/tsp/cmd_list
++factory command list++
fw_update
get_fw_ver_bin
get_fw_ver_ic
get_x_num
get_y_num
get_chip_vendor
get_chip_name
get_threshold
check_connection
glove_mode
aot_enable
set_sip_mode
set_game_mode
ear_detect_enable
prox_lp_scan_mode
dead_zone_enable
run_self_lpwg_rawdata_read
run_self_lpwg_rawdata_read_all_lcdoff
run_self_lpwg_noise_min_read
run_self_lpwg_noise_min_read_all_lcdoff
run_self_lpwg_noise_max_read
run_self_lpwg_noise_max_read_all_lcdoff
run_self_fdm_rawdata_read
run_self_fdm_rawdata_read_all_lcdoff
run_self_fdm_noise_min_read
run_self_fdm_noise_min_read_all_lcdoff
run_self_fdm_noise_max_read
run_self_fdm_noise_max_read_all_lcdoff
run_self_open_raw_read
run_self_open_raw_read_all
run_self_open_uni_read
run_self_open_uni_read_all
run_self_short_read
run_self_rawdata_read
run_self_rawdata_read_all
run_self_ccdata_read
run_self_ccdata_read_all
run_self_noise_min_read
run_self_noise_max_read
run_trx_short_test
run_sram_test
run_prox_intensity_read_all
factory_cmd_result_all
incell_power_control
factory_lcdoff_cmd_result_all

[febeslmeisl]

As far as I could see, disabling of AOT had not effect on the issue:

:/data/data # echo -n "aot_enable,0"> /sys/class/sec/tsp/cmd
1|:/data/data # cat /sys/class/sec/tsp/cmd_result
aot_enable,0:OK

Command suceeeded, but touch still not responding after sleep/wakeup. `

[phhusson]

I said to enable aot, not disable :P

[febeslmeisl]

Ok I should read more carefully, but I actually tried both: aot_enable,0:OK and aot_enable,1:OK still not reponse after sleep :'(

[phhusson]

k, in ps -A you should see two power HALs (something like android.hardware.power@2.0-service and vendor.samsung.hardware.power@1.0-service), do you see them? If you do, do a logcat --pid=<pid> for both of them, and dump here logs of both of those independantly, when doing suspend/resume

[febeslmeisl]

Sure here it comes, but no output from these pids during sleep/wake cycle, see below. Will check with logcat verbose detail level, will attach it in a minute....

130|:/data/data # ps -A | grep power
root            22     2       0      0 worker_thread       0 I [kworker/1:0-events_power_efficient]
root            76     2       0      0 worker_thread       0 I [kworker/u18:0-kbase_pm_shader_powerof]
root           153     2       0      0 worker_thread       0 I [kworker/1:1-events_power_efficient]
root           162     2       0      0 worker_thread       0 I [kworker/u18:1-kbase_pm_poweroff_wait]
root           245     2       0      0 worker_thread       0 I [kworker/1:2-events_power_efficient]
system         821     1 10855840  5676 binder_ioctl_write_read 0 S android.hardware.power.samsung-service
system         823     1 10911536  4412 binder_ioctl_write_read 0 S vendor.samsung.hardware.miscpower@2.0-service
root          1865     2       0      0 worker_thread       0 I [kworker/u18:3-kbase_pm_shader_powerof]
root          2802     2       0      0 worker_thread       0 I [kworker/2:2-events_power_efficient]
:/data/data # logcat --pid=821
^C
130|:/data/data # logcat --pid=823
^C
130|:/data/data #

[phhusson]

AH. That could be the issue. Check whether really nothing happens at all when doing suspend/resume with strace -p 821

[febeslmeisl]

After starting strace:

:/data/data # strace -p 821
strace: Process 821 attached
ioctl(3, BINDER_WRITE_READ

then poweroff -> nothing happens. power on:

ioctl(3, BINDER_WRITE_READ, 0x7fec61cac8) = 0
ioctl(3, BINDER_WRITE_READ, 0x7fec61b378) = 0
ioctl(3, BINDER_WRITE_READ

Every futher power on still

ioctl(3, BINDER_WRITE_READ, 0x7fec61cac8) = 0
ioctl(3, BINDER_WRITE_READ, 0x7fec61b378) = 0

For pid 823 strace shows for every power off and on:

ioctl(5, BINDER_WRITE_READ, 0x7feb8efac0) = 0

[phhusson]

I think having the same logcats done on stock rom would be useful, can you do that?

[febeslmeisl]

Here it comes: android.hardware.power.samsung-service -> has not output on sleep/wakeup only one line of log that threadloop is started. for vendor.samsung.hardware.miscpower@2.0-service you can see /sys/class/power_supply/battery/lcd: 0 on sleep resp. lcd: 1 on wake, see below

130|xcover5:/ $ ps -A | grep power
root            162      2       0      0 0                   0 I [kworker/u18:1-kbase_pm_poweroff_wait]
system          560      1 2164660   2640 0                   0 S android.hardware.power.samsung-service
system          564      1 2135408   2736 0                   0 S vendor.samsung.hardware.miscpower@2.0-service
root           5646      2       0      0 0                   0 I [kworker/u18:3-kbase_pm_poweroff_wait]
root          20554      2       0      0 0                   0 I [kworker/5:0-events_power_efficient]
xcover5:/ $ logcat --pid=560
--------- beginning of main
02-14 08:50:58.516   560  1720 I SS_POWER_HAL_QOS: threadLoop [DEXOPT] starting
^C
130|xcover5:/ $ logcat --pid=564
--------- beginning of main
01-01 13:00:25.050   564   564 D vendor.samsung.hardware.miscpower@2.0-service: sec-miscpower-2-0 starts
01-01 13:00:25.055   564   564 I HidlServiceManagement: Registered vendor.samsung.hardware.miscpower@2.0::ISehMiscPower/default
01-01 13:00:25.055   564   564 I HidlServiceManagement: Removing namespace from process name vendor.samsung.hardware.miscpower@2.0-service to miscpower@2.0-service.
01-01 13:00:53.958   564  1013 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 1
01-01 13:00:53.959   564  1013 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 1
02-14 08:53:34.723   564 16723 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 0
02-14 08:53:34.723   564 16723 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 0
02-14 08:53:36.212   564 16916 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 1
02-14 08:53:36.212   564 16916 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 1
02-14 08:54:51.611   564 23000 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 0
02-14 08:54:51.611   564 23000 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 0
02-14 08:55:23.246   564 25468 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 1
02-14 08:55:23.247   564 25468 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 1
02-14 08:55:58.025   564 25683 I Sec MiscPowerHAL: !@sysfs_write +: /sys/class/power_supply/battery/lcd: 0
02-14 08:55:58.025   564 25683 I Sec MiscPowerHAL: !@sysfs_write -: /sys/class/power_supply/battery/lcd: 0

[phhusson]

While you're there, also take full logs:

1. Right after reboot adb logcat -b all -d > log-at-boot.txt
2. For suspend/resume: Do adb logcat -b all -c three times to purge logs, then do suspend resume, then do adb logcat -b all -d > log-cycle.txt
3. The result of getprop
4. The result of lshal

Le ven. 8 avr. 2022 à 12:51, Felix @.***> a écrit :

Sure, but this will take some time to reflash. Will post results here

— Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/2205#issuecomment-1092734012, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA4OQZ7J5GDQVO2WMP3LTVEAFSBANCNFSM5O7W5SXQ . You are receiving this because you were mentioned.Message ID: @.***>

[febeslmeisl]

Stock ROM logcat for power HALs updated, see above. Here comes the rest

• log-at-boot.txt
• log-cycle.txt
• getprops.txt
• lshal.txt

Please let me know if further logs might become required/helpful for the analysis...

[phhusson]

Somewhere on the internet, on https://t.me/exynos850updates/8, there is this:

Exynos 850 • Updates, [16/02/2022 18:17]
Touchscreen fix for Exynos 850 (OneUI 3.x ONLY)

Tired of needing retarded scripts for the touchscreen?
Flash these images, and enjoy!

How to flash?

Reboot to download mode by turning your device off, and connecting the USB-C cable while holding both of the volume keys.

- Heimdall

Flash the dtbo.img file using the command heimdall flash —UP_PARAM dtbo.img.

dtbo.img.zip

Assuming you have your original dtbo/UP_PARAM, you could try this, and report back the result.

You could also try to make the diff between the original and this one

[febeslmeisl]

Ah ok, this might be the thing apass3rby mentioned in his post regarding device tree blob fix. Will try it out and post a compare of the DTB dump.

[ap4ss3rby]

Yep that's the private work. Currently source is closed (mostly due to being experimental). I personally tested it and it worked perfectly fine. No workarounds or fixes required system-side

[phhusson]

Being closed source is utterly stupid. K, can you give me the original UP_PARAM/dtbo, so I can make the comparaison?

[ap4ss3rby]

dtbo.zip This is taken directly from stock firmware downloaded using samfirm

[febeslmeisl]

I tried to flash the first dtbo.zip, but was caught in bootloop after that. I suppose the first the command of the telegram post is wrong describing it to flash it to UP_PARAM. It should read DTBO, I think. But even when flashing there it did not work on my device (maybe because I have XCover 5, not M12). Will try the new zip from apass3rby now...

[phhusson]

Thanks @apass3rby . So the "mysterious magical private experimental closed source" change is to enable iliteck,enable_sysinput_enabled which disables a notifier based on screen state to suspend/resume touchscreen, which disables Touchscreen suspend/resume altogether.

Reading again the driver's source code, I realized a mistake I made @febeslmeisl when asking you to enable aot. enabling AOT isn't enough to prevent low power mode, it also requires either ear_detect_enable or prox_power_off

So, try again but with both aot_enable and ear_detect_enable enabled (not disabled ;-)

[ap4ss3rby]

Cool. AFAIK this is only a very small part in building native LineageOS, there were some experimental builds done but still no public source access.

[phhusson]

@febeslmeisl The other alternative, is to try aot_enable, without ear_detecte_enable but with echo 1 > /sys/class/sec/tsp/prox_power_off

[febeslmeisl]

Ok, so I flashed back to orginal dtbo.img and GSI. Now enabling ;) both aot_enable and ear_detect_enable:

:/data/data # cat /sys/class/sec/tsp/cmd_result
aot_enable,1:OK
:/data/data # cat /sys/class/sec/tsp/cmd_result
ear_detect_enable,1:NG

Error message for ear_detect_enable in dmesg logs: [ 505.898445] NVT-ts spi1.0: [sec_input] ear_detect_enable: Not support EarDetection! Trying echo 1 > /sys/class/sec/tsp/prox_power_off now...

[febeslmeisl]

Setting prox_power_off with aot_enable does not have any effect. Still touch is not reponsive after wake up. :( Will check kernel logs and compare with kernel/driver source code, if it was actually set...

[febeslmeisl]

It seems that changes are to prox_power_off are reflected:

[  171.309617] [sec_input] sec_cmd_show_result: aot_enable,1:OK\x0a
[  179.615074] NVT-ts spi1.0: [sec_input] prox_power_off_store: 1

But still same issues like [ 249.563794] NVT-ts spi1.0: [sec_input] i2c/spi packet checksum not match. (point_data[65]=0xFE, checksum=0x80) after wake up.

Also saw some message that /dev/phh-ota file not found exception in logcat output, but I think this is rather related to my playing with Updater feature (might file a separate issue for that) then related to touchscreen, right?

[phhusson]

yup it's not related to touchscreen at all

Le lun. 11 avr. 2022 à 14:24, Felix @.***> a écrit :

It seems that changes are to prox_power_off are reflected:

[ 171.309617] [sec_input] sec_cmd_show_result: aot_enable,1:OK\x0a [ 179.615074] NVT-ts spi1.0: [sec_input] prox_power_off_store: 1

But still same issues like [ 249.563794] NVT-ts spi1.0: [sec_input] i2c/spi packet checksum not match. (point_data[65]=0xFE, checksum=0x80) after wake up.

Also saw some message that /dev/phh-ota file not found exception in logcat output, but I think this is rather related to my playing with Updater feature (might file a separate issue for that) then related to touchscreen, right?

— Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/2205#issuecomment-1094985181, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA4ORZTV7TQNKGIYBBXNTVEQKXHANCNFSM5O7W5SXQ . You are receiving this because you were mentioned.Message ID: @.***>

[ap4ss3rby]

In perhaps comedic timing the kernel repo is now public, and I suppose I can talk freely about it now. There are a fair bit of changes that apply to GSIs (AFAIK) MTP as well as the aforementioned changes to dtb. The repo is here https://github.com/exynos850-dev/android_kernel_samsung_exynos850

[febeslmeisl]

I did some further analyses of the log-cycle compare to stock log from above. In the PHH-GSI log-cycle-phh.txt we have some permissions issues (SELinux), like

04-10 08:03:02.191  1053  1053 I auditd  : type=1400 audit(0.0:10934): avc: denied { getattr } for comm="Binder:1053_2" scontext=u:r:surfaceflinger:s0 tcontext=u:r:system_server:s0 tclass=process permissive=0
04-10 08:03:02.191  1053  1053 W Binder:1053_2: type=1400 audit(0.0:10934): avc: denied { getattr } for scontext=u:r:surfaceflinger:s0 tcontext=u:r:system_server:s0 tclass=process permissive=0

Maybe this could be relevant for sleep/wake up issues.

(I came across this while looking at the phh-ota-make service issue, that is "not related to touchscreen at all" ;) having also permission problems 04-11 15:45:44.476 4211 4211 W phh-ota : type=1400 audit(0.0:45754): avc: denied { ioctl } for path="/dev/block/mmcblk0p38" dev="tmpfs" ino=1161 ioctlcmd=0x127a scontext=u:r:phhsu_daemon:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file permissive=0);

Will have a look into selinux config, if I find some time...

[febeslmeisl]

Update: Booted my device with selinux permissive, but no luck on this issue. Still same errors in log. Will check in a next step, if I can at least use the dtbo workaround mentioned above adapted for my device. (also created #2289 for OTA issue with /dev/phh-ota detected above)

[febeslmeisl]

I can also confirm now on xcover5 that removingnovatek,enable_sysinput_enabled from dtbo "fixed" the touch issue after wake up (special thanks to your previous posts and this rainy sunday afternoon leaving me time for setting up dtbo and avb toolchain). But my understanding and as far as I understood @phhusson's previous post, this is more a workaround than a fix.

I've checked kernel logs during wakeup again with new DTBO and actually the firmware upload of "sec-input" driver is different now, it's only updating tsp_novatek/nt36525_xcover5.bin, not als the "_mp" variant as before during wake cycle. And it has no checksum check errors in the kernel logs, see attached file kernelLogAfterDTBOfix.txt while during startup there are still these checksum errors (and "_mp" firmware update) like we had it before... kernelAfterDTBOFixStart.txt

I'm a little confused now:

• Device seems to work (maybe consuming more battery without enable_sysinput_enabled?)
• Why does stock rom work with enable_sysinput_enabled in dtbo and GSI not (still main unsolved issue as of my understanding)
• Any ideas where I can dig deeper to find the real difference between stock and GSI image for this issue? Please let me know...

[m23user]

I can also confirm now on xcover5 that removingnovatek,enable_sysinput_enabled from dtbo "fixed" the touch issue after wake up (special thanks to your previous posts and this rainy sunday afternoon leaving me time for setting up dtbo and avb toolchain). But my understanding and as far as I understood @phhusson's previous post, this is more a workaround than a fix.

I've checked kernel logs during wakeup again with new DTBO and actually the firmware upload of "sec-input" driver is different now, it's only updating tsp_novatek/nt36525_xcover5.bin, not als the "_mp" variant as before during wake cycle. And it has no checksum check errors in the kernel logs, see attached file kernelLogAfterDTBOfix.txt while during startup there are still these checksum errors (and "_mp" firmware update) like we had it before... kernelAfterDTBOFixStart.txt

I'm a little confused now:

* Device seems to work (maybe consuming more battery without `enable_sysinput_enabled`?)

* Why does stock rom work with `enable_sysinput_enabled` in dtbo and GSI not (still main unsolved issue as of my understanding)

* Any ideas where I can dig deeper to find the real difference between stock and GSI image for this issue? Please let me know...

Sir, may I ask as a noob that how did you do removing of "novatek,enable_sysinput_enabled" thingy from dtbo thingy? I may sound quite noob and totally clueless but I'm desperately searching for a solution or a workaround that works in order to make GSIs work on my galaxy f23. Can you give an idiotproof tutorial, what should I do to reach at your point of removing "novatek,enable_sysinput_enabled" thing?

[febeslmeisl]

Sir, may I ask as a noob that how did you do removing of "novatek,enable_sysinput_enabled" thingy from dtbo thingy? I may sound quite noob and totally clueless but I'm desperately searching for a solution or a workaround that works in order to make GSIs work on my galaxy f23. Can you give an idiotproof tutorial, what should I do to reach at your point of removing "novatek,enable_sysinput_enabled" thing?

Hello! I'm not sure if I can give a "idiotproof tutorial" nor if this github-issue is the right place to discuss it, but for documentation I can give an outline what I did back then from what I remeber. Unfortunately the linux VW were I set up the toolchain is no longer availble to me, because of an SSD-Hardware failure, so I cannot reproduce the exact steps now for writing a sophisticated documentation.

Here are the coarse steps as far as I remember:

• I downloaded the most recent Version of the original (Samsung) firmware packages (There's a tool around to get the whole package as zip archive containing some tar-files to your PC)
• One of this tar files started with AP_<some device/version nummer>.tar an contains the orginal image for the DTBO (dtbo.img.lz4)
• This has to be decompressed (lz4) to get raw dtbo.img
• Next thing is to get the orginal source back from the compliled dtbo.img. This will produce some dts-files, which are more or less human readable. I think there was intermediate step involved because the dtbo.img contained multiple images for different HW-Revision. First the files for each revision has to be extracted and later "decompiled" ->I'm not sure any more which tools I used (this was some linux commanline tool I found after searching the internet). You can maybe use this as reference. Probaly the "mkdtimg" was involved in this step.
• You can now edit the dts-files (for example replacing enable_sysinput_enabled line)
• Now a new dtbo image has to be repacked from the sources (sorry also not remembering the exact tooling)
  • again some tooling to create the binaries for each hardware revision) -> I think I used ubuntu package "device-tree-compiler"
  • and further tool for packaging back to dtbo.img with correct alignment -> I think I used some stuff like "mkdtimg create" with a lot of meta information to be specified, which can be more or less obtained from the original dtbo.img via "mkdtimg dump")
  • I also did a quick check with binary file compare tool, if the original dtbo.img looks similar the new created one to see if it is plausible that flashing it will not crash the whole phone
• then again lz4 compressing of the new Image to get new dtbo.img.lz4
• finally packing the new dtbo.img.lz4 in a tar file and flashing it with the Samsungs Odin3 tool to the Device (as AP)

I'm afraid this is some way to go if you start at zero and sorry for being not able to resproduce exact steps. Maybe someone has an easier solution and/or some better tooling for this?!? I nevertheless hope this helps you to get your phone working, but be aware that there's always a risk of breaking the phone, when flashing wrong content.

BR and Merry Christmas!

[m23user]

Thank you so much for the effort you put! I will try to execute these steps as much as I could understand. Hope I don't brick the phone lol

Merry Christmas!

[phhusson]

There should be a fix in latest trebledroid a13 ci if you could try it. (So that's without changing dtbo)

[m23user]

I've been trying the latest a13 ci build and it just works! Incredible! Thank you so so much for all of your efforts! By the way, just an idea: maybe you can add "touchscreen fix" or something like that to changelog of the latest build so that others can be informed. I hadn't installed this latest build just because looking to the changelog and not seeing any fixes about anything. Just "CI build" phrase misled me about nothing has changed over the last build of a13. Anyway, thank all of you sincerely.

Merry Christmas!

[phhusson]

Thanks for the report. I plan to automate generating change logs, but it requires some work, and doing it by hand is annoying

On December 21, 2022 9:47:59 PM GMT+01:00, m23user @.***> wrote:

I've been trying the latest a13 ci build and it just works! Incredible! Thank you so so much for all of your efforts! By the way, just an idea: maybe you can add "touchscreen fix" or something like that to changelog of the latest build so that others can be informed. I hadn't installed this latest build just because looking to the changelog and not seeing any fixes about anything. Just "CI build" phrase misled me about nothing has changed over the last build of a13. Anyway, thank all of you sincerely.

Merry Christmas!

-- Reply to this email directly or view it on GitHub: https://github.com/phhusson/treble_experimentations/issues/2205#issuecomment-1362074522 You are receiving this because you were mentioned.

Message ID: @.***>

[m23user]

Just as I said, what I say is just a humble recommendation. You know what to do better than me of course :) Have a nice work sir!

[m23user]

Just as I said, what I say is just a humble recommendation. You know what to do better than me of course :) Have a nice work sir!

By the way, do you plan adding gapps or floss variants of a13 ci builds? Having microG preinstalled on this fixed build would be astonishing lol

[m23user]

Just out of curiosity, may I ask what did you do as a fix in the latest ci build? Is there a way to apply the fix you did to an older gsi rom (such as android 11)? I very much like android 11's UI because it combines old and flatter android lines with newer icons and gesture navigation animations etc. Is it possible to use v313 aosp gsi rom of yours with the fix you put in the latest a13 ci build?

[phhusson]

https://github.com/TrebleDroid/platform_frameworks_base/commit/e3602b7dd7316c15fd98c5d5c6ca3b9461436074

That's the fix. You can't install it as a user, but you could rebuild a v313 with it. Maybe if i'm in the right mood I can do it, but it's unlikely