Realtek Bluetooth USB adapter coreelec20 N2+

I have gotten a bluetooth usb that is startech. It’s actually a rebranded realtek.

I have tested the usb as working under archlinux where it loads rtl8761bu

Coreelec20 loads rtl8761b. It seems the u denotes the USB version of this chip. So it’s loading a version of this driver for mobo chipsets.

I can actually pair and connect the controller with the bluetooth dongle within coreelec, but it just vibrates endlessly and doesnt send any input.

I know the controller input type is fine because it works wired with usbc, and I know the dongle is good because it works fine under archlinux. So its just a matter of getting rtl8761bu loaded on coreelec

So I guess the question is, how can I get rtl8761bu drivers and load them, or tell corelec to load that version if it already has them

update : I’ve found out the firmware it needs is already there, the question is how do I load bu instead of b.

I was just going to delete b and leave a symlink to bu in it’s place but the filesystem there is readonly and cant be remounted with

mount -o remount,rw /

CoreELEC:/usr/lib/kernel-overlays/base/lib/firmware/rtl_bt # ls | grep rtl8761b
rtl8761b_config.bin
rtl8761b_fw.bin
rtl8761bu_config.bin
rtl8761bu_fw.bin

ideas?

For start which device exactly is this?

lsusb | paste

http://ix.io/4jda

Realtek Semiconductor Corp. Bluetooth Radio

when i check dmesg for which firmware is loaded on the working vs nonworking the difference seems to be rtl8761b(semi-working) vs rtl8761bu(working)

coreelec has both these firmwares but loads the semi-working one

Can you also post dmesg after fresh reboot?

dmesg | paste

Here you go
http://ix.io/4jdr

and the section of note

[ 3.579772@3]- Bluetooth: HCI device and connection manager initialized
[ 3.579780@3]- Bluetooth: HCI socket layer initialized
[ 3.579785@3]- Bluetooth: L2CAP socket layer initialized
[ 3.579805@3]- Bluetooth: SCO socket layer initialized
[ 3.596619@5]- usbcore: registered new interface driver btusb
> [ 3.614160@4]- Bluetooth: hci0: rtl: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
> [ 3.614167@4]- Bluetooth: hci0: rtl: loading rtl_bt/rtl8761b_config.bin
> [ 3.622213@5]- Bluetooth: hci0: rtl: loading rtl_bt/rtl8761b_fw.bin
[ 3.623658@4]- Bluetooth: hci0: rom_version status=0 version=1
[ 3.623688@4]- Bluetooth: cfg_sz 25, total size 23485

compared to arch where it is working properly

[11631.703144] usb 1-1.5: new full-speed USB device number 4 using ehci-pci
[11631.801641] usb 1-1.5: New USB device found, idVendor=0bda, idProduct=8771, bcdDevice= 2.00
[11631.801657] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[11631.801663] usb 1-1.5: Product: Bluetooth Radio
[11631.801667] usb 1-1.5: Manufacturer: Realtek
[11631.801671] usb 1-1.5: SerialNumber: 00E04C239987
[11631.865540] Bluetooth: Core ver 2.22
[11631.865568] NET: Registered PF_BLUETOOTH protocol family
[11631.865569] Bluetooth: HCI device and connection manager initialized
[11631.865582] Bluetooth: HCI socket layer initialized
[11631.865584] Bluetooth: L2CAP socket layer initialized
[11631.865586] Bluetooth: SCO socket layer initialized
[11631.890022] usbcore: registered new interface driver btusb
> [11631.890918] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[11631.891919] Bluetooth: hci0: RTL: rom_version status=0 version=1
> [11631.891923] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
> [11631.899145] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[11631.900151] Bluetooth: hci0: RTL: cfg_sz 6, total sz 27814
[11631.958111] audit: type=1130 audit(1671641610.046:446): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=systemd-rfkill comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[11632.053029] Bluetooth: hci0: RTL: fw version 0x09a98a6b

For a quick test you can try this

mkdir -p /storage/.config/firmware/rtl_bt
cp /usr/lib/kernel-overlays/base/lib/firmware/rtl_bt/rtl8761bu_config.bin /storage/.config/firmware/rtl_bt/rtl8761b_config.bin
cp /usr/lib/kernel-overlays/base/lib/firmware/rtl_bt/rtl8761bu_fw.bin     /storage/.config/firmware/rtl_bt/rtl8761b_fw.bin
reboot

