Yes, I use the same version from ArchLinux repo, and that entry is present. But it adds those attributes just to this node
/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3:1.0 (usb)
and not to his parent
/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3 (usb)
making thunar (whole gvfs, I think) unable to recognize the camera.
This is due to the fact that just the child node has a modalias, the parent is matched by the old udev-rules function through its ID_USB_INTERFACES variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that this situation is at the moment unsolvable:
1) hwdb matches only against modalias
2) device node doesn't get modalias from kernel
3) gvfs doen't mount interface node
At least one of these three beahviours should be changed upstream.
The camera should be a FujiFilm FinePix JX370 with VendorID 04CB and ProductID 0250
Just out of curiosity, if we'd fix the PTP Class recognition, the USB ID list shouldn't become useless for cameras registered as PTP devices?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
and obviously gvfs works as expected.
But there's one thing I don't understand: if both this entry both the one referred to generic PTP class already present into 20-gphoto.hwdb match against a modalias (actually the same one, but by different patterns), why the former adds those two variables to the parent node too, and not just to the interface node like the latter does?
:-/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thus hwdb is not a dumb system that simply matches against the modalias string? It interprets its tokens and acquires their values, matching against the variables they refer to?
Awesome! I did totally underrate this mechanism.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually it is a dumb system doing matching of modalias style strings and then assigning udev variables when it triggers. Nothing more, no programming, no conditons.
I just wonder if I missed something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's something I don't get.
when hwdb read modalias and a pattern, it parses the strings and extracts all the values making a value-to-value matching, or it simply makes a string comparision between modalias and pattern passed?
If it's the latter, why there are different behaviours when you pass the first two tokens and when you pass the last three?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-06-10
So there are two obvious alternatives:
(1) Make gvfs look for PTP USB interfaces instead of USB devices. I don't know how much effort this is; I posted this on the corresponding GNOME bug as well, let's see what Ross thinks.
or
(2) Make the ID_GPHOTO2 tag for "generic PTP cam" appear on the parent
usb_device, too. AFAICS this isn't possible directly with hwdb, but it's
possible with a generic udev rule (we already had that in the past, before
moving to hwdb). Thus, when building with hwdb support, the generated udev rules could just contain the non-vendor/product matches (i. e. pretty much just the "generic PTP device" rule). This is the approach of media-player-info.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys, I'm the OP. :)
Some months ago I focused where the problem is and notified an udev guy, but totally forgot to reply to this ticket. Sorry. I copy/past the mail I sent to him:
I simulated by udevadm test the adding of the device, and I've seen into the output that usb devices match this rule at this line
If I've understood correctly, this should be the reason why the parent node, with this modalias added "at runtime", matches the hwdb entry based on VendorID & ProductID, and not the one based on PTP Class ID.
Thanks again for your courtesy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
do you use 2.5.3.1 ?
it generates this entry:
USB PTP Class Camera
usb:vic06isc01ip01
GPHOTO2_DRIVER=PTP
ID_GPHOTO2=1
which matches the PTP interface class.
(and I actually tested it ;)
there was a star (*) after v and at the end, but the editor threw it away ;)
Yes, I use the same version from ArchLinux repo, and that entry is present. But it adds those attributes just to this node
/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3:1.0 (usb)
and not to his parent
/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3 (usb)
making thunar (whole gvfs, I think) unable to recognize the camera.
This is due to the fact that just the child node has a modalias, the parent is matched by the old udev-rules function through its ID_USB_INTERFACES variable.
Well, we have to match what actually needs to be matched...
If the upstream code cannot handle that we just match the interface class, it is buggy and should be fixed.
I can do different hwdb rules, but I do think the problem lies in other layers.
(If you see cameras we do not know yet know by USB id, please send us reports.)
I think that this situation is at the moment unsolvable:
1) hwdb matches only against modalias
2) device node doesn't get modalias from kernel
3) gvfs doen't mount interface node
At least one of these three beahviours should be changed upstream.
The camera should be a FujiFilm FinePix JX370 with VendorID 04CB and ProductID 0250
Just out of curiosity, if we'd fix the PTP Class recognition, the USB ID list shouldn't become useless for cameras registered as PTP devices?
I just tried to add this entry to hwdb
usb:v04CBp0250*
GPHOTO2_DRIVER=PTP
ID_GPHOTO2=1
and obviously gvfs works as expected.
But there's one thing I don't understand: if both this entry both the one referred to generic PTP class already present into 20-gphoto.hwdb match against a modalias (actually the same one, but by different patterns), why the former adds those two variables to the parent node too, and not just to the interface node like the latter does?
:-/
The vendor/product device id matches the toplevel USB device, while the interface matches one of the many interfaces (so on a lower level).
Thus hwdb is not a dumb system that simply matches against the modalias string? It interprets its tokens and acquires their values, matching against the variables they refer to?
Awesome! I did totally underrate this mechanism.
Actually it is a dumb system doing matching of modalias style strings and then assigning udev variables when it triggers. Nothing more, no programming, no conditons.
I just wonder if I missed something.
There's something I don't get.
when hwdb read modalias and a pattern, it parses the strings and extracts all the values making a value-to-value matching, or it simply makes a string comparision between modalias and pattern passed?
If it's the latter, why there are different behaviours when you pass the first two tokens and when you pass the last three?
it matches the modalias as a pattern.
1 USB device gets multiple entries, like e.g. another PTP Camera:
KERNEL[1528.197903] add /devices/pci0000:00/0000:00:12.2/usb1/1-6/1-6.3 (usb)
KERNEL[1528.198518] add /devices/pci0000:00/0000:00:12.2/usb1/1-6/1-6.3/1-6.3:1.0 (usb)
the first is the toplevel device, the second is the PTP interface.
The device matcher would work on both (probably) and the interface matcher only works on the second.
If it just matches the modalias as a string, how could it matches against the device node (the toplevel one) that has no modalias at all?
You should ask this to the udev guys. ;)
can't do more here.
So there are two obvious alternatives:
(1) Make gvfs look for PTP USB interfaces instead of USB devices. I don't know how much effort this is; I posted this on the corresponding GNOME bug as well, let's see what Ross thinks.
or
(2) Make the ID_GPHOTO2 tag for "generic PTP cam" appear on the parent
usb_device, too. AFAICS this isn't possible directly with hwdb, but it's
possible with a generic udev rule (we already had that in the past, before
moving to hwdb). Thus, when building with hwdb support, the generated udev rules could just contain the non-vendor/product matches (i. e. pretty much just the "generic PTP device" rule). This is the approach of media-player-info.
We need to emit a UDEV rule file anyway again, to make sure the SCSI generic using devices work.
I committed emitting the generic ptp rule for
print-camera-list udev-rules version 201
Hi guys, I'm the OP. :)
Some months ago I focused where the problem is and notified an udev guy, but totally forgot to reply to this ticket. Sorry. I copy/past the mail I sent to him:
the hwdb contains the interface matcher
and we can still emit udev rule with a device matcher now.
in 2.5.5