On Mon 26 Jun 2023 at 19:45:45 (+0200), to...@tuxteam.de wrote: > On Mon, Jun 26, 2023 at 10:46:32AM -0400, gene heskett wrote:
> > Something with "gvfsd-gphoto2 service" in its name is being blamed for > > digiKam being able to see the pix in the camera when a usb cable is plugged > > into it [...] I don't know anything about gvfs* and gio. Perhaps they're since my time. > This would hint at an udev rule. I have little idea about the brave new > systemd world, but this one [1] recommends doing (in a terminal, most > likely with sudo): > > udevadm control --log-priority=debug > journalctl -f > > the first one setting the udev system into debug mode, the second one > doing what amounts to a 'tail -f /var/log/messages' > > So try this and watch things unfolding while you plug in and out your > expensive camera. Most probably we get a hint on which package you > are supposed to configure so it doesn't get in the way. I prefer to use: $ udevadm monitor -u -p to see what udev is doing. This monitors everything, so concentrate on a single device when using it, or other unrelated messages will get interspersed. Gene said that he got a lot of output; well, yes, a lot goes on, and in my case, connecting a digital camera produces 17 actions/paragraphs, headed by: add /devices/virtual/workqueue/scsi_tmf_8 (workqueue) add /devices/pci0000:00/0000:00:14.0/usb2/2-2 (usb) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0 (usb) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8 (scsi) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/scsi_host/host8 (scsi_host) bind /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0 (usb) bind /devices/pci0000:00/0000:00:14.0/usb2/2-2 (usb) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0 (scsi) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0 (scsi) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/scsi_disk/8:0:0:0 (scsi_disk) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/scsi_device/8:0:0:0 (scsi_device) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/bsg/8:0:0:0 (bsg) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/scsi_generic/sg4 (scsi_generic) add /devices/virtual/bdi/8:48 (bdi) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/block/sdd (block) add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0/block/sdd/sdd1 (block) bind /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host8/target8:0:0/8:0:0:0 (scsi) As you can see, a disk device gets created by the last two add actions. I would then refine the monitor line to: $ udevadm monitor -u -p -s block/partition filtering out all but those adds, ie USB devices, sticks, etc. I could then write a udev rule matching the camera model given in the ID_SERIAL property (for the internal memory), and/or automatically create mount points under /media for any partitions observed in IS_FS_LABEL/UUID/etc properties. I realise that many modern cameras won't make their memory or card available straightforwardly like this, but I think that udevadm's properties option might at least show what you're working with. I couldn't see much of any use in the debug output posted by Gene. It may be that that's more useful for debugging udev itself rather than tracking what udev is successfully doing. Cheers, David.
