Related
Hi folks,
On a lark I tried replacing the digitizer/touchscreen on a freebie Eris donated by a friend.
The old touchpanel was a Synaptics, and was dead/wonky in the lower left hand corner above the home/menu keys (those soft keys worked, however). It had a scratch on the glass in this same area, which led me to think that the repair would be straightforward.
The result was not acceptable, however - it is very "jittery". (The GB Dev Tools "Pointer Location" activity always seems to show a larger uncertainty circle on this unit compared to a different Eris w/ a Synaptics digitizer)
The replacement unit that I received was a Melfas assembly - the 1.49.2000 (S-OFF) bootloader reports it as a
TOUCH PANEL-MELFAS_45_17
Relevant kernel boot log messages (dmesg output post-replacement):
Code:
<3>[ 9.397033] i2c_smbus_read_byte_data failed
<4>[ 9.397125] synaptics-rmi-ts: probe of 0-0020 failed with error -5
( I^2C probe for Synaptics unit fails, as expected)
...
<6>[ 9.473785] melfas_ts_probe: detected done, Operation Mode: 0x2
<6>[ 9.477783] melfas_ts_probe: sensor_rev: 0x45, hw_rev: 0x14
<6>[ 9.477813] comp_group: 0x43, fw_ver: 0x17
<6>[ 9.477813] max X size: 320, max Y size: 480
<6>[ 9.478363] input: melfas-tsi-touchscreen as /devices/virtual/input/input1
<6>[ 9.637084] melfas_ts_probe: Start touchscreen melfas-tsi-touchscreen in interrupt mode
<6>[ 9.638336] GPIO Matrix Keypad Driver: Start keypad matrix for desirec-key
pad... in interrupt mode
<6>[ 9.638519] GPIO Input Driver: Start gpio inputs for desirec-keypad... in
interrupt mode
<6>[ 9.639556] input: desirec-keypad as /devices/virtual/input/input2
So, apparently the "45_17" thing that the bootloader reports is "<hardware_rev>_<firmware_version>". The Melfas digitizer is (probably) P/N MTH-HCERB00.R14 (mfg date 8/2009), and the controller chip on the digitizer assembly has a 40-pin QFP with the ID/Datecode:
MELFAS
6SI20D
0941E
Unfortunately, nothing useful on Melfas' website that would shed any light on this.
So, anyhow...
Q: For those of you that have Melfas Touchpanels, what values do you see reported by the bootloader for hardware and firmware versions?
It's probably too much to expect to find an Eris touchpanel expert here, so instead, I'm wondering:
Q: Have any of you experienced similar issues with digitizer replacements - things that made you suspect there might be either hardware or firmware revision compatibility issues?
At this point my best guess is the problem I have is on the mobo, not the digitizer - but I can't be 100% sure, as the hw/fw revs of the digitizer could also be a wildcard. Strange, though - I don't see a peep out of the I2C kernel driver complaining about problems on that bus.
bftb0
Hmmmm.
My Eris also has the Melfas_45_17 touch panel. I wonder if the 6SI20D chip is a rebranded ARM processor, like the one mentioned in this article:?
http://mobile.arm.com/about/newsroom/25222.php?setcookie=mobile
Sent from my ADR6200 using xda premium
DrkSynDc8 said:
Hmmmm.
My Eris also has the Melfas_45_17 touch panel. I wonder if the 6SI20D chip is a rebranded ARM processor, like the one mentioned in this article:?
http://mobile.arm.com/about/newsroom/25222.php?setcookie=mobile
Sent from my ADR6200 using xda premium
Click to expand...
Click to collapse
Thanks for the reply, DrkSynDc8 (85 page views and you're the first.) I take it that your digitizer is "factory", not a replacement.
I did a little more digging - in fact, a comment by someone in the (XDA) Samsung Moment forum (!) led me to take a look at the Eris HTC kernel sources, and in fact there is special handling in the melfas_tsi.c driver code, in particular
(snippet from melfas_tsi.h)
Code:
#define MELFAS_TRIANGLE_PATTERN 0x41
#define MELFAS_DIAMOND_PATTERN 0x45
(snippet from melfas_tsi.c)
Code:
if (ts->wake_up && (ts->sensor_revision == MELFAS_DIAMOND_PATTERN)) {
So, I suppose (if the sensor rev is printed in hex by the bootloader - i.e. "45") that this indicates that I have no reason to suspect this particular hardware - there is "sensor_revision" handling in the HTC driver code to handle this specific version (and nothing other than a print statement for the firmware rev), so that's conclusive evidence that HTC was building with this digitizer. Everything else about the digitizer seems reasonable - the manufacturing date is two months before the Eris first shipped.
As for the Melfas chip (and the link you provided, thanks) - the ARM "cores" are licensed as IP cores; ARM doesn't physically produce any chips themselves. So, yeah - there might be an ARM core in there, along with the analog circuitry for driving/detecting the passive panel's capacitive sensors. Too bad Melfas doesn't provide data sheets.
The odd thing about this (the fact that the replacement unit acts squirelly) is that the "interface" being disconnected at the digitizer flex-cable connector is an I^2C bus interface plus power/ground for digitizer circuit(s). I would think that if something were wrong on the mobo side of the connector, I would see the kernel barking about I^2C problems. (I suppose a degraded power/ground connection could muck up the analog side of things without affecting the I^2C interface.)
The only other thing that I suppose could be a possibility is a stray charge / grounding issue with the digitizer screen itself. I replaced the gummy, black, factory adhesive with double-sided tape. Makes me wonder if that gummy, black goo is slightly conductive, since the bond is made to an aluminum frame in the front assembly; otoh, I haven't seen any reports about problems from other folks who used superglues or other non-conducting cementing methods when they replaced digitizers.
cheers
bftb0
PS. A little off-topic, but in my digging around, I fooled around with ".idc" files, and concluded via experimentation that (for CCM7_v18 GB, anyway) that
/system/usr/idc/melfas-tsi-touchscreen.idc
is the correct location for the Input Manager's device-specfic "device calibration" file for the melfas-tsi-touchscreen driver.
But, without further digging, I am not sure that the Input Manager's behavior (see getInputDeviceCalibration() in com.android.server.InputManager) is anything more than a stub for this particular device - it will read java name/value pairs out of that file, but I don't know (a) whether anything is done with them or (b) what the appropriate name/value pairs would be for the melfas-tsi device.
bftb0 said:
Thanks for the reply, DrkSynDc8 (85 page views and you're the first.) I take it that your digitizer is "factory", not a replacement.
I did a little more digging - in fact, a comment by someone in the (XDA) Samsung Moment forum (!) led me to take a look at the Eris HTC kernel sources, and in fact there is special handling in the melfas_tsi.c driver code, in particular
(snippet from melfas_tsi.h)
Code:
#define MELFAS_TRIANGLE_PATTERN 0x41
#define MELFAS_DIAMOND_PATTERN 0x45
(snippet from melfas_tsi.c)
Code:
if (ts->wake_up && (ts->sensor_revision == MELFAS_DIAMOND_PATTERN)) {
So, I suppose (if the sensor rev is printed in hex by the bootloader - i.e. "45") that this indicates that I have no reason to suspect this particular hardware - there is "sensor_revision" handling in the HTC driver code to handle this specific version (and nothing other than a print statement for the firmware rev), so that's conclusive evidence that HTC was building with this digitizer. Everything else about the digitizer seems reasonable - the manufacturing date is two months before the Eris first shipped.
As for the Melfas chip (and the link you provided, thanks) - the ARM "cores" are licensed as IP cores; ARM doesn't physically produce any chips themselves. So, yeah - there might be an ARM core in there, along with the analog circuitry for driving/detecting the passive panel's capacitive sensors. Too bad Melfas doesn't provide data sheets.
The odd thing about this (the fact that the replacement unit acts squirelly) is that the "interface" being disconnected at the digitizer flex-cable connector is an I^2C bus interface plus power/ground for digitizer circuit(s). I would think that if something were wrong on the mobo side of the connector, I would see the kernel barking about I^2C problems. (I suppose a degraded power/ground connection could muck up the analog side of things without affecting the I^2C interface.)
The only other thing that I suppose could be a possibility is a stray charge / grounding issue with the digitizer screen itself. I replaced the gummy, black, factory adhesive with double-sided tape. Makes me wonder if that gummy, black goo is slightly conductive, since the bond is made to an aluminum frame in the front assembly; otoh, I haven't seen any reports about problems from other folks who used superglues or other non-conducting cementing methods when they replaced digitizers.
cheers
bftb0
PS. A little off-topic, but in my digging around, I fooled around with ".idc" files, and concluded via experimentation that (for CCM7_v18 GB, anyway) that
/system/usr/idc/melfas-tsi-touchscreen.idc
is the correct location for the Input Manager's device-specfic "device calibration" file for the melfas-tsi-touchscreen driver.
But, without further digging, I am not sure that the Input Manager's behavior (see getInputDeviceCalibration() in com.android.server.InputManager) is anything more than a stub for this particular device - it will read java name/value pairs out of that file, but I don't know (a) whether anything is done with them or (b) what the appropriate name/value pairs would be for the melfas-tsi device.
Click to expand...
Click to collapse
I always need an energy drink after reading your posts, sir Good stuff though!
We've sucessfully violated Samsung's Hardware-Based-Chain-Of-Trust once before by modifying the hardware , causing the device to boot from USB at which point we can upload an interceptor bootloader and then any unsigned code of choice.. This was done to resurrect dead devices and help promote development
It's time now to tackle the Galaxy S2(Exynos) platform. A lot of lessons were learned last time.. So we'll start this thing off by saying that it looks like they've removed UART functionality in this edition of Samsung processors. I can understand why... We were able to access a root prompt when the kernel loaded up to charge the battery, as well as clear the download counts, flash partitions and have other full access to the Serial Administration Console... So, it looks like there's no UART available.
I took the liberty of creating the Galaxy S2 Hack Pack which will help out. This contains the Public processor manual, the i9100 service manual and a ton of other helpful tools.
Contained within the Level 3 service manual was a processor pinout with each pin labeled. I yanked that out of the processor manual, put it into GIMP, flipped it, labeled it prepaired it. This contains all the pins and they're labeled.. but they're small, so I enlarged the ones we're concerned with.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Here's the i9100 board. I obtained this great image from ifixit.
Now, we can apply the overlay to the board and....
Now if we look to the left in the picture above we can see that there are 5 resistor switches. The right side is low and the left side is high. there are 3 high, 1 low and 1 disconnected.
The Development board for this processor shows only 5 switches though, 2 of the 7 signals we are concered with (xOM0 and xOM6) are hardwired and non-switchable. This leaves a promissing 5 switches.. However I don't know what to make of the one which is disconnected. Logically the shortest path would apply here and look something like this:
So, since xOM5 switched boot mode from OneNAND to UART>USB>OneNAND on the Hummingbird.. Considering xOM6 doesn't count on this device.. I'm thinking xOM5 could control boot mode on this device as well.
Any input? I have a i9100 here.
according to the documentation in the processor manual the xOM register may be read from 0x1000_0008, this is the OP_MODE register and it should contain a 8 bit binary word (2 hexidecimal digits) which displays the xOM value.
I've got many useful data already, but missing the most important one - complete Exynos manual. All I've got about CPU alone is 4,3MB document called "SEC_Exynos4210_pulbic_manual_Ver.0.00.01.pdf" it's incomplete.
Can you people look for newer version or any related documentation? It's very important to me to get such.
(Yes, I also have OrigenBoard schemas)
What may help in looking is that Exynos4210 marking is S5PV310/S5PC210 (don't mix up with Hummingbird which is S5PV210/S5PC110/S5PC111), sometimes it's also called as Exynos4 which is wrong name, because it's probably different CPU, but Samsung tends to mix up their own products so who knows.
The The xOM0 pin controls clocks. This pin is for sure irrelevant to changing boot order.
Here's some documentation relating to the boot
Code:
Owing to the recent increase in the prices of NOR flash memory and the moderately priced DRAM and NAND
flash, customers prefer to execute boot code on NAND flash and execute the main code on DRAM.
The boot code in Exynos4210 can be executed on external NAND flash. It will copy NAND flash data to DRAM. To
validate the NAND flash data, Exynos4210 comprises of hardware Error Correction Code (ECC). After the NAND
flash content is copied to DRAM, main program will be executed on DRAM. NAND flash controller uses
ACLK_133 clock, which is from clock controller (FSYS).
Analysis: ECC is used.. This may prevent changes to a live bootloader
Code:
Auto boot: The boot code is transferred to internal SRAM during reset. After the transfer, the boot code will be
executed on the SRAM.
Analysis: Code is executed in SRAM, this is different from DRAM in Hummingbird. It is possible that code may be injected somehow during reset... point of weakness to examine.
Code:
64 KB ROM for secure booting and 128 KB RAM for security function
Analysis: I do not like this Secure Ram thing.. We need more documentation to figure out how SRAM works.
Code:
The Watchdog Timer (WDT) in Exynos4210 is a timing device that resumes the controller operation after
malfunctioning due to noise and system errors. WDT can be used as a normal 16-bit interval timer to request
interrupt service. The WDT generates the reset signal.
Analysis: the Watchdog timer will initiate a reset if not reset. this timer must be reset every 65,536 units of measure. Apparently this is powered by the 100 MHz ACLK_100 signal. This could be a window of opportunity.. however it might be entirely too small if this is a 1:1 clock.
here is the Watchdog Timer calculation
Code:
1/(CLK/(Prescaler value + 1)/Division_factor)
where
CLK=100,00,000
prescaler value is 0 to 2^8-1. (0-255)
Division_Factor is 16, 32, 64, or 128.
So, the watchdog timer on this device can reset anywhere between .0003 seconds and .000000017 seconds... acording to my calculations.
Code:
Once the watchdog timer is enabled, the value of watchdog timer data (WTDAT) register cannot be automatically
reloaded into the timer counter (WTCNT). Therefore, an initial value must be written to the watchdog timer count
(WTCNT) register, before the watchdog timer starts.
Analysis: If we manage to get code booted onto the device, the watchdog must be kicked frequently during the boot sequence or disabled all together.
The watchdog timer may be disabled by setting 0x1006_0000 bit0 to a 0. this would render the watchdog useless as it will not reset the device.
We need manuals to find out the boot modes of this device. I will probe more this weekend, but we really need the finalized manuals.
just dropping in to say thank you guys for all your hard work. You guys rock the world!! I just ordered my Galaxy Tab 7.0 Plus HSPA+ with voice feature from Malaysia. This mod will be a huge help for development,etc.
This is a stock device
Code:
# viewmem 0x10000008 |hexdump
[INFO] Reading 4 bytes at 0x10000008...
0000000 2001 1011
0000004
The bits we are looking at is the "20". 20 makes out to b00100000..
Translated:
xOM0=0
xOM1=0
xOM2=0
xOM3=0
xOM4=0
xOM5=1
xOM6=0
Meaning these binary values must be inverted from HIGH to LOW... Or I am reading the wrong area of memory.
Rebellos, you mentioned that the device takes the OM register into memory at startup and it's likely not changed dynamically. Any insight here?
I thought I would begin locating UART. So... here's what I'm doing..
I set up the device to connect on startup to my wifi
I rooted the device
I purchased market app QuickSSHd and set it up to begin a root ssh connection
I removed the device from its case and taped the battery in place so that I could work with the board itself
Finally, I made this script which causes the device to echo "ttySAC0" to /dev/ttySAC0... same for SAC1 and SAC2. It also increments a counter so I know the device is still operational.
Code:
check=0;
mknod /dev/ttySAC0 c 204 64;
mknod /dev/ttySAC1 c 204 65;
mknod /dev/ttySAC2 c 204 66;
while [ 0 ]; do
echo -e "ttySAC0\n\n">/dev/ttySAC0;
echo -e "ttySAC1\n\n">/dev/ttySAC1;
echo -e "ttySAC2\n\n">/dev/ttySAC2;
check=`let $check+1`;
echo $check;
done;
Now I can probe the device and find the UART consoles. Each ttySAC corresponds to UART... UART0=SAC0, UART1=SAC1, UART2=SAC2.
We are most concerned with UART2, however, it would appear thus far, that I cannot locate any UART consoles on this device.
Here's how I probe:
UsbBoot seems to be invoked directly only when OM values are
0 low, 1 low, 2 high, 3 high, 4 high, 5 high, 6 high, 7 low
OM7 and OM0 looks to me to be irrevelant to booting order. But all of the infos I get are more or less guess.
Too bad for us. As default only OM5 seems to be high or all are low.
I badly need updated CPU manual, the one I have is nearly useless.
described as OM register = 0x10000008
non stated in manual other OM register = 0x10020000 (offset 0 of PMU block)
OM cache also used by iROM to inform IBL if it's supposed to invoke USB or UART boot is 0x10020980
They seems to differ alot between themselves, Adam is unable to find UART which is also bad.
Probably i'm stuck until Sammy release more detailed documentation about CPU. :/
I too am stuck as I cannot probe for more information without some sort of live debugging interface like UART. It seems that samsung may have messed up here because UART is available on models after this one like i777. We need more information. Here's what we need to continue and save bricked Exynos devices.
1. Datasheets on Exynos processor
2. Schematics or documantation. showing AP UART testpoints and/or locations
I just wanted to link this topic in http://forum.xda-developers.com/showthread.php?t=1313588
This shows the UART output we are expecting.. However the i9100 was made incorrectly so research on this device will be impossible. I am looking for a i777 to continue this project.
AdamOutler said:
I thought I would begin locating UART. So... here's what I'm doing..
...
We are most concerned with UART2, however, it would appear thus far, that I cannot locate any UART consoles on this device.
Click to expand...
Click to collapse
Hi, 2 things: (on a GT-I9100)
1. Why are you making new SAC devices, are they not already present?
Another way to check device types is by:
# cat /proc/tty/drivers
Code:
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
rfcomm /dev/rfcomm 216 0-255 serial
g_serial /dev/ttyGS 253 0 serial "Datarouter" & see dun: (10,123)
ttySAC /dev/s3c2410_serial 204 64-68 serial SAmsung Console (UART)
serial /dev/ttyS 4 64-67 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
pty_slave /dev/ttyp 3 0-255 pty:slave
pty_master /dev/pty 2 0-255 pty:master
unknown /dev/tty 4 1-63 console
However, these are not always immediately available, when
not in use. E.g. You will not have an /dev/rfcomm unless you have
activated Bluetooth. In addition you can check your ttySAC's with:
# cat /proc/tty/driver/ttySAC
Code:
serinfo:1.0 driver revision:
0: uart:S3C6400/10 mmio:0x13800000 irq:16 tx:0 rx:0 DSR|CD
1: uart:S3C6400/10 mmio:0x13810000 irq:20 tx:205473 rx:1666 RTS|CTS|DTR|DSR|CD
2: uart:S3C6400/10 mmio:0x13820000 irq:24 tx:0 rx:0 DSR|CD
3: uart:S3C6400/10 mmio:0x13830000 irq:28 tx:0 rx:0 DSR|CD
4: uart:S3C6400/10 mmio:0x13840000 irq:320 tx:0 rx:0 CTS|DSR|CD
2. Have you set the USB connection behavior in the PhoneUtils (service/engineering) menu?
Dial: *#7284#
Code:
UART:
[[B]o[/B]] MODEM[B]*[/B]
[ ] PDA
USB:
[ ] MODEM
[[B]o[/B]] PDA[B]*[/B]
* is default SGS2 setting.
However, my problem is that if I change to USB-MODEM, then my PC no longer find the correct drivers, and I have no clue where to find them. Perhaps the Bada guys may know something about this...
---------------------------------- adendum --------------------------------
[EDIT 2012-02-15]
On second thought, this is really some kind of MUX, so you have to put your UART to point to PDA (AP)!
The sac2 device did not exist by default. It's easier to just create it when SSHing in.
Hey, I guess we need to promote this thread somewhere. I really would like to see some progress here, before we all start crying over our SGS-2's!
For what little its worth, if anything:
See my latest addition to the proprietary ATCs: AT+XSIO and AT+XTRACE.They may have something to do with specifying the UART (and other) debug ports. http://forum.xda-developers.com/showpost.php?p=21965170&postcount=3
Apart from that, there seem to be quite a few ways to "enable" various "debug" and log options (over different types of transport). Problem is (still) that they're not documented anywhere.
Also, since SGS2 should conform to all JTAG standards, there HAVE to be other lines for talking to AP. In addition, looking at the source of ServiceMode application, there are many references in there pointing to using other protocols (PCM, I2S, IPC, UART, USB) for debugging purposes. So even if pure serial is not currently available, the same log-stream may be found on a different transport, like mentioned or whatever the heck they use...
Please don't give up!
You should have a look at the special notes in this post. (It's just part of the manual.) Have you tried to activate that GPIO pin that is mentioned? I have also tried to trace all the Modem - AP connections and put the results in that thread...
I spent several hours over the weekend rooting, unrooting, and re-rooting my new NST. Each time I rooted it, I ended up with a touchscreen problem where touches registered with the wrong column.
For example: when trying to use the backspace key, 'h' would also register. When trying to use 'p', 'e', or 'r', 'y' would also register. Both the key that I wanted and the central key would indicate a keypress (turn black) but only one of them would register in the text box. This is entirely dependent on software, but it's something that is cleared with the 8x failed boot restore and not with the two bottom buttons restore.
I have tried both TouchNooter and MinimalTouch twice. My latest attempt was MinimalTouch:
Start with a clean NST with software 1.0.1
Install 1.1 update (keyboard still works)
Follow MinimalTouch procedure
NST is rooted and android home screen is accessible, however, the keyboard no longer functions properly
Perform reset (hold bottom two buttons on startup)
Button Saver is gone, android home screen is not accessible, keyboard still does not function properly
Perform 8x reboot restore
Keyboard functions perfectly
Has anyone dealt with this before? I couldn't find anything with the search function.
Though this thread appears to be doing nothing, I will at least let you guys know of the current idea:
I have gone back and checked the touchscreen after each step in the procedure, and appears like the 1.1.2 update causes the problem.
Without any rooting or funky installs:
Perform 8-reboot reset
Touchscreen works fine, SW 1.0.1
Install 1.1.2
Touchscreen is impaired, SW 1.1.2
Perform 8-reboot reset
Touchscreen works fine, SW 1.0.1
Did the 1.1 update include a change in the touchscreen sensitivity?
How do I ensure that the IR sensors are clean? A shot of compressed air?
Should I just call B&N/sears and try to get a replacement that functions properly with the update?
I believe that I have determined the cause of my touchscreen difficulty:
The front bezel of my NST is not entirely glued down. I noticed that the spacing was irregular between the eink display, the black (really dark) plastic layer, and the top matte gray layer.
Squeezing my NST temporarily blocks the issue (until the glue re-expands)
The software updates must change the touchscreen sensitivity to some extent, causing the poor tolerance in my particular NST to result in inaccurate touchscreen response.
I'll be talking to the manufacturer or the seller (Sears) soon about a replacement unit.
I hope noone else has to figure their way through this with a brand new nook!
Sorry for resurrecting a death thread. But my nook simple touch (which was rooted and had button saviour etc), slowly started having problems with touch. Now since 2 days, touch screen isn't working anymore, no matter how much cleaning I do to the bezels. I can't even open it due to the slider lock screen. Don't know what to do. I would be happy to settle with a button-based navigation, all I want to do is to read epubs. Any help greatly appreciated. I can prob for problems. I have a rooted nst1 which I haven't tinkered since 2012.
If this isn't the right place, I will start a new thread.
TIA
Forthe55 said:
Sorry for resurrecting a death thread. But my nook simple touch (which was rooted and had button saviour etc), slowly started having problems with touch. Now since 2 days, touch screen isn't working anymore, no matter how much cleaning I do to the bezels. I can't even open it due to the slider lock screen. Don't know what to do. I would be happy to settle with a button-based navigation, all I want to do is to read epubs. Any help greatly appreciated. I can prob for problems. I have a rooted nst1 which I haven't tinkered since 2012.
If this isn't the right place, I will start a new thread.
TIA
Click to expand...
Click to collapse
Have you tried swiping two fingers across the screen from right to left? This is not my original idea but someone else long ago delivered me from your situation with this simple tip. If I ever knew the explanation, I have forgotten it. Probably something with the multi-touch kernal. It will even work on an unresponsive lock screen. I still use it on occasion, so something triggers the behavior, but it is generally infrequent.
If that doesn't work to restore functionality then something more dire has happened.
Forthe55 said:
Now since 2 days, touch screen isn't working anymore.
Click to expand...
Click to collapse
Your swipe lockscreen may present a problem.
I don't see any entry in the settings on my NST, so I don't know how to disable it.
You can download my Touch-1.0.apk from the signature.
That will help you debug the tricky IR paths.
All the lines should be light gray, darker lines indicate an occlusion.
The corners are always difficult and you may have a line or two dark.
The problems are either dirt on the bezel or the bezel/filter/display coming unglued.
You can install and run it (without a launcher or touch screen):
Code:
C:\>adb install Touch-1.0.apk
C:\>adb shell am start -n com.temblast.touch/.Touch
I am sure that my nook is rooted , but adb isn’t working. May be usb debugging isn’t on. The problem is that I can’t even unlock it past the “drag to unlock” screen. Now I have to find out how to enable adb without having a working touchscreen to install the touch1.apk.
The two finger swipe isn’t working. I used to draw a single finger across the borders clockwise, which used to help calibrate the touch , not working anymore.
Forthe55 said:
Maybe usb debugging isn’t on.
Click to expand...
Click to collapse
Well, you should be able to tell.
There are three ways to interact with a running Nook:
Touch screen
ADB over USB or WiFi
Hardware root console
You seem to say that the first two don't work.
You can also try a factory reset or recovery.
There is the whole OmapLink thread that describes how to unbrick an NST.
Here is the middle of the thread, you might need to read before and after:
https://forum.xda-developers.com/nook-touch/general/root-nook-glowlight-t2853056/page6
I did a factory reset and the nook is at startup screen with the NEXT button, which obviously can’t be pressed. So the touch issue is definitely “hardware-related “. Few days back I travelled to a hot and humid place , carrying my nook and the soft rubber part in the front of the bezel, started coming of. No matter how much I clean the bezel , this time touch isn’t coming back. I am wondering whether there’s any way to disassemble and readjust the ir sensor for touch.
Renate NST said:
The problems are either dirt on the bezel or the bezel/filter/display coming unglued.
Click to expand...
Click to collapse
It's stuck together with the standard super-double-stick tape.
It's hypersensitive to the slightest bending up or down of any of the layers.
Without ADB and diagnostics (like Touch-1.0.apk) it's impossible to figure out which bit of the edge is out of whack.
It sounds like you only have two options:
Get the hardware console working with a 1.8V level shifter and a UART.
(Easy for me, may not be easy for you.)
Use OmapLink to boot an image that has ADB running (like Noogie or CWMR)
and enable ADB on your main image.
I remember rooting it in 2012 with some image burned on my SD card. Is there a way to again root with the help of an SD card without involving touching the screen with adb enabled rom. That way I can install the diagnostic app and dismantle it to prob further.
Sorry, it's been so long that I forget all this stuff.
Yeah, if you put Noogie on an SD card, I believe that it will boot from there.
With the OmapLink and Windows 10 it can be a bear sometimes to get the three (all the same) drivers working.
Windows 10 is really crappy on recognizing/capturing USB devices that appear briefly.
I can't get W10 to see 0451/d00e
My Raspberry Pi grabs it immediately:
Code:
[ 60.061477] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[ 60.202744] usb 1-1.3: New USB device found, idVendor=0451, idProduct=d00e
[ 60.202756] usb 1-1.3: New USB device strings: Mfr=33, Product=37, SerialNumber=0
[ 60.202766] usb 1-1.3: Product: OMAP3630
[ 60.202774] usb 1-1.3: Manufacturer: Texas Instruments
[ 63.348937] usb 1-1.3: USB disconnect, device number 4
It appears for 3 seconds from a cold power up, that's too quick for W10 to do anything.
I saw a video on YouTube on screen replacement, with complete disassembly and assembly. Opened the nst , took out the screen from the bezel (keeping the screen and the aluminium metal frame intact, too much sticky tape there), wiped everything clean, reassembled everything back. Still the same problem. I am wondering, even if I somehow get to install and run the diagnostic app, what kind of hardware alterations we need to do. Since the infrared touch LEDs are on the back of the motherboard, what kind of alignment would be necessary.
Is it to the metal frame or the plastic bezel, do we need to tinker?
Did you use new tape?
I think that everything has to be really tight and old tape seems to leave gaps.
There is also the possibility that the MSP340 has lost its mind.
I'll have to look at my oldest NST.
I haven't detached the screen from the metal frame. But the screen attachment to the front bezel seems to be attached to a plastic ribbon which was partially coming out of the front frame. It was sticky so I reattached the screen/metal frame back to it the front plastic part. Now when I see the screen up front, the bezel space/gap between the screen and the black plastic part is uneven. I don't thing that can be repaired as the front black part is disintegrating. Three of my four page turn buttons are no more attached to the frame, I have kept them there with tape.
Well, I completely cleaned with Goo-Be-Gone and isopropyl alcohol the bezel, the filter and the display.
I redid everything with 4mm Tesa film: https://www.microcenter.com/product/507366/tesa-double-sided-tape-4-mm-wide
The horizontal spans (except for the corners) are good, the vertical spans are still problematical.
You can lightly press and warp the bezel and things go in and out.
I think that I'm throwing in the towel on this one.
Reasons to dump the NST: Android 2.1, 256M RAM, OMAP3621 not being further developed by B&N
Reasons to keep the NST: Only Nook with a bare eInk (no backlight layer, no capacitive layer)
Don’t know about the filter, but the bezel looks very fragile to handle. I also believe that the time has come to retire it. But what I liked the most about nst was it’s screen and ability to side load books via wifi. I had gmail and opera mini installed on it. All I needed was to send a link to gmail to download the book, after the Dropbox support was gone. I am searching for a similar ebook reader. Can’t decide between Kindle paper white(which is available locally) and nook glow light 3(which has to be imported). Any suggestions welcome.
Well, the "filter" or "lens" or "light pipe" is what I'm calling the flimsy green translucent piece.
I've never even looked at the Kindles. I don't want to get involved with that whole ecosystem.
The Glow3 is physically almost the same as the NST.
I've got enough devices with browsers on them.
I use my Nooks with WiFi off and sync with USB (ADB & AdbSync).
Installed it on a Fusion Garage JooJoo tablet that has a Intel Atom N270 cpu, Nvidia ION graphics, 128gb SSD, and 4gb memory. I have everything working on it accept for the accelorometer and the touch screen is reversed (i touch the top right and it touches the bottom left).
Really not sure what to do on the touch screen but any help would be greatly appreciated. I've tried calibrating it through windows and all that does is cause the touch input to go completely crazy. I have tried multiple drivers and the only one that even remotely works is the eGalax driver but that causes the touch screen to be seen as a mouse which makes the swipe gestures impossible as well as the built in touch keyboard won't come up anymore.
I'm not worried about the accelorometer as I can just change the orientation in the nvidia control panel if need be. However having a tablet without a fully functional touch screen is pretty much useless.
The touch screen shows up in Device Manager as an HID device. If you need any more information please let me know.
Device HID\VID_0EEF&PID_720C&Col01\6&25a26708&2&0000 was configured.
Driver Name: input.inf
Class GUID: {745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
Driver Date: 06/21/2006
Driver Version: 6.2.9200.16384
Driver Provider: Microsoft
Driver Section: HID_Raw_Inst.NT
Driver Rank: 0xFF1003
Matching Device ID: HID_DEVICE
Outranked Drivers:
Device Updated: false
Any help would be greatly appreciated.
redline0889 said:
Installed it on a Fusion Garage JooJoo tablet that has a Intel Atom N270 cpu, Nvidia ION graphics, 128gb SSD, and 4gb memory. I have everything working on it accept for the accelorometer and the touch screen is reversed (i touch the top right and it touches the bottom left).
Really not sure what to do on the touch screen but any help would be greatly appreciated. I've tried calibrating it through windows and all that does is cause the touch input to go completely crazy. I have tried multiple drivers and the only one that even remotely works is the eGalax driver but that causes the touch screen to be seen as a mouse which makes the swipe gestures impossible as well as the built in touch keyboard won't come up anymore.
I'm not worried about the accelorometer as I can just change the orientation in the nvidia control panel if need be. However having a tablet without a fully functional touch screen is pretty much useless.
The touch screen shows up in Device Manager as an HID device. If you need any more information please let me know.
Device HID\VID_0EEF&PID_720C&Col01\6&25a26708&2&0000 was configured.
Driver Name: input.inf
Class GUID: {745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
Driver Date: 06/21/2006
Driver Version: 6.2.9200.16384
Driver Provider: Microsoft
Driver Section: HID_Raw_Inst.NT
Driver Rank: 0xFF1003
Matching Device ID: HID_DEVICE
Outranked Drivers:
Device Updated: false
Any help would be greatly appreciated.
Click to expand...
Click to collapse
go over to the joojooforum
they had that issue resolved for windows 7
once tought of buying a joojootablet.
After receiving my G4 last week and digging into it, I found that LG is once again dual-sourcing (JDI and in-house LGD) panels for the G4, and that all most verifiable touchscreen issues I have recorded have been on JDI panel equipped devices (EDIT: Though the vast majority were JDI, there was at least one LGD with the same issue). The problem itself is EMI/noise related and is remedied by a solid path to ground (plugging it in, good contact with your hand, etc).
I have verified this with a few dozen phones so far, but more data would be helpful. If you're going to, however, please don't post if you just feel that your touchscreen isn't as responsive as you'd like (missed taps, etc). There's too much room for error there. To verify that your device has the issue, it is best to count the number of discreet touch events it can register both while unplugged and plugged-in/grounded. If your device has the issue, you will only get 5-6 before failure while unplugged and 10 while plugged-in. You can use the free app Display Tester from the play store to check.
As for determining which panel you have, the easiest way is to check your kernel message buffer immediately after boot using dmesg. If you're rooted you can do this on the device, if you aren't rooted you can use adb.
Code:
dmesg | grep -i panel
The oem will be in your kernel command line, panel name, etc.
NOTE: Though it appears that there is a hardware element to this issue, I do think it's possible that LG could fix it in the touch driver with a software update. I personally haven't updated to the firmware that was reported to fix this on my variant (vs98612a) as it was pulled, so I can't say firsthand.
LG panel here. Just tested with display tester. While holding the phone in my hand it recognizes multiple fingers easily.
However if I lay down the G4 on whatever ground/table (it doesn't matter) it barely recognizes two fingers, the second one has to be pushed harder to get it recognized by the screen. Three fingers and it's game over. Really strange. So now I know why it was always difficult using the phone i.e. at work when I wanted to "passively" check whats going on. Most of my touches and swipes (even with one finger) were more prone to erratic behaviour while the pone was laying on my desk.
I am using LG's 6.0 MM by the way with S3V3n's rooted kernel and unlocked bootloader btw. Also there is a tempered glass protector on my screen.
Check the terminal log below for reference regarding my screen type (LGD).
[email protected]:/ $ su
[email protected]:/ # dmesg | grep -i panel
[ 0.000000 / 01-01 00:00:00.000][0] Kernel command line: sched_enable_hmp=1 sched_enable_power_aware=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 androidboot.selinux=permissive msm_rtb.filter=0x37 androidboot.hardware=p1 lge.rev=rev_10 model.name=LG-H815 lge.sim_num=1 lge.battid=SW3800_VC0 lge.bootreason=Reboot_by_PowerKey maxcpus boot_cpus=0-5 kswitch cc_mode=0 androidboot.bl_unlock_complete=true androidboot.dlcomplete=0 gpt bootcable.type=NO_INIT androidboot.ddr_info=0x3b000206 fakebattery=disable lge.bootreasoncode=0x77665501 lge.hreset=off fips_allow_others=1 fips_panic=0 fips=0 androidboot.bootdevice=f9824900.sdhci androidboot.serialno=LGH8157479244e lge.signed_image=false lge.dsv_id=DW androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_lgd_r69007_1440p_mipi0_cmd:1:qcom,mdss_dsi_lgd_r69007_1440p_mipi1_cmd
[ 0.766209 / 01-01 00:00:00.759][4] mdss_dsi_panel_init: Panel Name = LGD INCELL 1440p Dual 0 cmd mode dsi panel
[ 0.766220 / 01-01 00:00:00.759][4] lgd_qhd_command_mdss_dsi_panel_init: panel_type is LGD_INCELL_CMD_PANEL
[ 0.766229 / 01-01 00:00:00.759][4] panel_type is 2
[ 0.766364 / 01-01 00:00:00.759][4] mdss_dsi_panel_timing_from_dt: found new timing "qcom,mdss_dsi_lgd_r69007_1440p_mipi0_cmd" (ffffffc0c56a38a8)
xdabbeb said:
After receiving my G4 last week and digging into it, I found that LG is once again dual-sourcing (JDI and in-house LGD) panels for the G4, and that all verifiable touchscreen issues I have recorded have been on JDI panel equipped devices.
Click to expand...
Click to collapse
It took just one reply to disprove that
The problem itself is EMI/noise related and is remedied by a solid path to ground (plugging it in, good contact with your hand, etc).
Click to expand...
Click to collapse
which will apply regardless of where the panel was sourced. A phone with a curve isn't really ideally suited to be operated on a flat surface anyway.
I've noted this tendency to point out where a component comes from here on the boards and this then gets extrapolated into something bad. i would not interpret a non-oem panel as a problem whatsoever.
components are sourced when required from suppliers that can build to scale. They are equivalent for all intents and purposes.
it should not make a bit of difference whether the panel is LG or JDI. If it does then it just means you 'may' have a defective panel. This can happen with either source.
I think you may be on to something. I got the JDI panel, and I noticed that if I use a touch tester app, it can only register 5 touches successfully when unplugged. The 6th touch causes it to lose all touch points. However, when it's plugged into power, it can register 10 touches without a problem.
Not that I need more than 5 touch points, but is this normal behavior for a digitizer to do that? Looks to me like this is something that could be tweaked in the driver. Would be interesting to know by someone with Verizon software 12A (I am on 11A) if they notice the same issue that their device only registers 5 touches max, or if that is something that has been addressed. I am really getting ticked off by Verizon peddling around and not being able to provide the update every other G4 user already has received. At this point, I am hoping xdabbeb's efforts of coming up with a fix for the 11A version bear some fruits.
One Twelve said:
It took just one reply to disprove that
Click to expand...
Click to collapse
Actually, no...given the individual's report of not even being able to register 2 touches that sounds more like a hardware failure than what is being investigated here.
which will apply regardless of where the panel was sourced. A phone with a curve isn't really ideally suited to be operated on a flat surface anyway.
Click to expand...
Click to collapse
I don't believe I mentioned laying it flat on a table as part of this test, but, yes, a curved phone isn't suited to that.
I've noted this tendency to point out where a component comes from here on the boards and this then gets extrapolated into something bad. i would not interpret a non-oem panel as a problem whatsoever.
components are sourced when required from suppliers that can build to scale. They are equivalent for all intents and purposes.
it should not make a bit of difference whether the panel is LG or JDI. If it does then it just means you 'may' have a defective panel. This can happen with either source.
Click to expand...
Click to collapse
I was actually quite careful in making no judgment in this regard. The words 'bad' and 'defective' were only used by you, actually. I personally don't care what panel was/is used and even stated that given the nature of the problem I feel a software fix is certainly possible.
Though there will be a tendency with any device that has a large scale issue such as this to (sometimes blindly) grasp at finding the cause, the purpose of this was to gather more information, not incite a witch hunt. I personally gathered over 3 dozen logs/reports that supported this before posting, and felt that this was the best way to get more.. I have no horse in this otherwise. I have noted tendencies of contrarianism and gross generalization, but it's the Internet...You're going to get that
@konradsa the qfuse situation makes investigating that more problematic, but that's precisely what I'm looking into next.
@konradsa the qfuse situation makes investigating that more problematic, but that's precisely what I'm looking into next.
Click to expand...
Click to collapse
Thanks, appreciate your efforts and looking forward to your results.
konradsa said:
I think you may be on to something. I got the JDI panel, and I noticed that if I use a touch tester app, it can only register 5 touches successfully when unplugged. The 6th touch causes it to lose all touch points. However, when it's plugged into power, it can register 10 touches without a problem.
Click to expand...
Click to collapse
Same problem with LGD panel.
random_word said:
Same problem with LGD panel.
Click to expand...
Click to collapse
If it was exactly the same then that settles it. Thanks for the report. Closing the thread.