Keyboard arrow keys issues about mbp-2016-linux

[puellanivis]

When you hit Fn with the touchbar, there is a short period where the touchbar is being changed, and there might be an exclusionary interrupt lock or such…

So, it’s possible that you might be managing to fall into some tight “race condition” type situation?

\badjoke{have you tried typing slower?}

I guess what I am saying is that it’s entirely possible that you’re running into a real issue (it’s definitely plausible) but I think someone very familiar with touchbar code may need to look into things… I’m particularly not a good choice, because I’ve also had to give up linux on my MBP 13,2, myself. (And I hate it. But after a trunc("libsystemd") I had to reinstall anyways…)

[mzanetti]

Yeah, I thought the very same... The one thing that makes me a bit unsure about this is that I think it also happens with just the arrow keys, no fn too. But not sure, could be I am running into the same after relasing fn... Would also explain why it only happens with the arrow keys, I never really use any other keys at the same time as interacting with fn.

Thanks for your input. I'll pay closer attention if this is indeed related to the fn key press/release.

[puellanivis]

Well, both press and release introduce the same touchbar change response, so it’s would be most likely to affect both if it were to affect either.

[roadrunner2]

I'm fairly certain the touchbar is not (noticeably) slowing things down here: the driver listens for the FN key events from the core, and determines if the touchbar needs to be changed; if a change is needed, that is scheduled to be done on a separate thread (a workqueue, to be exact). So while locks are certainly acquired during the processing of the FN key events, they are held only for very short times (on the order of µs at most). Delays in the touchbar updating are generally either due one or more of: A) workqueue scheduling delays, B) sending USB commands and the touchbar itself, or C) retries of the USB commands when they fail. There is also an extra delay when waking the touchbar back up after it was turned off due to being idle. But all of these delays happen "asynchronously" after the work has been scheduled.

If you want to verify and conclusively exclude the appletb driver as the culprit you can always just sudo rmmod appletb.

Back to the arrow keys themselves, I have noticed that the up and down keys feel stiffer than the other keys, which is possibly an artifact of their smaller size; the left/right keys feel normal. But I haven't noticed them not responding. Having said that, I've experienced issues with various keys on occasions: for a while one of the main keys would often generate two events (i.e. the letter would be doubled), and that happened when pressing the key on one particular side (rather than in the center or one of the other sides) - that eventually resolved itself. Another one I ran into on somebody else's laptop was the key suddenly having almost no travel and needing a lot of pressure to trigger - this was consistent, though, unlike what you're reporting, and application of compressed air (as described here) fixed that.

[mzanetti]

Hey, yeah, I've already had something under my down button already too but I was able to remove that and the key is working fine again. That's not the issue here, no.

Good point with removing the touchbar module... Will try to code for a while without it (although not sure how to manage that without F keys) but just for testing if the fn+arrows situation improves it should be ok.

So if you say there is indeed a lock where any incoming events would be ignored, even if it's just µs, that kinda sounds like it tbh... Couldn't (or rather shouldn't) those events be queued instead?

Anyways, will hack some code without touchbar today and report back.

Thanks for all your input folks!

[puellanivis]

OMG, my keyboard was at one time repeating n’s for like a week or two… maybe longer. :( Kind of expected that it was a lone issue, odd to hear that it might be an edge-case mechanical issue…

[roadrunner2]

So if you say there is indeed a lock where any incoming events would be ignored, even if it's just µs, that kinda sounds like it tbh... Couldn't (or rather shouldn't) those events be queued instead?

You can't really put something on a queue without acquiring a lock either... (in a multi-thread/process environment). And effectively that's what it's doing. Furthermore I didn't say events would be ignored - if you somehow manage to send thousands of key-board events a second (probably much higher) so that the event processing in the kernel can't keep up, then it would back-pressure to whatever is generating the keyboard events; in the case of applespi that would then back-pressure to the keyboard device itself, which has some buffering, though I have no idea how much.

Anyway, this is all really fairly academic.

[mzanetti]

Ok, after using it a while without touchbar I think I can say it still happens. I had the impression it happens less, but that might be me paying extra attention to it.

[Dunedan]

Does that still happen with the latest version of applespi?
Sounds like it could've been the same as cb22/macbook12-spi-driver#53 which got fixed two weeks ago.

[mzanetti]

uh, will test it asap. thanks for the heads up

[Dunedan]

@mzanetti Any news regarding this issue?

[mzanetti]

I've upgraded the driver now... let's see how it goes.

[mzanetti]

Been using this for a bit now but I don't have the impression it changed anything in this regard.

[rwuwon]

Is this not purely a hardware issue? In my MBP 13,1 the half keys wouldn't trigger unless I pressed them square-on - I could replicate non-presses by pressing the corner of the keys lightly to feel the click but not see the output. The mechanism was less even than the normal keys.

After a top case replacement due to a battery life issue, I ended up with a 2017 keyboard which appears to feel and sound subtly different. The half keys work a lot better in this case and I've not had any misfires with both volume and arrows.

Can you rule out a similar situation seeing that you appear to have the 2016, and not 2017 keyboard?

[turenar]

I bought MBP14,3 on May 2018, and soon, found Fn+Left/Right are sometimes ignored.
I'm not sure whether I actually press keys, and whether there is the same issue with PgUp/PgDn.
It seems, however, pressing arrow keys immediately after (actually after) Fn-keydown sometimes causes this issue and cursor is not moved.

[Dunedan]

Key presses not getting registered could also be caused by the key rollover behavior of the keyboard. That of course would require pressing multiple keys in parallel or very quick succession. I had such a problem a while back (before applespi got a fix to behave the same as macOS and hid_apple): cb22/macbook12-spi-driver#53
Even with that fix there is still a maximum of keys registered in parallel and that maximum depends on which keys are pressed.

[rwuwon]

I've just installed the SPI drivers from roadrunner2's fork for the first time on my 13,1 (but with a 2017 keyboard/battery) and haven't been able to notice any of the described behaviours so far with Firefox and gnome-terminal.

@mzanetti, are you still not able to reproduce the issue every time on demand - for example, by pressing the corners lightly? I remain convinced that the 14,x (2017) keyboards are different enough in both feel, sound and actuation and if true, I think that would affect a responsiveness when hitting the keys off-centre (i.e., from after being on the home row in an IDE or elsewhere).

If you can notice the same issue under macOS, I think taking up the newly announced Butterfly keyboard service program could be a worthy consideration - my guess is that if eligible, you'll probably end up with a 2017 keyboard as part of the top case replacement (if you go for this option, I'd recommend setting up a temporary non-admin login and read-protect the rest of your ~/ because in my case, Apple asked for login details (apparently for testing purposes) just like the example here).

[Dunedan]

Still anybody here having problems with key presses not getting registered? For me all problems are gone since the key rollover fix mentioned above.

[Dunedan]

Closing this, because of missing feedback. Feel free to reopen, if that's still an issue for you.