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.

GNOME pourra bientôt accéder aux données GPS de votre mobile

De plus en plus d’applications (Cartes, Météo…) ont besoin de connaître la localisation précise de l’utilisateur, dans le but de lui faciliter la vie en fournissant directement les données de l’endroit où il se trouve. Pour se faire, GNOME utilise le service GeoClue, qui peut utiliser plusieurs sources plus ou moins précises : GPS, Wi-Fi, modem 3G ou GeoIP. Malheureusement, la plupart des ordinateurs n’étant pas équipés pour pouvoir fournir des données fiables, la localisation se fait généralement à partir de l’adresse IP, dont la précision ne dépasse guère les dizaines de kilomètres (contre quelques mètres pour le GPS).

Dans le même temps, de nos jours, la plupart des gens possèdent un smartphone équipé d’un récepteur GPS. Ankit, étudiant indien à l’Institut national de technologie de Srinagar, a ainsi pour projet de travailler durant le Google Summer of Code 2015 sur une application Android (la version iOS viendra par la suite) qui agira comme un serveur de localisation pour le service GeoClue, et dont la découverte sur le réseau pourra s’effectuer depuis des clients mDNS tels que Avahi ou Bonjour. Tout se fera bien évidemment automatiquement, et l’utilisateur n’aura pas besoin de s’en préoccuper.

Maquette d’application Android

Comme on peut le voir sur les maquettes, l’utilisateur pourra choisir ou non de partager sa localisation avec d’autres périphériques, et la liaison pourra s’effectuer quant à elle par Wi-Fi, Bluetooth ou USB.

Ceux qui s’intéressent à la technique pourront lire le billet de blog d’Ankit, mais en gros, l’application Android utilisera les ServerSocket pour communiquer avec GeoClue. Et à chaque fois qu’Android obtiendra un nouvel emplacement par le biais de LocationListener, il transmettra les données de localisation à GeoClue sous forme d’une phrase NMEA, que ce dernier convertira ensuite sous forme de localisation GPS.

Et pour terminer sur les questions de vie privée, non seulement personne ne sera obligé d’installer une telle application sur son smartphone, mais le partage sera en opt in, et nécessitera donc l’accord de l’utilisateur. Tout comme c’est finalement déjà le cas dans les paramètres de confidentialité de GNOME.