Shift key makes arrow keys send numbers instead [solved - MacBook quirk]

[je55eah]

When editing grub.cfg I discovered a strange behavior.
The arrow keys send numbers if shift is depressed. This would be normal on the number pad, but it interferes with highlighting a block of text.

[step]

Thanks for reporting. Fatdog64 isn't yet involved at this stage. The motherboard BIOS/UEFI starts the boot manager, grub, which then interprets keypresses. I googled for "grub keyboard not working" and found some pages, all involving specific, hardware-dependent work-arounds, which may not be applicable in your case? Such as, changing the USB keyboard or USB port, enabling USB legacy support in BIOS setup, finding surrogate keys (Page Up/Down mentioned), and so on, upgrading grub. Another option is changing the boot manager. Have you tried grub4dos beforf? The applet "Fatdog64 Control Panel > Install > Grub4dos bootloader config" can help in preparing boot media for grub4dos.

[je55eah]

I should have been more precise. This happened when I was editing grub.cfg with geaney in the running system.

The other keyboard issue that I mentioned in other threads was resolved with the coldplug boot option. That was an issue where the keyboard worked in grub and in the fully loaded system, but not during the early stages when a decryption password was recovered or when prompted to choose between multiple save files.

This thread is about the keyboard in a running fatdog system returning numbers when the normal arrows are pressed with shift. This makes it difficult to select text with the keyboard.

[JakeSFR]

This is weird. Can you reproduce it in Leafpad?

Also, type xev in terminal and press Shift + an arrow key.
For Shift+Right I get state 0x11, keycode 114 (keysym 0xff53, Right).

Greetings!

[je55eah]

Yes. It happens with leafpad.
shift up and down are normal, but left and right produce numbers.

xev logs keypress and release events

shift
0x0 50 0xffe1 shift_L
0x1 50 0xffe1 shift_L

shift up
0x1 111 0xff52 up

shift down
0x1 116 0xff54 down

shift right
0x1 114 0xffb6 kp_6

shift left
0x1 113 0xffb4 kp_4

right
0x0 114 0xff98 kp_right

left
0x0 113 0xff96 kp_left

[JakeSFR]

right
0x0 114 0xff98 kp_right

left
0x0 113 0xff96 kp_left

Ok, for some reason your left/right keys are recognized as 4 and 6 keys on the numeric keypad. Mine aren't:

Code: Select all

# xmodmap -pk | egrep 'Left)|Right)'
     83    	0xff96 (KP_Left)	0xffb4 (KP_4)	0xff96 (KP_Left)	0xffb4 (KP_4)	
     85    	0xff98 (KP_Right)	0xffb6 (KP_6)	0xff98 (KP_Right)	0xffb6 (KP_6)	
    113    	0xff51 (Left)	0x0000 (NoSymbol)	0xff51 (Left)	
    114    	0xff53 (Right)	0x0000 (NoSymbol)	0xff53 (Right)

You could try to rempap them using:

Code: Select all

xmodmap -e 'keycode 113 = Left'
xmodmap -e 'keycode 114 = Right'

and see if it helps.

Greetings!

[step]

@je55eah, these fix was already included in the macbook sfs I posted. I guess you haven't loaded it.

[je55eah]

I discovered that everything else seemed to be working so I stopped using the sfs you provided. It looks like I should either use it or figure out a way to make a sfs with only this key remapping.

Thanks gentlemen

[je55eah]

@step
On the system with your sfs loaded the shifted left and right arrows still print 4 and 6.

[step]

@step
On the system with your sfs loaded the shifted left and right arrows still print 4 and 6.

Strange, it works for me. Are you perhaps testing the sfs with your savefile loaded? That could explain why you get a different result. Files in the savefile override equally-named files in the sfs. Can you please test again with the sfs and without a savefile?

out_2022-10-10_101533.gif (354.54 KiB) Viewed 1036 times

I discovered that everything else seemed to be working so I stopped using the sfs you provided. It looks like I should either use it or figure out a way to make a sfs with only this key remapping.

You can pick and choose from the sfs:

1. Click the sfs file icon; This will mount the sfs as a regular folder.

2. In that folder navigate to etc/X11/app-defaults to find a file named Xmodmap.

3. Merge the contents of this file with the contents of file /etc/X11/app-defaults/Xmodmap in your system. Save the latter.

4. Click the sfs file again to unmount it.

5. Restart X to affect Xmodmap changes.

You can read more about the layered file system and sfs tricks in this FAQ How does Fatdog's layered filesystem work?

[je55eah]

Yes, I have loaded the sfs in a system without a savefile and the shifted arrows still print 4 and 6.

Is it safe to open and mount the sfs while the sfs is loaded?

[je55eah]

It turns out that the Xmodmap changes from the MacBookPro sfs are built into the default fatfog813 with no save file.

