Building a firmware using EDK2, what is the easiest way to provide a custom default boot order?
For instance, I know that Ovmf for QEMU redefines programmatically the UEFI boot order based on QEMU's "bootorder" fw_cfg file (using code in QemuBootOrderLib).
So, similarly, I could specify and enforce a boot order programmatically.
Is there a simpler way to achieve that (perhaps providing custom values for UEFI vars)?
Note: without using the shell! I need this configuration included in the firmware image!
You need to provide Boot0001/Boot0002/... and BootOrder variables. The first have specified format and require a valid device paths to work properly, so your boot devices should also be predefined, the second is just a list of UINT16s. Read this for more info.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
I was in the middle of adding a new board to Yocto while I noticed that a lot of the configuration could be inherited from the previous hw revision.
So I was wondering if there could be the possibility of including a common_defconfig in the <new_board>_defconfig to not duplicate all the configuration files. Similarly to what happens with dts files.
E.g.
common_defconfig:
CONFIG_ARM=y
CONFIG_SPL=y
CONFIG_CMD_I2C=y
board_hw1_defconfig:
#include "common_defconfig"
CONFIG_TARGET_BOARD_HW1=y
board_hw2_defconfig:
#include "common_defconfig"
CONFIG_TARGET_BOARD_HW2=y
UPDATE 1
Like pointed out by #Xypron, and as I was suspecting, there is no way to include different _defconfig one in another.
I also tried to create a generic Kconfig.defconfig to select some configurations. The problem was that, for example, ARM is defined as a config inside a choice so cannot be selected from inside a Kconf file.
I will end up creating a do_configure_append task where I will merge the _defconfig files through the use of scripts/kconfig/merge_config.sh if no one will come with a better solution.
U-Boot inherits the build system from Linux. Neither of both support includes in _defconfig-files up to now. If you want it changed you need to come up with a patch for scripts/kconfig/Makefile scripts/kconfig/Makefile.
The configs/*defconfig files are seeding .config. So anyway most of the configuration comes from presets in the Kconfig files. This is different to the device trees where for ARM systems all values come from *.dts and *.dtsi files.
I am trying to write a Vulkan program but am somewhat fuzzy on how the extension mechanism works.
Concretely, I want to access VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT (is not found at compilation) but am not sure how to include the swapchain_colorspace extension.
VK_EXT_swapchain_colorspace is an instance extension.
You can enable the extension by passing its name to vkCreateInstance via the pCreateInfo->ppEnabledExtensionNames.
You can use either "VK_EXT_swapchain_colorspace" directly or use the VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME macro to avoid typos.
Then, generally speaking, you have to load extension commands (functions) unless it is WSI and you are using the official Vulkan loader.
VK_EXT_swapchain_colorspace defines no new commands, so that step can be skipped.
Enumerants such as VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT are always present\defined (assuming you have updated vulkan.h header; if not, just download newest LunarG Vulkan SDK). Enabling the extension only gives formal permission for them to be used.
I want to check if Qt5 was compiled with or without some options, regarding supported image formats. I know about the QImageReader supportedImageFormats function but I want to know the configure options.
Is there a way to retrieve the used commandline options of the configure call dynamically?
Cheers.
No, there is not. You could fake it, if you still have the source tree. In qt5/qtbase you find two files: config.summary and config.status. Those contain the info you seek. However, these files are not part of a normal installation.
I'm writing a command-line utility in Go that (as part of its operation) needs to get a password from the user. There's a great gopass module for Unix that does this, and I know how to write one for the Windows console. The problem is that the Windows module obviously won't build on *nix, and the *nix version won't build on Windows. Since Go lacks any preprocessor support (as far as I can tell), I have absolutely no idea what the right way to approach this is. I know it's possible, since Go itself must do this for its own libraries, but the tooling I'm used to (conditional imports/preprocessors/etc.) seems to be missing.
Go has build constraints, which can either be specified as comments in a .go file, or as part of the file name.
One set of constraints is for target operating system, so you can have one file for Windows, one for e.g. Linux and implement the same function in two different ways in the two.
More information on build constraints are at http://golang.org/pkg/go/build/#hdr-Build_Constraints