This is a complicated issue, and I'm having a tough time wording the summary. Apparently there's a fairly substantial change in the 4.14 kernel series that breaks existing udev rules for mostly generic USB (userspace driver) hotplug devices. This does not seem to affect hotplug of kernel drivers like usb-storage. When a device is plugged in, an add event is generated. In newer kernels (4.14) a bind event is also inserted into the queue to udev. Udev decides to clear a lot of the rules that were done during the add event, specifically tagging, and causes things to break. These tags are used by userspace generic library drivers, and I think: - mtp devices - ptp devices - some USB modems not using kernel drivers - USB printers not using the kernel driver are affected. Generally their packages install a udev rule that tags the devices to flag the user space driver to operate them and the tag gets cleared on bind. This caused shotwell to break for me. I'm not entirely sure but I think libgphoto2 tools don't use the same method shotwell uses to detect cameras. I believe libmtp https://bugs.gentoo.org/664666 and https://bugs.gentoo.org/658836 are related. For me with stable, plugging in a camera while shotwell is running results in the camera is not detected at all despite going through the motions in dmesg. Hacking the udev rule in /lib/udev/rules.d/70-libgphoto2.rules: -ACTION!="add", GOTO="libgphoto2_rules_end" +ACTION!="add|bind", GOTO="libgphoto2_rules_end" restores operation for me. It appears libmtp took this approach upstream and whether libgphoto2 needs to do the same, but I'm not sure what the udev people will do: https://github.com/systemd/systemd/issues/8221 Someone supplied a workaround patch to udev to ignore the bind events to make things work like they had before. It seems like the kernel broke userspace and not going to fix it? I don't know what's the best course of action for Gentoo for now, just adding this bug in case people weren't aware of the issue.
Could you look at libgphoto2-2.5.20. If it is still problematic, you might want to take this issue upstream as I clearly cannot reproduce with the camera I own.
I downloaded the 2.5.20 code and it appears it has not changed, and will generate the same unusable udev rules for shotwell. Looks like there were some updates in by poettering in the past 2 weeks, and he does not want to change udev/systemd, and coupled with the kernel not want to revert(?), seems userspace needs to fix it... The question is, who owns the bug: shotwell or libgphoto2 -- libgphoto2 components appear to still work as needed, but it was shotwell broke. Shotwell needs libgphoto2 to change as it depends on udev flagging things correctly. Twisted web we weave, and I don't think keeping a local patch against $LIBGPHOTO2_ROOT/packaging/generic/print-camera-list.c (this is the program that generates the udev rules!) is what we want either...
The workaround fix was in shotwell: https://gitlab.gnome.org/GNOME/shotwell/issues/4 Ubuntu did put the fix in shotwell via a local patch: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1772913 So I guess the answer is a new release of shotwell is needed that rips out the custom udev handling it does...whatever that is...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=51788dacf249b00be488bc801e1fb66238d25c85 commit 51788dacf249b00be488bc801e1fb66238d25c85 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-03-03 14:58:58 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-03-03 15:05:51 +0000 media-libs/libgphoto2: bump to 2.5.22 This release handles new "bind" udev event in udev rule generator, which our rule generation logic picks up from the print-camera-list output (which specifically adds it). Closes: https://bugs.gentoo.org/670064 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> media-libs/libgphoto2/Manifest | 1 + media-libs/libgphoto2/libgphoto2-2.5.22.ebuild | 211 +++++++++++++++++++++++++ 2 files changed, 212 insertions(+)
I'm guessing shotwell may still be broken even against this new libgphoto2? Just curious, we'll eventually get the shotwell bump done anyways
Shotwell may very well work fine now actually, since supposedly now libgphoto2 is doing what shotwell needs - the udev tag - that was lost with the bind event. I have yet to inspect the code and ensure this works, but if the bind event is now handled by libgphoto2 I think this may be fully fixed. It was funny that libgphoto2 itself was working just fine without the tag. Will test soon, I need to go shovel snow right now...
