Open doak opened 1 month ago
I haven't checked out yet if there was an update of the OS within the last days …
This was not the case. There was an (stable) update yesterday, but I've experienced the issue already before. I hardly can imagine that such behaviour is caused by slightly different SW for FP4 and FP5, though.
Hence, any input is highly appreciated.
In what application do you observe this ? There has been recent changes to related code but I can't reproduce the problem (ec8e78d, dc3a303)
In every single applications. Tested with Chromium, Conversations, Signal, Orgzly and Kiss. Im pretty sure it is related to the device, but cannot imagine how.
I've just downloaded the debug build for #626 and will try that one.
Testing with default settings for #626: It happens not always but sometimes. Strange. Some timing issue …
Oh shit. It seems somehow related with the size of the key(s). Somehow the smaller the key, the higher "I" don't hit it. But only if I press the second key very quick after Ctrl
. I don't observe this if I press Ctrl
alone.
But only if I press the second key very quick after
Ctrl
.
I should probably point out that I use two distinct fingers (i.e. both thumbs) for this.
I've replaced the Shift
with an additional Ctrl
. This one works as expected. I've swapped Shift
and Ctrl
in my custom layout – now Shift
has the issue.
Hence it seems related to this specific position.
I've added an additional minimal width key before Ctrl
– no change.
I've increased the bottom margin to maximum – it work's.
⇒ Perhaps the OS interferes with dual touch if the first is near the (bottom left) corner. Is that plausible?
Another observations:
I've enabled debug options for touches. Even pressing only Ctrl
looks different than for z
or Shift
. Please have a look at the attached videos. (I had pressed Ctrl+h
all the time when only h
is recognised.)
https://github.com/Julow/Unexpected-Keyboard/assets/2485924/caad5954-3f73-4350-a334-9f869941bff4
https://github.com/Julow/Unexpected-Keyboard/assets/2485924/0676229d-15b7-400d-8b4c-9e2d4dd80f14
Could the back to home gesture interfere with the keyboard ? This seems consistent with the fact that bottom margin helps. The keyboard already has to opt-out of the back gestures on both sides of the screen but as explained here it can't opt-out of the home gesture. Could you try this debug build ? (code is here)
Unfortunately no improvement, it looks like the same. I've also disabled gesture navigation at all.
https://github.com/Julow/Unexpected-Keyboard/assets/2485924/7464b86c-54a2-4ce2-8a45-74440b748d49
The same is at the bottom right corner (Enter
), but neither top left nor right. At least according to debug pointer locations.
The same regions "look different" (i.e. the same like for Unexpected Keyboard) in another app (Orgzly) without the keyboard being displayed. You still can't reproduce it, @Julow, right?
~In Chromium the displayed debug pointer locations are "correct"/like expected.~ No, it's the same.
If you can't reproduce with another device, I am pretty sure this is related to Fairphone 5 or perhaps CalyxOS. Thanks for your support, @Julow!
I've created a ticket for CalyxOS as well: https://gitlab.com/CalyxOS/calyxos/-/issues/2338
This worked for sure, but after reinstalling on a new phone this is broken for
Ctrl
but not for other modifiers likeAlt
orShift
. Surprisingly it behaves the same when using an outdated debug build which is still installed. This was definitely not the case when I had installed it those days. I've reset data and reinstalled – no change. Hence it looks like the SW of the new device breaks something. Any ideas?Expected behaviour: Pressing and holding
Ctrl
while pressing e.g.w
quickly afterwards sendsCtrl+w
.Actual behaviour: Pressing and holding
Ctrl
while pressing e.g.w
sends solew
. (It works however ifCtrl
is holded for some time.)Previous phone:
Current phone:
I haven't checked out yet if there was an update of the OS within the last days …