Linux X11

Adding a `hyper` modifier key to your keyboard, because shift/ctrl/alt/meta/super aren’t enough

TL/DR: Try this in your ~/.Xmodmap log out of X11 and log back in. If you moved to Wayland, hopefully one day we'll get stable APIs for 3rd party window utilities. Until that happens, I recommend switching back to X11 if you can.

clear mod1
clear mod2
clear mod3
clear mod4
clear mod5

keycode 248 = Hyper_L

add Mod1 = Alt_L Alt_R
add Mod2 = Num_Lock
add Mod3 = Hyper_L
add mod4 = Super_L Super_R
add mod5 = ISO_Level3_Shift Mode_switch

Note that you can't blindly copy code 248... You need to find a key that will work for your keyboard.

Soft fn key on keyboard

Use xev -event keyboard to find the keycode for the key that you want to use. While xev is running, focus on the xev window and press the key you want to use. You'll see the KeyRelease event show on your console. Best to use the xev -event keyboard filter so that all mouse events can be ignored.

In my example, this is AFTER I've use Xmodmap to map this key to Hyper_L... You won't see this until your remapping is successful.

You need to make sure Xmodmap will actually start with your widow manager, and for me, it works best with a delay. So I have a file ~/.config/autostart/xmodmap.desktop

[Desktop Entry]
Comment=Xmodmap Keyboard Modification

And then delay_xmodmap is a trivial script that just sleeps for a bit before launching.


sleep 10;
xmodmap ~/.Xmodmap

Using a hot key manager like sxhkd you should be able to map shortcuts to the Hyper key now. Put something like this in your ~/.config/sxhkd/sxhkdrc to test that Hyper is working.

hyper + {a-z}
        notify-send "hyper {a-z}"

Every keyboard I've ever seen has a SHIFT key and CONTROL keys. Historical Unix vs Mac vs Windows are a bit different for the other keys:
Alt == Meta (Option in the Mac World)
Windows Key == Super Key == Command Key

So you basically get 3 modifiers on each key, but SHIFT is so common for text it's dangerous for most of us to configure that.

If you're on Linux, and you have a keyboard that generates an actual "keycode" (some fn labeled keys actually run software in the keyboard to send a different keycode to the OS, without the OS knowing that a modifier was involved).

mod1AltOptionAlt_L Alt_R / Meta
mod2Num LockNum Lock
mod4Windows KeyCommand KeySuper_L Super_R
X11 mod1 keys


What are _GTK_FRAME_EXTENTS and how does Gnome Window Sizing work?

Gnome is a trailblazer. Desktop icons? Using the Win/Cmd/Super key as a shortcut key? Getting rid of backwards compatibility? The Gnome developers are always eager to try new things...

There was once a time when the KDE (kwin) folks and the GNOME (mutter) folks appeared to get along quite well, and jointly created several versions of the wm-spec of the Specifications. Collectively, the FreeDesktop specifications are why application developers can create apps that work across various types of Linux desktops.

Many parts of the spec are frequently updated, but sadly the wm-spec portion of the specifications hasn't gotten gotten an update since November, 29th 2011.

The wm-spec defines "Extended Window Manager Hints". Messages that applications, window managers, pagers (navigation aids like virtual desktop selectors), and automation applications such as xdotool and wmctrl.

The wl-roots project that provides the foundation for SwayWM, basically the Wayland port of the i3 tiling window manager, may eventually become a sort of successor to wm-spec, giving other desktops a common platform to build for Wayland on top of, however, I don't think GNOME or KDE are building on top of wl-roots. The future best case scenario may be code that works for wl-roots, KDE and GNOME... So for anyone that thought using xcb, the C interface directly to the X11 protocol, was difficult, there's not even a consistent layer to write to once everything moves to Wayland. Hopefully Arcan or something else comes out and surprises us, as I think Wayland could be a significant step backwards for the most sophisticated users. That said, the WL-ROOTS author seems to be optimistic on Wayland...

X11 has been updated periodically since it's initial release in 1987. Lots of things change over the years... The MOTIF_ related proprieties aren't used very often any more.

You can read all of the properties for any window you're interested in with xprop. For example:

# use -len 80 to drop X11's archaic icon info
xprop -len 80

Prior to _GTK_FRAME_EXTENTS, the next most recent window sizing method was to check _NET_FRAME_EXTENTS.


left, right, top, bottom, CARDINAL[4]/32

The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the window's frame. left, right, top and bottom are widths of the respective borders added by the Window Manager

EWMH (Extended Window Manager Hints) spec

GNOME released a new property called _GTK_FRAME_EXTENTS that usually have a value close to 25, 25, 25, 25... In 20202, KDE's KWin window manager was updated to automatically handle _GTK_FRAME_EXTENTS, so if you're a user or developer who's trying to understand how this property works on Kwin, it's even more confusing, because Kwin takes these values into account, and then gets them out of your way. This is the ideal behavior. Congratulations to the Kwin team. However, don't expect to understand this property if you're using a version of Kwin that already effectively hides it.

I had been searching for documentation on how exactly `_GTK_FRAME_EXTENTS` worked for a few weeks, but on KDE I just couldn't make any sense of it. I even found this video and though "isn't that just doing what it was supposed to do? what did it look like before?"

Today when I was using Gnome for a while, it finally all came together.

# &! to launch and disconnect from the terminal
gnome-calculator &!
kcalc &!

# give your windows a moment to open
sleep 1

# -x to use a window class, not window title
# 100,100 should now be top left of window (X,Y)
# 300,300 is less than window minimum, ignored
wmctrl -x -r "gnome-Calculator" -e 0,100,100,300,300
wmctrl -x -r "kcalc"            -e 0,100,100,300,300

Ideally, these two windows would now be in the same X, Y position... Just looking at this image (taken on Gnome on X11) and you can probably figure out how _GTK_FRAME_EXTENTS works.

Here's a screenshot of gnome-calculator with a 10x10 pixel grid in the background...

And when we run xprop on this gnome-calculator window, we get:


Just to make sure that we don't have any ambiguity, let's try the same thing on kcalc and see what we get.


🎁 Putting a bow on it...

So GTK creates a large buffer around the edges of every window. I presume this could be used for dropshadows and other eyecandy. As a result, window is actually much larger than you expect the window to be. The _GTK_FRAME_EXTENTS values (Left, Right, Top, Bottom) communicate how much of the window should be cropped off when considering things like window "snap to edges".

Meanwhile the KDE Kcalc window is using _NET_FRAME_EXTENTS (Left, Right, Top, Bottom), and the actual Window that you would use for placement and alignment extends that much BEYOND the size of the window.

_NET_FRAME_EXTENTS tell you how much EXTRA SPACE add to your Window Size calculations.

_GTK_FRAME_EXTENTS tell you how much EXTRA SPACE to REMOVE from your Window Size calculations.

Here I wrote a Xlib program that just displays a 3pixel, red frame window in the top left, starting at point 0,0. It's 100 x 100 pixels.

You can see, the top left of the Kcalc window (x=100, y=100) is just inside of the titlebar.

Meanwhile, the top left of the of the Gnome-Calculator window using _GTK_FRAME_EXTENTS is actually fully outside of the GTK window..

_GTK_FRAME_EXTENTS should work the same on Wayland, but xprop and wmctrl surely will not since they're directly based on X11.

Hopefully Wayland will soon have command line tools like wmctrl and xdotool and hotkey tools like sxhkd that can work on any Linux or BSD desktop environment on top of Wayland...