Bluetooth UDEV info like empty after hi2hci

Bluetooth UDEV info like empty after hi2hci

[Alexandre Ghisoli]

Hi, 

I've asked this on bluetooth mailing list, but I cannot see if this
issue come from UDEV or Bluetooth stack.

Linux 2.6.15
UDEV 084
DiNovo keyb and mice


I cannot force the device name in udev to link it in xorg
configuration file.

Fixed device name is required for the Xorg configuration, since kernel
and udev change device numbers at reconnect, after a Bluetooth stop to
save batteries.

Example :

/dev/input/event0       -> mouse at startup (in usb mode)
/dev/input/event1       -> keyboard (in usb mode) 
/dev/input/event3       -> mouse in BT mode, if I touch mice first
/dev/input/event4       -> keyboard in BT mode

After a while without using mouse, hidd will stop session with device.
Touching the mouse re-enable the link, but device number could be
event5 !


So, I want to fix the device name with a udev script. Testing : 
KERNEL="event[0-9]*"  SYSFS{idVendor}="046d",
SYSFS{idProduct}="b001", NAME="input/ev-mx900", MODE="0664"

Not working !!


/proc/bus/input/devices gives : 
I: Bus\005 Vendor\x046d Product°01 Version"00
N: Name="Bluetooth HID Boot Protocol Device"
P: PhysS: Sysfs=/class/input/input4
H: Handlers=mouse1 event4
B: EV=7
B: KEY=xxx
B: REL\x103

And UDEV has only : 
udevinfo -a -p /sys/class/input/mouse1

--cut--
  looking at device '/class/input/input4/mouse1':
    KERNEL="mouse1"
    SUBSYSTEM="input"
    SYSFS{dev}="13:33"

  looking at device '/class/input/input4':
    ID="input4"
    BUS="input"
    DRIVER=""
    SYSFS{uniq}=""
    SYSFS{phys}=""
    SYSFS{name}="Bluetooth HID Boot Protocol Device"




This mean that the udev struct is not filled with all needed infos to
match udev rules.

Any help to make it working ?




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Kay Sievers]

On Tue, Feb 07, 2006 at 10:25:58AM +0100, Alexandre Ghisoli wrote:
> Hi, 
> 
> I've asked this on bluetooth mailing list, but I cannot see if this
> issue come from UDEV or Bluetooth stack.

> --cut--
>   looking at device '/class/input/input4/mouse1':
>     KERNEL="mouse1"
>     SUBSYSTEM="input"
>     SYSFS{dev}="13:33"
> 
>   looking at device '/class/input/input4':
>     ID="input4"
>     BUS="input"
>     DRIVER=""
>     SYSFS{uniq}=""
>     SYSFS{phys}=""
>     SYSFS{name}="Bluetooth HID Boot Protocol Device"

The kernel driver needs to set the "struct device", to get a "device" link
in sysfs pointing to the physical device, otherwise the USB devices are not
reachable and udev can't match.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 07 February 2006 12:25, Alexandre Ghisoli wrote:
> Hi,
>
> I've asked this on bluetooth mailing list, but I cannot see if this
> issue come from UDEV or Bluetooth stack.
>
> Linux 2.6.15
> UDEV 084
> DiNovo keyb and mice
>
>
> I cannot force the device name in udev to link it in xorg
> configuration file.
>
> Fixed device name is required for the Xorg configuration, since kernel
> and udev change device numbers at reconnect, after a Bluetooth stop to
> save batteries.
>
> Example :
>
> /dev/input/event0       -> mouse at startup (in usb mode)
> /dev/input/event1       -> keyboard (in usb mode)
> /dev/input/event3       -> mouse in BT mode, if I touch mice first
> /dev/input/event4       -> keyboard in BT mode
>
> After a while without using mouse, hidd will stop session with device.
> Touching the mouse re-enable the link, but device number could be
> event5 !
>
>
> So, I want to fix the device name with a udev script. Testing :
> KERNEL="event[0-9]*"  SYSFS{idVendor}="046d",
> SYSFS{idProduct}="b001", NAME="input/ev-mx900", MODE="0664"
>
> Not working !!
>

try using SYSFS{id/vendor}, SYSFS{id/product}. They are in subdirectory 
of /sys/class/input/inputX. Not quite logical comparing with all other 
subsystems.

- -andrey

>
> /proc/bus/input/devices gives :
> I: Bus\005 Vendor\x046d Product°01 Version"00
> N: Name="Bluetooth HID Boot Protocol Device"
> P: Phys> S: Sysfs=/class/input/input4
> H: Handlers=mouse1 event4
> B: EV=7
> B: KEY=xxx
> B: REL\x103
>
> And UDEV has only :
> udevinfo -a -p /sys/class/input/mouse1
>
> --cut--
>   looking at device '/class/input/input4/mouse1':
>     KERNEL="mouse1"
>     SUBSYSTEM="input"
>     SYSFS{dev}="13:33"
>
>   looking at device '/class/input/input4':
>     ID="input4"
>     BUS="input"
>     DRIVER=""
>     SYSFS{uniq}=""
>     SYSFS{phys}=""
>     SYSFS{name}="Bluetooth HID Boot Protocol Device"
>
>
>
>
> This mean that the udev struct is not filled with all needed infos to
> match udev rules.
>
> Any help to make it working ?
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD6NCqR6LMutpd94wRAmA+AJ9ljRgaZjHpwkjMovvOtPGkrtU9KACfRq0F
uUCvBW0ptr4uzrsOPVQmxuA=kRjT
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Marcel Holtmann]

Hi Kay,

