Bluetooth

Bluetooth is a standard for the short-range wireless interconnection of cellular phones, computers, and other electronic devices. In Linux, the canonical implementation of the Bluetooth protocol stack is BlueZ.

Related articles

Installation
  1. Install the bluez package, providing the Bluetooth protocol stack.
  2. Install the bluez-utils package, providing the bluetoothctl utility. Alternatively install bluez-utils-compatAUR to additionally have the deprecated BlueZ tools.
  3. The generic Bluetooth driver is the kernel module. Check whether that module is loaded. If it is not, then load the module.
  4. Start/enable .

Console
  • bluetuith — Provides a bluetooth manager via a Terminal User Interface for easier pairing and device/adapter management, with OBEX File Transfer and mouse support.
https://www.github.com/darkhz/bluetuith || bluetuithAUR
Tip: To automate bluetoothctl commands, use echo -e "command1\ncommand2\n" | bluetoothctl or bluetoothctl -- command.

Graphical

The following packages allow for a graphical interface to customize Bluetooth.

Pairing

This section describes directly configuring bluez5 via the bluetoothctl CLI, which might not be necessary if you are using an alternative front-end tool (such as GNOME Bluetooth).

The exact procedure depends on the devices involved and their input functionality. What follows is a general outline of pairing a device using bluetoothctl.

Start the bluetoothctl interactive command. Input to get a list of available commands.

  1. (optional) Select a default controller with .
  2. (optional) Enter to turn the power to the controller on if the device is set to off. It is on by default; see #Default adapter power state.
  3. Enter devices to get the MAC address of the device with which to pair.
  4. Enter device discovery mode with scan on command if device is not yet on the list.
  5. Turn the agent on with or choose a specific agent: if you press tab twice after you should see a list of available agents. A bluetooth agent is what manages the Bluetooth 'pairing code'. It can either respond to a 'pairing code' coming in, or can send one out. The should be appropriate in most cases.
  6. Enter to do the pairing (tab completion works).
  7. If using a device without a PIN, one may need to manually trust the device before it can reconnect successfully. Enter to do so.
  8. Enter to establish a connection.

An example session may look this way:

Dual boot pairing

To pair devices on dual boot setups you need to change the pairing keys on your Linux install so that they are consistent with what Windows or macOS is using.

This page only describes the manual method of doing so. To automate the process, see the bt-dualboot project and the related repositories.

Setup

To do this, first pair your device on your Arch Linux install. Then reboot into the other OS and pair the device. Now you need to extract the pairing keys, but first switch off the Bluetooth devices to prevent any connection attempts.

Extracting on Windows

First, boot into Windows.

The registry key containing the link keys may only be accessed by the SYSTEM account, which cannot be logged into. Therefore, you will need Microsoft's PsExec tool from the official Windows Sysinternals site in order to run as SYSTEM.

Download PsTools, and extract .

In an administrator instance of a command shell, from the location of the extracted EXE, launch the registry editor:

.\PsExec64.exe -s -i regedit.exe

In the registry editor, navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys

Within this key is a key for each Bluetooth adapter, by MAC address. If there are multiple keys, and you are unsure of which to use, follow this guide to find the MAC address for the desired Bluetooth adapter.

Within the desired device adapter key, there is a binary value for each paired device, by MAC address in the same way.

For each paired device that you wish to share between the installations, right click on the whole key and export it as a .reg file. This is a text file that you can copy the keys from.

Within this file, if there is a single binary key, then this is not a Bluetooth 5.1 device, and that paring key is all that is needed.

Otherwise, if there are several keys for the paired device such as or , then this is a BT5.1 device. Refer to #Preparing Bluetooth 5.1 Keys to see how to use them.

Finally, to import the key(s) into your Linux installation, reboot into Linux and proceed to #Finishing up.

Extracting on Linux

Reboot into Arch. Install . Mount your windows system drive.

$ cd /path/to/windows/system/Windows/System32/config
$ chntpw -e SYSTEM

Inside the chntpw environment, run 

> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys

or

> cd ControlSet00X\Services\BTHPORT\Parameters\Keys

Then get your Bluetooth adapter's MAC address and enter its folder

