© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
(In reply to comment #0)
> Some laptops like the Dell Mini 10 have builtin SD card readers which are wired
> through an internal USB bus. The current behaviour is that if you click the
> eject button in nautilus, the card reader device gets ejected and disconnected,
> and cannot be reactivated ever, except by a reboot.
Huh, that's interesting, I never thought of that problem ;-).
(Also, the fact that Dell is so cheap that they use USB-connected SD readers is interesting in it's own right.)
> The cause of this is that DK-d's update_info_drive() sets "can_detach" for all
> USB devices currently, which causes devkit-
> called on them.
>
> So clearly this is too eager. Obviously there is no way to programmatically
> tell whether a particular USB device can actually be physically detached or
> whether it's sitting inside a case. So I see the following options right now:
>
> * If we can tell whether the device has removable media (like card readers),
> don't detach the reader device. Otherwise, continue to set can_detach. This
> still errs on the side of breakage, but at least would fix the behaviour with
> those card readers. I'm currently not sure whether this is feasible, I asked
> the original reporter for a dk-disks dump to check the properties.
>
> * Don't set can_detach for all USB devices, and just add udev rules which set
> ID_DRIVE_DETACHABLE for some known safe cases.
>
> This would again introduce a whitelist, something which we hoped to get rid
> of with https:/
>
> So my question is, why was this current can_detach behaviour introduced? Are
> there some devices where not even eject is enough? Years ago, when I tested
> this with an iPod, umount wasn't sufficient, but eject made the "unsafe to
> remove blabla" warning go away.
The different between DriveEject() and DriveDetach() is that the latter makes the whole device go away while the former only makes partitions go away. DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove blabla" warning go away.
Maybe we can look at the usb interface classes to avoid ejecting USB connected card readers? I also think the DMI data tells you whether a particular usb port has an external receptable - I remember Kay talking about that (adding to Cc).
If this works for the Dell Mini maybe we can use this and vendors who are not properly populating DMI data will suffer (and we'd quirk this up via udev rules).
I don't know. Please also ask the original reporter for output of dmidecode and 'tree /sys'. Thanks.