input-keymap sizes

input-keymap sizes

[John Snow]

Heya!

I've been looking into producing minimal QEMU configurations for
sandboxing, and as part of that, I've been auditing "what exactly
takes up room in our QEMU binary?"

One of the things that came up was that input-keymap.c burns over 250
KiB of .rodata all by itself; all of the keymaps we generate for QEMU
are included statically in one big blob and are linked with every last
build.

There's a few things we could do about this;

(1) We can split out each keymap into its own object file, which
allows us to link only the keymaps we need for the features we have
enabled. Dan Berrange wrote a quite POC for this and the results look
good at a glance. We need new linker flags to automatically prune
unused keymaps from the build, or enhanced meson-fu to
deterministically exclude them. Either way, it's likely a worthwhile
pursuit. In a microvm-only build configuration I've been testing with,
this immediately dropped us from 250KiB to 180KiB.

(2) The x11 keymap used by ui/input-barrier.c and ui/gtk.c - all by
itself - consumes 128KIB for its keymap. This is because although the
x11_to_linux keymap has fewer than 512 total entries, it allocates
this in a const array with 64K entries in it so it can span keycodes
0x00 to 0xff and 0xff00 to 0xffff.

It's the second one I am concerned about. At first I thought that I
might be able to write a "condensed" table that uses 0 - 255 and then
remaps 65,280 - 65,535 onto 256-511 and then take (index & 0x1ff) on
lookup table input, but I realize that the entire unmodified table is
passed off to gd_get_keymap() in ui/gtk.c where I can't inject those
index transformations.

Does anyone have any suggestions on how to help shave the x11_to_linux
keymap down to a more reasonable size? I doubt we need 128KB when 1KB
could theoretically hold everything we need.

--js

Re: input-keymap sizes

[Daniel P. Berrangé]

On Wed, Nov 04, 2026 at 05:16:03PM -0500, John Snow wrote:
> Heya!
> 
> I've been looking into producing minimal QEMU configurations for
> sandboxing, and as part of that, I've been auditing "what exactly
> takes up room in our QEMU binary?"
> 
> One of the things that came up was that input-keymap.c burns over 250
> KiB of .rodata all by itself; all of the keymaps we generate for QEMU
> are included statically in one big blob and are linked with every last
> build.
> 
> There's a few things we could do about this;
> 
> (1) We can split out each keymap into its own object file, which
> allows us to link only the keymaps we need for the features we have
> enabled. Dan Berrange wrote a quite POC for this and the results look
> good at a glance. We need new linker flags to automatically prune
> unused keymaps from the build, or enhanced meson-fu to
> deterministically exclude them. Either way, it's likely a worthwhile
> pursuit. In a microvm-only build configuration I've been testing with,
> this immediately dropped us from 250KiB to 180KiB.
> 
> (2) The x11 keymap used by ui/input-barrier.c and ui/gtk.c - all by
> itself - consumes 128KIB for its keymap. This is because although the
> x11_to_linux keymap has fewer than 512 total entries, it allocates
> this in a const array with 64K entries in it so it can span keycodes
> 0x00 to 0xff and 0xff00 to 0xffff.
> 
> It's the second one I am concerned about.

But can the first one solve the second one ?  In your sandbox use
case, presumably you don't need the GTK graphical frontend, and
so if GTK is dropped from the minimal build config there's no need
to link in the X11 keymap and thus (1) fixes the problem.

>                                            At first I thought that I
> might be able to write a "condensed" table that uses 0 - 255 and then
> remaps 65,280 - 65,535 onto 256-511 and then take (index & 0x1ff) on
> lookup table input, but I realize that the entire unmodified table is
> passed off to gd_get_keymap() in ui/gtk.c where I can't inject those
> index transformations.

Bear in mind all these keymaps tables are auto-generated by a tool
that is used by many applications

> Does anyone have any suggestions on how to help shave the x11_to_linux
> keymap down to a more reasonable size? I doubt we need 128KB when 1KB
> could theoretically hold everything we need.

That's binary size, but presumably not all those pages are mapped.
We won't access every index in the table so many pages won't get
faulted in to RAM.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|