Home & End buttons not working properly

My ‘Home’ key and ‘End’ key are not working properly.

By default they get me to the start of a line (‘home’ key) and the end of a line (‘End’ key) however, if I press the combination of the ‘Shift’ key wither either one of them I get the number printed rather than the entire line selected as one would expect.

To get the entire line to be selected I need to toggle the ‘NumLk’ key, which then breaks the default behaviour breal, e.g. pressing ‘Home’ key alone prints a number rather than taking the cursor to the start of the line.

This is rather frustrating.

I tried various ways to re-map the functionality to ‘Ctrl + arrows’ (Ctril + left arrow for Home and Ctrl + right arrow for End) using the the GNOME Setings->Keyboard app but couldn’t find it there, and spent a whole morning looking at keymap tool to load a custom map in my local .initrc file, but again no luck as the ‘Ctri’ key is not a key modifier.

Anyone can help with this? Ideally I would prefer to remap Ctrl + arrow as I don’t use the word navigation functionality.

I am using a Librem 15 with PureOS.
I would like to disable the numpad. completely.

A very common thing I do on the keyboard is Shift+End to highlight/select everything from the cursor position to the end of the line and Shift+Home to highlight/select everything from the cursor to the beginning of the line.

I cannot figure out how to input those key combinations on the librem. When I have numlock off, Shift+Home gives me a 7 instead. When numlock is on, Shift+Home acts just like Home.

1 Like

yep, same problem here. I have reported this to the Purism team on their feedback email as well as in this thread. They said they would look into it.

Hi,

I agree here, some way to fiddle with the keyboard firmware would be awesome.

For this particular problem, you can diagnose a bit better with the “xev” program. It would appear that pressing shift with num-lock turned off reverts the key to regular digits (actually not numpad digits! There should be a difference between numpad 3 and upper row 3)
It’s probably not too difficult and I can’t see any reason someone would want a capital 3, or what it would look like in the first place, so hopefully we’ll get that fixed :slight_smile:

Unfortunately I can’t see how to work around this with /etc/inputrc or from xinput/xmodmap, so we’ll have to wait a bit.

Cheers,

unsurprisingly, the same is true for shift+PgUp and shift+PgDn

Turns out this actually is something we can fix in software, although I’m not sure how to make Num Lock work at all it’s easy enough to disable entierly with Xmodmap.

You can generate the current map with this command:
xmodmap -pke > ~/.Xmodmap

Then edit the file, look for KP_Prior and similar, and simply replace the KP_3 by KP_Prior again etc.
I’ve actually taken this occasion to replace them with non-keypad versions (Prior etc) so that the compatibility with e.g. urxvt is slightly better (I already had gotten it to work through .Xdefaults and URxvt.keysym.KP_Prior* but might as well make that regular page up for better compatibility)

I’ve also been fiddling with media keys and adapted mute to play/pause, brightness down/up to media prev/next, volume down/up to brightness down/up. I would have liked to add or change more media keys (the multi display litterally sends super+p so can’t overwrite that…), but this is really going to need some firmware change, so if we can fiddle with it I’m still very interested.

Please note:

  • xmodmap is somewhat deprecated, I’m not using gnome but if it’s switched to wayland you might need to fiddle with xkb instead. There are similar maps we can find and edit, I might do it at some point™ laterⓁ
  • I’ll try to understand num lock a bit more, basically it seems to send the same keycode with a modifier 0x10. shift is 0x1, caps lock toggles 0x2, ctrl is 0x4, alt 0x8. These flags all add up and software decides how to interpret the key then, so I think it’s just a matter of understanding how to tell it and restore the behavior.

With that said, my .Xmodmap file looks like that:

keycode  63 = asterisk asterisk asterisk asterisk asterisk asterisk XF86ClearGrab
keycode  77 = Num_Lock NoSymbol Num_Lock
keycode  79 = Home Home KP_7 KP_7
keycode  80 = Up Up KP_8 KP_8
keycode  81 = Prior Prior KP_9 KP_9
keycode  82 = minus minus minus minus minus minus XF86Prev_VMode
keycode  83 = Left Left KP_4 KP_4
keycode  84 = Begin Begin KP_5 KP_5
keycode  85 = Right Right KP_6 KP_6
keycode  86 = plus plus plus plus plus plus XF86Next_VMode
keycode  87 = End End KP_1 KP_1
keycode  88 = Down Down KP_2 KP_2
keycode  89 = Next Next KP_3 KP_3
keycode  90 = Insert Insert KP_0 KP_0
keycode  91 = Delete Delete period period

! original Audio Lower/Raise Volume -> brightness
keycode 122 = XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown
keycode 123 = XF86MonBrightnessUp NoSymbol XF86MonBrightnessUp

! original Audio Mute -> Play toggle
keycode 121 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause
! original Brightness Down/Up -> Play prev/next
keycode 232 = XF86AudioPrev NoSymbol XF86AudioPrev
keycode 233 = XF86AudioNext NoSymbol XF86AudioNext

And you just need to load it (with xmodmap ~/.Xmodmap) when session starts (can’t help for gnome)

(If anyone at purism can write down in the feedbacks, it’d be awesome to have a small LED indicator for caps locks and num lock!)

2 Likes

thanks for the post @Asmadeus, I too have been playing around with xmodmap, and in fact re-mapped the Home/End functionality to ‘Ctrl+arrow left/right’ as I find that more convenient for my use, however as you rightly pointed out…

~/.Xmodmap will not load by default and the only way others have managed to execute it at session logon for gnome3 is to launch it as a delayed startup command to ensure the xkb has loaded prior to that. Seems to be a bit of hack and so I have been reading about xkb which is far more complex to customise and I am yet to get it work properly. I hope to get some time to fiddle with it some more and report back here my findings.