Linux 7.3 revierte soporte de Logitech Bolt tras avalancha de bugs
El kernel 7.3 reintroduce el driver HID++ para receptores Bolt, pero los fallos obligan a volver al código genérico por ahora.
La versión 7.3 del kernel Linux ha tenido que revertir la integración del soporte para receptores USB Logitech Bolt en el controlador hid-logitech-dj. La decisión llega después de que usuarios reportaran una degradación significativa en el funcionamiento de ratones Logitech comparado con versiones anteriores, como el Linux 7.2.
El problema surgió al intentar tratar los receptores Bolt como dispositivos del protocolo HID++ directamente en el kernel, en lugar de usar el controlador HID genérico para el USB y reservar el HID++ para conexiones Bluetooth. Esta mezcla técnica provocó errores variados: rodamientos de scroll comportándose erráticamente, necesidad de reajustar configuraciones tras cada ciclo de suspensión o reconexión, y distancias de desplazamiento incorrectas.
Benjamin Tissoires, mantenedor del subsistema HID, ha identificado dos causas raíz principales. Por un lado, el receptor Bolt no identifica claramente qué dispositivo está enviando cada evento; si se conectan dos ratones al mismo receptor, uno funciona mientras el otro se vuelve inutilizablemente lento o rápido. Por otro lado, los ajustes por defecto nuevos chocaban con las configuraciones que los usuarios ya habían hecho a nivel de espacio de usuario (userspace), generando conflicto.
Ante la falta de parches que cubran todos los casos extremos de forma estable, Tissoires ha encolado un parche para la rama de mantenimiento for-7.3/upstream-fixes del repositorio HID. La acción revierte el soporte específico para Bolt HID++ y devuelve la navegación USB al controlador HID genérico. Esto sacrifica las funciones avanzadas de HID++ a través de este receptor, pero garantiza estabilidad en la versión final del kernel mientras se desarrolla una solución correcta.
El mantenedor resumió la postura: "Introducir Bolt como receptor DJ creó muchos problemas... el resultado final es que la función no está lista para un kernel final, y lo sensato es revertir el parche y revisarlo en un kernel posterior". Los administradores de sistemas que usen equipos con estos periféricos en entornos críticos deberían esperar a que los fijaciones lleguen a las ramas estables, ya que la solución actual es una retirada temporal de la funcionalidad, no un parche definitivo.
