하이라이트 {#highlights}
디바이스 범위 설정의 저장 내용은 해당 설정을 저장한 세션뿐만 아니라, 해당 디바이스를 보유한 모든 클라이언트 세션에 반영되도록 변경되었습니다.두 번째 뷰어는 폴링을 하는 대신 자체적으로 세션 업데이트됨 이벤트가 발생하면 업데이트됩니다. 유지 중인 각 세션마다 정확히 한 번의 이벤트가 전송되며, 쓰기 작업을 수행한 클라이언트에게는 두 번 전송되지 않습니다.
이제 클라이언트에 장치의 물리적 마운트 구성을 보고할 수 있게 되었습니다. 이전에는 서비스가 항상 세션에 설정된 마운트를 보고했습니다. 어떤 값을 나타내는지 표시하는 레이블은 모든 출력 형식에서 구조적으로 항상 정확하게 표시되도록 개선되었습니다.장치가 고유한 장착 기준을 유지하는 경우, 서비스가 해당 변경 사항을 반영하도록 개선되었습니다. 이전 버전의 서비스는 장치 시작 시 획득한 값을 그대로 반환하고, 그 이후에는 재확인하지 않았습니다. 현재는 클라이언트의 렌더링 주기에 맞춰 요청에 따라 이 기준을 업데이트할 수 있습니다. 서비스 측에서 속도 제한을 적용하고 있으므로, 렌더링 빈도가 높은 클라이언트라도 장치와의 연결에 과부하를 일으키지 않습니다. 장착이 실제로 회전했을 때, 변경 사항을 한 번 알립니다.내부 개선 {#internal-improvements}
실험적인 그립 요각 드리프트 자동 보정. 새로운 서비스 모듈이 무선 VerseGrip의 관성으로 인한 요각 드리프트를 폐쇄 루프 방식으로 보정합니다. 그립의 절대 요각을 장착된 페어링 완료된 Inverse3 또는 Minverse의 움직임에 맞춰 조정하고, 일련의 품질 기준이 모두 충족되면 한 번의 보정 값을 그립의 펌웨어에 기록합니다.이 기능은초기 상태에서 비활성화되어있으며, 실험용 옵트인 스위치를 켠 경우에만 사용할 수 있습니다. 또한, 스위치를 전환하는 순간 작동 중인 모든 그립의 보정 기능을 강제로 비활성화하도록 하는 런타임 스위치도 갖추고 있습니다. 이는 장치 펌웨어에 기록되는 기능이기 때문에 생략할 수 없는 구조입니다.모든 장치를 대상으로 하는 설정 쓰기 작업은 이제 ‘전부 또는 전혀’ 방식의 처리로 변경되었습니다. 변경 대상 장치가 하나도 없는 상태에서, 펌웨어 지원 현황 및 장치 준비 상태를 포함하여 선택된 모든 항목에 대한 검증이 수행됩니다. 따라서 펌웨어가 혼재된 기기군에서 두 번째 장치에서 오류가 발생했을 때, 절반만 전환된 상태로 멈추는 일이 더 이상 발생하지 않습니다.이제 각 요청마다 그립 펌웨어의 응답 확인을 추적하도록 변경되었습니다. 공유된 결과 슬롯이 하나뿐이었기 때문에, 두 개의 요청을 동시에 보내면 서로의 응답을 혼동하는 경우가 있었습니다. 또한, 하나의 모호한 값이 ‘거부’와 ‘응답 없음’을 모두 나타내고 있었기 때문에, 거부가 재시도 폭주로 이어질 위험이 있었습니다.현재는 각 요청이 고유한 토큰을 가지며, 전송되지 않은 요청은 등록되지 않습니다. 응답이 손실된 경우, 처리가 중단된 상태로 남아 있는 대신 실패로 확정됩니다. 이 스윕 처리는 처리되지 않은 요청이 없는 동안에는 부하를 발생시키지 않습니다.잉크웰 도크의 보정 기능은 새로운 그립의 펌웨어 기능 점검의 영향을 받지 않습니다. 펜을 도크에 놓으면 완전한 자세 재보정이 수행됩니다. 이는 펌웨어 버전에 관계없이 출하된 모든 펜에서 정상적으로 작동하는 현상입니다. 이 경로는 계산에 의한 방향 보정을 위해 도입된 기능 요구 사항의 최소 기준에서 명시적으로 제외되어 있으며, 그 제외 사유는 추측이 아닌 호출 위치에 명확히 기재되어 있습니다.수정 {#fixes}
중력 보정 재설정 시, 과보정이 아닌 올바른 기본값으로 돌아가게 되었습니다.이름과는 달리,config/중력 보정 의 스케일링 계수 필드는 승수가 아닙니다. 이는 장치 자체의 무게에 더해 보정해야 하는 엔드 이펙터의 추가 탑재 하중 질량(킬로그램 단위)입니다. 이전의 재설정은 이름을 그대로 받아들여 ‘중립’ 계수 1 로 되돌려 놓았습니다. 이는 가상의 1킬로그램 페이로드에 해당하므로, 리셋 후에는 장치가 핸들을 계속 위로 밀어 올리고 있었습니다. 이는 연결 직후 장치의 동작과는 다릅니다. 현재의 리셋에서는 실제 기본값으로 돌아갑니다. 즉, 보정이 활성화되어 있으며,스케일링 계수 는 0 로 설정됩니다. 장치는 자체 중량만 지탱하며, 페이로드는 없는 것으로 간주하여 작동합니다. 애플리케이션에서 리셋을 통해 보정 강도를 높였던 경우, 대신 필요한 값을 명시적으로 설정해 주십시오.
홈 리턴 재설정을 통해 홈 리턴 기능이 실제로 다시 활성화되도록 변경되었습니다. config/home_return 리셋 시, ‘홈으로 돌아가기’ 기능이 비활성화되어 있음에도 호출 측에는 활성화된 것으로 전달되는 문제가 있었습니다. 현재는 리셋을 통해 실제로 공장 출하 시의 기본값(활성화됨)으로 복원되며, 이후 애플리케이션이 읽어오는 값은 기기가 실제로 사용하고 있는 값과 일치합니다.디바이스 스코프의 장착 또는 방향에 대한 쓰기 작업 후, 다른 클라이언트의 표시가 이전 상태로 남아 있는 현상이 더 이상 발생하지 않습니다. 3.5.6 이전 버전에서는 디바이스 자체에 대한 쓰기 작업(해당 디바이스를 보유한 모든 세션에서 공유됨) 시, 쓰기 작업을 수행한 클라이언트의 설정만 업데이트되었고, 디바이스 전체의 경로는 누구의 설정도 업데이트하지 않았습니다. 동일한 디바이스를 사용하는 다른 클라이언트는 폴링을 수행할 때까지 이전 값을 계속 표시했습니다. 현재는 해당 디바이스를 보유한 모든 세션에 알림이 전송됩니다.잉크웰 도크의 재시도 과정에서 한 번 거부되었다고 해서 바로 포기하는 일은 더 이상 발생하지 않습니다. 이전 도크의 상태가 후속 도크까지 이어졌기 때문에, 두 번째 도크는 첫 번째 거부를 재시도 기간의 종료 시점으로 간주했습니다. 이제 재시도 기간은 도크 시도가 있을 때마다 초기화됩니다.무선 VerseGrip 장치의 틱 처리 과정에서 발생하던 데이터 경합 문제를 수정했습니다. 장치의 식별자가 연결 스레드에 의해 재할당되는 경우가 있었는데, 이 과정에서 스테이징 처리가 다른 잠금 상태에서 해당 식별자를 읽어들일 수 있었습니다. 현재는 올바른 잠금 상태에서 식별자가 한 번만 스냅샷으로 저장되며, 모든 경로(거부된 경로 포함)는 해당 복사본을 기반으로 작동합니다.4개의 Wireless VerseGrip 송신원에서 발생하던 비동기 메시지의 스테이징 문제를 수정했습니다. 4개의 메시지 전송 경로는 페이로드와 체크섬을 조립하여 전송을 요청했으나, 쓰기 잠금을 획득하지 않았습니다. 이로 인해 두 송신원이 공유 버퍼에서 처리가 겹치는 경우가 발생했습니다.잠재적인 호환성 문제 {#potential-breaking-changes}
API, 와이어, 설정에는 변경 사항이 없습니다. 기본 출력은 3.5.5 버전과 바이트 단위로 동일하며, 어떤 경로도 삭제되거나 재경로 설정되지 않았고, 공개된 C API에도 차이가 없으며, 설정 키의 이름 변경, 삭제 또는 새로운 기본값 설정도 없습니다.SDK 프리뷰 또는 실험적 기능을 사용하도록 설정한 애플리케이션의 경우, 이번 주기 내에 마이그레이션작업이 필요합니다. 여기에는 스위치 계층 구조의 변경 및 삭제된 토큰 세트가 포함됩니다. 각 단계는 엔지니어링용 보충 변경 내역에 기재되어 있습니다.중력 보정 재설정 시, 3.5.5 버전과는 다른 값이 반환되도록 변경되었습니다. 필드, 경로, 응답의 형태는 변경되지 않았지만, 리셋으로 인해 스케일링 계수 하지만 1 쓰기 작업을 전제로 설계된 애플리케이션은 대신 공장 출하 시의 기본값을 0 을 수신합니다. 어느 경우든 보상 자체는 유효한 상태로 유지됩니다. 재설정에 의존하지 말고 값을 명시적으로 설정해 주십시오. 위의 수정 사항을 참조하십시오.홈 리턴을 재설정한 후에는 홈 리턴이 꺼진 상태가 아닌 켜진 상태로 유지됩니다. 필드, 경로, 응답의 형태는 변경되지 않았지만, 재설정을 통해 홈 리턴이비활성화될 것이라고가정했던 애플리케이션에서는 대신 활성화된 상태가 됩니다. 재설정 후 비활성화하려면 명시적으로 ‘꺼짐’으로 설정하십시오. 위의 수정 사항을 참조하십시오.클라이언트에는 추가 설정 이벤트가 전송되게 됩니다. 세션 업데이트됨 자신의 작성 내용에 의해서만 이벤트가 전달된다고 가정했던 애플리케이션은, 동일한 기기를 사용하는 다른 클라이언트가 변경을 가한 경우에도 해당 이벤트를 수신하게 됩니다. 그 후 전체 설정의 재렌더링도 수행됩니다. 이는 앞서 언급한 팬아웃(fan-out)에 따른 의도된 결과입니다. 이벤트를 수신하여 단순히 다시 불러오는 클라이언트는 변경할 필요가 없습니다.
