Ref bluez-4.43 /etc/udev/bluetooth.rules:
# Run helper every time a Bluetooth device appears
# On remove actions, bluetoothd should go away by itself
ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules so that it starts in the correct order - i.e. after dbus?
Is it possible to have a udev rule check that dbus is running before executing?
Regards, John
Hi Bastien,
> > > > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> > > >
> > > > # Run helper every time a Bluetooth device appears
> > > > # On remove actions, bluetoothd should go away by itself
> > > > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd
> > > > --udev"
> > > >
> > > > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules
> > > > so that it starts in the correct order - i.e. after dbus?
> > >
> > > That's taken care of - if dbus is not available, bluetoothd will exit
> > > with return code 1. udev will notice that and later start it again in
> > > the coldplug run.
> > >
> > > > if dbus is not started, I need to do this:
> > > > # udevtrigger --subsystem-match=bluetooth
> > > > is this is what was meant by "coldplug run"?
> > > --
> > > Thanks - I'd been playing around with this as /etc/udev/rules.d/85-bluetooth.rules but hadn't got around to trying without dbus started - it works for me with dbus started.
> > >
> > > It would be nice if "--prefix=/usr/local" were passed to bluetooth.rules to give:
> > >
> > > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/local/sbin/bluetoothd
> >
> > I fixed that now and we generate bluetooth.rules with the correct
> > prefix.
>
> The UDEV_DATADIR code is broken:
>
>
> 114 UDEV_DATADIR="`$PKG_CONFIG --variable=udevdir udev`/rules.d"
> 115 if (test -z "${UDEV_DATADIR}"); then
> 116 UDEV_DATADIR="${sysconfdir}/udev/rules.d"
> 117 fi
>
> UDEV_DATADIR will never be empty, because it will contain at least
> "/rules.d".
fixed with bluez-4.45 release. Thanks for reminding me about a
brown-paper-bag ;)
Regards
Marcel
On Mon, 2009-07-06 at 10:31 -0700, Marcel Holtmann wrote:
> Hi John,
>
> > > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> > >
> > > # Run helper every time a Bluetooth device appears
> > > # On remove actions, bluetoothd should go away by itself
> > > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd
> > > --udev"
> > >
> > > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules
> > > so that it starts in the correct order - i.e. after dbus?
> >
> > That's taken care of - if dbus is not available, bluetoothd will exit
> > with return code 1. udev will notice that and later start it again in
> > the coldplug run.
> >
> > > if dbus is not started, I need to do this:
> > > # udevtrigger --subsystem-match=bluetooth
> > > is this is what was meant by "coldplug run"?
> > --
> > Thanks - I'd been playing around with this as /etc/udev/rules.d/85-bluetooth.rules but hadn't got around to trying without dbus started - it works for me with dbus started.
> >
> > It would be nice if "--prefix=/usr/local" were passed to bluetooth.rules to give:
> >
> > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/local/sbin/bluetoothd
>
> I fixed that now and we generate bluetooth.rules with the correct
> prefix.
The UDEV_DATADIR code is broken:
114 UDEV_DATADIR="`$PKG_CONFIG --variable=udevdir udev`/rules.d"
115 if (test -z "${UDEV_DATADIR}"); then
116 UDEV_DATADIR="${sysconfdir}/udev/rules.d"
117 fi
UDEV_DATADIR will never be empty, because it will contain at least
"/rules.d".
Cheers
Hi John,
> > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> >
> > # Run helper every time a Bluetooth device appears
> > # On remove actions, bluetoothd should go away by itself
> > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd
> > --udev"
> >
> > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules
> > so that it starts in the correct order - i.e. after dbus?
>
> That's taken care of - if dbus is not available, bluetoothd will exit
> with return code 1. udev will notice that and later start it again in
> the coldplug run.
>
> > if dbus is not started, I need to do this:
> > # udevtrigger --subsystem-match=bluetooth
> > is this is what was meant by "coldplug run"?
> --
> Thanks - I'd been playing around with this as /etc/udev/rules.d/85-bluetooth.rules but hadn't got around to trying without dbus started - it works for me with dbus started.
>
> It would be nice if "--prefix=/usr/local" were passed to bluetooth.rules to give:
>
> ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/local/sbin/bluetoothd
I fixed that now and we generate bluetooth.rules with the correct
prefix.
Regards
Marcel
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbGludXgtYmx1ZXRvb3RoLW93bmVy
QHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5l
bC5vcmddIE9uIEJlaGFsZiBPZiBTdGVmYW4gU2V5ZnJpZWQNClNlbnQ6IDA1IEp1bHksIDIwMDkg
MTU6MzMNClRvOiBsaW51eC1ibHVldG9vdGhAdmdlci5rZXJuZWwub3JnDQpTdWJqZWN0OiBSZTog
dWRldiBydWxlIGJsdWV0b290aC5ydWxlcw0KDQpPbiBTdW4sIDUgSnVsIDIwMDkgMTI6MjQ6MzQg
KzAyMDANCkpvaG4gRnJhbmtpc2ggPGotZnJhbmtpc2hAc2xiLmNvbT4gd3JvdGU6DQoNCj4gUmVm
IGJsdWV6LTQuNDMgL2V0Yy91ZGV2L2JsdWV0b290aC5ydWxlczoNCj4NCj4gIyBSdW4gaGVscGVy
IGV2ZXJ5IHRpbWUgYSBCbHVldG9vdGggZGV2aWNlIGFwcGVhcnMNCj4gIyBPbiByZW1vdmUgYWN0
aW9ucywgYmx1ZXRvb3RoZCBzaG91bGQgZ28gYXdheSBieSBpdHNlbGYNCj4gQUNUSU9OPT0iYWRk
IiwgU1VCU1lTVEVNPT0iYmx1ZXRvb3RoIiwgUlVOKz0iL3Vzci9zYmluL2JsdWV0b290aGQNCj4g
LS11ZGV2Ig0KPg0KPiBTaG91bGRuJ3QgdGhpcyBiZSBvZiB0aGUgZm9ybWF0IC9ldGMvdWRldi9y
dWxlcy5kL3h4LWJsdWV0b290aC5ydWxlcw0KPiBzbyB0aGF0IGl0IHN0YXJ0cyBpbiB0aGUgY29y
cmVjdCBvcmRlciAtIGkuZS4gYWZ0ZXIgZGJ1cz8NCg0KVGhhdCdzIHRha2VuIGNhcmUgb2YgLSBp
ZiBkYnVzIGlzIG5vdCBhdmFpbGFibGUsIGJsdWV0b290aGQgd2lsbCBleGl0DQp3aXRoIHJldHVy
biBjb2RlIDEuIHVkZXYgd2lsbCBub3RpY2UgdGhhdCBhbmQgbGF0ZXIgc3RhcnQgaXQgYWdhaW4g
aW4NCnRoZSBjb2xkcGx1ZyBydW4uDQoNCj4gaWYgZGJ1cyBpcyBub3Qgc3RhcnRlZCwgSSBuZWVk
IHRvIGRvIHRoaXM6DQo+ICMgdWRldnRyaWdnZXIgLS1zdWJzeXN0ZW0tbWF0Y2g9Ymx1ZXRvb3Ro
DQo+IGlzIHRoaXMgaXMgd2hhdCB3YXMgbWVhbnQgYnkgImNvbGRwbHVnIHJ1biI/DQotLQ0KVGhh
bmtzIC0gSSdkIGJlZW4gcGxheWluZyBhcm91bmQgd2l0aCB0aGlzIGFzIC9ldGMvdWRldi9ydWxl
cy5kLzg1LWJsdWV0b290aC5ydWxlcyBidXQgaGFkbid0IGdvdCBhcm91bmQgdG8gdHJ5aW5nIHdp
dGhvdXQgZGJ1cyBzdGFydGVkIC0gaXQgd29ya3MgZm9yIG1lIHdpdGggZGJ1cyBzdGFydGVkLg0K
DQpJdCB3b3VsZCBiZSBuaWNlIGlmICItLXByZWZpeD0vdXNyL2xvY2FsIiB3ZXJlIHBhc3NlZCB0
byBibHVldG9vdGgucnVsZXMgdG8gZ2l2ZToNCg0KQUNUSU9OPT0iYWRkIiwgU1VCU1lTVEVNPT0i
Ymx1ZXRvb3RoIiwgUlVOKz0iL3Vzci9sb2NhbC9zYmluL2JsdWV0b290aGQNCg0KLi53b3VsZCBo
YXZlIHNhdmVkIG1lIDMwbWlucyBvciBzbyBhbnl3YXkgOikNCg0KDQo=
> > > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> > >
> > > # Run helper every time a Bluetooth device appears
> > > # On remove actions, bluetoothd should go away by itself
> > > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
> > >
> > > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules so that it starts in the correct order - i.e. after dbus?
> > >
> > > Is it possible to have a udev rule check that dbus is running before executing?
> >
> > you are right. I should have fixed this. Just forgot about it. What
> > number prefix do we want for Bluetooth.
>
> You don't need the prefix. D-Bus isn't started through udev...
we don't need it, but we should be nice and add it anyway. I pushed a
fix for that. BlueZ being the only project not following conventions
here is a bad idea.
> Using /etc/udev/rules.d/97-bluetooth with bluez-4.43 does indeed load all required
> modules and start bluetoothd as soon as I use the hardware switch to enable Bluetooth
>
> Thanks, John
Hi Bastien,
> > > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> > >
> > > # Run helper every time a Bluetooth device appears
> > > # On remove actions, bluetoothd should go away by itself
> > > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
> > >
> > > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules so that it starts in the correct order - i.e. after dbus?
> > >
> > > Is it possible to have a udev rule check that dbus is running before executing?
> >
> > you are right. I should have fixed this. Just forgot about it. What
> > number prefix do we want for Bluetooth.
>
> You don't need the prefix. D-Bus isn't started through udev...
we don't need it, but we should be nice and add it anyway. I pushed a
fix for that. BlueZ being the only project not following conventions
here is a bad idea.
Regards
Marcel
On Sun, 2009-07-05 at 09:24 -0700, Marcel Holtmann wrote:
> Hi John,
>
> > Ref bluez-4.43 /etc/udev/bluetooth.rules:
> >
> > # Run helper every time a Bluetooth device appears
> > # On remove actions, bluetoothd should go away by itself
> > ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
> >
> > Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules so that it starts in the correct order - i.e. after dbus?
> >
> > Is it possible to have a udev rule check that dbus is running before executing?
>
> you are right. I should have fixed this. Just forgot about it. What
> number prefix do we want for Bluetooth.
You don't need the prefix. D-Bus isn't started through udev...
Hi John,
> Ref bluez-4.43 /etc/udev/bluetooth.rules:
>
> # Run helper every time a Bluetooth device appears
> # On remove actions, bluetoothd should go away by itself
> ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"
>
> Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules so that it starts in the correct order - i.e. after dbus?
>
> Is it possible to have a udev rule check that dbus is running before executing?
you are right. I should have fixed this. Just forgot about it. What
number prefix do we want for Bluetooth.
Regards
Marcel
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaW51eC1ibHVldG9vdGgtb3du
ZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2Vy
bmVsLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZhbiBTZXlmcmllZA0KU2VudDogMDUgSnVseSwgMjAw
OSAxNTozMw0KVG86IGxpbnV4LWJsdWV0b290aEB2Z2VyLmtlcm5lbC5vcmcNClN1YmplY3Q6IFJl
OiB1ZGV2IHJ1bGUgYmx1ZXRvb3RoLnJ1bGVzDQoNCk9uIFN1biwgNSBKdWwgMjAwOSAxMjoyNDoz
NCArMDIwMA0KSm9obiBGcmFua2lzaCA8ai1mcmFua2lzaEBzbGIuY29tPiB3cm90ZToNCg0KPiBS
ZWYgYmx1ZXotNC40MyAvZXRjL3VkZXYvYmx1ZXRvb3RoLnJ1bGVzOg0KPg0KPiAjIFJ1biBoZWxw
ZXIgZXZlcnkgdGltZSBhIEJsdWV0b290aCBkZXZpY2UgYXBwZWFycw0KPiAjIE9uIHJlbW92ZSBh
Y3Rpb25zLCBibHVldG9vdGhkIHNob3VsZCBnbyBhd2F5IGJ5IGl0c2VsZg0KPiBBQ1RJT049PSJh
ZGQiLCBTVUJTWVNURU09PSJibHVldG9vdGgiLCBSVU4rPSIvdXNyL3NiaW4vYmx1ZXRvb3RoZA0K
PiAtLXVkZXYiDQo+DQo+IFNob3VsZG4ndCB0aGlzIGJlIG9mIHRoZSBmb3JtYXQgL2V0Yy91ZGV2
L3J1bGVzLmQveHgtYmx1ZXRvb3RoLnJ1bGVzDQo+IHNvIHRoYXQgaXQgc3RhcnRzIGluIHRoZSBj
b3JyZWN0IG9yZGVyIC0gaS5lLiBhZnRlciBkYnVzPw0KDQpUaGF0J3MgdGFrZW4gY2FyZSBvZiAt
IGlmIGRidXMgaXMgbm90IGF2YWlsYWJsZSwgYmx1ZXRvb3RoZCB3aWxsIGV4aXQNCndpdGggcmV0
dXJuIGNvZGUgMS4gdWRldiB3aWxsIG5vdGljZSB0aGF0IGFuZCBsYXRlciBzdGFydCBpdCBhZ2Fp
biBpbg0KdGhlIGNvbGRwbHVnIHJ1bi4NCi0tDQpUaGFua3MgLSBJJ2QgYmVlbiBwbGF5aW5nIGFy
b3VuZCB3aXRoIHRoaXMgYXMgL2V0Yy91ZGV2L3J1bGVzLmQvODUtYmx1ZXRvb3RoLnJ1bGVzIGJ1
dCBoYWRuJ3QgZ290IGFyb3VuZCB0byB0cnlpbmcgd2l0aG91dCBkYnVzIHN0YXJ0ZWQgLSBpdCB3
b3JrcyBmb3IgbWUgd2l0aCBkYnVzIHN0YXJ0ZWQuDQoNCkl0IHdvdWxkIGJlIG5pY2UgaWYgIi0t
cHJlZml4PS91c3IvbG9jYWwiIHdlcmUgcGFzc2VkIHRvIGJsdWV0b290aC5ydWxlcyB0byBnaXZl
Og0KDQpBQ1RJT049PSJhZGQiLCBTVUJTWVNURU09PSJibHVldG9vdGgiLCBSVU4rPSIvdXNyL2xv
Y2FsL3NiaW4vYmx1ZXRvb3RoZA0KDQouLndvdWxkIGhhdmUgc2F2ZWQgbWUgMzBtaW5zIG9yIHNv
IGFueXdheSA6KQ0K
On Sun, 5 Jul 2009 12:24:34 +0200
John Frankish <[email protected]> wrote:
> Ref bluez-4.43 /etc/udev/bluetooth.rules:
>
> # Run helper every time a Bluetooth device appears
> # On remove actions, bluetoothd should go away by itself
> ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd
> --udev"
>
> Shouldn't this be of the format /etc/udev/rules.d/xx-bluetooth.rules
> so that it starts in the correct order - i.e. after dbus?
That's taken care of - if dbus is not available, bluetoothd will exit
with return code 1. udev will notice that and later start it again in
the coldplug run.
--
Stefan Seyfried
R&D Preload Department | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)