GNOME 3.18 supportera différents types de capteurs

Les tablettes et les ordinateurs portables modernes sont désormais truffés de capteurs : un accéléromètre pour le positionnement de l’écran, un capteur de lumière ambiante pour ajuster la luminosité de l’écran, un compas gyroscopique pour la navigation…

Suite aux travaux sur la WeTab, GNOME et Linux supportaient déjà les accéléromètres depuis plusieurs années, mais certains changements apportés par Windows 8 et les périphériques compatibles avec ce dernier ont poussé à tout remettre à plat.

Bastien Nocera a donc développé le projet iio-sensor-proxy, dont la version 1.0 vient tout juste de sortir. En plus des accéléromètres, cette première version stable supporte également les capteurs de lumière ambiante, ce qui signifie qu’en plus de pouvoir s’adapter automatiquement à une rotation de l’écran, GNOME 3.18 pourra également adapter, tout aussi automatiquement, la luminosité de ce dernier.

Dans les prochaines versions, il est prévu de pouvoir exporter les données brutes de l’accéléromètre pour qu’elles puissent être utilisées par les applications. Ce qui pourrait être intéressant dans le cas de jeux vidéos. Il est également prévu d’ajouter le support du compas gyroscopique, dont les informations seront communiquées au service de géolocalisation GeoClue, permettant ainsi d’obtenir l’emplacement et la direction avec une même API.

Histoire de mieux comprendre le projet, s’ensuit un petit entretien avec Bastien Nocera, que je remercie encore une fois pour le temps qu’il a bien voulu m’accorder ;)

Le projet s’appuie sur systemd. Qu’apporte réellement ce dernier, et cela a t’il permis de simplifier le développement ?

Dans ce cas précis, systemd/udev est uniquement utilisé pour lancer le daemon en tâche de fond, quand un capteur apparaît (lors du démarrage, lorsque qu’on sort du sommeil, ou, comme pour le ColorHug ALS, s’il est branché en USB). systemd permet de simplifier le lancement de services D-Bus lorsqu’ils sont attachés à un périphérique amovible. C’est aussi la manière dont bluetoothd, le daemon qui s’occupe du Bluetooth, fonctionne.

Utiliser un autre système d’init est parfaitement possible, mais moins pratique, et surtout inutile étant donné que toutes les distributions majeures de Linux utilisent systemd (et que iio-sensor-proxy ne fonctionne que sur Linux).

Les capteurs semblent être reconnus comme des périphériques HID. Est -ce que ça implique une certaine normalisation, offrant par défaut, une fois le pilote initial développé, le support de tous les capteurs d’un même type, ou est-ce qu’il faudra développer des pilotes différents pour chaque capteur de chaque fabricant ?

Certains capteurs sont des capteurs HID, mais pas tous. Pour avoir le tampon de certification pour Windows 8, les capteurs doivent utiliser HID pour exporter leurs données, et le faire d’une certaine manière. Cependant, sous Linux, les capteurs sont souvent, de toute façon, gérés par la surcouche du noyau IIO (« Industrial I/O », entrées-sorties industrielles). Ce qui nous permet de gérer à la fois les capteurs basés sur le HID que supporte Windows 8 par défaut, ainsi que de nombreux autres que les constructeurs peuvent intégrer dans leurs systèmes.

Les capteurs mono-fonctions plus anciens, comme ceux de la WeTab, sont eux encore différents, apparaissant comme de vrais périphériques d’entrée, tels une souris, mais avec Z, l’axe de la profondeur, en plus. Nous supportons aussi les capteurs utilisés sur MacBook, qui sont exportés par le noyau Linux de manière différente. En clair, les capteurs HID compatibles Windows 8 bénéficieront de pilotes Linux déjà intégrés, mais les autres, avec un driver IIO supporté, fonctionneront aussi.

Dans le cas des capteurs de lumière ambiante, j’ai cru comprendre que les différents fabricants n’utilisaient pas une unité de mesure commune et normalisée. Comment avez-vous procédé pour pouvoir tout de même offrir à l’utilisateur un système unifié ?

Dans ce cas, le problème n’est plus dans iio-sensor-proxy lui-même. Le daemon exporte le fait que les données sont sans unité, ramenées à un pourcentage et les applications se débrouillent pour savoir si elles peuvent gérer ces données. Dans le cas de gnome-settings-daemon (une tâche de fond qui gère l’énergie sous GNOME), nous utilisons les préférences de l’utilisateur pour calibrer les changements de luminosité de l’écran, et « apprend ». Pour plus de détails, il vaut mieux inspecter le patch écrit par Richard Hughes directement.

Comment est gérée la sécurité, pour qu’un programme malicieux ne puisse pas accéder à certaines informations sensibles, comme la localisation de l’utilisateur et la direction prise ?

Pour l’instant, le problème ne se pose pas : nous n’exportons pas aux applications les données brutes des accéléromètres, ou les données des compas électroniques. Dans le futur, les données du compas ne seront disponibles que pour GeoClue, qui renverra ces données vers les applications de géolocalisation, telles que Cartes ou Météo, avec les mêmes demandes de permission.

Pour ce qui est de l’accéléromètre, le même système sera mis en place. Dans les deux cas de figure, nous attendons un déploiement plus généralisé des technologies utilisées, comme kdbus et xdg-app.

Les intéressés peuvent suivre le développement de cette fonctionnalité sur GitHub.