Jump to content

[maybe solved] Touchscreen does not react after flashing an new ROM


Guest Seb801

Recommended Posts

Guest evgenyo
CM7 Gen1 test OK~

Touchscreen works!

:)

Guys, could you please provide a step-by step guide on how to apply the fix? Thanks in advance.

Link to comment
Share on other sites

Guest RamanRB
As i understood - this is not original CM kernel, right? I see 2.6.32.9, while CM supposed to be 2.6.37

It should be original. I have CM 7.0.0 stable and it has 2.6.32.9-perf kernel.

Link to comment
Share on other sites

Guest RamanRB
Guys, could you please provide a step-by step guide on how to apply the fix? Thanks in advance.

I believe you need to reboot into Recovery (Power+Volume down) and then Choose zip -> choose cm_kernelb10.zip, then Install zip. Confirm installation and it will just replace one kernel with another. It is the so-called "update.zip" method when you may replace any system files on those you wish without rebuilding whole package.

...I will wait till someone more experienced in Android than me would confirm :)

Link to comment
Share on other sites

Guest RamanRB

Works for me! Have flashed update, wiped the cache & dalvik cache, then rebooted via recovery. It took some more time than usual, btw. Touchscreen works! In ~30 minutes I have rebooted again just to make sure. It works again!

What is the difference? Screen set to max brightness on start, perhaps it is the reset we were told about.

Huge thanks from me and mine OSF back cover :)

Link to comment
Share on other sites

Guest leromarinvit
I'm a bit confused. I thought the ZTE kernel source (link) when I said official ZTE kernel. Why did try to find fixes in the binary instead of source?

This is the kernel tree all custom Blade kernels (at least for Froyo and CM7) are based on. Unfortunately, it's too old to contain a fix for the touchscreen problem. Also, it's 2.6.32, while the version they ship with Eclair is 2.6.29. There is a 2.6.29 download too on ZTE's website, but it's even older and AFAIK doesn't even work. There was a long thread some months ago about this, and it seemed that ZTE were stupid enough to lose the source for the kernel binary they actually shipped. To me, it seems that they must have found it again after all, otherwise they wouldn't have been able to fix the touchscreen problem in the kernel. But so far, they haven't released any updates for the old source (though they would certainly be obligated to do so under the GPL).

Link to comment
Share on other sites

Guest leromarinvit

I said earlier that I wanted to try reprogramming the controller's configuration with a known good dump. I've finished adding the necessary interface to the kernel, now I need help from somebody with a B01 Blade (one which never had any touchscreen issues). So, if you want to help, please install this kernel (for Swedish Spring), copy /proc/touchscreen/configuration off the device and post it here (either as an attachment or as a hex dump).

Here's the only command you need:

adb pull /proc/touchscreen/configuration
Mine looks like this:
00000000  00 07 00 0b 00 00 1e 1e  4b 07 18 0c 5f 00 01 02  |........K..._...|

00000010  03 04 05 06 07 08 89 8a  8b 8c 8d 8e 8f 90 91 92  |................|

00000020  93 94 95 96 97 8b 8d 8c  8c 8b 8c 8c 8b 8c 89 89  |................|

00000030  89 86 87 87 87 8a 89 8a  8a 8b 8c 8e 8c 19 0a 06  |................|

00000040  0a 00 00 00 00 96 00 00  04 04 00 1e 19 05 00 00  |................|