That didnt seem to work, It just endlessly vibrates and doesnt send any input after pairing like before

Im not sure what the deal is now, if it actually loaded the rtl8761bu firmware instead of the rtl8761b

It did because b files were overwritten by bu. But looks like it doesn’t work.

Yeah im not sure why,

I plugged the controller up by USB to coreelec and the input profile works fine and the controller works as intended, so I cant isolate the problem down to the input profiles or some kind of controller config

I also cant isolate the problem down to the firmware/drivers either now.

I dont know why it does this

Which linux version runs on arch? Can you post whole dmesg from there?

[christopher@arch ~]$ uname -a
Linux arch 6.0.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 08 Dec 2022 11:03:38 +0000 x86_64 GNU/Linux

here is the dmesg from usb dongle plugin to successful working connection from the arch machine

[12779.606265] usb 1-1.6: new full-speed USB device number 6 using ehci-pci
[12779.704805] usb 1-1.6: New USB device found, idVendor=0bda, idProduct=8771, bcdDevice= 2.00
[12779.704820] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12779.704826] usb 1-1.6: Product: Bluetooth Radio
[12779.704830] usb 1-1.6: Manufacturer: Realtek
[12779.704834] usb 1-1.6: SerialNumber: 00E04C239987
[12779.707410] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[12779.708252] Bluetooth: hci0: RTL: rom_version status=0 version=1
[12779.708265] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
[12779.717275] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[12779.718059] Bluetooth: hci0: RTL: cfg_sz 6, total sz 27814
[12779.876256] Bluetooth: hci0: RTL: fw version 0x09a98a6b
[12779.944572] Bluetooth: MGMT ver 1.22
[12967.060382] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[12967.060388] Bluetooth: HIDP socket layer initialized
[12967.347974] hid-generic 0005:045E:02E0.0005: unknown main item tag 0x0
[12967.348062] input: 8BitDo Pro 2 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/bluetooth/hci0/hci0:2/0005:045E:02E0.0005/input/input18
[12967.348265] hid-generic 0005:045E:02E0.0005: input,hidraw4: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on e8:ea:6a:8c:0a:cd
[12967.433165] microsoft 0005:045E:02E0.0005: unknown main item tag 0x0
[12967.433252] input: 8BitDo Pro 2 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/bluetooth/hci0/hci0:2/0005:045E:02E0.0005/input/input19
[12967.433481] microsoft 0005:045E:02E0.0005: input,hidraw4: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on e8:ea:6a:8c:0a:cd

here is the bluetooth connection but not working properly from coreelec

[ 912.151183@3]- usb 1-1.4: New USB device found, idVendor=0bda, idProduct=8771
[ 912.151185@3]- usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 912.151187@3]- usb 1-1.4: Product: Bluetooth Radio
[ 912.151189@3]- usb 1-1.4: Manufacturer: Realtek
[ 912.151190@3]- usb 1-1.4: SerialNumber: 00E04C239987
[ 912.171681@0]- Bluetooth: hci0: rtl: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[ 912.171689@0]- Bluetooth: hci0: rtl: loading rtl_bt/rtl8761b_config.bin
[ 912.171797@0]- Bluetooth: hci0: rtl: loading rtl_bt/rtl8761b_fw.bin
[ 912.172645@0]- Bluetooth: hci0: rom_version status=0 version=1
[ 912.172692@0]- Bluetooth: cfg_sz 6, total size 27814
[ 934.809278@0]- xpadneo 0005:045E:02E0.0005: unknown main item tag 0x0
[ 934.809432@0]- input: 8BitDo Pro 2 as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:2/0005:045E:02E0.0005/input/input7
[ 934.814558@0]- xpadneo 0005:045E:02E0.0005: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on e8:ea:6a:8c:0a:cd
[ 934.818034@1]- xpadneo udev: 0005:045E:02E0.0005
[ 934.822920@1]- xpadneo udev: ok

and here is properly working usbC

