Bug 513103
| Summary: | Bluetooth not working on Dell Studion XPS 16 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rodd Clarkson <rodd> |
| Component: | bluez | Assignee: | Bastien Nocera <bnocera> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | bnocera, dwmw2, marcel, plautrba |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 4.42-9.fc11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-06 00:07:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Rodd Clarkson
2009-07-21 23:41:27 UTC
The behaviour is completely correct. You'll need to enable hid2hci in /etc/sysconfig/bluetooth and it will be run on each boot (make sure the bluetooth service is enabled, which it is by default). I don't get it. Doesn't this leave bluetooth less than useful unless someone knows to hack a file by hand. At the very least there should be some sort of comment about this somewhere, or better a switch to enable this in the application. Also, I enabled the two options in /etc/sysconfig/bluetooth and suspend resume stopped working. Commenting out the two lines and then rebooting fixes things and suspend and resume works again. (In reply to comment #2) > I don't get it. Doesn't this leave bluetooth less than useful unless someone > knows to hack a file by hand. Welcome to Linux. > At the very least there should be some sort of comment about this somewhere, or > better a switch to enable this in the application. I won't add any sort of hacks for those devices. The situation in this particular case hasn't changed since the very first release of bluez (or bluez-utils) containing hid2hci. If we had documentation for those devices and were able to read link keys off of them, then we'd enable the Bluetooth support all the time (the same way MacOS X does on Apple machines). But we don't. As for your suspend problems, file bugs against the kernel, they're unlikely to be related to hid2hci. (In reply to comment #4) > (In reply to comment #2) > > I don't get it. Doesn't this leave bluetooth less than useful unless someone > > knows to hack a file by hand. > > Welcome to Linux. It's a bit late for welcomes ;-] I've been using Linux since 1997 so I'm quite used to hacking on text files. But I thought the whole point of Linux moving forward is that I shouldn't have too. Things should just work, and that config options like this should be accessible without using sudo vi. > > At the very least there should be some sort of comment about this somewhere, or > > better a switch to enable this in the application. > > I won't add any sort of hacks for those devices. The situation in this > particular case hasn't changed since the very first release of bluez (or > bluez-utils) containing hid2hci. > > If we had documentation for those devices and were able to read link keys off > of them, then we'd enable the Bluetooth support all the time (the same way > MacOS X does on Apple machines). But we don't. But my bluetooth device works fine (as far as I can tell, and with the exception of suspend issues) once hid2hci is enabled. I'm able to sync with my Palm for example. > As for your suspend problems, file bugs against the kernel, they're unlikely to > be related to hid2hci. I've filed a bug against the kernel, but if I run hid2hdi then suspend resume fails, and if I don't then it works. Of course, if don't then bluetooth doesn't work. Arggghhhh! One hack to work around the suspend problem is running 'hid2hci --tohid' before suspend, and running hid2hci again on resume (although the latter may well be happening anyway since the device has been reset). <snip>
> But my bluetooth device works fine (as far as I can tell, and with the
> exception of suspend issues) once hid2hci is enabled. I'm able to sync with my
> Palm for example.
Except that we can't detect whether the device is within a laptop, or a desktop, and on a desktop you'd just have lost your mouse and keyboard.
You do know if you have a keyboard/mouse other than the ones on the HID device in question. And we _could_ give the user some easier way to choose, other than having to edit files manually. (In reply to comment #8) > You do know if you have a keyboard/mouse other than the ones on the HID device > in question. And we _could_ give the user some easier way to choose, other than > having to edit files manually. We could enable the switching regardless when we have a pairing assistant (as available in MacOS X). See: http://bugzilla.gnome.org/show_bug.cgi?id=556301 That's currently waiting on XInput2 support in GTK+ to do the enumeration/hotplug. Okay, after quite a few bluez updates that seem to completely break bluetooth, I noticed that after the current update, when I start my laptop, the bluetooth icon is in the notification area without any intervention by myself. This is great. Even better, I can sync my Palm Zire72 using Bluetooth. Fantastic. However, after a suspend/resume cycle, the icon disappears and if I run S > P > Bluetooth, it says no bluetooth device exists. Oh, and I reopened the bug because while it was closed early on in the piece, later input would suggest that something is actually being done to address the issues reported and as such it feels like the bug is actually open and being address (which is great). Might also be necessary: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=8a0217ffd432e56231b0d1bccda71449bca5f8f6 http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=8aba9a4bcabb791fa4dae89bc2d2ac194793ae9a http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=4b6769f61206e90850aff8a30e8e93fbfcc18673 http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=9821e7026401553e9ccba124afd9408a83007ba6;hp=5bacd2aadc854a0c01934bab76d4f575543d361e Could you please test the build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1683124 I've installed the koji stuff above. I'm not sure if I was meant to do something with the 'Might also be necessary' stuff and haven't. After a reboot (not necessary, but nice to know it's all going to work like it should) I no longer see a bluetooth icon in the notification area and trying to run the bluetooth tool in System > Preferences says I don't have any bluetooth devices. This is a regression from the previous version I had installed. It's now a month since this bug was updated and bluetooth is still 'no working' for me (with all recent updates installed). Please test with: http://koji.fedoraproject.org/koji/buildinfo?buildID=139403 Bastien, I've tried the packages above and they work great. I had been using bluez-4.56-1 which worked on boot, but when you cycled through a suspend and resume, the icon disappeared and then /system/preferences/bluetooth would say no bluetooth device existed. However, I can cycle through suspend/resume cycles and the icon reappears and appears to work fine. Does this give you something to work with. Hmmm, work noting that this is on an f12 box. I didn't notice that the packages you offer where f11. So, is it possible to test this fix in f12 with f12 packages too. I'll try and test them in f11 for you. Which one do you use? If you use F12, file a bug against udev which is where the hid2hci mechanics live. If you use F11, then you'll want this package. Does it work with the above package on F11? Strangely, it doesn't work in f11, but it does work in f12. It's an improvement in f11. At least bluetooth is now appearing when I log in the first time, but after cycling through suspend and resume, it doesn't appear again. I'm happy to file a bug against udev for f12, but would like to know what I need to tell them to do. bluez-4.42-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bluez-4.42-9.fc11 bluez-4.42-9.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update bluez'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10931 Bastien, What do I need to ask the udev guys to do to get bluez working in f12? I've file a bug, but I don't know what to ask them to do. https://bugzilla.redhat.com/show_bug.cgi?id=532628 bluez-4.42-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. |