Today I released the first version of GNOME MultiWriter, and built it for Rawhide and F21. It’s good enough for a first release, although there are still a few things left to do. The most important now is probably the self-profiling mode so that we know the best number of parallel threads to use for the read and the write. I want this to Just Work without any user interaction, but I’ll have to wait for my shipment of USB drives to arrive before I can add that functionality.
Also important to the UX is how we display failed devices. Most new USB devices accept the ISO image without a fuss, but the odd device will disconnect before completion or throw a write error. In this case it’s important to know which device is the one that belongs in the rubbish bin. This is harder than you think, as the electrical port number is not always what matches the decal on the plastic box.
For my test system I purchased a 10-port USB hub. I was interested to know how the vendor implemented this, as I don’t know of a SOIC chip that can drive more than 7 ports. It turns out, my 10-port hub is actually a 4-port hub, with a 7-port hub attached to the last port of the first hub. The second hub was also wired 1,2,3,4,7,6,5 rather than 1,2,3,4,5,6,7. This could cause my dad some issues when we tell him that device #5 needs removing.
I’ve merged some code into GNOME MultiWriter to work around this, but if you’ve got a hub with >7 ports I’d be interested to know if this works for you, or if we need to add some more VID/PID matches. If you do try this out you need libgusb from git master today. Helpfully gnome-multi-writer outputs quirk info to the command line if you use --verbose, so that makes debugging this stuff easier.
One thought would be for MultiWriter to support an identification step.
Most USB keys have a write indicator light. It may be possible, if writing fails in some way, to strobe the light. Failed keys could then simply flash at a periodic interval. This may be somewhat difficult as you’ll have to determine how much to write to strobe the light appropriately. You’d also have to deal with failures. But it might be workable.
Alternatively, you could have an identification process before writing the image. This would write some data in a stream to a USB key while the user identified the key. Repeat for all keys. Once all keys are properly identified, writing would begin. This requires more manual work for the user.
Lastly, you could simply have an “identify” button which would perform steady writes to the key to keep the write indicator light on. You could show this button on keys that fail.
Not all USB keys have LEDs — especially the cheap ones :(
Another idea that does not rely on the stick having a led: all ok->done, one or more failed->ask user to remove one by one, detect which one was removed, tell user if the last one goes into OK-pile or trashcan.
Yes, that could work. I.e. a “bing” if the USB stick just removed and a “buzz buzz” if it belongs in the bin. Can you file that as an issue in github please.
Hi,
I wanted to reach out to you and offer several of our 7 and 10 port USB hubs to you for VID/PID matching and/or USB port mapping. We’ve got hubs with 4+4, 4+7, and 4+4+4 chipset configurations. The 4+4+4 design can be particularly troublesome for some users.
If you’re interested in some free hubs to test/review/etc for your project just let me know!
Best wishes,
Josh @ Plugable
I’d love to take you up on your offer if that’s okay. I’ve sent you an email with my contact details, thanks!