Mario Limonciello wrote:
Hi Justin:
Justin Mattock wrote:
For some reason in rules.d
for the permission setting:
#ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
to
RUN+="/usr/sbin/bluetoothd --udev"
gets this working for me.
prior to this, udev just would not activate
bluetoothd
Anyways thought it would be good to let people know.
I'm wondering if you are seeing something similar that was happening on
Ubuntu when getting bluez-4.45 added in where the daemon failed to start
upon bootup but works fine later (eg if you hotplug the device).
It turned out that dbus wasn't up and running at the time udev triggered
all devices early in the boot.
The easiest solution was to run:
udevadm trigger --subsystem-match=bluetooth
later on, during an init script or similar.
yeah, the:
ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
option gave no response after rebooting numerous times, until commenting out
ACTION, and SUBSYSTEM, and just using RUN+=
The init script has /sbin/udevadm trigger and /sbin/udevadm settle
after /sbin/udevd --daemon is called.
And from what I see that might be whats happening,
udevadm needs to be told about the subsystem call.
I'll go ahead and try your solution and see if it reads the susbsystem
option without having to change the *.rules
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