> ls
> cd your-device's-mac-address

Do the same for your paired devices. If this is not a Bluetooth 5.1 device, you will only see the pairing key:

If so, get your device's key through :

The "XX"s are the pairing key. Make note of which keys map to which MAC addresses.

If this is a Bluetooth 5.1 device, then you will see several keys corresponding to the one device.

Node has 0 subkeys and 8 values
  size     type              value name             [value if type DWORD]
    16  3 REG_BINARY         <LTK>
     4  4 REG_DWORD          <KeyLength>               16 [0x10]
     8  b REG_QWORD          <ERand>
     4  4 REG_DWORD          <EDIV>                 37520 [0x9290]
    16  3 REG_BINARY         <IRK>
     8  b REG_QWORD          <Address>
     4  4 REG_DWORD          <AddressType>              1 [0x1]
     4  4 REG_DWORD          <AuthReq>                 45 [0x2d]

Refer to #Preparing Bluetooth 5.1 Keys to see how to use these, using to obtain the requested values.

Finally, to import the key(s) into your Linux installation, proceed to #Finishing up.

For macOS

Boot into macOS:

  • For macOS Monterey or newer:
    1. Open Keychain Access and search for Bluetooth.
    2. Sort by date.
    3. If you've recently removed and reconnected the device then you can simply sort the keys by date modified and pick the latest. It is probably called MobileBluetooth (for older Bluetooth devices) or is just an UUID (for Bluetooth 5.1+).
    4. Double click on the entry. Check that the MAC address in the Account field matches the MAC address of your device.
    5. Click the "Show password" checkbox. You will now need to enter your password, twice.
    6. Copy the text in the password field, it's actually an XML file ( )
    7. Paste the text in in your home directory.
  • For High Sierra or newer, run the following in a terminal:
  • For Sierra or older, run the following in a terminal: 
    # defaults read /private/var/root/Library/Preferences/blued.plist LinkKeys > ~/bt_keys.txt

The file now contains the established Bluetooth keys. For older versions of macOS (High Sierra and older) you will have to reverse the keys before proceeding. For example, becomes .

Note: The reversal can be done with the following Python code: 
>>> Key="98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm}"
>>> Key=list(reversed(ERand.strip().split()))

If this is a Bluetooth 5.1 device, then there will be more than one key corresponding to one device. Refer to #Preparing Bluetooth 5.1 Keys to see how to use these.

Finally, to import the key(s) into your Linux installation, reboot into Linux and proceed to #Finishing up.

Preparing Bluetooth 5.1 Keys

If you observed the presence of Bluetooth 5.1 keys while following #For Windows or #For macOS, you must apply certain transformations to their values before importing them into Linux. Create the requested files with their appropriate contents, for installation in #Finishing up. This process will depend on the device, and some of the values have to be manipulated; code utilities for doing so are provided below.

DeviceSource Key and Transformations (Windows)Source Key and Transformations (macOS)Destination Key File
Logitech MX Master 3
  • Copy .
  • Remove the spaces between the hex octets.
  • Copy .
  • Remove the spaces between the hex octets.
 and
and should be 0 Random Number and Encrypted Diversifier should be 0.
ThinkPad TrackPoint Keyboard II and Pebble M350 mouse
  • Copy .
  • Reverse the order of the octets.
  • Copy Remote IRK.
  • Convert from base64 to hex.
  • Copy . Remove the spaces between the hexadecimal octets.
  • Copy Remote Encryption > Long-term Key.
  • Convert from base64 to hex.
 LongTermKey.Key
  • Copy .
  • Reverse the order of the octets.
  • Convert the whole number to decimal.
  • Copy Remote Encryption > Random Number.
  • Convert from base64 to hex.
  • Reverse the order of the octets.
  • Copy .
  • Reverse the order of the octets.
  • Convert the whole number to decimal.
  • Copy Remote Encryption > Encrypted Diversifier.
  • Convert from base64 to hex.
  • Reverse the order of the octets.
