Points saillants
Les écritures de configuration à la portée d'un appareil atteignent désormais chaque session cliente qui détient cet appareil, et nonseulement celle qui a effectué l'écriture. Une deuxième visionneuse se rafraîchit d'elle-même à la réception de son événement session-updated, au lieu d'interroger le service à intervalles réguliers — exactement un événement par session détentrice, et jamais deux pour l'auteur de l'écriture.
L'emplacement physique de montage d'un appareil peut désormais être communiqué à un client, au lieu que le service renvoie systématiquement le montage configuré par la session. L'étiquette qui indique lequel des deux vous consultez est désormais exacte par construction, dans toutes les formes de sortie.Lorsqu'un appareil conserve sa propre référence de montage, le service la suit. Auparavant, le service renvoyait une valeur capturée au démarrage de l'appareil, sans jamais la réexaminer. Il peut désormais actualiser cette référence à la demande, au rythme de rendu propre au client — avec une limitation de débit côté service pour qu'un client rapide ne puisse pas saturer la liaison avec l'appareil — et signaler le changement une fois que le montage a réellement pivoté.Améliorations internes
Correction automatique expérimentale de la dérive en lacet de la poignée. Un nouveau module de service referme la boucle sur la dérive en lacet inertielle du VerseGrip sans fil : il ajuste le lacet absolu de la poignée en fonction du mouvement du Inverse3 appairé ou du Minverse auquel elle est attachée; une fois que l'ensemble des conditions de qualité est satisfait, il écrit une seule correction dans le micrologiciel de la poignée. Il est livré désactivé, n'est accessible que lorsque le commutateur d'adhésion expérimentale est activé, et comporte un commutateur d'exécution qui ramène immédiatement chaque poignée active à l'état désactivé dès qu'on le bascule — ce qui n'est pas facultatif pour un composant qui écrit dans le micrologiciel d'un appareil.Une écriture de configuration qui vise tous les appareils à la fois est désormais tout ou rien. L'ensemble de la sélection est validé (capacité du micrologiciel et disponibilité de chaque appareil) avant que le moindre appareil ne soit modifié; ainsi, un parc aux micrologiciels hétérogènes ne peut plus se retrouver à moitié basculé à cause d'une erreur sur le deuxième appareil.Les accusés de réception du micrologiciel des poignées sont désormais suivis par requête. Un seul emplacement de résultat partagé faisait en sorte que deux demandeurs simultanés pouvaient perdre la réponse de l'autre, et une même valeur ambiguë signifiait à la fois « refusé » et « rien pour l'instant » — ce qui pouvait transformer un refus en avalanche de tentatives. Chaque requête porte désormais son propre jeton, une requête jamais transmise n'enregistre rien, et une réponse perdue se solde par un échec au lieu de bloquer le système. Le balayage qui effectue ce suivi ne coûte rien lorsqu'aucune requête n'est en attente.L'étalonnage de la station d'accueil Inkwell n'est pas touché par les nouvelles vérifications de capacité du micrologiciel des poignées. L'arrimage d'un stylet effectue un réétalonnage complet de la pose, ce qui est correct pour chaque stylet livré, quelle que soit la version du micrologiciel; ce chemin est explicitement exempté du seuil minimal de capacité introduit pour les corrections de cap calculées, et cette exemption est précisée au point d'appel plutôt que déduite.Corrections
La réinitialisation de la compensation de gravité rétablit désormais la véritable valeur par défaut au lieu de surcompenser.Malgré son nom, le champ scaling_factor de config/gravity_compensation n'est pas un multiplicateur : c'est la masse additionnelle de charge utile de l'effecteur terminal, en kilogrammes, que l'appareil compense en plus de son propre poids. La réinitialisation prenait ce nom au pied de la lettre et rétablissait le facteur « neutre » 1, soit une charge fantôme d'un kilogramme; après une réinitialisation, l'appareil poussait donc la poignée vers le haut, ce qui n'est pas le comportement d'un appareil fraîchement connecté. La réinitialisation renvoie désormais la valeur par défaut réelle : compensation activée avec scaling_factor à 0, ce qui signifie que l'appareil porte son propre poids et ne suppose aucune charge utile. Si votre application utilisait la réinitialisation pour augmenter l'intensité de la compensation, définissez plutôt explicitement la valeur souhaitée.
La réinitialisation du retour à l'origine le réactive désormais réellement. La réinitialisation de config/home_return avait fini par désactiver le retour à l'origine tout en indiquant à l'appelant qu'il était activé; une réinitialisation rétablit désormais réellement la valeur d'usine (activé), et la valeur que votre application lit ensuite correspond à celle que l'appareil utilise effectivement.Une écriture de montage ou d'orientation à la portée d'un appareil ne laisse plus les autres clients avec des données périmées. Avant la version 3.5.6, une écriture qui touchait l'appareil lui-même — partagée par chaque session qui détient cet appareil — ne rafraîchissait que la configuration du client qui avait écrit, et les routes à l'échelle de l'appareil ne rafraîchissaient personne. Tout autre client sur le même appareil continuait d'afficher l'ancienne valeur jusqu'à ce qu'il interroge le service. Chaque session détentrice est désormais avisée.Une tentative d'arrimage répétée sur la station Inkwell n'abandonne plus après un seul refus. L'état d'un arrimage précédent persistait d'un arrimage à l'autre, de sorte que le second arrimage considérait son premier refus comme la fin de sa fenêtre de nouvelles tentatives. La fenêtre de nouvelles tentatives est désormais réinitialisée à chaque tentative d'arrimage.Correction d'une condition de course sur les données lors du cycle de mise à jour de l'appareil VerseGrip sans fil. L'identifiant de l'appareil pouvait être réassigné par le fil d'exécution de connexion pendant qu'un chemin de préparation le lisait sous un verrou différent. L'identifiant est désormais capturé une seule fois sous le bon verrou, et tous les chemins ci-dessous, refus compris, travaillent à partir de cette copie.Correction de la préparation non synchronisée des messages sur quatre émetteurs VerseGrip sans fil. Quatre chemins d'envoi de messages assemblaient leur charge utile et leur somme de contrôle, puis demandaient l'envoi sans prendre le verrou d'écriture; deux émetteurs pouvaient donc s'entrelacer dans le tampon partagé.Changements potentiellement incompatibles
Aucun changement d'API, de format de transmission ou de paramètres. La sortie par défaut est identique octet pour octet à celle de la version 3.5.5, aucune route n'a été supprimée ou déplacée, l'API C publique n'a subi aucun changement, et aucune clé de paramètres n'a été renommée, retirée ou dotée d'une nouvelle valeur par défaut. Les applications qui activent volontairement les surfaces d'aperçu ou expérimentales du SDK ont toutefois du travail de migration pour ce cycle, notamment un changement de niveau de commutateur et un ensemble de jetons retiré; chaque étape est documentée dans le journal des modifications technique d'accompagnement.La réinitialisation de la compensation de gravité renvoie une valeur différente de celle de la version 3.5.5. Aucun champ, aucune route ni aucune forme de réponse n'a changé, mais une application qui comptait sur la réinitialisation pour écrire un scaling_factor de 1 obtient désormais la valeur d'usine 0; la compensation elle-même demeure activée dans les deux cas. Définissez explicitement la valeur plutôt que de dépendre de la réinitialisation; voir la correction ci-dessus.La réinitialisation du retour à l'origine laisse désormais le retour activé, et non désactivé. Aucun champ, aucune route ni aucune forme de réponse n'a changé, mais une application qui comptait sur la réinitialisation pour désactiver le retour à l'origine le trouve maintenant activé. Si c'est ce dont vous avez besoin, désactivez-le explicitement après une réinitialisation; voir la correction ci-dessus.Les clients recevront des événements de configuration supplémentaires. Une application qui supposait qu'un événement session-updated n'arrivait qu'en raison de sa propre écriture en recevra désormais aussi un lorsqu'un autre client modifie un appareil que tous deux détiennent, suivi d'un rendu complet de la configuration. C'est la conséquence voulue de la diffusion décrite plus haut; un client qui relit simplement les données à la réception de l'événement n'a besoin d'aucune modification.