> > I've asked this on bluetooth mailing list, but I cannot see if this
> > issue come from UDEV or Bluetooth stack.
> 
> > --cut--
> >   looking at device '/class/input/input4/mouse1':
> >     KERNEL="mouse1"
> >     SUBSYSTEM="input"
> >     SYSFS{dev}="13:33"
> > 
> >   looking at device '/class/input/input4':
> >     ID="input4"
> >     BUS="input"
> >     DRIVER=""
> >     SYSFS{uniq}=""
> >     SYSFS{phys}=""
> >     SYSFS{name}="Bluetooth HID Boot Protocol Device"
> 
> The kernel driver needs to set the "struct device", to get a "device" link
> in sysfs pointing to the physical device, otherwise the USB devices are not
> reachable and udev can't match.

I would love to do that, but the Bluetooth subsystem is only available
under /sys/class at the moment. So which "struct device" should I use?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Kay Sievers]

On Tue, Feb 07, 2006 at 11:25:53PM +0100, Marcel Holtmann wrote:
> Hi Kay,
> 
> > > I've asked this on bluetooth mailing list, but I cannot see if this
> > > issue come from UDEV or Bluetooth stack.
> > 
> > > --cut--
> > >   looking at device '/class/input/input4/mouse1':
> > >     KERNEL="mouse1"
> > >     SUBSYSTEM="input"
> > >     SYSFS{dev}="13:33"
> > > 
> > >   looking at device '/class/input/input4':
> > >     ID="input4"
> > >     BUS="input"
> > >     DRIVER=""
> > >     SYSFS{uniq}=""
> > >     SYSFS{phys}=""
> > >     SYSFS{name}="Bluetooth HID Boot Protocol Device"
> > 
> > The kernel driver needs to set the "struct device", to get a "device" link
> > in sysfs pointing to the physical device, otherwise the USB devices are not
> > reachable and udev can't match.
> 
> I would love to do that, but the Bluetooth subsystem is only available
> under /sys/class at the moment. So which "struct device" should I use?

Ah, ok. The Bluetooth "bus" never happened, right? I just remember we
talked about that last year with David in Ottawa. :) Passing the usb
"device" behind the hci would not be correct, right?

Cheers,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Marcel Holtmann]

Hi Kay,

> > > > I've asked this on bluetooth mailing list, but I cannot see if this
> > > > issue come from UDEV or Bluetooth stack.
> > > 
> > > > --cut--
> > > >   looking at device '/class/input/input4/mouse1':
> > > >     KERNEL="mouse1"
> > > >     SUBSYSTEM="input"
> > > >     SYSFS{dev}="13:33"
> > > > 
> > > >   looking at device '/class/input/input4':
> > > >     ID="input4"
> > > >     BUS="input"
> > > >     DRIVER=""
> > > >     SYSFS{uniq}=""
> > > >     SYSFS{phys}=""
> > > >     SYSFS{name}="Bluetooth HID Boot Protocol Device"
> > > 
> > > The kernel driver needs to set the "struct device", to get a "device" link
> > > in sysfs pointing to the physical device, otherwise the USB devices are not
> > > reachable and udev can't match.
> > 
> > I would love to do that, but the Bluetooth subsystem is only available
> > under /sys/class at the moment. So which "struct device" should I use?
> 
> Ah, ok. The Bluetooth "bus" never happened, right? I just remember we
> talked about that last year with David in Ottawa. :) Passing the usb
> "device" behind the hci would not be correct, right?

I got convinced that keeping them as class device is better and once the
unified /sys/devices/ got merged we re-evaluate it.

Since not every Bluetooth device is attached over USB it might be kinda
not the right way. However such a workaround can be used for now. Will
this really work and not cause more troubles?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bluetooth UDEV info like empty after hi2hci

[Kay Sievers]

On Wed, Feb 08, 2006 at 03:53:12AM +0100, Marcel Holtmann wrote:
> > > > > I've asked this on bluetooth mailing list, but I cannot see if this
> > > > > issue come from UDEV or Bluetooth stack.
> > > > 
> > > > > --cut--
> > > > >   looking at device '/class/input/input4/mouse1':
> > > > >     KERNEL="mouse1"
> > > > >     SUBSYSTEM="input"
> > > > >     SYSFS{dev}="13:33"
> > > > > 
> > > > >   looking at device '/class/input/input4':
> > > > >     ID="input4"
> > > > >     BUS="input"
> > > > >     DRIVER=""
> > > > >     SYSFS{uniq}=""
> > > > >     SYSFS{phys}=""
> > > > >     SYSFS{name}="Bluetooth HID Boot Protocol Device"
> > > > 
> > > > The kernel driver needs to set the "struct device", to get a "device" link
> > > > in sysfs pointing to the physical device, otherwise the USB devices are not
> > > > reachable and udev can't match.
> > > 
> > > I would love to do that, but the Bluetooth subsystem is only available
> > > under /sys/class at the moment. So which "struct device" should I use?
> > 
> > Ah, ok. The Bluetooth "bus" never happened, right? I just remember we
> > talked about that last year with David in Ottawa. :) Passing the usb
> > "device" behind the hci would not be correct, right?
> 
> I got convinced that keeping them as class device is better and once the
> unified /sys/devices/ got merged we re-evaluate it.

Yeah, may make sense, even when it will not be that different for the
driver core users in the first run. It will just look a bit different for
userspace.

> Since not every Bluetooth device is attached over USB it might be kinda
> not the right way. However such a workaround can be used for now. Will
> this really work and not cause more troubles?

It should work without trouble, yes. But sure, it may not be worth the effort,
when it will change again later this year. So it should be fine for now to plug
in a shell script in the udev process and lookup that information from
somewhere else.

Cheers,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel