More on hotplug issue w/HAL
matt at aclaro.com
Sat Jan 10 01:56:21 EET 2004
David Zeuthen wrote:
> Many thanks, I've just committed the code with a change in linux_osspec
> to check if the device->bus_id starts with i2c instead of checking that
> device->bus equals i2c. The latter was 'unknown' on my box - might be a
> kernel or libsysfs issue.
I forgot to mention this - I'm discussing a kernel change with gregkh
w/r/t the i2c-n adapters not appearing in the /sys/bus/i2c directory.
Since they don't appear in this bus directory, libsysfs assign the
adapters to the "unknown" bus. My patch registers these on the i2c bus
to fix this, but Greg isn't certain this is the correct approach.
I can't consider myself an authority on this, so I'm not certain if this
is even the correct way to do things. I've CC'd you on my other message
to greg and the sensors list - perhaps you might offer more insight.
If the patch isn't accepted, it might be necessary for libsysfs to
enumerate the /sys/bus/class/i2c-adapter to place the i2c-n adapters
correctly on the i2c bus. I don't know what the correct solution is in
>>No capabilities are currently supported, but the devices nodes now show
> I've added that info.[category|capabilities] will be set to i2c. Btw, I
> wonder what a desktop application would use such a device for, any
A desktop motherboard monitor could detect available sensors via their
capabilities and dynamically generate a list of available sensor items
(if they appeared as "sensor").
As well, a TV-watching-app could detect all I2C tuner devices with
Both of these would require additional sysfs information - perhaps via
BTW, Is there a way to easily add the linux driver to the info.*
More information about the xdg