20221010_102848-01.jpg (158.06 KiB) Viewed 815 times

I deleted the text in the Xmodmap file, restarted X and now the keys function normally.

It wasn't the solution we expected, but it looks like we have fixed everything. Thank you.

I'm surprised that everyone doesn't have this problem if everyone running 813 has those keys remapped. There's a puzzle here.

[step]

Is it safe to open and mount the sfs while the sfs is loaded?

Yes

It turns out that the Xmodmap changes from the MacBookPro sfs are built into the default fatfog813 with no save file.

There is no /etc/X11/app-defaults/Xmodmap file in the Fatdog64-813 ISO. Your screenshot shows the same Xmodmap file seen in two different layers: the mounted macbook sfs layer on the left, and the loaded macbook sfs layer on the right. I know it can sound confusing but bear with me. The loaded sfs layer is the one that affects the system, that is, your keyboard. The savefile is yet another layer, on top of the loaded sfs layer, which affects the system and overrides equally-named files in the loaded macbook sfs(*). When you start without a savefile you allow the Xmodmap file in the loaded sfs to affect the keyboard because the that file effectively becomes /etc/X11/app-defaults/Xmodmap.

It wasn't the solution we expected, but it looks like we have fixed everything. Thank you.

Great!

I'm surprised that everyone doesn't have this problem if everyone running 813 has those keys remapped. There's a puzzle here.

Again, the Xmodmap file is in the sfs but not in the ISO.

____
(*) As well as deleted files and deleted directories but let's keep this discussion simple. You can always read more details in the FAQ links I already mentioned.

[je55eah]

@step

I must still be confused.

The terminal in the lower left indicates that the sfs was not loaded.

I also booted the unmodified iso and there is an Xmodmap file with those key remappings included.

[step]

@step

I must still be confused.

The terminal in the lower left indicates that the sfs was not loaded.

I also booted the unmodified iso and there is an Xmodmap file with those key remappings included.

@je55eah, to check ISO contents I ran a qemu virtual machine with the Fatdog64-813 ISO as a guest OS then inside the vm I navigated to /etc/X11/app-defaults. There are 10 files inside, no Xmodmap though. The checksum of the ISO I used is a1e0ed048391faaf494ae88af5448810 Fatdog64-813.iso.

[je55eah]

our iso files have the same checksum.

I created yet another installer with rufus on windows. I chose the dd mode because the iso mode doesn't boot on the mac. The resulting live boot system does include Xmodmap. Something doesn't make sense. Could there be a script somewhere which is detecting the macbook and adding the key remappings?

Out of curiosity I booted it on another computer, a samsung, and checked. Sure enough, only 10 files appear in the folder and Xmodmap is not present.

[step]

Could there be a script somewhere which is detecting the macbook and adding the key remappings?

Bravo! Yes, it's /etc/rc.d/rc.platform. It runs only once on the very first session. It's platform dependent. For model MacBook9,2 it creates Xmodmap in what will become your savefile when you shutdown the first session and you're asked if you want to create a savefile. So you're correct, when you boot your macbook for the very first session - without macbook sfs loaded and without a savefile loaded (because it's the first session), you will still find Xmodmap, which was just created behind the scenes.

Out of curiosity I booted it on another computer, a samsung, and checked. Sure enough, only 10 files appear in the folder and Xmodmap is not present.

A Samsung model isn't a MacBook9,2 so rc.platform doesn't do its first run magic. The same happens for a qemu vm.

The sfs I gave you is a collection of the changes made by rc.platform for the macbook, plus some drivers, keyboard daemons and tweaks of my own.

Now, I am asking myself, why didn't the arrow keys work in the first place since rc.platform provides a Xmodmap for them? My guess is that when you opened this thread you: 1) were loading a savefile; 2) the savefile had been created of a first session that ran on your samsung or other PC but not on your MacBook9,2. #1 and #2 would give you reason to open this thread. Then @JakeSFR helped you partially fix the arrow key map. So 3) a partially- but not completely-fixed Xmodmap existed in that savefile. And this created some further confusion and led to this point in time.

If my reconstruction of events is correct, then my learning is to never assume that a user asking for support has created the first session savefile on the same machine for which they're reporting an issue.

[je55eah]

@step
The problem is that the changes made to Xmodmap by rc.platform are breaking changes. My fix is to delete them. Every person who uses fatdog on a MacBookPro9,2 will have the arrow key problem unless those changes are removed from rc.platform.

[je55eah]

I wonder if the unneeded changes in Xmodmap have something to do with the way home and end are mapped to fn+left and fn+right. Could it be that when @step swapped ctrl and fn it messed that up and then the Xmodmap somehow fixed it for his use case? I'm only speculating, but I just learned about the home and end keys on the Macbook and it struck me as a possible clue.