Hey, I solved this by adding a udev rule for the device in /etc/udev/rules.d, and it now works! For anyone else on Linux with a similar problem, this is what I did:
You need the USB vendor and product ID of the device, for the seed it is “0483” and “df11”, respectively. It will be the same for you, but if you want to check, you can open a console and type lsusb | grep DFU, then look for the two numbers “ID xxxx:xxxx”.
In a console type sudo nano /etc/udev/rules.d/50-daisy-stmicro-dfu.rules
Ctrl+O, then Enter to save, Ctrl+X to exit nano. Disconnect / reconnect the seed, and press BOOT then RESET. You should now be able to connect with the web programmer.
Note: You may want to check that you are in the plugdev group (but you probably are), by typing groups
Thank you very much kborch !
It worked for me after some adjustments.
I’m on a Manjaro distro (ArchLinux family).
1- to find the IDs of the Daisy I typed lsusb -v
2- I changed the GROUP to one I’m already in
3- I had to reboot.
So glad it works on my linux laptop !
Cheers !
Xavier
I don’t think you can, on Ubuntu. The Linux Mint devs – which have Ubuntu upstream from them – threw a shitfit about this (see here, for example Monthly News – May 2020 – The Linux Mint Blog).
In mint, I was able to manually install chrome using the .deb from google’s chrome website.
(Then got SecurityError when trying to access usb devices in the web programmer… had to do the udev rules fix documented previously in the thread, too.
I assume you’ve already found a solution, but I’ll add this here as one possible solution (for those who don’t want to manually update a Chromium .deb all the time or set up an automation process for that…):
(Funny Story: After adding udev rules, adding myself to the plugdev group, and restarting the system, I was able to flash ‘Blink’ on Snap Chrome before “They” knew what I was doing (I think) by opening Chrome immediately after login. Post flashing, the “connect” button was stuck on “disconnect” after Flashing (not correct behavior ). After the (Snap) rules loaded, the Daisy Seed was not allowed on Snap Chromium. This also was the result using Brave browser(chromium variant).
As an added bonus, this .deb browser is ORDERS of MAGNITUDE faster than Snap for uploading to MCUs.
Anyway, I’m just glad it works now.
Best of building to you.
I would not consider this solved. Linux users shouldn’t have to create special udev rules when Windows users don’t. Daisy firmware updates are one of the lingering reasons I keep a Windows VM around so I don’t have to muck about with this.