Other devices
  • Copy .
  • Remove the spaces between the hex octets.
  • Copy Remote IRK.
  • Convert from base64 to hex.
 LongTermKey.Key
  • Copy .
  • Reverse the order of the octets.
  • Convert the whole number to decimal.
  • Copy Remote Encryption > Long-term Key.
  • Convert from base64 to hex.
  • Copy .
  • Remove the spaces between the hex octets.
  • Copy Remote Encryption > Encrypted Diversifier.
  • Convert from base64 to hex.
  • Reverse the order of the octets.

For an example of the general case:

  • An of makes for a LongTermKey.Key of .
  • An of makes for a of .
  • An of 37520 makes for an of 37520.

Finishing up

Now that you have the keys change user to root, then continue with:

Here you will find folders for each paired Bluetooth device. For each device you want to pair with Arch and your dual boot, do the following:

Note: At this point, if you are using a device which increments its MAC address on pairing, you must move the MAC address directory to the incremented path. Either copy the MAC address from Windows, or increment it yourself while minding the fact that each octet is a two-digit hexadecimal number.

If you have a pairing key (i.e. this is not a Bluetooth 5.1 device), then edit the file and change the key under . E.g.:

If you have Bluetooth 5.1 keys, then you must instead copy the key files to the MAC address directory.

Then restart and (with pulseaudio -k && pulseaudio --start).

You should be able to connect to your device now.

Configuration

Default adapter power state

As of bluez 5.65, BlueZ' default behavior is to power on all Bluetooth adapters when starting the service or resuming from suspend.

If you would like the adapter to not be automatically enabled (e.g. on a portable device where you wish to save battery), set in in the [Policy] section:

The adapter can still be turned on manually by running as described in #Pairing.

Discoverable on startup

If the device should always be visible and directly connectable:

Wake from suspend

To allow Bluetooth keyboards, mice, etc. to wake the system from suspend. First, check the bios settings and make sure that wake from USB is not disabled. In many cases, Bluetooth from the motherboard is a USB device.

Find the vendor code and device ID for the Bluetooth adapter.

Add a new udev rule for the vendor code and device ID to enable wake from suspend.

