I'm attemping to figure out the screen issue some users are having when they tried to update the stock firmware from Curtis
The issue was caused by trying to update using the manufacturer's update.
Screen Issue Symptoms:
Tablet will boot up into the Android OS all the way to the lockscreen but the screen will not respond to any touch by the user making it impossible to use.
Ill keep this section updated as to what I find pertaining to the screen issue.
thanks to one of our dedicated users, SuperNoober
, has decided that he is fed up with his broken Klu tablet (with the touchscreen issue) and is sending it to me so that I can do what I can to fix it. "If" a fix is possible, share with everyone. Its on the way by mail to me now. Please be grateful to him for donating his device to the cause.
I received it yesterday. Been doing a lot of testing..
For this type of issue, like most, I thought it'd be best to rule out what it's not by the process of elimination.
First, I downloaded the Curtis firmware again to re-flash it to the tablet just to rule out user error. It did flash successfully but didn't change anything as far as screen issue.
Next, I found some tool/scripts
made by user Wendal
over in SlateDroid forums that I used to unpack the stock firmware.img from Curtis inc. and mount the different partition images in order to check for integrity and make sure nothing was missing by comparing it to my daughters WORKING (no screen issue) tablet. I also found a Linux shell script that will pull all the images from a working device and place then into a working_folder and used that to pull the firmware right from my WORKING tablet and the NON-WORKING tablet. then I compared the two but found no differences in either comparing to the stock firmware or each other.
More research led me to another forum, FreakTab.com
where there have been lots of development on Rockchip tablets and developers have made good efforts in collaborating their research on the devices. In this thread
, Developer, hacker, Rom Chef, Finless_Bob
has explained in detail all about modding on rockchip devices and how they are structured. Using Finless' advice I learned how to extract the boot.img in order to compare any differences.
I split the boot.img into kernel & ramdisk on both working and non-working and they where the same.
I went through all the stock .libs, kernel modules, .ko and .so drivers and they where the same too.
Basically, everything I looked into seemed identical in both working and non-working tablet.
In my research and some help from vulcanize
here in the forums,
I have found that there is a sister device (exact same device) sold under a different name (proscan PLT-7035-b
In finding this out, I downloaded the ICS
firmware for the Proscan model and flashed them each, thinking maybe it was something in the Klu firmware still or possibly the download. (No Luck, screen was still the same) but the Klu and Proscan firmwares are almost identical.
Also, in testing, I found that if you press the "restore" button in RKBatchtool.exe, it will reformat the whole nand-flash device before installing the new firmware. Still didn't help though..
Then, In doing more research, I found a developer who has done alot of work on all kinds of rk29xx, rk30xx, rk31xx tablets and other devices with rockchip boards. (Oma) (Ody's Loox)
Crew RKTablets | Per aspera ad astra, we rock the Tablets
I downloaded 3 of his custom firmwares ( CyanogenMod 10.1
) (JellyBean 4.2.2
) (JellyBean 4.1.1
) and his modded kernel for the proscan plt-7033-b
. All of them flashed successfully and booted up just fine but it still didn't have any response to touch.
My next step was to see if the Android OS was working properly and was even able to receive touchscreen events. First I needed to enable USB debugging so I could use adb while Android was running. For reference, here is how I did it:
after flashing Oma's CM10.1
rebooted into recovery (CWM)
mounted /system as read/write
mount -o remount,rw /system
and enabled USB debugging by editing a few lines in system files by running these commands:
echo "persist.service.adb.enable=1" >> default.prop
echo "persist.service.debuggable=1" >> default.prop
echo "persist.sys.usb.config=mtp,adb" >> default.prop
echo "persist.service.adb.enable=1" >> /system/build.prop
echo "persist.service.debuggable=1" >> /system/build.prop
echo "persist.sys.usb.config=mtp,adb" >> /system/build.prop
Then once I rebooted back into the lockscreen, I used several different adb commands to swipe and unlock the screen and also to make a few selections.
for reference, I used commands similar to these:
adb shell sendevent /dev/input/event2 3 57 29
adb shell sendevent /dev/input/event2 3 53 240
adb shell sendevent /dev/input/event2 3 54 400
adb shell sendevent /dev/input/event2 3 48 29
adb shell sendevent /dev/input/event2 3 58 2
adb shell sendevent /dev/input/event2 0 0 0
adb shell sendevent /dev/input/event2 3 57 4294967295
adb shell sendevent /dev/input/event2 0 0 0
In which, I was able to unlock and make a few selections inside the OS
My conclusion so far:
Seems that the only thing missing is a responce to touch which can only be that the digitizer is defective..
My next step is to swap screens with a screen that I know works only to confirm my findings.
Thanks to another user in our community, Dan L Smith, has confirmed a work-around if you have one of these tablets that won't respond to touch. He plugged in a USB mouse to the mini port on the tablet and was able to control it just fine that way. I'm sure a Bluetooth dongle with a Bluetooth mouse would also work too.
I ended up swapping the screens on the two tablets and the tablet with the screen issue works just fine with the screen from my daughter's tablet.
So it is confirmed that it is in fact that the screen is defective/broken beyond repair for whatever reason.
I don't really understand why it only happened when the firmware was updated but my theory is that flashing was only the trigger to make the digitizer go out. I'm pretty sure it's a manufacturer defect and they were going to go out at some point anyways but that is just theory. I suspect that it could also be a problem with the windows driver that people are using for the device when they are flashing the update. That could certainly cause the screen to be broken during the flash.
In my opinion, Curtis International should be sued for selling so many people defective screens that were probably made in some child abusing sweat-shop in china somewhere. I would be happy to sign that petition and also submit my findings.
If any other person or developer would like to do any testing for themselves, just about everything I used and all info is posted here but if I can help in any way, please feel free to post here or send me a PM and I would be happy to help