[ 1156.891482@3]- usb 1-1.4: New USB device found, idVendor=045e, idProduct=028e
[ 1156.891485@3]- usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1156.891487@3]- usb 1-1.4: Product: 8BitDo Pro 2
[ 1156.891489@3]- usb 1-1.4: Manufacturer: 8BitDo
[ 1156.891490@3]- usb 1-1.4: SerialNumber: 000000000003
[ 1156.901715@3]- usb 1-1.4: Unsupported device
[ 1156.901784@3]- usb 1-1.4: Unsupported device
[ 1156.901849@3]- usb 1-1.4: Unsupported device
[ 1156.902220@3]- usb 1-1.4: Unsupported device
[ 1156.919867@4]- input: Microsoft X-Box 360 pad as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/1-1.4:1.0/input/input8
[ 1156.921402@2]- usbcore: registered new interface driver xpad
[ 1157.377347@2]d meson6-dwmac ff3f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

It does look like it’s using two different profiles for USBC vs bluetooth

maybe its something wrong with whatever xpadneo is

Another quick test: 240.55 MB file on MEGA

after update

dmesg | paste

that seemed to result in the same behavior

http://ix.io/4jdK

Then I don’t know what to do for now.

this may be an xpadneo problem

I worked on this some more.

After realizing there is pretty much no reason this X-input needs needs to work with xpadneo,but can be picked up by many other drivers,I tried to stop it from loading and grabbing the device. hid_xpadneo is called by a udev rule that exists in an uneditable folder, so i cant simply remove it or symlink around it

Blacklisting the module in modprobe did not seem to work.

CoreELEC:~ # lsmod | grep xpad
hid_xpadneo 20480 0
CoreELEC:~ # cat /etc/modprobe.d/xpadneo.conf
blacklist hid_xpadneo
CoreELEC:~ # dmesg | tail -n 6
[ 154.007985@0]- xpadneo udev: 0005:045E:02E0.0003
[ 154.016161@0]- xpadneo: hello there!
[ 154.016788@0]- xpadneo 0005:045E:02E0.0003: unknown main item tag 0x0
[ 154.017311@0]- input: 8BitDo Pro 2 as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:11/0005:045E:02E0.0003/input/input5
[ 154.018270@1]- xpadneo 0005:045E:02E0.0003: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on 00:19:0e:17:56:de
[ 155.010531@4]- xpadneo udev: ok

Without rebuilding coreelec and removing the udev rule I cant have this work in xbox controller mode. Xpadneo only exists in a few places in the build folders, in a kernel patch, and in a udevrule that calls it. I may just be waiting on an upstream fix and for that to work its way down into coreelec over time.

Because the controller has 4 modes

Switch, macOS, X-input (Windows), and D-input (Android)

I tried different modes. Switch seems to work but I still need to test it with moonlight and steam controller profiles. X-input(windows) is the xpadneo driver that doesnt work, but is also going to be the most widely supported mode with other things.

Here is dmesg documenting the loading of drivers for nintendo switch mode

[ 619.903871@1]- hid-generic 0005:057E:2009.0004: unknown main item tag 0x0
[ 619.904105@1]- input: Pro Controller as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:11/0005:057E:2009.0004/input/input6
[ 619.905468@1]- hid-generic 0005:057E:2009.0004: input,hidraw2: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on 00:19:0e:17:56:de

Udev rule can be overwritten by putting same file in folder /storage/.config/udev.rules.d copied from /usr.

To blacklist module add it to /storage/.config/modprobe.d/blacklist.conf (file with .conf extension).

copying the udev rule wont do me much good because the udev rule is what grabs the device and starts the xpadneo driver. Maybe I could edit the file and have it just not start the xpadneodriver and see what happens

copying the blacklisted module into /storage didnt seem to have an effect

CoreELEC:~/.config/modprobe.d # realpath blacklist.conf
/storage/.config/modprobe.d/blacklist.conf
CoreELEC:~/.config/modprobe.d # cat blacklist.conf
blacklist hid_xpadneo
CoreELEC:~/.config/modprobe.d # lsmod | grep xpad
hid_xpadneo 20480 0
CoreELEC:~/.config/modprobe.d #

Its not a big deal, letting it think the controller is a nintendo switch controller instead of an xbox controller allows it to work properly for my purposes. Steam and moonlight seem to know how to deal with it

Seems blacklist is not working because module is loaded from udev rule by modprobe.

That’s why you need to adjust the copied udev rule in /storage. It’s the 99-xpadneo.rules file right?
Try changing RUN= line with something like

RUN:="/bin/sh -c 'echo skip xpadneo udev: $kernel > /dev/kmsg"

and this will not load module anymore.