00000050  19 00 38 00 5b 00 80 00  a7 00 cc 00 ec 00 05 01  |..8.[...........|

00000060  1e 01 3a 01 5b 01 7c 01  98 01 b3 01 c5 01 d6 01  |..:.[.|.........|

00000070  e1 01 ef 01 fa 01 07 02  12 02 1a 02 1f 02 2b 02  |..............+.|

00000080  35 02 41 02 4c 02 5e 02  7a 02 80 02 00 00 1a 00  |5.A.L.^.z.......|

00000090  38 00 5c 00 80 00 ab 00  d1 00 f0 00 09 01 21 01  |8.\...........!.|

000000a0  3c 01 5a 01 79 01 95 01  ad 01 c3 01 d3 01 dc 01  |<.Z.y...........|

000000b0  e8 01 f4 01 00 02 09 02  16 02 1c 02 2b 02 2c 02  |............+.,.|

000000c0  3b 02 44 02 5e 02 6d 02  80 02 f9 f8 3e 3e 00 00  |;.D.^.m.....>>..|

000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

000001f0  00 00 00 00 00 00 00 00  00 00 00 00 25 41 e6 3a  |............%A.:|

00000200

Link to comment
Share on other sites

Guest tlaci
This is the kernel tree all custom Blade kernels (at least for Froyo and CM7) are based on. Unfortunately, it's too old to contain a fix for the touchscreen problem. Also, it's 2.6.32, while the version they ship with Eclair is 2.6.29. There is a 2.6.29 download too on ZTE's website, but it's even older and AFAIK doesn't even work. There was a long thread some months ago about this, and it seemed that ZTE were stupid enough to lose the source for the kernel binary they actually shipped. To me, it seems that they must have found it again after all, otherwise they wouldn't have been able to fix the touchscreen problem in the kernel. But so far, they haven't released any updates for the old source (though they would certainly be obligated to do so under the GPL).

I see, thanks.

So, if you want to help, please install this kernel (for Swedish Spring), copy /proc/touchscreen/configuration off the device and post it here (either as an attachment or as a hex dump).

I'll have time to take a look on Saturday.

Is it a special kernel? What did you change? Or can I simply use the RLS4b rom?

Link to comment
Share on other sites

Guest leromarinvit
I'll have time to take a look on Saturday.

Is it a special kernel? What did you change? Or can I simply use the RLS4b rom?

Thanks!

I added a virtual file called /proc/touchscreen/configuration, which can be used to read and write the controller's configuration flash memory. I've attached my changes as a patch against kallt_kaffe's git (without the old patch applied).

blade_synaptics_proc.zip

Link to comment
Share on other sites

Guest Rotmann
I got a PM asking me how I did it, and thought I'd post it here in case other people are interested too:

The first clue was that whenever the touchscreen wasn't working, the X/Y range would be "unknown" in logcat. I tried manually setting it in the initialization routine, but that didn't work either: no matter what I wrote to these registers, they would always read back 0. So I tried to make sense of the Synaptics RMI4 documentation, and was quite annoyed that it doesn't contain a useful register map, only functional descriptions of the various registers.

As it turns out, that was actually quite helpful for getting me on the right track. Synaptics devices are logically organized in "functions", where each has an ID and its own register blocks. And there's a table which describes the available functions. Wanting to know the address ranges so I could poke around some more, I enumerated them - and saw that only the flash management function was active. From there on it was easy, I read up about this bootloader mode and how to reset the chip and tried it, and it worked. :)

CM7 kernel here: http://www.multiupload.com/HBY4TOYCAK

Only Gen1 this time!

CM7 Gen2 kernel (untested!): http://www.multiupload.com/KYRMSG9M14

What a brilliant guy! :) Thanks for doing this, you are a hero! You've made the lives of many bladers a little sweeter.

Link to comment
Share on other sites

Guest kallt_kaffe

I haven't paid much attention to this thread (too many threads and too little time) but this looks interersting. I'll keep an eye on the development and unless this breaks anything for non-troublish touchscreens I'll be happy to add the patch to the SS-kernel.

The proper way to add this to Toms kernel (the CM kernel) is to fork Toms repo, apply the patch, push the commit to your forked repo, and the make a pull request for the commit.

I apologize for not reading the whole thread to try to find this out but is this problem really present on Gen2 devices? I was told that upgrading to Gen2 made the unresponsive touchscreen problem go away. Can someone confirm if this is true or not?

Link to comment
Share on other sites

Guest leromarinvit
I haven't paid much attention to this thread (too many threads and too little time) but this looks interersting. I'll keep an eye on the development and unless this breaks anything for non-troublish touchscreens I'll be happy to add the patch to the SS-kernel.

It shouldn't, since it only resets the controller if it is in bootloader mode.

I apologize for not reading the whole thread to try to find this out but is this problem really present on Gen2 devices? I was told that upgrading to Gen2 made the unresponsive touchscreen problem go away. Can someone confirm if this is true or not?

I just tried it and it seems to have the same problem. I was about to report success, but after a reboot, it stopped working again. The patched kernel fixes it.

Now let's see if I can downgrade to Gen1 and keep my IMEI. But that's a different topic. :)

Link to comment
Share on other sites

Guest isambard
I haven't paid much attention to this thread (too many threads and too little time) but this looks interersting. I'll keep an eye on the development and unless this breaks anything for non-troublish touchscreens I'll be happy to add the patch to the SS-kernel.