To automatically re-configure your Bluetooth keyboard after wakeups to e.g. have a different keymap or key press repeat rate (for details, see Xorg/Keyboard configuration#Adjusting typematic delay and rate and xmodmap), create an executable script.

Then create an additional udev rule like above.

/etc/udev/rules.d/92-keyboard-reconfiguration-wakeup.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/''your''/''path''/''to''/configure_keyboard.sh"

Enabling experimental features

The Bluez stack keeps new, potentially buggy features behind the D-Bus experimental and kernel experimental options. The functionality included under these varies over time, as experimental features are determined to be stable and no longer require the option. To enable these, uncomment the corresponding line in the configuration:

Alternatively, you can edit the to add the or flag, like this drop-in file:

Either way, you must then restart the .

Audio

You will typically need to take an additional step to integrate the audio server with Bluetooth. This is detailed in the below sections.

See the Bluetooth headset page for more information about Bluetooth audio and Bluetooth headsets.

PulseAudio

In order to be able to use audio equipment like Bluetooth headphones or speakers, you need to install the additional package. Make sure to restart pulseaudio to make the installation take effect: . With a default PulseAudio installation you should immediately be able to stream audio from a Bluetooth device to your speakers.

If you have a system-wide PulseAudio setup make sure the user running the daemon (usually pulse) is in the group and you load the Bluetooth modules in your PulseAudio config:

Optionally, add load-module module-switch-on-connect if you want to auto-switch all audio to the Bluetooth device.

PipeWire

PipeWire as of v0.3.19 enables its Bluetooth support by default.

ALSA

First, ensure that your Bluetooth audio device is correctly paired and connected to the system.

Then, install , start (and enable) the service, and add your user to the group.

Run the following command to check if everything is working as intended (replace and below):

$ aplay -D bluealsa:SRV=org.bluealsa,DEV=XX:XX:XX:XX:XX:XX,PROFILE=a2dp FILE.wav

Finally, add the following lines to your :

~/.asoundrc
defaults.bluealsa {
    service "org.bluealsa"
    device "XX:XX:XX:XX:XX:XX"
    profile "a2dp"
}

You can now use the device to reach your Bluetooth audio device. Volume management is conducted normally via with the option .

Bluetooth serial

To get Bluetooth serial communication working on Bluetooth-to-Serial modules (HC-05, HC-06) do the following steps:

Pair your Bluetooth device using bluetoothctl as described above.

Install bluez-utils-compatAUR, as it provides certain functionality which is missing from newer tools.

Bind paired device MAC address to tty terminal:

# rfcomm bind rfcomm0 MAC_address_of_Bluetooth_device

Now you can open /dev/rfcomm0 for serial communication:

$ picocom /dev/rfcomm0 -b 115200

Troubleshooting

Debugging

In order to debug, first stop .

And then start it with the parameter:

# /usr/lib/bluetooth/bluetoothd -n -d

Another option is via the tool.

Deprecated BlueZ tools

Eight BlueZ tools were deprecated and removed from bluez-utils, although not all of them were superseded by newer tools. The bluez-utils-compatAUR package provides an alternative version of bluez-utils with the deprecated tools.

Deprecated tool Most likely replacement
gatttoolbtgatt-client, D-Bus Gatt API
hciattachbtattach
hciconfigbtmgmt (and bluetoothctl?)
hcidumpbtmon (and btsnoop)
hcitoolmissing, D-Bus Device API available
rfcomm missing, implement with D-Bus Profile1 API?
ciptool
sdptool missing, functionality seems to be scattered over different D-Bus objects: Profile, Advertising, and the UUIDs arrays in device and adapter.

gnome-bluetooth

If you see this when trying to enable receiving files in bluetooth-properties:

Bluetooth OBEX start failed: Invalid path
Bluetooth FTP start failed: Invalid path

Then make sure that the XDG user directories exist.

Bluetooth USB dongle

If you are using a USB dongle, you should check that your Bluetooth dongle is recognized. You can do that by running as root when you have plugged in the USB dongle (or inspecting ). It should look something like the following (look out for hci):

If you only get the first two lines, you may see that it found the device but you need to bring it up. Example:

Or

To verify that the device was detected you can use btmgmt which is part of the . You can get a list of available devices and their identifiers and their MAC address by issuing:

It is possible to check the Bluetooth version as mapped to the HCI version according to the table in the official specification. For example, in the previous output, HCI version 6 is Bluetooth version 4.0.

More detailed information about the device can be retrieved by using the deprecated . (bluez-utils-compatAUR)

Audio devices start to skip at short distance from dongle

If other devices share the same USB host, they can interrupt communication with audio devices. Make sure it is the only device attached to its bus. For example:

$ lsusb
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 048d:1345 Integrated Technology Express, Inc. Multi Cardreader
Bus 001 Device 003: ID 0424:a700 Standard Microsystems Corp. 2 Port Hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

CSR dongle 0a12:0001

The device has a regression bug, and currently only works in the kernel version 5.17 and < 6.0. For more information, see Kernel Bug 60824.

Logitech Bluetooth USB dongle

There are Logitech dongles (ex. Logitech MX5000) that can work in two modes: Embedded and HCI. In embedded mode dongle emulates a USB device so it seems to your PC that you are using a normal USB mouse/keyoard.

If you hold the little red Button on the USB BT mini-receiver it will enable the other mode. Hold the red button on the BT dongle and plug it into the computer, and after 3-5 seconds of holding the button, the Bluetooth icon will appear in the system tray. Discussion

Alternatively, you can install the package. When you connect your Logitech dongle it will automatically switch.

hcitool scan: Device not found
  • On some laptops (e.g. Dell Studio 15, Lenovo Thinkpad X1) you have to switch the Bluetooth mode from HID to HCI. Install the package, then udev should do this automatically. Alternatively, you can run this command to switch to HCI manually:
# /usr/lib/udev/hid2hci
  • If the device will not show up and you have a Windows operating system on your machine, try booting it and enable the Bluetooth adapter from windows.
  • Sometimes also this simple command helps:
# bluetoothctl power on

bluetoothctl: No default controller available

There is a bug with some motherboard bluetooth controllers. To see if this might be the issue, run . If there are entries like "command tx timeout" or "Reading Intel version command failed", then power off your pc and physically unplug the power cable for a few seconds. This forces the controller to reload the firmware (while a standard reboot will not). See bug report here.

Make sure the device is not being blocked by rfkill.

It might also happen with some intel cards (such as the 8260) to not be picked up correctly by the Bluetooth service. In some cases, using the deprecated bluez-utils-compatAUR in lieu of bluez-utils have reportedly fixed the issue.

This might also be caused by power saving measures, in which case adding the kernel parameter is a potential solution. See also Red Hat Bugzilla – Bug 1573562.

Sometimes unloading and loading without options helps to get the controller back:

# modprobe -r btusb
# modprobe btusb

It may occur also when the dongle is a CSR clone

systemd: Condition check resulted in Bluetooth service being skipped

 
only requires the directory /sys/class/bluetooth to exist, which should be created by kernel module , which is only autoloaded by  if it actually finds a working Bluetooth hardware device.

If your /sys/class/bluetooth does not exist, check if your kernel Bluetooth module is loaded by . If not, and you believe you have a Bluetooth device, you can try manually starting them by loading the Bluetooth module and restarting .

You should also load your corresponding kernel Bluetooth driver when loading the module, most likely , but can also be etc.

Check 's unit status to see whether it started.

See also Debian Bug report logs - #853207.

If started successfully, but there is chance that you still cannot use Bluetooth normally (e.g. bluetoothctl says something like when you scan on). If this happens, try rebooting your computer, and double-check: whether directory /sys/class/bluetooth exists; whether includes correct Bluetooth modules; log messages in the journal; etc. should pickup your Bluetooth hardware automatically without manual changes again.

rfkill unblock: Do not unblock

If your device still soft blocked and you run ConnMan, try this:

$ connmanctl enable bluetooth

Computer is not visible

Enable discoverable mode if your computer cannot be discovered from your phone:

# bluetoothctl discoverable on

Verify that discoverable mode is on:

Note: Check DiscoverableTimeout and PairableTimeout in /etc/bluetooth/main.conf.

If the computer still does not show up, try changing the device class in as follows:

# Default device class. Only the major and minor device class bits are
# considered.
#Class = 0x000100 # Computer Type (from default config)
Class = 0x100100 # (Object-Transfer Service & Computer Type)

A user reported that this was the only solution to make their computer visible for their phone. LG TVs (and some others) are discoverable from their audio devices, so using (the soundbar class) will make such devices appear.

See https://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html to generate Bluetooth device/service classes.

Foxconn / Hon Hai / Lite-On Broadcom device

Some of these devices require the firmware to be flashed into the device at boot. The firmware is not provided but can converted from a Microsoft Windows .hex file into a .hcd using hex2hcd (which is installed with bluez-utils).

In order to get the right .hex file, try searching the device vendor:product code obtained with lsusb, for example:

...
Bus 002 Device 004: ID 04ca:2006 Lite-On Technology Corp. Broadcom BCM43142A0 Bluetooth Device
...

or

Bus 004 Device 004: Id 0489:e031 Foxconn / Hon Hai

Alternatively, boot into Windows (a virtual machine installation will suffice) and get the firmware name from the Device Manager utility. If you want to know the model of your device but cannot see it in lsusb, you might see it in lsusb -v as .

The .hex file can be extracted from the downloaded Windows driver without having to run Windows for it. Download the right driver, for example Bluetooth Widcomm (listed among the drivers for Lifebook P771[dead link 2022-09-17 ⓘ]), which contains the drivers for many Broadcomm devices. In case of Bluetooth Widcomm, the driver is a self-extracting RAR archive, so it can be extracted using x. To find out which of the many .hex files is the right one for you, look in the file and search for , where should be replaced with the product code (the second hex number in lsusb) of your device in upper-case. Underneath you should see the file name of the right .hex file.

Once you have the .hcd file, copy it into - this filename is suggested by dmesg and it may change in your case so check your dmesg output in order to verify. Then reload the btusb module:

# rmmod btusb
# modprobe btusb

The device should now be available. See BBS#162688 for information on making these changes persistent.

Intel combined WiFi and Bluetooth cards

See Wireless network configuration#Bluetooth coexistence.

Device connects, then disconnects after a few moments

If you see messages like the following in the journal, and your device fails to connect or disconnects shortly after connecting:

bluetoothd: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)
bluetoothd: connect error: Connection refused (111)

