[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!