So shutting it down and unplugging it and holding down the power button for 30 seconds and then plugging back in and restarting didn’t work as it did for @lemone?
Are you dual booting with Windows? Make sure fast startup up feature in Windows power management is disabled.
No windows here. And unfortunately no, it didn’t.
Edit Wifi works without issues
I don’t think what you’ve linked here is a solution. Rather the problem seems to be that we don’t have the proper firmware for the device yet. I’ve been using the latest 6.5-rc1 kernel and still see the issue that OP sees (I have an Acer Swift Edge 16 with this device). We may just have to wait for the proper firmware/drivers to be introduced.
Certainly that’s a possibility. But i provided information i found that is relevant. It’s not necessarily going to work for everyone’s hardware. It’s just something to try. I also don’t have faith in some hardware manufacturers as everything they build is intended for Windows.
So since I had some time today, I figured I’d dig into why this was happening on my system. So on my system I was getting the following error when it attempted to load the bluetooth device:
Bluetooth: hci0: Opcode 0x c03 failed: -110
It looks like in my case all that was needed was to add support of my device into the btusb kernel module. Here’s what I had to do:
lsusb. It came back with this (note that, at least for my device, Foxconn / Hon Hai Wireless Device is a subsystem of the MediaTek MT7922):Bus 001 Device 003: ID 0489:e102 Foxconn / Hon Hai Wireless_Device
drivers/bluetooth/btusb.c in the kernel source, I noticed that the Product ID (in my case e102) was missing from the file, so I made the following additions to the file:+++ b/drivers/bluetooth/btusb.c
@@ -628,6 +628,9 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0489, 0xe0f2), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH |
BTUSB_VALID_LE_STATES },
+ { USB_DEVICE(0x0489, 0xe102), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH |
+ BTUSB_VALID_LE_STATES },
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
If you notice, there are entries in this file that require both the Vendor and Product ID. It looks like there are plenty of entries for the Vendor (0x0489), but I didn’t see my Product ID represented (0xe102 which corresponds to e102 in my device).
I suppose I can make a report against this, but not sure how to proceed. Different laptops/machines may have different Product IDs, so maybe there needs to be a list compiled of all the missing ones for this device.
In any case I hope that helps someone. And before someone asks, yes I tested bluetooth functionality with a 8bitdo controller and it worked just fine.
I have wondered if there was a way to do this with just a module parameter, seems like quite a few USB devices are this easy to get working, or old devices have been updated without changing the ids and just need to change the ie UAS/UASP is a minefield and the usbquirks system seems flexible.
Maybe if you can isolate the change in a way that dkms can support you will get automated updates when you update the kernel assuming binary kernel downloads, if you are manually building anyway not much point.
Dkms would be generally more distributable and might be more generally applicable to more kernel versions and help more people until more generally available. Ie probably/maybe it works for lts kernel too.
Sounds like an aur really. Pull the relevant files from kernel.org for version, patch driver file, setup dkms. Or maybe dkms can do it all. Not familiar enough with either aur/pkgbuild or dkms.
You may have been able to do it another way. But I’m not 100% sure without testing this.
sudo -i
modprobe -r bluetooth
modprobe btusb
echo "0489 e102" >> /sys/bus/usb/drivers/btusb/new_id
modprobe bluetooth
Good idea, but seems like would need the flags too, but maybe usbquirks would work then? Avoiding arbitrary kernel building is almost always a good idea.
Even though OP has a solution, it would be interesting to know if it can be worked around.
Starting from a cold boot. It would be worth trying as I am just picking up on info here and there.
https://unix.stackexchange.com/questions/67936/attaching-usb-serial-device-with-custom-pid-to-ttyusb0-on-embedded this seems to have a range of options some with new_id / remove_id, some with bind.
Don’t think it addresses the flags options though.
I was trying to submit a PR against the kernel source for adding my Product ID (never done this before, so has been a learning experience): https://lkml.org/lkml/2023/7/16/351
However, I got an auto-reply from bluez.test.bot saying the following:
error: patch failed: drivers/bluetooth/btusb.c:628
error: drivers/bluetooth/btusb.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
I guess submitting this is going to be an uphill battle. Not sure what the bot is doing differently to cause the patch to fail.
I’ve never been down that road either. Good luck. Probably relatively simple when you figure out exactly what is required.
Still, beats diff -c & patch, SCCS, RCS, SVN .
I wonder exactly which tree you need to patch against? Do they have a BT tree they use, which is slightly different / more advanced from the torvalds tree?
Did you try it by my suggestion rather than trying to get into modifying the and rebuilding kernels.
I did - but I didn’t have time to explore it much. The first error I got was that the bluetooth module was in use when doing the modprobe -r bluetooth (it wouldn’t allow me to remove it), even after stopping the bluetooth service and removing the mt7921e module. I did this on the standard kernel where bluetooth doesn’t work on my device, not the 6.5.0-rc1/2 one.
I was doing this against the master branch per some instructions I read online. In my research I didn’t see anything mentioned about patching against a particular tree/branch.
I don’t know anything for certain, but am used to seeintg maintainers accepting patch for xxxx-next tree, which I assume they build, and then generate patches again the torvalds tree.
If the BT have a a tree then I guess it would make sense they would test against it, however if the lkml is generic, then seems like torvalds would probably work.
Maybe it desn’t work because you added to the end or the MediaTech, and they already have another one there at the moment, and the patch doesn’t match any more?
It’s very difficult to search but I did find this https://lkml.org/lkml/2023/7/7/115 - it looks like e102 was already added based on the logs in this submission. I’ll have to dig into kernel sources later today to see what they are building against.
EDIT: They must be building against this. Just wonder how this eventually gets merged into the 6.5 sources. The last merge was 3ish weeks ago so maybe there’s some sort of unannounced cadence. In any case it looks like support is slowly building for this device.
Not sure what /how you were searching. searching for
mediatek 0x0489 0xe102
gave me an immediate hit. Manually searching lkml would have been a nightmare if you did that.
Yes, bluetooth-next sounds like the kind of thing I see in LWN updates.
3 weeks ago was probably the end of the 6.4 window?
6.5 is open to some extent since you are seeing -rc releases.
I guess they collect patches until it is consistent enough and worth the effort to generate the PR.
So the good news is you don’t have to go thru the process, the bad news is you don’t get your name up in lights, or at least very small lights in the footnotes : - )
Good news for everybody is device will hit the kernel trees eventually. Unlikely for me for a while as I usually stick to LTS unless I really really need something, and it has been a long long time since I last did a kernel compile. And I don’t have the device, so don’t need to worry for a while, but I was thinking about the MT WiFi devices when I upgrade from 802.11n maybe this year.
Yep I searched the “hard” way. 
I don’t think it’s time lost as I still learned quite a bit over the past day. Fun stuff.