On Tue, Mar 31, 2020 at 6:03 PM Jesus Sanchez-Palencia <
address@hidden> wrote:
(...)
Probably there is a mismatch between where the firmware
is for you and where configure has told QEMU to look for it.
(Though if you are doing an install of QEMU it ought to
be installing the keymaps in the same place, and if you
are running QEMU from within the build directory then
it ought to be finding the keymaps by looking in the
source directory's pc-bios subdirectory, though I've
just noticed the latter code is not very clever and will
be wrong if your build directory wasn't a direct subdirectory
of the source directory. How are you building and
running QEMU exactly?)
See below.
In more detail, the directory list is constructed from:
* any "-L somedir" options you pass to QEMU
* the 'firmware path' (default usually /usr/local/share/qemu-firmware,
changeable with configure's --firmwarepath option)
* the directory '../pc-bios/' relative to the location
of the executable
* the directory '$datadir$confsuffix' where both parts
can be set using configure --datadir and --confsuffix
arguments, defaulting to '/usr/local/share' and '/qemu' so
we look in '/usr/local/share/qemu'
I'm not sure if any of that changed from 4.2 -- the
general mechanism is pretty longstanding but maybe
we changed one of the defaults? You should be able to
ask the working 4.2 binary where it's looking...
The behavior changed after v4.2.0. The commit that introduced this was:
commit 6dd2dacedd83d12328afa8559bffb2b9ec5c89ed
Author: Marc-André Lureau <
address@hidden>
Date: Wed Sep 18 12:24:10 2019 +0400
os-posix: simplify os_find_datadir
Before that commit, $bindir/../share/qemu was always a valid path for installed
binaries. Now qemu relies solely on CONFIG_QEMU_DATADIR, so there is
no way to have the binary looking for files using a relative path anymore.
Is this something that would be open for reconsideration or is that the behavior
you folks want to keep moving forward?
Thanks,
Jesus