Points clés {#highlights}
Les modifications apportées aux paramètres de portée d'un périphérique sont désormais répercutées sur toutes les sessions client associées à ce périphérique. Il ne s'agit pas d'un système où les modifications n'étaient répercutées que dans la session où elles avaient été effectuées. Le deuxième visualiseur, au lieu d'effectuer une interrogation, utilise son propre mis à jour lors de la session La page est actualisée à la réception de l'événement. Un seul événement se produit pour chaque session sur laquelle l'appareil est connecté, et il ne se produit pas deux fois sur le client ayant effectué l'écriture.Il est désormais possible de signaler au client l'emplacement réel du montage sur l'appareil. Cela remplace l'ancienne méthode, dans laquelle le service ne signalait que le montage défini pour la session. L'étiquette indiquant laquelle des deux valeurs est signalée est désormais structurellement correcte dans tous les formats de sortie.Si l'appareil conserve ses valeurs de référence de montage, le service suit cette logique. Auparavant, le service fournissait telles quelles les valeurs capturées au démarrage de l'appareil, sans les revérifier. Désormais, il est possible d'actualiser les valeurs de référence à la demande, en fonction du cycle de rendu du client. Afin d'éviter qu'un client trop rapide ne surcharge la liaison avec l'appareil, le service limite la vitesse et ne signale les modifications qu'une seule fois, une fois que le montage a effectivement tourné.Améliorations internes {#internal-improvements}
Correction automatique expérimentale de la dérive de lacet (yaw) de la poignée. Un nouveau module de service permet de boucler la boucle de correction de la dérive inertielle de la poignée Wireless VerseGrip. Il aligne la valeur absolue du lacet de la poignée sur les mouvements de l’ Inverse3 ou du Minverse appairé auquel elle est fixée, puis enregistre une valeur de correction unique dans le micrologiciel de la poignée dès lors que l’ensemble des critères de qualité est satisfait. Cette fonctionnalité est désactivée par défaut etn’est accessible que si le commutateur expérimental « opt-in » est activé. Elle comprend également un commutateur d’exécution qui, dès son activation, désactive de force la correction de toutes les poignées actuellement actives. Ce commutateur est indispensable, car il s’agit d’une opération d’écriture dans le micrologiciel de l’appareil.La mise en application des paramètres sur l'ensemble des appareils s'effectue désormais de manière globale : soit tous les appareils sont mis à jour, soit aucun ne l'est. Avant de modifier un appareil, le système vérifie la compatibilité des fonctionnalités du micrologiciel et l'état de préparation de l'appareil pour l'ensemble des éléments sélectionnés. Ainsi, il n'arrive plus qu'un parc de micrologiciels hétérogène reste partiellement mis à jour, avec une erreur sur le deuxième appareil.Les réponses de vérification du micrologiciel du grip sont désormais suivies au cas par cas. En raison d’un seul emplacement partagé pour les résultats, deux demandeurs simultanés pouvaient perdre la réponse de l’autre, et une valeur ambiguë pouvait signifier à la fois « refusé » et « pas encore de réponse ». Il en résultait que les refus pouvaient entraîner une avalanche de nouvelles tentatives. Désormais, chaque requête dispose d’un jeton unique, et aucune requête qui n’a pas été effectivement transmise n’est enregistrée. Si une réponse est perdue, la requête est traitée comme un échec au lieu d’être suspendue. Le balayage (sweep) qui effectue cette opération n’entraîne aucun coût lorsqu’il n’y a pas de requêtes en attente.La calibration du socle Inkwell n’est pas affectée par le test des nouvelles fonctionnalités du micrologiciel de la poignée. Lorsque le stylo est placé dans son socle, un recalibrage complet de la position est effectué ; il s’agit d’un comportement normal pour tous les stylos commercialisés, quelle que soit la version du micrologiciel. Ce parcours est explicitement exclu des exigences fonctionnelles minimales introduites pour la correction d’orientation calculée ; cette exclusion est clairement indiquée au point d’appel et ne doit pas être laissée à l’interprétation.Corrections {#fixes}
Lors de la réinitialisation de la compensation de gravité, celle-ci est désormais rétablie à sa valeur par défaut réelle, et non plus à une valeur excessive. Contrairement à ce que son nom laisse penser, config/compensation_de_la_gravitéde facteur_d'échelle Ce champ n'est pas un coefficient multiplicateur. Il s'agit de la masse utile de l'effecteur terminal (en kilogrammes) que l'appareil compense en plus de son propre poids. La réinitialisation reprend ce nom tel quel pour définir un coefficient « neutre », à savoir 1Je l'ai réinitialisé. Cela revient à définir une charge utile virtuelle de 1 kilogramme, ce qui a fait que, après la réinitialisation, l'appareil s'est retrouvé dans une position où la poignée est poussée vers le haut. Les appareils nouvellement connectés ne fonctionnent pas de cette manière. Désormais, les valeurs par défaut réelles sont appliquées lors de la réinitialisation. La récompense est activée et facteur_d'échelleest 0Ce paramètre est défini par défaut, ce qui suppose que l'appareil ne supporte que son propre poids et qu'il n'y a pas de charge utile. Si votre application utilisait la réinitialisation pour augmenter l'intensité de la compensation, veuillez définir explicitement la valeur souhaitée.La réinitialisation du retour à l'accueil (home return) est désormais à nouveau activée. config/retour_à_l'accueilLa réinitialisation indiquait à l'appelant qu'elle était activée, alors qu'en réalité, elle désactivait le retour à l'écran d'accueil. Désormais, lors de la réinitialisation, les paramètres d'usine par défaut (activés) sont réellement rétablis, et la valeur lue par l'application correspond alors à celle effectivement utilisée par l'appareil.Après un montage de portée de périphérique ou une écriture d’orientation, aucune valeur obsolète ne subsiste chez les autres clients. Avant la version 3.5.6, une écriture appliquée au périphérique lui-même (partagée par toutes les sessions disposant de ce périphérique) ne rafraîchissait que les paramètres du client ayant effectué l’écriture, tandis que les routes globales du périphérique n’étaient rafraîchies par aucun client. Les autres clients utilisant le même périphérique continuaient d’afficher les anciennes valeurs jusqu’à ce qu’ils effectuent une interrogation. Désormais, une notification est transmise à toutes les sessions disposant du périphérique.Lorsqu’on effectue plusieurs tentatives d’amarrage à Inkwell, on n’abandonne pas après un seul refus. L’état de l’amarrage précédent étant conservé d’un amarrage à l’autre, le deuxième amarrage considérait le premier refus comme la fin de la période de réessai. Désormais, la période de réessai est réinitialisée à chaque nouvelle tentative d’amarrage.Nous avons corrigé un problème de flux de données dans le dispositif VerseGrip sans fil. Le thread de connexion pouvait réattribuer l'identifiant du dispositif pendant que d'autres chemins de traitement lisaient sous un autre verrou. Désormais, l'identifiant est enregistré une seule fois sous le verrou approprié, et tous les chemins en aval (y compris le traitement des rejets) fonctionnent à partir de cette copie.Nous avons corrigé un problème de désynchronisation de la mise en file d'attente des messages au niveau des quatre émetteurs du VerseGrip sans fil. Les quatre chemins de transmission des messages assemblaient la charge utile et la somme de contrôle, puis demandaient la transmission sans avoir obtenu de verrou d'écriture ; cela permettait à deux émetteurs de mélanger les données dans la mémoire tampon partagée.Modifications susceptibles d'entraîner des problèmes de compatibilité {#potential-breaking-changes}
Il n'y a aucun changement au niveau de l'API, du format de transmission ni des paramètres. La sortie par défaut reste identique à celle de la version 3.5.5 au niveau des octets ; aucune route n'a été supprimée ni n'a changé d'itinéraire ; il n'y a aucune différence au niveau de l'API C publique ; et aucun nom de clé de configuration n'a été modifié, supprimé ou doté d'une nouvelle valeur par défaut. Toutefois, les applications ayant opté pour la préversion ou les fonctionnalités expérimentales du SDK devront effectuer une migration au cours de ce cycle. Cela inclut des changements de niveau de commutateur et des ensembles de jetons supprimés ; toutes les étapes sont documentées dans le journal des modifications à usage technique.La réinitialisation de la compensation de gravité renvoie une valeur différente de celle de la version 3.5.5. Les champs, les routes et les formats de réponse n'ont pas changé, mais la réinitialisation facteur_d'échellele 1Les applications qui s'appuyaient sur l'enregistrement sous forme de 0vous le recevrez. Dans tous les cas, la compensation reste active. Ne comptez pas sur la réinitialisation et définissez explicitement la valeur. Reportez-vous aux modifications ci-dessus.Une fois la fonction « Retour à l'accueil » réinitialisée, celle-ci reste activée et ne se désactive pas. Bien que les champs, l'itinéraire et le format de réponse n'aient pas changé, les applications qui désactivaient auparavantla fonction « Retour à l'accueil » à l'aide de la réinitialisation la verront désormais activée. Si vous souhaitez qu'elle soit désactivée, veuillez la désactiver explicitement après la réinitialisation. Reportez-vous aux modifications ci-dessus.Le client recevra un événement de configuration supplémentaire. mis à jour lors de la session Une application qui partait du principe que les événements n’étaient reçus que lorsqu’elle effectuait elle-même une écriture reçoit désormais également des événements lorsque d’autres clients modifient les appareils qu’elle gère conjointement, ce qui entraîne ensuite le rafraîchissement de l’ensemble de la configuration. Il s’agit là d’un résultat escompté du « fan-out » décrit plus haut. Les clients qui se contentent de relire les données après avoir reçu un événement n’ont pas besoin d’être modifiés.
