Certain keys not working initially? [fixed bug in old ROM]

[cerialphreak 17]

I'm curious to see if anyone else is having this issue: when first opening the phone some keys wont type anything until another key is pressed. This seems to happen mostly to Y and H (qwerty varient) which is getting to be seriously irritating considering a lot of text messages start with "yes" or "hi." I've seen the repeating key issue as well, but only once.

[david 929]

Yh

I just typed those after closing and opening the phone.  Does it happen every time for you?  What do you have your keyboard language set to?  Mine is set to default (qwerty version too).  I don't use fin qwerty, but I do have SwiftKey installed.

[jjarmasz 81]

23 minutes ago, cerialphreak said:

I'm curious to see if anyone else is having this issue: when first opening the phone some keys wont type anything until another key is pressed. This seems to happen mostly to Y and H (qwerty varient) which is getting to be seriously irritating considering a lot of text messages start with "yes" or "hi." I've seen the repeating key issue as well, but only once.

Yeah, I think I'm getting the same thing. Notice it especially with the H key. Glad to know I'm not the only one, I thought maybe I was imagining it.

[tdm 2,322]

It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.

 

Edited February 23, 2020 by tdm

[david 929]

20 minutes ago, tdm said:

It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.

 

Just verified this.  Rebooted.  Couldn't type y or h until I hit another key first.  I can close and open the keyboard and type y and h fine though.

[EskeRahn 5,471]

You only see this issue if you boot password/pin starts with one of 7, U, J, N plus Period Up and Enter, thanks @FlyingAntero (of course letters shifted for those on the shifted keyboards, it follows the physical keys).

(Or obviously if you have disabled the security, or use the touch screen for it)

I stand corrected, see @FlyingAntero below, it is indeed not limited to boot. I'm a bit puzzled, that I have only seen it after boots. Must normally be doing something with other keys so I have not noticed.

[cerialphreak 17]

8 hours ago, tdm said:

It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.

 

On mine it is not limited to immediately after a reboot. Seems to happen randomly throughout the day.

3 hours ago, EskeRahn said:

You only see this issue if you boot password/pin starts with one of 7, U, J, N - (of course shifted for those on the shifted keyboards, it follows the physical keys).

(Or obviously if you have disabled the security, or use the fake keyboard for it)

My pin doesnt have those characters, so this would seems to be a different issue (or at least different behavior).

[DieBruine 397]

This has happened to me with Enter. Started on Saturday. I have to use one of the numbers or letters before Enter starts working again.

Boot-password is a pattern btw.

[FlyingAntero 871]

4 hours ago, EskeRahn said:

You only see this issue if you boot password/pin starts with one of 7, U, J, N - (of course shifted for those on the shifted keyboards, it follows the physical keys).

(Or obviously if you have disabled the security, or use the fake keyboard for it)

In my QWERTZ unit "7", "U", "J", "N", ".", "UP" and "Enter" (total of 7 buttons) are not working right after waking up the screen. Those buttons will work after I press some other button first. I can reproduce the issue every time I wake up the screen. I don't need to reboot device. All I need to do is lock and unlock to see the issue.

[netman 1,424]

12 hours ago, tdm said:

It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.

The next OTA should pull either your or my keyboard driver and fix this.

[zurvan2 125]

9 hours ago, DieBruine said:

This has happened to me with Enter. Started on Saturday. I have to use one of the numbers or letters before Enter starts working again.

Same here. I mostly notice it in Termux, and didn't know if it was specifically an issue with Termux. Now confirmed in other apps.

This happens every time the screen turns on and off, not just at boot time.

[cerialphreak 17]

10 hours ago, netman said:

The next OTA should pull either your or my keyboard driver and fix this.

Great news! Thanks for your effort!

[david 929]

For the people who have this happen every time the screen comes back on, are you on QWERTY or QWERTZ?  I am on QWERTY, and as mentioned before, I only have the issue after powering on. 

There could me multiple variables involved.

- QWERTY vs QWERTZ

- Some system setting

- Some 3rd party app (keyboard related or button mappers would seem to rank high on the suspicion list)

- Some bad config hiding in the /data partition that a system reset could clear up

Mine is QWERTY, with it set at Default, with no language picked.  Been reset since the last OTA, at least twice, I believe.  Only SwiftKey installed for keyboard behavior.  No button mappers yet.

I am rooted with Magisk too, but I am not sure how that would avoid an issue vs causing one, since I am not running any special keyboard/button/Tasker type apps under root.   I mainly have file explorers and backup apps granted superuser.  

Oh, and I did run all those tests on the secret screen that was discovered a week ago.

[elvissteinjr 359]

Gotta say, I can't reproduce this on my unit at all. Did not bother to reboot to check that part, but otherwise it's just working. The touch screen does not count as a "button" for this, right? I don't have a password on the lockscreen so I have to touch my way into some input field first.