This may be because you have already paired the device with another operating system using the same Bluetooth adapter (e.g., dual-booting). Some devices cannot handle multiple pairings associated with the same MAC address (i.e., Bluetooth adapters). Follow instructions on #Dual boot pairing for solving this issue.

Device does not show up in scan

Some devices using Bluetooth low energy do not appear when scanning with bluetoothctl, for example the Logitech MX Master. The simplest way I have found to connect them is by installing , then start and do:

In another terminal:

# hcitool lescan

Wait until your device shows up, then Ctrl+c hcitool. bluetoothctl should now see your device and pair normally.

If incoming file transfers fail on an an otherwise functional Bluetooth connection, the problem may be due to symlinks in your file transfer path. Logs like this would appear in the journal:

Jun 18 11:18:13 ember obexd[3338969]: open(/home/me/.cache/obexd/MOC740): Operation not permitted (1)

If the path shown in the error message contains a symlink, then obexd by default will not accept it. The behavior can be overridden on initialization using a drop-in file for the user service:

Then reload the systemd manager configuration of the calling user and restart the user unit.

Interference between Headphones and Mouse

If you experience audio stuttering while using a Bluetooth mouse and keyboard simultaneously, you can try the following as referenced in #23 https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/424215

# hciconfig hci0 lm ACCEPT,MASTER
# hciconfig hci0 lp HOLD,SNIFF,PARK

