Device specific package

We aim to have ideally only one device specific package. Other packages should be shared between all devices.

However, in practice, we need an extra package for the kernel (unless the device has been mainlined). And sometimes one for device specific firmware (in theory it is possible to divide these in the firmware files for specific chips, and then share these chip-specific firmware packages across multiple devices, but we're not quite there yet).

Every device specific package contains at least the deviceinfo file, and the. This article describes special characteristics of the device.

Generate a template
The recommended way to start with a new device package is using  and typing in a new device name. But it is also possible to directly call the device package wizard with  (adjust changeme accordingly).

devicepkg-dev
In order to share code between the s of these packages, all new device packages depend on a   package and call its functions inside their  s:

The variables  and   are always available where they are used, and must be passed to these functions. and  are simple shell scripts, and they get packaged from here.

devicepkg_build
Optionally creates an udev rule for the device's touch screen, based on the data from the. We can extend this to do more when it makes sense.

The source code is in devicepkg_build.sh of the devicepkg-dev pmaport.

devicepkg_package
Installs the  file (to  ) and all other files, that may have been generated during.

The source code is in devicepkg_package.sh of the devicepkg-dev pmaport.

Use install_if to pull in packages
If your device requires a specific X11 driver for example, it is possible to say: "Install this driver when this device package and Xorg are installed.".

Here is one example from :

We only create the, because building subpackages fails, when the subpackage folder does not exist. You can add multiple subpackages per package, see.

Add a device specific config file
It might be, that you would like to disable Xweston for your device, because it does not work and then weston does not start. To accomplish this, we will also make use of   and a subpackage. But this time we won't pull in another package, but install the config file:

This will only install the custom Weston config, when  is installed. The  is implicitly created with.

Camera subpackage
Right now the state in postmarketOS is, that we have multiple camera applications and some only work for some devices. Until we reach the state where one camera application nicely works for every device, or possibly one per UI, we add camera subpackages to devices. As device maintainer, test the various camera applications and add a subpackage like the following for the camera app that works best. It is likely that none of them work out of the box, until you add support for your device upstream.

See for details.

Proprietary firmware
The actual blobs don't belong into the device package, but into their own package:
 * Either a  package from Alpine
 * Or a  package from postmarketOS' aports
 * check out the existing ones we already have for reference.

Once you have that package, modify your device package: Update the checksums and rebuild your device package.
 * Add  to the   line
 * Do not replace the  variable.
 * Add a block based on the following at the end of your device package's, before the.
 * Change  to the blob package that you found/made for your device.
 * Adjust the  accordingly. It will be shown to the user in   when deciding how libre they want their postmarketOS installation to be.
 * Keep the  variable, that variable exists in this context.

Use cases
It is possible to let the user choose between multiple kernels for one device during. Some use cases:
 * selection between downstream kernel and mainline kernel (e.g. because mainline isn't as functional as downstream yet)
 * combining similar devices in one device package, with minor differences in:
 * the deviceinfo file (example: two dtbs)
 * dependencies on other packages

How to

 * Remove the current kernel package from  of your device's
 * Add the kernel subpackages and subpackage functions. One example from :
 * Additionally in your  file you can use the suffix from your kernel subpackage (e.g.   or  ) to limit the variables to one kernel variant in case you need different values. An example:
 * Also consider adjusting the dependencies of your device package to not include downstream- or mainline-specific helper packages, such as,   or  . You can use   as an example for that.
 * Run  afterwards to test the change. It should ask you for the kernel now.
 * See  for another example.
 * Implementation details and discussion:, devicepkg_subpackage_kernel source
 * See  for another example.
 * Implementation details and discussion:, devicepkg_subpackage_kernel source

Initramfs hook
Some devices need to run special commands at boot time, for example turning on the display or kicking a watchdog. It is possible to do this with a device specific initramfs hook.

Create a new  file in your device package's dir and fill it with the command that needs to be executed, along with a comment describing what it does:

Then open the APKBUILD and add  to.

As usually, update the checksums, build the package with  and test the hook on your device.

Android dynamic partitions
Some of the newer Android (10+) devices support so-called dynamic partitions. The separate Android dynamic partitions article explains how the deviceinfo package needs to be modified, so postmarketOS can be flashed to them without replacing the super partition. This makes it easier to switch back and forth between other operating systems.