http://bugs.winehq.org/show_bug.cgi?id=57526
Vibhav Pant vibhavp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vibhavp@gmail.com
--- Comment #4 from Vibhav Pant vibhavp@gmail.com --- (In reply to Patrick Hibbs from comment #3)
The error message has changed slightly, but is still present in Wine-10.0-rc5.
It prints: err:winebth:bluez_dbus_loop Error getting object list from BlueZ: 'org.freedesktop.DBus.Error.TimedOut': 'Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)'
This was fixed in 49a0e297fffe0d7a1f125cfc31f4875a71a918d4.
(In reply to Patrick Hibbs from comment #2)
(In reply to Zeb Figura from comment #1)
(In reply to Patrick Hibbs from comment #0)
Even for a system with bluez installed, it would be nice to have some option that could disable this support when it's not needed. As bluetooth snooping can be a method of privacy invasion, and a misbehaving app could cause issues with the native apps running on the host.
If you're concerned about that, a setting in Wine won't save you. We don't do anything that requires special privileges.
The main thing I'm more worried about is something similar to the following:
End user is talking with their boss via bluetooth. User runs some Windows app under wine. The Windows app hits a wine bug and tries to reset the bluetooth controller as a result. End user is accused of "hanging up" on their boss.
Keep in mind, the same thing could happen with a potential wifi driver. (And in fact is far more likely to occur.)
Having a means to turn that support off would at least mitigate the risk of such occurrences.
Neither the current Bluetooth stack driver nor user-mode Bluetooth APIs provide a way to reset the underlying controller, AFAIK. There is IOCTL_BTH_HCI_VENDOR_COMMAND, which allows sending vendor-specific HCI commands to the controller, but since sending raw HCI data on Linux requires elevated privileges, it's unlikely to be implemented on Wine.