Bluetooth mouse laggy movements

Try to edit the file (XX:XX:XX:XX:XX:XX - your Bluetooth adapter MAC address, - your mouse MAC address) and add these lines:

[ConnectionParameters]
MinInterval=6
MaxInterval=9
Latency=44
Timeout=216

You can see your local adapter MAC address by running the command . You can see the MAC addresses of currently connected remote devices by running the command .

Adapter disappears after suspend/resume

First, find vendor and product ID of the adapter. For example:

In this case, the vendor ID is 8087 and the product ID is 0025.

Then, use to reset the adapter:

# usb_modeswitch -R -v vendor_ID -p product_ID

Problems with all BLE devices on kernel 5.9+

Starting with v5.9, the kernel Bluetooth stack tries to use link-layer privacy on BLE connections. If the device works after pairing but does not survive a reboot or suspend, it is probably because of this.

To workaround this issue, open /var/lib/bluetooth/adapter_mac/device_mac/info, remove the following lines, and restart :

See the relevant discussion on the Arch forum.

Bluetooth immediately waking up suspend-to-idle devices

On systems capable of suspend-to-idle/S2idle/S0ix/Modern Standby, Bluetooth controllers will stay enabled during sleep. This will usually cause the system to wake up immediately after going to sleep if any Bluetooth device is connected.

To prevent this, you can disable Bluetooth completely before going to sleep - install bluez-utils and create this file:

Enable this service and check if Bluetooth devices disconnect when going to sleep, and whenever Bluetooth goes back up after waking up the system.

If this workaround is in use, waking up the system with a Bluetooth mouse/keyboard will not work.

Use the settings below:

/etc/bluetooth/main.conf
...
[General
JustWorksRepairing = always
FastConnectable = true
Class = 0x000100
...
[GATT]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true
...

Then restart the .

You can see relevant discussion on xpadneo but the xpadneo driver is not needed.

Mediatek MT7921 or MT7961 on dual boot with windows

On dual boot systems, if Bluetooth firmware versions are different for Windows and Linux, the Bluetooth adapter is not working after rebooting to Windows.

The best way to prevent this is updating the Bluetooth drivers (especially firmware) with latest version for each OS.

If you cannot find the latest version driver (or firmware) for Windows, you can copy the latest firmware file from Arch Linux and extract to Windows (e.g. , you can find the firmware file path in the device manager on Windows).

gollark: ... seriously? That's very dodecahedral of them.
gollark: OR DID YOU?
gollark: Probably better to make basic features work first.
gollark: Also, it may still leak if you look at it weirdly.
gollark: fixed leaks but it now weighs 5 times more somehow

See also
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.