It's really useful feature now when we have the Pixelbook with large storage that fit pretty good for simple tethered shooting. It's when you're shooting with your dslr camera or even phone and see a preview on your chromebook that is connected to the camera. Or even saving photos to your chromebook.

Of course I can workaround this problem by using polling but it would be great if "contents_changed" worked.

<files-triage>

Assigning to tommycli@ for triage.

I believe we use file system monitors for addGalleryWatch. I would not be surprised if they do not work for PTP/MTP devices. I also doubt we will add support for watching PTP/MTP galleries.

I'll bounce this to thestig@ who is is the MTPd author if he has any further comment.

I don't have to work on this, but happy to help review code if someone else wants to take this bug.

Donna, would you be intersted in taking a look after finishing the servification work with the MTP code?

What needs to happen is:

a) mtpd has to listen for LIBMTP_EVENT_OBJECT_ADDED / LIBMTP_EVENT_OBJECT_REMOVED events from the device. It already listens for LIBMTP_EVENT_STORE_ADDED / LIBMTP_EVENT_STORE_REMOVED.
b) Add new DBus signals and fire them. See MtpdServer::StorageAttached() and dbus_bindings/org.chromium.Mtpd.xml.
c) On the Chromium side, the browser has to listen for the new signals and plumb them up to the extensions code. (This one is the most hand-wavy)

Even with all the code written, we still need to see what PTP/MTP devices actually send object added / removed events. If a particular phone or camera doesn't send the first place, all the work here won't help.

Hi Lei, I'd like to take this issue after MTP servicification and these hints are good points to follow. The only concern is that, I don't have a ChromeBook on hand, it may take some time to find a device for verification. Or, is ChromeBook a hard need to verify the issue?

I found a pixelbook, so take this bug.