QWERTZ (this part should make zero difference except for the key label), rooted, running FinQwerty and Tasker (but turning it off didn't change a thing).
I did technically factory reset from the current OTA when unlocking my boot loader.

[EskeRahn 5,471]

...Interesting that not all have it. Could it be something that depends on how late we got it? If I recall right both @david and @elvissteinjr only rather recently got theirs, so could something have been fixed???

I suspected Swiftkey, but an uninstall did not change it. I have also tried with both Gboard enabled and disabled.

[VaZso 1,998]

28 minutes ago, EskeRahn said:

...Interesting that not all have it. Could it be something that depends on how late we got it? If I recall right both @david and @elvissteinjr only rather recently got theirs, so could something have been fixed???

I suspected Swiftkey, but an uninstall did not change it. I have also tried with both Gboard enabled and disabled.

My friend told me about this strange behaviour a few weeks ago.

Before that I ran into this problem but as pressing an other key solved it, I didn't really care of it.
A little bit after he said it I ran into this thing again and showed him if he is speaking about this behaviour. It was not after a reboot but I have opened the keyboard and started typing... so I showed him I pressed one of the buttons several times and nothing happened... then I have pressed a button nearby which appeared and then the previous button also worked.

Anyway, I thought it is much better than the previous "keyboard stopped working" bug, so I can live with it.

Otherwise, the keyboard driver has improved a lot since then by @tdm and @netman so I really hope stock firmware will also contain these improvements...

 

[EskeRahn 5,471]

2 minutes ago, VaZso said:

Anyway, I thought it is much better than the previous "keyboard stopped working" bug, so I can live with it.

Oh certainly. I actually really seldom run it to it in practise. As it is not among the most common first letters in Danish.

Usually I only encounter it if I just want to answer an sms with Yes ("Ja" in Danish), and if that short, I often just use the fake keyboard anyway...

[david 929]

Serial number 838 here.  Although, we can't be certain all parts of later phones are truly later parts, but it certainly could be something to later phones somehow having a difference.  

It definitely is not a problem for me, since it only happens after reboots, and I didn't notice it before.  I may have had one or two times where I thought the keyboard was dead, and it may have been this situation.  Just looking for possible causes, since it might be something fxtec can't fix (if it is caused by something external).  And if they can fix it, it would help if we can narrow down the variables for them.

[EskeRahn 5,471]

39 minutes ago, david said:

Serial number 838 here.  Although, we can't be certain all parts of later phones are truly later parts, but it certainly could be something to later phones somehow having a difference.  

It definitely is not a problem for me, since it only happens after reboots, and I didn't notice it before.  I may have had one or two times where I thought the keyboard was dead, and it may have been this situation.  Just looking for possible causes, since it might be something fxtec can't fix (if it is caused by something external).  And if they can fix it, it would help if we can narrow down the variables for them.

Well I guess the fix is known, as it is not there on LineageOS after they fixed the driver, so could be a matter of merely copying the known fix. They also fixed other keyboard issues in the same go...

[netman 1,424]

55 minutes ago, david said:

Just looking for possible causes, since it might be something fxtec can't fix (if it is caused by something external).  And if they can fix it, it would help if we can narrow down the variables for them.

It's a very simple bug, they initialize a register in the keyboard chip wrongly. Fix exists but I suspect we will get OTA only when the corona thing calms down a bit. If there is a desperate need for multi-key support and having all the keys work on boot here are fastboot images to fix it (but WARNING this requires erasing userdata - aka a factory reset - and then another one when you want to go back to normal images that can actually receive OTA update, and it comes with bonus bug of fully locking out the phone when the touchscreen bug happens) https://matland.be/pro1/kernel.zip

Alternatively, and probably betterly, there is Lineage as an option.

[david 929]

3 hours ago, netman said:

It's a very simple bug, they initialize a register in the keyboard chip wrongly. Fix exists but I suspect we will get OTA only when the corona thing calms down a bit. If there is a desperate need for multi-key support and having all the keys work on boot here are fastboot images to fix it (but WARNING this requires erasing userdata - aka a factory reset - and then another one when you want to go back to normal images that can actually receive OTA update, and it comes with bonus bug of fully locking out the phone when the touchscreen bug happens) https://matland.be/pro1/kernel.zip

Alternatively, and probably betterly, there is Lineage as an option.

What I'm suggesting is that because the bug happens differently for some people, maybe there is more than one bug.  It is possible that it is the same root bug and that other, external factors make it behave differently on different devices, however.  In that case, fixing the root problem will fix both manifestations of it.  In the meantime, there may be a way to get around it for those who have the issue every time they close and open the screen.  But I get the point that maybe fxtec doesn't need any other info *if* the root cause is the same.

Stupid question...  Can this register be modified from the shell with superuser privileges?  If so, that could be another way for people to get the fix without getting all the other negatives with flashing the images.

[netman 1,424]

2 minutes ago, david said:

What I'm suggesting is that because the bug happens differently for some people, maybe there is more than one bug.  It is possible that it is the same root bug and that other, external factors make it behave differently on different devices, however.  In that case, fixing the root problem will fix both manifestations of it.  In the meantime, there may be a way to get around it for those who have the issue every time they close and open the screen.  But I get the point that maybe fxtec doesn't need any other info *if* the root cause is the same.

Stupid question...  Can this register be modified from the shell with superuser privileges?  If so, that could be another way for people to get the fix without getting all the other negatives with flashing the images.

The only thing I could imagine might make a difference is whether the device actually went to sleep or not, I'm fairly sure this is just one bug. Pressing a key that is not control/shift/fn before continueing could work around it but with added annoyance.

There's no way around flashing a new boot image as far as I know because it requires a modified kernel. But I have to admit I don't know the details of how verified boot and disk encryption work on android, there could be ways around it that I don't know about.

[david 929]

18 minutes ago, netman said:

The only thing I could imagine might make a difference is whether the device actually went to sleep or not, I'm fairly sure this is just one bug. Pressing a key that is not control/shift/fn before continueing could work around it but with added annoyance.

Ding ding ding!!!  You just won the fake prize of the night! 🙂  My phone had been sitting a while, so I tested out your idea, and sure enough, the 7, Y, H were dead.  N was not, but maybe I bumped something else before trying it.

Oh, I just looked above, and maybe on the QWERTY, it is the B key on the bottom row that would be dead.  I'll test that in in the morning, after my phone has been sleeping.

But I think the mystery is solved.  Things must need to be re-initialized after sleeping, so the register issue happens again, just like when the phone is powered on again.

Maybe it isn't the whole phone going to sleep.  Maybe it is a matter of the keyboard just being retracted for some length of time and the keyboard part of it sort of going to sleep after some period of time.  We can test that out.  But it definitely happens after the phone screen has been off for some length of time.

18 minutes ago, netman said:

There's no way around flashing a new boot image as far as I know because it requires a modified kernel. But I have to admit I don't know the details of how verified boot and disk encryption work on android, there could be ways around it that I don't know about.

I figured it was a longshot, but since people were able to run apps that can tweak sound hardware, I thought maybe there was a chance for keyboard hardware too.

Do the keys wake up if you press Ctrl or Shift?  If so, maybe Tasker or some other app could be run when the keyboard is opened (or the screen wakes up), and could automate sending the Shift or Control key code to the device, to automate waking up the other keys?

[david 929]

UPDATE:  The phone doesn't even have to enter any sort of deep sleep.  If I turn off the display and turn it back on, that's enough to do it.  So whereas others were reporting it happening when opening the keyboard, in my case, if the screen is on and I open the keyboard, I'm fine.  *IF* the keys were fine the last time I closed the keyboard and *if* the screen hasn't gone off in the meantime.

In other words, after the keys have been "woken up", everything is fine as long as the screen stays on, whether the phone is opened or closed multiple times.  But if the phone is in the open state *or* the closed state, and the screen goes off, then the next time the keys are attempted, those special keys are dead.

I tried Shift and Control and that doesn't wake up the keys.  Esc does, but that could have unintended consequences.  Left arrow does, so that might be a good choice.  Sym does, so that could be a really good choice.  Delete and Backspace work, but those aren't the best options, in case you are in the middle of some text.  Double tapping caps lock works too.  I think Sym is the best option for creating an automated solution for simulating a keypress when the screen wakes up and/or the keyboard is opened.  If people are using some sort of keyboard mapping where that key does something, then simulating hitting caps lock 2 times will also work.

[netman 1,424]

3 minutes ago, david said:

Ding ding ding!!!  You just won the fake prize of the night! 🙂  My phone had been sitting a while, so I tested out your idea, and sure enough, the 7, Y, H were dead.  N was not, but maybe I bumped something else before trying it.

There will be 8 keys to find.

4 minutes ago, david said:

 Things must need to be re-initialized after sleeping, so the register issue happens again, just like when the phone is powered on again.

Maybe it isn't the whole phone going to sleep.  Maybe it is a matter of the keyboard just being retracted for some length of time and the keyboard part of it sort of going to sleep after some period of time.  We can test that out.  But it definitely happens after the phone screen has been off for some length of time.

It happens because a register in the keyboard chip gets initialized incorrectly, I don't know exactly when android decides to re-initialize, but it does not care whether the keyboard is retracted or not. It'll depend on what apps are running, time of sleeping, and some mystery factors that I won't even try guessing at.

7 minutes ago, david said:

Do the keys wake up if you press Ctrl or Shift?  If so, maybe Tasker or some other app could be run when the keyboard is opened (or the screen wakes up), and could automate sending the Shift or Control key code to the device, to automate waking up the other keys?

I don't think the modifier keys can wake it, but not 100% confident, I solved the issue for myself so can't test xD. Sending keypresses artificially won't do the trick, the keyboard driver needs to receive an interrupt from the keyboard chip for the issue to go away (the part of the driver that handles actual keypresses will initialize the chip properly once it's done handling the keypress).