Ctrl-Shift-T not working
JanmanX opened this issue · comments
When swapping Left-Shift Left-Ctrl with FN, CTRL-SHIFT-T combination is not being registered.
Using the original patch supplied in this repository (hid-apple.c.original_(kernel_3.16.0-28), the combination works.
I first noticed it when trying to reopen last opened tab in Chrome, but verified in some other programs.
You might want to get some better readings using "xev".
Free5lot has a much better understanding of the module, but I figure it is a problem with the mechanical part of the keyboard, and not the patch itself, and thus, can't be solved. (@free5lot, please verify :) )
Also, the key-combination is not working either on my version of this patch.
UPD (2020) for readers from future: the real workaround for Ctrl(Fn)+Shift+T combination is to release Ctrl(Fn) key first in this combination.
Also see: https://github.com/free5lot/hid-apple-patched#limitations
Original message:
NOT CONFIRMED.
Well, first of all I checked and it works for me. I've checked Ctrl+Shirt+T in Firefox and in Konsole (KDE). So, it's really and be a hardware problem of yours but I can't be sure.
Under "Ctrl" we both mean left-bottom key on keyboard with "fn" label on it, yes? :)
Secondly, I cloned the kernel from mainstream repo a week ago and checked, the hid-apple.c file is the same as this patch uses (as original code hid-apple.c.original_(kernel_3.16.0-28)), so everything is up to date.
Jan, what do you exactly mean with "a problem with the mechanical part of the keyboard"? Is it broken or there is a hardware limitation of fn+2_more_keys events?
@free5lot
Yes, I press the "fn" which is mapped to ctrl.
To be clear, I press buttons labelled with: FN-LSHIFT-T, which are mapped to LCTRL-LSHIFT-T.
By "problem with mechanical part of the keyboard" I meant a hardware limitation of the keyboard - yes, something like fn+2_more_key events.
I have verified this issue on 2 separate machines running Ubuntu 14.04, but with the same keyboard.
I will try to find any documentation on this FN key...
Well. Than good news is that Macbook Pro Retina doesn't have this limitation.
And bad one - maybe it'll be unsolvable for you if there is electric limitation on the keyboard's board.
One more chance - try LiveCD of Kubuntu or other KDE-based GNU/Linux. Maybe it's some kind of Gnome's limitation, but I doubt it.
What model of external keyboard do you have exactly?
@free5lot
I have the "Apple Wireless Keyboard" model: A1314 Image.
I have found no documentation on limitations of the FN key, but I have found a very strange behavior.
Using this site, I can press any key with the combination of fn-shift (mapped to ctrl-shift) except "t".
Unfortunatelly, Ubuntu seems to be the only distro that supports my bluetooth drivers out of the box. Installing drivers for my adapter on Kubuntu is a mess, so I cant test it on KDE just yet.
Using this site, I can press any key with the combination of fn-shift (mapped to ctrl-shift) except "t".
Quite interesting and strange! So Ctrl+Shift+… almost works for you except T char.
Please try ctrl+shift+… combinations somewhere in Gnomes soft. And maybe in settings where you can set hotkeys.
Maybe Fn+Shift+T means something exceptional on Mac.
@free5lot
Maybe. The Gnome Keyboard shortcut program doesn't register the combination either.
I cannot help any further right now, as I am rather busy, but here is samle output from "xev" of the combination being pressed. Maybe you can make some sense of it:
KeyPress event, serial 37, synthetic NO, window 0x4c00001,
root 0x2c9, subw 0x0, time 3498322, (16,7), root:(16,59),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 37, synthetic NO, window 0x4c00001,
root 0x2c9, subw 0x0, time 3498772, (16,7), root:(16,59),
state 0x1, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
-------------------------------- "T" is being pressed, but xev reports KeyRelease event on Left-Shift
KeyRelease event, serial 37, synthetic NO, window 0x4c00001,
root 0x2c9, subw 0x0, time 3500772, (16,7), root:(16,59),
state 0x5, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
-------------------------------- "T" being released, xev reports KeyPress on Left Shift
KeyPress event, serial 37, synthetic NO, window 0x4c00001,
root 0x2c9, subw 0x0, time 3501360, (16,7), root:(16,59),
state 0x4, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
So, it seems to be some hardware related problem of external keyboard, and doesn't affect MacBook Pro or other devices, that can get key-press correctly (who doesn't make FN key (Ctrl after modification) as something special on HARDWARE level). So it's not a patch issue and probably can't be fixed for this hardware.
So I'm closing this ticket as on other hardware it was not confirmed.
I can confirm the issue with the "Apple Wireless Keyboard" model: A1314.
@JanmanX did you figure out any solution for the problem?
Thanks,
Miguel
Same behavior with Wireless Keyboard A1255.
I have an question to guys, who have original MacOS and this external Apple Wireless Keyboards. Can you switch the buttons in MacOS and try ctrl+shift+t there? It may either prove it's a physical limitation or give some hope.
Can also confirm with A1644. Only T doesn't work. Everything else does.
@StephanDollberg Can you switch the Fn and LeftCtrl buttons in MacOS and try Ctrl+Shift+T there (really Fn+Shift+T actual keys)? Will it work there?
@free5lot I don't have access to a Mac right now but I might have in a couple weeks (not fully sure yet though). Then I can try.
UPD (2020): You don't have to press keys in small window or fast. The real workaround for Ctrl(Fn)+Shift+T is to release Ctrl(Fn) key first in these combinations.
See: https://github.com/free5lot/hid-apple-patched#limitations
Anyhow thanks to @djdevin for this information as it was crucial to understand that workaround does exist.
Original message:
Some additional information from @djdevin:
FWIW if you train yourself you might be able to get around this limitation. The keys cannot simultaneously be pressed but you have a small window which may be recognize as simultaneous.
"Roll" up to Control-Shift-T by pressing no more than 2 keys at the same time (control, then shift, then start to pull off as you press T) and you should be able to trick it into thinking you pressed them all together. I accidentally discovered this and I can get it 99% of the time now.
I don't have monster hands so I can't do it with 1 hand which might be more difficult.
Just for the record:
I am using this configuration on an external slim Apple Bluetooth keyboard (A1314):
options hid_apple fnmode=2
options hid_apple swap_fn_leftctrl=1
options hid_apple swap_opt_cmd=1
options hid_apple rightalt_as_rightctrl=1
options hid_apple ejectcd_as_delete=1
- Control_L Shift_L t works only with "rolling" off the Control_L key as I am pressing the t key
- Control_L Shift_R t works perfectly
- Control_R Shift_R t works perfectly (I can live with this one for reopening closed tabs)
- Control_R Shift_L t works perfectly
Other three-key combinations also work perfectly, e.g.:
- Control_L Shift_L TAB
- Control_L Shift_L c
- Control_L Shift_L v
In sum, I'm grateful for this clean solution for matching my external Apple keyboard to the one built into my Dell XPS laptop.
@almson can you please test this combination using Bluetooth connection mode?
Ctrl+Shift+T doesn't work in Bluetooth mode either, but the trick with "rolling" works! Thanks!
It's pretty common for keyboards to have such limitations. Expensive keyboards advertise their n-key "rollover" https://en.wikipedia.org/wiki/Rollover_(key). Apple must have cut a corner with the Fn key.
So, it's still a hardware limitation.
Thanks for information.
PS. It's just odd that the only key affected by cutting corners is T key. I have no explanation for this technical decision.
The entire 5-T-G-B column is affected. Fn+Option+G doesn't register (to use the silkscreened names), as well as Fn+Command+B, and Fn+Control+5.
The entire 5-T-G-B column is affected.
Oh, that makes more sense then. That indeed seems to be cutting corners by Apple.
Maybe these details should be mentioned at the end of README?
And rolling trick that mitigates this issue for these 3 keys combinations.
PS. On Macbook Pro there is no issue with Ctrl+Shift+T and probably any issue with any column at all.
This also affects me using the Magic Keyboard A1644 over bluetooth.
A quick tip to those wondering how to do the "rolling trick". Timing doesn't matter. Just press "Fn+Shift+T", then release the Fn key first. That will always register a Ctrl+Shift+T press.
A quick tip to those wondering how to do the "rolling trick". Timing doesn't matter. Just press "Fn+Shift+T", then release the Fn key first. That will always register a Ctrl+Shift+T press.
Thanks for the tip. I will add it to the Readme.
I can confirm that this combination doesn't work in A1644 (nor usb-connected, neither bluetooth connected) and it didn't work in A1242 either, which I had been using for ages. The rolling trick is super helpful though, thanks for the tip! 👍 for adding it to the Readme.
Wow, I don't know how @klaeufer found the "rolling-off" trick but thank you! 🙏
My bad! Thanks all around!
FWIW, not sure if it's already known, but in testing with A1644 (ANSI US English) connected via USB to macOS 13.2.1, and mapping the physical fn key to ctrl, I can reproduce the issue with T, but not with 5-G-B. So it's at least partly an OS-independent issue...