Spoľahlivú Logitech MX Master 3, počítačovú myš, ktorú používam, považujem za skvelý prírastok do svojho arzenálu. Hoci sa snažím používať myš čo najmenej v čase, keď je klávesnica hlavným vstupným zariadením (keď niečo píšem), myš je stále veľmi dôležitá.
Nepochopte ma zle – pravdepodobne som len ďalší, kto skočil na vlnu ľudí odporúčajúcich túto myš, no nahradiť ju by som sa nesnažil, pretože má všetky funkcie, ktoré potrebujem.
Konkrétne prepínač zdrojov je jednou z takých funkcií. Myš má tlačidlo na spodnej strane, ktoré umožňuje prepínať zdroj – teda zariadenie, ku ktorému je momentálne pripojená. Sú tri možnosti. Číslo 1 je pre USB dongle, alebo Unifying Receiver, ako ho Logitech nazýva. Je „unifying” preto, lebo umožňuje súčasne pripojiť viacero Logitech zariadení, napríklad myš a klávesnicu. Klávesnicu zatiaľ nemám, pretože sa stále neviem rozhodnúť medzi tými, ktoré Logitech ponúka.
Myš však vlastním a s ňou aj Unifying Receiver. Vec je v tom, že dongle nie je zapojený v laptope, ale namiesto toho ho mám zapojený v ThinkPad docku, ako som vysvetlil v článku vyššie. Keď používam dongle (zdroj 1) zapojený do laptopa alebo docku, myš funguje bez akéhokoľvek problému, dokonca aj pri dual boote.
Problém #
Situácia sa mení, keď cestujem. Dock ani dongle so sebou samozrejme neberam. Myš má ďalšie dva zdroje (čísla 2 a 3), ktoré umožňujú spárovať dve Bluetooth zariadenia s príslušnými číslami. Takže keď som na cestách, jednoducho prepnem zdroj z dongla na Bluetooth a všetko je v poriadku.
Toto je obzvlášť dôležité pri dual boote počas cestovania, keďže zdroj číslo 3 je spárovaný s iným operačným systémom. Klasická Bluetooth myš s jedným zdrojom je oveľa ťažšia na konfiguráciu pre dual boot.
Tento rozprávkový príbeh išiel dobre nejaký čas, no možno pred dvoma mesiacmi som začal zažívať tento nepríjemný problém s Bluetoothom. Po akomkoľvek obnovení zo spánku alebo hibernácie, ba dokonca po reštarte alebo studeného štarte, sa myš síce pripojí ako má, ale okamžite nereaguje. Včera som sa rozhodol nájsť riešenie natrvalo, keďže viac ako rok fungovala bez problémov, takže to muselo byť možné.
Príznaky v logoch #
Okrem najzrejmejšieho príznaku – nereagujúcej myši – existujú ďalšie
náznaky, že niečo nie je v poriadku. Tu sú dva zaujímavé riadky z
journalctl -xe:
bluetoothd[411]: profiles/input/hog-lib.c:set_report_cb() Error setting Report value: Unexpected error code
A tento:
bluetoothd[411]: profiles/network/connection.c:connect_cb() connect to 0C:CB:85:02:4E:D4: Host is down (112)
Situácia v dmesg tiež nie je radostná. Našiel som toto:
[ 2065.385987] Bluetooth: hci0: Received unexpected HCI Event 00000000
[ 2065.386013] Bluetooth: hci0: unexpected event for opcode 0x0000
[ 2065.431367] Bluetooth: hci0: Received unexpected HCI Event 00000000
[ 2065.622357] Bluetooth: hci0: Received unexpected HCI Event 00000000
[ 2065.633500] Bluetooth: hci0: Received unexpected HCI Event 00000000
[ 2067.354587] Bluetooth: hci0: FW download error recovery failed (-110)
[ 2067.355066] Bluetooth: hci0: Hardware error 0x00
[ 2069.488056] Bluetooth: hci0: Controller not accepting commands anymore: ncmd = 0
[ 2069.488072] Bluetooth: hci0: Injecting HCI hardware error event
[ 2077.380961] Bluetooth: hci0: Reset after hardware error failed (-110)
[ 2077.492030] Bluetooth: hci0: Received unexpected HCI Event 00000000
[ 2079.514574] Bluetooth: hci0: Reading Intel version information failed (-110)
[ 2079.514587] Bluetooth: hci0: Intel Read version failed (-110)
[ 2079.514585] Bluetooth: hci0: command 0x0c03 tx timeout
[ 2081.647859] Bluetooth: hci0: command 0xfc05 tx timeout
[ 2081.648039] Bluetooth: hci0: Intel reset sent to retry FW download
A tiež toto:
[ 2082.239431] Bluetooth: hci1: Bootloader revision 0.0 build 26 week 38 2015
[ 2082.240460] Bluetooth: hci1: Device revision is 16
[ 2082.240467] Bluetooth: hci1: Secure boot is enabled
[ 2082.240471] Bluetooth: hci1: OTP lock is enabled
[ 2082.240474] Bluetooth: hci1: API lock is enabled
[ 2082.240476] Bluetooth: hci1: Debug lock is disabled
[ 2082.240479] Bluetooth: hci1: Minimum firmware build 1 week 10 2014
[ 2082.248290] Bluetooth: hci1: Found device firmware: intel/ibt-12-16.sfi
[ 2084.151749] Bluetooth: hci1: Waiting for firmware download to complete
[ 2084.152457] Bluetooth: hci1: Firmware loaded in 1859559 usecs
[ 2084.152625] Bluetooth: hci1: Waiting for device to boot
[ 2084.165433] Bluetooth: hci1: Device booted in 12616 usecs
[ 2084.165710] Bluetooth: hci1: Found Intel DDC parameters: intel/ibt-12-16.ddc
[ 2084.168419] Bluetooth: hci1: Applying Intel DDC parameters completed
[ 2084.169468] Bluetooth: hci1: Reading supported features failed (-16)
[ 2084.170482] Bluetooth: hci1: Firmware revision 0.1 build 212 week 30 2021
[ 2085.744578] logitech-hidpp-device 0005:046D:B023.000D: Device not connected
Objavil sa aj tento riadok:
[ 1338.544489] Bluetooth: hci0: urb 0000000066025a26 failed to resubmit (2)
Všetko vyššie uvedené bolo nájdené na najnovšom jadre dostupnom na Arch,
ktoré je momentálne 5.14.14. Postihnuté sú všetky tri oficiálne hlavné
jadra:
Situácia na LTS jadre
linux-lts, ktoré
momentálne je vo verzii 5.10.75-1, je v podstate identická, čo je celkom
smutné, pretože som dúfal, že LTS jadro tento problém jednoducho vyrieši.
Dočasné obchádzky #
Počas predchádzajúcich dvoch mesiacov som musel robiť nasledovné, aby myš opäť fungovala cez Bluetooth.
Možnosť 1: Vypnúť a zapnúť myš #
Najzrejmejšie riešenie je vypnúť a znova zapnúť myš pomocou prepínača na jej spodnej strane. Myš sa znovu pripojí a začne reagovať. Robiť to viackrát denne je otravné.
Možnosť 2: Prepnúť zdroj #
Ďalšia vec, ktorá prinúti myš znovu sa pripojiť, je stlačiť tlačidlo zdroja opísané vyššie presne trikrát. Keďže sú tri zdroje, skončí na presne rovnakom zdroji. Je to presne tak otravné ako predchádzajúca možnosť.
Možnosť 3: Gnome Bluetooth GUI #
Prejsť do nastavení Bluetooth v Gnome, odpojiť a znovu pripojiť myš cez GUI prepínač tiež funguje. Ale keďže je to v GUI, vyžaduje to veľa kliknutí touchpadom. Absolútne najhoršia možnosť.
Možnosť 4: bluetoothctl CLI #
Samozrejme, na vyriešenie problému je možné použiť príkazový riadok. Príkaz
bluetoothctl z balíčka
bluez-utils to
zvládne:
bluetoothctl -- disconnect MAC_ADDRESS
Ktorý vypíše nasledovné:
Attempting to disconnect from E7:B9:C9:15:DF:80
[CHG] Device E7:B9:C9:15:DF:80 ServicesResolved: no
Successful disconnected
MAC adresu myši možno nájsť napríklad takto:
bluetoothctl -- devices | grep Master | cut -d' ' -f2
Zdá sa, že odpojenie stačí – myš sa sama znovu pripojí a stane sa responzívnou. Nie som si istý, čo si z toho vziať.
Poznámka: Používanie
bluetoothctlv interaktívnom režime (len spustenie príkazu) ponúka dopĺňanie príkazov aj MAC adries, takže takto môže byť dokonca rýchlejšie, keď nie ste vo vnútri skriptu.
Čo nefungovalo #
Napokon som našiel rozumné riešenie, no predtým som musel vyskúšať niekoľko vecí. Pre úplnosť uvádzam veci, ktoré som skúšal a ktoré mi nefungovali.
Neúspech 1: IdentityResolvingKey #
Prvá vec, ktorú som niekoľkokrát skúšal, je zdokumentovaná v
Arch Wiki
a vyžaduje odstránenie dvoch riadkov v súbore
/var/lib/bluetooth/adapter_mac/device_mac/info:
[IdentityResolvingKey]
Key=...
Toto je pravdepodobne najčastejšie odkazované riešenie podobného problému s Bluetooth myšou, no pre mňa neurobilo žiadny rozdiel.
Neúspech 2: usb_modeswitch #
Ďalšie riešenie vo wiki hneď vedľa toho predchádzajúceho je použiť usb_modeswitch:
sudo usb_modeswitch -R -v vendor_ID -p product_ID
Neúspech 3: modprobe btusb #
Toto myš k responzívnosti nevrátilo, ale je to vlastne veľmi dobrý spôsob,
ako vynútiť zápis do dmesg:
sudo rmmod btusb && sudo modprobe btusb
Toto bolo navrhnuté na viacerých miestach, napríklad opäť na tej istej Bluetooth stránke Arch Wiki.
Neúspech 4: hciconfig #
Toto je variácia vyššie uvedeného prevzatá odtiaľto. Vyžaduje bluez-hciconfig, ktorý je zastaraný. Existuje aj súvisiaci bluez-hcitool. Riešenie navrhuje nasledovné:
hciconfig hci0 down
rmmod btusb
modprobe btusb
hciconfig hci0 up
Tiež nefungovalo.
Neúspech 4: TLP USB autosuspend #
Niektoré komentáre
naznačovali, že USB autosuspend môže byť problémom, keďže Bluetooth môže
byť interne pripojený cez USB, čo je bežné. Žiaľ, vypnutie služby tlp nič
nezmení.
Použitie blacklistu alebo USB_DENYLIST,
ako to tlp nazýva, nemá žiadny efekt.
Neúspech 5: btusb.enable_autosuspend kernel parameter #
Ďalší súvisiaci návrh riešenia, ktorý mi nefungoval, je použiť parameter
jadra btusb.enable_autosuspend=n. Zaujímavé čítanie nájdete v tomto
príspevku na StackExchange.
Neúspech 6: hid2hci #
Posledné zrejmé riešenie je nainštalovať bluez-hid2hci spomínaný viackrát v už citovanej stránke Bluetooth Wiki, napríklad tu. No toto bolo skôr zúfalé gesto a neveril som, že to niečo zmení, čo sa aj potvrdilo.
Riešenie #
Napokon som bol vďačne schopný nájsť riešenie tohto bolestivého problému.
Použil som staršie LTS jadro z AUR balíčka
linux-lts54 momentálne
vo verzii 5.4.155 a nechal ho kompilovať cez noc.
Toto jadro, zdá sa, nijako nenarúša môj pracovný tok a elegantne rieši
problém s Bluetooth myšou. S týmto jadrom na ThinkPad T470 je dmesg úplne
čistý bez akýchkoľvek zjavných problémov, takže ho možno chvíľu nechám a
uvidím, ako to pôjde. Dúfam, že pomáha!
Odkazy #
- https://bugzilla.kernel.org/show_bug.cgi?id=209745
- https://bbs.archlinux.org/viewtopic.php?id=259954
- https://www.reddit.com/r/pop_os/comments/lcknuj/bluetooth_keeps_disconnecting/
- https://bugzilla.redhat.com/show_bug.cgi?id=1573562
- https://www.reddit.com/r/Fedora/comments/qair1l/mxmaster_3_doesnt_reconnect_after_suspend_have_to/