The proper way to add this to Toms kernel (the CM kernel) is to fork Toms repo, apply the patch, push the commit to your forked repo, and the make a pull request for the commit.

I apologize for not reading the whole thread to try to find this out but is this problem really present on Gen2 devices? I was told that upgrading to Gen2 made the unresponsive touchscreen problem go away. Can someone confirm if this is true or not?

i have experienced touchscreen issues. but once could have been due to not wiping cache.

other times were solved with toggle of the power key. too few data points to confirm right now...

Link to comment
Share on other sites

Guest leromarinvit
i have experienced touchscreen issues. but once could have been due to not wiping cache.

other times were solved with toggle of the power key. too few data points to confirm right now...

The power key or other more obscure magic tricks never worked for me. I didn't wipe the cache though, gonna try this later. Still busy with the downgrade.

Edit: tried it, no go.

Edited by leromarinvit
Link to comment
Share on other sites

Guest kallt_kaffe
It shouldn't, since it only resets the controller if it is in bootloader mode.

I just tried it and it seems to have the same problem. I was about to report success, but after a reboot, it stopped working again. The patched kernel fixes it.

So which patch should I use?

blade_synaptics_reset.patch or blade_synaptics_proc.patch?

Now let's see if I can downgrade to Gen1 and keep my IMEI. But that's a different topic. :)
Just keep a copy of you original Channel1.nvm and you should be able to recover. I lost my IMEI but was able to restore it by going back to Gen2 and injecting my Channel1.nvm at the right moment.
Link to comment
Share on other sites

Guest leromarinvit
So which patch should I use?

blade_synaptics_reset.patch or blade_synaptics_proc.patch?

The second one is part of an experiment I wanted to try. The controller is in bootloader mode because of a config checksum mismatch. So I added a /proc/touchscreen/configuration file to read/write the controller's config flash, since I thought that maybe ZTE programmed a broken config into their newer devices. If that's the case, I think a better solution than the reset would be to flash a dump from a good device when needed, and have the decision logic in userspace.

I'm not really sure what's causing the checksum error though: The last 4 bytes should be a Fletcher-32 checksum of the rest, and in my dump, it agrees with what the example code from the Wikipedia article generates (to which Synaptics' documentation refers). However, I tried to verify that with two other programs, and each came up with a different result. Apparently nobody knows how to implement Fletcher-32 correctly, and I couldn't find any test vectors either. So it could be that ZTE's checksum is wrong precisely because they used the (possibly wrong) Wikipedia code to calculate it. Or it is right and both of the other programs are wrong.

It would be very helpful if anybody with an older Blade (before the touchscreen problem showed up) could flash this kernel and dump /proc/touchscreen/configuration so we can find out which checksum is right.

Link to comment
Share on other sites

I bought my Base Lutea back in January, so it should match your requirement. How do I proceed? I booted twice with the new kernel, but the file configuration is empty alas it's size is 0 byte. Any suggestions?

Link to comment
Share on other sites

Guest leromarinvit
I bought my Base Lutea back in January, so it should match your requirement. How do I proceed? I booted twice with the new kernel, but the file configuration is empty alas it's size is 0 byte. Any suggestions?

ls won't show any size, since it's dynamically generated. Just read it with cat (to a file, it's the raw binary) or cp.

Link to comment
Share on other sites

Ah ok, I googled a little bit and I figured something out. I used this command line in adb shell

# logcat /proc/touchscreen/configuration > sdcard/ts_conf.txt

and I got a 60 kb file. But I really doubt, that it is of any use. Anyway, this file is attached.

ts_conf.zip

Edited by bhf
Link to comment
Share on other sites

Guest leromarinvit
Ah ok, I googled a little bit and I figured something out. I used this command line in adb shell

# logcat /proc/touchscreen/configuration > sdcard/ts_conf.txt

and I got a 60 kb file. But I really doubt, that it is of any use. Anyway, this file is attached.

logcat is the wrong command, that's the Android system log. Either of these will work:

on the phone (via adb shell)

cp /proc/touchscreen/configuration /sdcard/ts_conf.bin
or
cat /proc/touchscreen/configuration >/sdcard/ts_conf.bin
or on the PC
adb pull /proc/touchscreen/configuration ts_conf.bin

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.