From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 08 Feb 2006 17:01:38 +0000 Subject: Re: Bluetooth UDEV info like empty after hi2hci Message-Id: <20060208170138.GA21244@vrfy.org> List-Id: References: <1139304358.7057.12.camel@pc-05.ycom.ch> In-Reply-To: <1139304358.7057.12.camel@pc-05.ycom.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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&kid3432&bid#0486&dat1642 _______________________________________________ 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