From: Antonio Ospite <hidden> Date: 2011-02-23 22:51:14
Hi,
in my attempts to handle leds setting and usb pairing for the Sixaxis
controller I had to fight with libudev a little bit, eventually I
succeeded in what I wanted to achieve but I still have some questions
about the libudev API, so here I am.
This is basically the layout for the device:
4-1:1.0/
|-- 0003:054C:0268.000C (hid device)
| |-- hidraw
| | `-- hidraw1
| `-- uevent (which tells me HID_PHYS)
|
`-- input
`-- input17
|-- js0
`-- phys
I needed to get the hidraw device node, and the js device number, the
two sibling devices (from hid and input subsystem) can be matched using
the 'phys' property.
This is what I do now:
0. Monitor with a filter matching the "hidraw" subsystem.
1. When a matching device is connected we get the "hidraw" device.
2. Go up to its "hid" parent device and check it is actually a
Sixaxis (using HID_NAME), if not GOTO 1.
3. Store the hidraw device node for later use
4. Store the HID_PHYS value in order to look for the matching joystick.
5. Enumerate the joystick devices with the sysname filter "js*"
6. For each joystick:
a. Go up to its input parent device
b. Check that the phys attribute matches HID_PHYS,
if so, store the joystick device number.
7. Set leds
8. If the Sixaxis is connected via USB do the cable pairing.
My doubt is about 5. and 6a.: I have go deep in the hierarchy down to
the js0 leaf device and then I have to go up one level to get the
input device, naively I would have done the contrary:
5'. Enumerate the input devices such that phys == HID_PHYS
6'. Enumerate the devices _below_ the input device from 5'. looking
for the jsX device.
But this is not possible because the enumerate API is designed to start
always from the root of /sys.
Finally the question: why the enumerate API in libudev does not allow
enumerating only from a _subtree_? Has that been designed this way to
keep the API simple, or because it is not considered useful?
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
From: Kay Sievers <hidden> Date: 2011-03-07 15:28:05
On Wed, Feb 23, 2011 at 23:50, Antonio Ospite [off-list ref] wrote:
Hi,
in my attempts to handle leds setting and usb pairing for the Sixaxis
controller I had to fight with libudev a little bit, eventually I
succeeded in what I wanted to achieve but I still have some questions
about the libudev API, so here I am.
This is basically the layout for the device:
4-1:1.0/
|-- 0003:054C:0268.000C (hid device)
| |-- hidraw
| | `-- hidraw1
| `-- uevent (which tells me HID_PHYS)
|
`-- input
`-- input17
|-- js0
`-- phys
I needed to get the hidraw device node, and the js device number, the
two sibling devices (from hid and input subsystem) can be matched using
the 'phys' property.
This is what I do now:
0. Monitor with a filter matching the "hidraw" subsystem.
1. When a matching device is connected we get the "hidraw" device.
2. Go up to its "hid" parent device and check it is actually a
Sixaxis (using HID_NAME), if not GOTO 1.
3. Store the hidraw device node for later use
4. Store the HID_PHYS value in order to look for the matching joystick.
5. Enumerate the joystick devices with the sysname filter "js*"
6. For each joystick:
a. Go up to its input parent device
b. Check that the phys attribute matches HID_PHYS,
if so, store the joystick device number.
7. Set leds
8. If the Sixaxis is connected via USB do the cable pairing.
My doubt is about 5. and 6a.: I have go deep in the hierarchy down to
the js0 leaf device and then I have to go up one level to get the
input device, naively I would have done the contrary:
5'. Enumerate the input devices such that phys == HID_PHYS
6'. Enumerate the devices _below_ the input device from 5'. looking
for the jsX device.
But this is not possible because the enumerate API is designed to start
always from the root of /sys.
Finally the question: why the enumerate API in libudev does not allow
enumerating only from a _subtree_? Has that been designed this way to
keep the API simple, or because it is not considered useful?
The usual enumeration in udev never uses the device tree in
/sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
have something to enumerate all child devices of a given device. It's
not simple, but could be made working.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The usual enumeration in udev never uses the device tree in
/sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
have something to enumerate all child devices of a given device. It's
not simple, but could be made working.
Hi Kay,
The documentation in Documentation/sysfs-rules.txt seems to warn against
using /sys/class and sys/bus:
- devices are only "devices"
There is no such thing like class-, bus-, physical devices,
interfaces, and such that you can rely on in userspace. Everything is
just simply a "device". Class-, bus-, physical, ... types are just
kernel implementation details which should not be expected by
applications that look for devices in sysfs.
...
- all elements of a devpath must be real directories. Symlinks
pointing to /sys/devices must always be resolved to their real
target and the target path must be used to access the device.
That way the devpath to the device matches the devpath of the
kernel used at event time.
- using or exposing symlink values as elements in a devpath string
is a bug in the application
...
- accessing attributes reached by a symlink pointing to another
device,
like the "device"-link, is a bug in the application
...
- Hierarchy in a single device tree
There is only one valid place in sysfs where hierarchy can be examined
and this is below: /sys/devices.
and more...
I figured that this document was probably out of date, since even
libudev uses /sys/class. What's your take on this document?
Alan.
From: Kay Sievers <hidden> Date: 2011-03-07 16:11:29
On Mon, Mar 7, 2011 at 17:01, Alan Ott [off-list ref] wrote:
On 03/07/2011 10:27 AM, Kay Sievers wrote:
quoted
The usual enumeration in udev never uses the device tree in
/sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
have something to enumerate all child devices of a given device. It's
not simple, but could be made working.
The documentation in Documentation/sysfs-rules.txt seems to warn against
using /sys/class and sys/bus:
- devices are only "devices"
There is no such thing like class-, bus-, physical devices,
interfaces, and such that you can rely on in userspace. Everything is
just simply a "device". Class-, bus-, physical, ... types are just
kernel implementation details which should not be expected by
applications that look for devices in sysfs.
...
- all elements of a devpath must be real directories. Symlinks
pointing to /sys/devices must always be resolved to their real
target and the target path must be used to access the device.
That way the devpath to the device matches the devpath of the
kernel used at event time.
- using or exposing symlink values as elements in a devpath string
is a bug in the application
...
- accessing attributes reached by a symlink pointing to another device,
like the "device"-link, is a bug in the application
...
- Hierarchy in a single device tree
There is only one valid place in sysfs where hierarchy can be examined
and this is below: /sys/devices.
and more...
I figured that this document was probably out of date, since even libudev
uses /sys/class. What's your take on this document?