udev rule bluetooth.rules

udev rule bluetooth.rules

[John Frankish]

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

Re: udev rule bluetooth.rules

[Stefan Seyfried]

On Sun, 5 Jul 2009 12:24:34 +0200
John Frankish <j-frankish@slb.com> 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)

RE: udev rule bluetooth.rules

[John Frankish]

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

RE: udev rule bluetooth.rules

[John Frankish]

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=

RE: udev rule bluetooth.rules

[Marcel Holtmann]

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

RE: udev rule bluetooth.rules

[Bastien Nocera]

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

RE: udev rule bluetooth.rules

[Marcel Holtmann]

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

Re: udev rule bluetooth.rules

[Marcel Holtmann]

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

Re: udev rule bluetooth.rules

[Bastien Nocera]

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...

Re: udev rule bluetooth.rules

[Marcel Holtmann]

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

RE: udev rule bluetooth.rules

[John Frankish]

> > > 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