agent008 223 Posted May 4 Share Posted May 4 2 hours ago, VaZso said: When has your keyboard stopped working anyway? About a couple weeks ago. It didn't work, I rebooted, it started working again. Then later on the same day it died permanently. I hadn't been using it during the last couple months prior to the first symptom a couple weeks ago. 2 hours ago, VaZso said: Anyway, have you used a metal tool to disconnect connectors? Always my fingernails or a plastic cellphone pry tool. 2 hours ago, VaZso said: My suspect is somehow you made a short-circuit and now power of these devices are missing, so it would be good to check that somehow and find a way to power them... but that is not something an ordinary user can do. I can try looking at the whole motherboard assembly and the screen connectors with a magnifying glass. But only will be able to do so during the weekend. But this wouldn't explain the keyboard failing by itself prior to the screen replacement. Quote Link to post Share on other sites
VaZso 1,630 Posted May 4 Share Posted May 4 6 hours ago, agent008 said: About a couple weeks ago. It didn't work, I rebooted, it started working again. Then later on the same day it died permanently. It sounds strange... like there was already a contact problem somewhere... 6 hours ago, agent008 said: Always my fingernails or a plastic cellphone pry tool. That case I would not really think a short-circuit caused during disassembly... 6 hours ago, agent008 said: I can try looking at the whole motherboard assembly and the screen connectors with a magnifying glass. That would be good, maybe you will notice something. 1 Quote Link to post Share on other sites
agent008 223 Posted May 5 Share Posted May 5 (edited) Here's an idea. My phone was delivered on August 5th 2020. So, not yet 2 full years from purchase. Do you believe I could have it fixed on warranty terms? Thanks EDIT: I also have a Pro1x on order. Maybe that will ship sooner rather than later now. Hehe Edited May 5 by agent008 Quote Link to post Share on other sites
Hook 1,945 Posted May 5 Share Posted May 5 (edited) 24 minutes ago, agent008 said: Here's an idea. My phone was delivered on August 5th 2020. So, not yet 2 full years from purchase. Do you believe I could have it fixed on warranty terms? Thanks EDIT: I also have a Pro1x on order. Maybe that will ship sooner rather than later now. Hehe Yes, it should be covered by warranty. Looking at thew Wayback machine, the 2 year warranty was listed through at least March 4th 2021: https://web.archive.org/web/20210304055614/https://fxtec.com/faq It was only sometime after that, showing up in the archived page for April 11th, that the policy was changed to a 1 year warranty (made, I think, when they changed the Pro1x from a 2 year warranty to a 1 year warranty-- there probably weren't any Pro 1s being shipped by this time. https://web.archive.org/web/20210411034712/https://fxtec.com/faq Edited May 5 by Hook 1 Quote Link to post Share on other sites
Tagamon 0 Posted Friday at 08:18 PM Share Posted Friday at 08:18 PM I just replaced my screen and am having the same problem with non-responsive margins. Does anyone have the apk referenced in this thread that can supposedly be used to resolve the issues? Thanks in advance for any info! Quote Link to post Share on other sites
dualinfinity 4 Posted Sunday at 04:20 PM Share Posted Sunday at 04:20 PM On 5/13/2022 at 10:18 PM, Tagamon said: I just replaced my screen and am having the same problem with non-responsive margins. Does anyone have the apk referenced in this thread that can supposedly be used to resolve the issues? Thanks in advance for any info! I'd also like the original APK/set of files used to fix the edge issue in 17.1. Let me share my experience and research here: 1. When flashing to stock to resolve the issue, having the phone actually boot up the most recent update is necessary. Otherwise the fix does not work. I know this because I tried flashing an old version of stock and installing the stock OTA updates via the normal (booted!) route. The issue did not go away at any point during this. I then flashed the non OTA 2020-08-25 stock version again and let it boot. Only then was the issue resolved. 2. Given that the issue is resolved on boot, it must either be a firmware update to the touchscreen or more likely a configuration setting of the touchscreen directly written to the touchscreen chip. 3. The touchscreen used in the Fxtec Pro1 and Elephone U is apparently the Goodix GT9286, a version of the Goodix GT928 ( https://www.mail-archive.com/[email protected]/msg2470881.html# ). I've attached what I could find with regard to this controller and its configuration (found by searching for "goodix gt928 programming guide"). From: https://docplayer.net/37943624-Gt928-bbr-displayworks-10-point-soc-touch-solution-for-tablet-rev-gt928-10-point-soc-touch-solution-for-tablet.html 4. In the register information (6.2 in the PDF), there are 4 configuration options mentioned at addresses 0x805B and 0x805C which I believe might be the settings we are looking for ("Blank area of boarder-top (coefficient 32)") and which the stock firmware sets on boot. Now, a lot of this is just conjecture. I would really like to inspect the older fix to try and find out if this is indeed the right path before I start tinkering with writing data to the touchscreen controller. The Pro1 is still my daily driver, after all. GT928.Datasheet.and.Register.Information-BBR.Displayworks.pdf 4 Quote Link to post Share on other sites
VaZso 1,630 Posted Sunday at 05:05 PM Share Posted Sunday at 05:05 PM (edited) 1 hour ago, dualinfinity said: 4. In the register information (6.2 in the PDF), there are 4 configuration options mentioned at addresses 0x805B and 0x805C which I believe might be the settings we are looking for ("Blank area of boarder-top (coefficient 32)") and which the stock firmware sets on boot. You are right and it seems the manufacturer of touch screen controller is correct but the actual model is basically seems to be different. This document states "GT928 has 2 sets of slave address 0xBA/0xBB & 0x28/29" but we have address 0x14 with an alternate address of 0x5D which is different than what is written in this document. However, it may be a very similar command what we need or (considering it is the same manufacturer) it may also happen to be the same, however, I would not try it. I have only found it described as "gt1x" but a better model name may help and a pdf which made for this specific model. Also, first I would try to read instead of writing and also it may be necessary to temporarily disable OS-level handling of touch screen before. Edited Sunday at 06:00 PM by VaZso 1 Quote Link to post Share on other sites
VaZso 1,630 Posted Sunday at 06:05 PM Share Posted Sunday at 06:05 PM 57 minutes ago, VaZso said: 4 configuration options mentioned at addresses 0x805B and 0x805C Another option would be to find I2C line of touch controller (physically), attach a logical analyzer, then let stock OS boot and analyze its initial communication during boot process. 🙂 2 Quote Link to post Share on other sites
VaZso 1,630 Posted Sunday at 06:24 PM Share Posted Sunday at 06:24 PM 1 hour ago, dualinfinity said: 3. The touchscreen used in the Fxtec Pro1 and Elephone U is apparently the Goodix GT9286, a version of the Goodix GT928 ( https://www.mail-archive.com/[email protected]/msg2470881.html# ). I've attached what I could find with regard to this controller and its configuration (found by searching for "goodix gt928 programming guide"). From: https://docplayer.net/37943624-Gt928-bbr-displayworks-10-point-soc-touch-solution-for-tablet-rev-gt928-10-point-soc-touch-solution-for-tablet.html Okay, so Pro1's touch controller seems to be model GT911, PDF attached. ...or at least it mentions our 0x5D and 0x14 addresses which is a calming fact... ...and yes, it also has 0x805B and 0x805C registers for setting blank area. These are R/W values, so it is recommended to read before writing and also reading stock values of Pro1 would be interesting. Also touch/release levels may be set differently anyway. 🙂 GT911 Programming Guide_v0.1.pdf 1 Quote Link to post Share on other sites
EskeRahn 4,335 Posted Monday at 07:57 AM Share Posted Monday at 07:57 AM 13 hours ago, VaZso said: Okay, so Pro1's touch controller seems to be model GT911, PDF attached. The "gt1x" could well indicate x is to be replaces with some digits, According to this, at the least a gt1151 exists, so that might be a relevant guess? Have we got any good images of the print that might help? We expect a minor square chip like on this image. ADD a little more googling indicates that a gt1143 and gt1152 also exists Quote Link to post Share on other sites
EskeRahn 4,335 Posted Monday at 08:17 AM Share Posted Monday at 08:17 AM this is a gt1x driver for android, that might be interesting https://github.com/goodix/gt1x_driver_generic Quote Link to post Share on other sites
VaZso 1,630 Posted Monday at 10:25 AM Share Posted Monday at 10:25 AM (edited) 2 hours ago, EskeRahn said: The "gt1x" could well indicate x is to be replaces with some digits, According to this, at the least a gt1151 exists, so that might be a relevant guess? 2 hours ago, EskeRahn said: ADD a little more googling indicates that a gt1143 and gt1152 also exists That was what we were starting with. 🙂 An I2C chip has an address which used for communication and usually devices have pre-programmed address or addresses. For example, address may be selected using one or more pins at the IC or it may also be a setting. In a few cases (specific circuits) also a custom address can be given. This case we have an address of 0x14 and also found a 0x5D address is an option (above in this thread). I have looked in other model numbers like gt1151 which had a different set of I2C addresses which may have a reason or at least it is not the same IC what is in use in our case (although they are similar, maybe newer versions). That is why I have attached a PDF for GT911 as that case also I2C address is correct, so that PDF looks to be correct for our case (or at least it looks to be better than others found). Also it is a good news it still has these settings at the very same registers. From this perspective, it does not look to be hard to read/write these values. Edit: I mean I2C addresses are usually hard-wired and this case only 0x14 and 0x5D can be selected using INT pin. (INT should be initially high [I mean after reset] for selecting address 0x14 which is our case, otherwise it would be 0x5D, there are no other options for address selection). Edited Monday at 10:57 AM by VaZso 2 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.