Points forts {#highlights}
Les modifications apportées aux paramètres de portée d'un périphérique s'appliquent désormais non seulement à la session dans laquelle elles ont été effectuées, mais également à toutes les sessions client utilisant ce périphérique.Le deuxième visualiseur, au lieu d'effectuer un polling, utilise son propre mis à jour lors de la session La mise à jour s'effectue à la suite d'un événement. Un seul événement est envoyé pour chaque session en cours, et il n'est jamais envoyé deux fois au client ayant effectué l'écriture.
Il est désormais possible de signaler au client la configuration physique des montages du périphérique. Auparavant, le service signalait systématiquement les montages définis dans la session. L'étiquette indiquant quelle valeur est prise en compte affiche désormais un affichage structurellement toujours exact, quel que soit le format de sortie.Lorsque l'appareil dispose de ses propres repères de montage, le service s'adapte désormais à ces changements. Auparavant, le service renvoyait simplement les valeurs obtenues au démarrage de l'appareil, sans les vérifier par la suite. Désormais, il est possible de mettre à jour ces repères à la demande, en fonction de la fréquence de rafraîchissement du client. Grâce à la limitation de débit mise en place par le service, les clients affichant une fréquence de rafraîchissement élevée ne risquent pas de surcharger la connexion avec l'appareil. Une notification est envoyée une seule fois, au moment où le montage a effectivement pivoté.Améliorations internes {#internal-improvements}
Correction automatique expérimentale de la dérive de l'angle de lacet de la pince. Un nouveau module de service corrige en boucle fermée la dérive de l'angle de lacet due à l'inertie de la pince VerseGrip sans fil. Il ajuste l'angle de lacet absolu de la pince en fonction des mouvements de l'Inverse3 ou du Minverse appairé et monté sur celle-ci, puis, une fois que toutes les conditions de qualité sont remplies, il enregistre une valeur de correction unique dans le micrologiciel de la pince.Cette fonctionnalité estdésactivée par défautet n'est disponible que si le commutateur expérimental « opt-in » est activé. De plus, elle dispose d'un commutateur d'exécution qui, dès son activation, réinitialise de force la correction sur « désactivée » pour toutes les poignées en cours de fonctionnement. Comme il s'agit d'une fonctionnalité qui s'écrit dans le micrologiciel de l'appareil, ce mécanisme est incontournable.La mise en œuvre des paramètres sur l'ensemble des appareils s'effectue désormais selon un principe « tout ou rien ». Avant qu'aucun appareil ne soit modifié, tous les éléments sélectionnés sont vérifiés, y compris la compatibilité du micrologiciel et l'état de préparation des appareils. Ainsi, dans un parc d'appareils utilisant des micrologiciels hétérogènes, il n'arrive plus que le processus s'arrête alors que la mise à jour n'est effectuée qu'à moitié, en cas d'erreur sur le deuxième appareil.Nous avons désormais mis en place un suivi de la confirmation des réponses provenant du micrologiciel de la poignée pour chaque requête. Comme il n’y avait qu’un seul slot de résultats partagé, l’envoi simultané de deux requêtes pouvait entraîner une confusion entre leurs réponses respectives. De plus, une valeur ambiguë pouvant signifier à la fois « refus » et « absence de réponse » risquait de provoquer une avalanche de tentatives de réessai en cas de refus.Désormais, chaque requête dispose de son propre jeton, et les requêtes qui n’ont pas abouti ne sont pas enregistrées. En cas de perte de réponse, le traitement est définitivement considéré comme un échec, au lieu de rester bloqué. Ce processus de balayage n’entraîne aucune charge tant qu’il n’y a pas de requêtes en attente.L'étalonnage de l'Inkwell Dock n'est pas affecté par la vérification des fonctionnalités du micrologiciel de la nouvelle poignée. Lorsque le stylo est placé dans le dock, un réétalonnage 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 processus est explicitement exclu du seuil minimal des exigences fonctionnelles introduites pour la correction d'orientation par calcul, et la raison de cette exclusion est clairement indiquée dans le code source, et non pas le fruit d'une simple supposition.Corrections {#fixes}
La réinitialisation de la compensation de la gravité permet désormais de revenir à la valeur par défaut correcte, et non plus à une surcompensation.Contrairement à ce que son nom laisse supposer,config/compensation_de_la_gravité の facteur_d'échelle Le champ « Field » ne correspond pas à un coefficient multiplicateur. Il s'agit de la masse de charge utile supplémentaire (en kilogrammes) de l'effecteur terminal, qui vient s'ajouter au poids de l'appareil lui-même. Les réinitialisations précédentes prenaient ce nom au pied de la lettre, avec un coefficient « neutre » 1 Il était revenu à cette valeur. Comme cela correspond à une charge utile fictive d'un kilogramme, l'appareil continuait à pousser sur le levier après la réinitialisation. Ce comportement diffère de celui observé juste après la connexion. Avec la réinitialisation actuelle, l'appareil revient à sa valeur par défaut réelle. En d'autres termes, la compensation est active, etfacteur_d'échelle は 0 est défini. L'appareil ne supporte que son propre poids et fonctionne comme s'il n'y avait aucune charge utile. Si votre application utilisait la fonction « reset » pour augmenter le niveau de compensation, veuillez définir explicitement la valeur requise à la place.
La réinitialisation de la fonction « Retour à l'accueil » permet désormais de réactiver effectivement cette fonction. config/retour_à_l'accueil La réinitialisation entraînait une situation dans laquelle, bien que la fonction « Retour à l'accueil » soit désactivée, elle était signalée comme étant activée à l'application appelante. Désormais, la réinitialisation rétablit réellement les paramètres d'usine par défaut (activée), et la valeur lue par l'application correspond alors à celle effectivement utilisée par l'appareil.Après une écriture concernant la position ou l'orientation d'un périphérique, l'affichage des autres clients ne reste désormais plus obsolète. Avant la version 3.5.6, une écriture sur le périphérique lui-même (partagée par toutes les sessions utilisant ce périphérique) ne mettait à jour que les paramètres du client à l'origine de l'écriture, et la position globale du périphérique ne mettait à jour les paramètres d'aucun utilisateur. Les autres clients utilisant le même périphérique continuaient d'afficher l'ancienne valeur jusqu'à ce qu'ils effectuent une requête. Désormais, toutes les sessions utilisant ce périphérique en sont informées.Le système de réessai d'InkWell Dock ne s'arrête plus après un seul refus. Comme l'état du dock précédent était conservé pour les docks suivants, le deuxième dock 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 tentative de dock.Nous avons corrigé un conflit de données lors du traitement des ticks sur les appareils VerseGrip sans fil. Il arrivait que l'identifiant de l'appareil soit réattribué par le thread de connexion, et que, pendant ce processus, le traitement de mise en attente le lise sous un autre verrou. Désormais, l'identifiant est capturé une seule fois sous le verrou approprié, et tous les chemins suivants (y compris ceux qui ont été rejetés) fonctionnent sur la base de cette copie.Nous avons corrigé un problème de mise en file d'attente des messages non synchronisés au niveau des quatre sources Wireless VerseGrip. Les quatre voies d'envoi de messages assemblaient la charge utile et la somme de contrôle avant de demander l'envoi, mais n'obtenaient pas de verrou d'écriture. De ce fait, il arrivait que deux sources se chevauchent dans le traitement sur un tampon partagé.Modifications susceptibles d'entraîner des incompatibilités {#potential-breaking-changes}
Il n'y a aucun changement au niveau de l'API, du câblage ou de la configuration. La sortie par défaut est identique à celle de la version 3.5.5 au niveau des octets, aucune route n'a été supprimée ou réacheminée, il n'y a aucune différence par rapport à l'API C publiée, et aucune clé de configuration n'a été renommée, supprimée ou dotée d'une nouvelle valeur par défaut.Les applications ayant opté pour la préversion ou la surface expérimentale du SDKdoivent effectuerdes opérations de migration au cours de ce cycle. Cela inclut des modifications de la hiérarchie des commutateurs et des ensembles de jetons supprimés. Chaque étape est détaillée dans l’historique des modifications complémentaire destiné aux ingénieurs.La réinitialisation de la compensation de gravité renvoie désormais une valeur différente de celle de la version 3.5.5. Bien que la structure des champs, des routes et des réponses n'ait pas été modifiée, la réinitialisation a entraîné facteur_d'échelle mais 1 Les applications qui prévoyaient que des données y soient écrites utilisent désormais les valeurs par défaut définies en usine à la place. 0 est récupérée. Dans tous les cas, la couverture reste valide. Ne comptez pas sur la réinitialisation et définissez explicitement la valeur. Reportez-vous à la correction mentionnée ci-dessus.Après la réinitialisation de la fonction « Home Return », celle-ci reste activée et non désactivée. Bien que la structure des champs, des itinéraires et des réponses n'ait pas été modifiée, les applications qui partaient du principeque la réinitialisation désactiverait la fonction « Home Return »verront celle-ci rester activée. Si vous souhaitez la désactiver après la réinitialisation, veuillez la désactiver explicitement. Veuillez vous reporter à la correction mentionnée ci-dessus.Le client recevra désormais des événements de configuration supplémentaires. mis à jour lors de la session Une application qui partait du principe que les événements n'étaient transmis que par ses propres mises à jour recevra désormais ces événements même si un autre client, utilisant le même appareil, effectue une modification. Un rafraîchissement complet de la configuration s'ensuivra. Il s'agit là d'un résultat prévu du mécanisme de « fan-out » mentionné plus haut. Les clients qui se contentent de recharger la page à la réception d'un événement n'ont pas besoin d'être modifiés.
