[nemo-qml-plugin-systemsettings] Parse manufacturer and device name

[jmlich]

SailfishOS relies on /etc/hw-release which doesn't exists in Asteroid OS.

The values are taken from /system/build.prop if wasn't loaded before.

This is related to AsteroidOS/asteroid-btsyncd#31 and AsteroidOS/asteroid-settings#97

Please note, that I have very few experience with bitbake. This patch was crafted manually and need careful review and test.

[FlorentRevest]

The problem with /system/build.prop is that this is an android file and not all our ports are based on an Android HAL. Also, even some Android ports could be missing this file or have incorrect values there for one reason or another. (sometimes we could use the /system of another watch or whatever). Also we lack control on the strings written there (for example, maybe we want to write LG rather than LGE). This is why SailfishOS implemented the "hw-release" file where they can define an arbitrary hardware name, even on devices that don't have an android /system/build.prop and also add other values.

This is why I feel we should start providing hw-release files for our watches rather than growing a dependency to android stuff.

In AsteroidOS, we have a vaguely similar concept of "device info" in /etc/asteroid/machine.conf. We use it for device specific information such as "does it have a round screen". Seeing how it's implemented should give you an idea of how to generate hw-release files.

• each port has a layer in meta-smartwatch and a MACHINE definition. MACHINE specific values can be defined, for example, bass defines MACHINE_DISPLAY_ROUND = "true" https://github.com/AsteroidOS/meta-smartwatch/blob/master/meta-bass/conf/machine/bass.conf#L9
• all AsteroidOS builds build the "asteroid-machine-config" recipe which uses these macros to conditionally generate a MACHINE specific /etc/asteroid/machine.conf file: https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-asteroid/asteroid-machine-config/asteroid-machine-config_1.0.bb this is a bit of clever python but at the end of the day it's quite straightforward, it reads the MACHINE_DISPLAY_ROUND value set by the machine from the build environment and generates a file for it.

You could introduce a similar mechanism to generate hw-release files. You'd first need to modify all meta-smartwatch/meta-*/conf/machine/*.conf files and add macros such as MACHINE_VENDOR and MACHINE_NAME there. Then you could modify asteroid-machine-config to generate /etc/hw-release (with some fallback strings if we build on a machine that doesn't have this macro defined. And then everything would work ;)

Thank you!

[beroset]

For a number of AsteroidOS images, there is more than one manufacturer and model, and there's simply no way to supply that information when compiling because the only difference is the case in which the watch is packaged. See https://asteroidos.org/watches/firefish/ as an example: ray shows 11 different models and 7 different manufacturers.

[FlorentRevest]

For a number of AsteroidOS images, there is more than one manufacturer and model, and there's simply no way to supply that information when compiling because the only difference is the case in which the watch is packaged. See https://asteroidos.org/watches/firefish/ as an example: ray shows 11 different models and 7 different manufacturers.

Indeed. But on the other hand, we also tend to ship a custom /system/ directory with a custom build.prop there so the manufacturer and model will also be wrong there :/