Description of problem: The provided fxload RPM does not support USB3 devices using the fx3 flag. This is because the version of fxload is based from a very old version of libusb. libusb is now packaged as libusbx, and a more recent version of fxload is provided with the same sources as libusbx Version-Release number of selected component (if applicable): libusbx-1.0.23-2 fxload-2008_10_13-16 How reproducible: Steps to Reproduce: 1. A USB3 hardware device such as a QHY163M is needed, making this difficult to test 2. Using existing fxload RPM, firmware is not loaded and the device is not recognized 3. Actual results: device not recognized Expected results: USB3 device is recognized and usable Additional info: The fxload RPM is far out of date from the libusbx RPM. These should be kept in sync. It might even make sense to combine fxload into libusbx as they are part of the same source code repository. https://github.com/libusb/libusb/tree/master/examples Initially reported here: https://github.com/indilib/indi-3rdparty/issues/257
I'm the package maintainer for the fxload package. Would the libusbx package maintainers be willing ship a fxload subpackage to replace the ancient standalone one? It would involve installing /usr/bin/libusb-example-fxload as /sbin/fxload and I would retire the standalone package. There would need to be some coordination with other packages because the fxload command line argument syntax changed a bit and there is some missing (but perhaps unneeded) functionality in the new version. We may also want to port the manpage over and update it. Old syntax: >/sbin/fxload no device specified! usage: /sbin/fxload [-vV] [-l] [-t type] [-D devpath] [-I firmware_hexfile] [-s loader] [-c config_byte] [-L link] [-m mode] ... [-D devpath] overrides DEVICE= in env ... device types: one of an21, fx, fx2, fx2lp ... at least one of -I, -L, -m is required Old functionality missing from new: -L link Creates the specified symbolic link to the usbfs device path. This would typically be used to create a name in a directory that would be searched by an application. The symlink would be removed by some other component on device unplug. -m mode Changes permissions on the "usbfs" device node. By default, those nodes are only accessible by privileged users, which doesn't help when the user mode device driver needs to run without root privileges. Note that usbfs mount options like devmode=0666 are also available. -c config Indicates the specified firmware should be downloaded to an I2C boot EEPROM rather than to RAM. The parameter is the EZ-USB FX or FX2 con‐ figuration byte, and for AnchorChips devices the value should be zero. This requires a second stage loader (e.g. vend_ax.hex) that knows how to write to I2C EEPROMs specified using the -s option, as well as a de‐ vice that's provided with an EEPROM large enough to store the boot firmware. After downloading to a device's EEPROM, you should retest it starting from power off. New syntax: >/usr/bin/libusb-example-fxload no firmware specified! Usage: fxload [-v] [-V] [-t type] [-d vid:pid] [-p bus,addr] [-s loader] -i firmware -i <path> -- Firmware to upload -s <path> -- Second stage loader -t <type> -- Target type: an21, fx, fx2, fx2lp, fx3 -d <vid:pid> -- Target device, as an USB VID:PID -p <bus,addr> -- Target device, as a libusb bus number and device address path -v -- Increase verbosity -q -- Decrease verbosity (silent mode) -V -- Print program version >sudo dnf repoquery --whatrequires /sbin/fxload Last metadata expiration check: 1:40:06 ago on Tue 15 Dec 2020 10:17:31 AM EST. >sudo dnf repoquery --whatrequires /usr/sbin/fxload Last metadata expiration check: 1:40:14 ago on Tue 15 Dec 2020 10:17:31 AM EST. >sudo dnf repoquery --whatrequires fxload Last metadata expiration check: 1:40:21 ago on Tue 15 Dec 2020 10:17:31 AM EST. alsa-tools-firmware-0:1.2.2-3.fc33.x86_64 midisport-firmware-0:1.2-25.fc33.noarch midisport-firmware: /usr/lib/udev/rules.d/42-midisport-firmware.rules ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0763", ATTRS{idProduct}=="1001", RUN+="/sbin/fxload -s /lib/firmware/MidiSportLoader.ihx -I /lib/firmware/MidiSport2x2.ihx -D %N" ... etc. alsa-tools-firmware: /lib/udev/tascam_fw: FLAGS= LOADER=/sbin/fxload $LOADER $FLAGS -s $LOADERFIRMWARE -I $FIRMWARE -D $DEVNAME The new fxload would provide support for USB3 devices using the -fx3 flag. It doesn't appear that the -L, -m, or -c functions are used by the existing Fedora packages, but there may be 3rd party software that needs them.
Well, from a purely distribution point of view, the change seems simple enough (i.e. the two audio firmware packages need to be adjusted). But, I have no idea what other 3rd party users may be out there. And it seems like the libusb fxload demo application has a completely different way of selecting the device (vid:pid or bus:addr vs. device path). To be fair, the libusb one is probably saner, but if there are any 3rd parties, they'll be unhappy about it. So, fine with me in general. But if anyone knows more about typical third party users of fxload, I would appreciate feedback. The initial bug sounds like it would be a welcome change.
It's coming up on a year, and the people that asked for this to be updated downstream in the projects I work in have amazing patience, but would it be possible to move forward on this? Thanks Jim
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
I just discovered this bug while doing some searches related to fxload. I also just finished building fxload from the sources in libusb/examples and the result is certainly superior to the fxload currently being distributed as a Fedora package. 1) it has support for fx3 devices (or says it does) as per the original bug that started this. 2) It allows the target device to be specified via vid:pid rather than using the -D switch. The -D switch in the ancient version (currently being distributed) expects "the "usbfs" path name for the device in question, such as /proc/bus/usb/004/080". As most readers of this know, /proc/bus/usb no longer exists. Working up an analogous path name using /sys/bus/usb is not so straightforward and has so far eluded me -- and it is entirely the wrong way to go about things. Using libusb and a vid:pid is certainly the way to go and the version I just built from the libusb examples addresses this. I thank Charles Anderson for his comment almost 2 years ago. Clearly this issue and bug has entirely stalled, but it would be nice if it would get back on the table. The currently distributed version of fxload is all but useless.
I'm willing to help libusbx maintainers to move this forward as a subpackage. Otherwise, would it be acceptable for me to package the libusbx version in the existing fxload package using the same upstream source tarball? In other words, Fedora would have two source packages, libusbx and fxload, both containing the same source tarball.
(In reply to Charles R. Anderson from comment #9) > I'm willing to help libusbx maintainers to move this forward as a > subpackage. Otherwise, would it be acceptable for me to package the libusbx > version in the existing fxload package using the same upstream source > tarball? In other words, Fedora would have two source packages, libusbx and > fxload, both containing the same source tarball. libusbx --> libusb1
(In reply to Charles R. Anderson from comment #9) > I'm willing to help libusbx maintainers to move this forward as a > subpackage. That is great thank you. > Otherwise, would it be acceptable for me to package the libusbx > version in the existing fxload package using the same upstream source > tarball? In other words, Fedora would have two source packages, libusbx and > fxload, both containing the same source tarball. Having fxload as a regular subpackage if libusb would be best and I see no reason why that cannot be done. So IMHO there is no need for a separate source package. If you can prepare the suggested modifications for adding a fxload sub-package then we will review them and get them merged. It would be ideal if you can submit a pull-request through the pagure gitforge interface: https://src.fedoraproject.org/rpms/libusb1 Or alternatively you can attach a .spec file with the suggested modifications here.
@cra Hi Charles, Could you also consider making fxload to be a plugin in fwupd as well? It could be much easier to manage the process of flashing the devices. The git repo URL is shown as follows. https://github.com/fwupd/fwupd Thank you :)
I think this would be perfect for a fwupd plugin, and I'd be happy to help in whatever way.
(In reply to Hans de Goede from comment #11) > If you can prepare the suggested modifications for adding a fxload > sub-package then we will review them and get them merged. It would be ideal > if you can submit a pull-request through the pagure gitforge interface: > https://src.fedoraproject.org/rpms/libusb1 The old fxload package EVR compares newer than the libusb1 package EVR: $ rpmdev-vercmp 2008_10_13-21.fc38 1.0.25-10.fc38 2008_10_13-21.fc38 > 1.0.25-10.fc38 How best to deal with this? Keep a separate version for the fxload subpackage? Or bump the epoch of the whole libusb1 package? Adding Epoch: 1 would work but I'm not sure that is the best option: $ rpmdev-vercmp 2008_10_13-21.fc38 1:1.0.25-10.fc38 2008_10_13-21.fc38 < 1:1.0.25-10.fc38 There isn't really a "version" maintained for fxload--in fact, the binary just uses the build date for the -V argument which isn't very helpful IMO: $ grep FXLOAD_VERSION * fxload.c:#ifndef FXLOAD_VERSION fxload.c:#define FXLOAD_VERSION (__DATE__ " (libusb)") fxload.c: puts(FXLOAD_VERSION); $ fxload -V The closest thing to a proper version would be to use the date of the latest git commit of the files ezusb.c, ezusb.h, and fxload.c and remember to update that when it changes: %package -n fxload Version: 2022_01_22 $ rpmdev-vercmp 2008_10_13-21.fc38 2022_01_21-10.fc38 2008_10_13-21.fc38 < 2022_01_21-10.fc38
I did not realize there also was an older fxload already packaged. In this case I think it is best to call the new package libusb-fxload (I was expecting that as a name anyways) and then add: %global last_fxload_ver 2008_10_13-25 Provides: fxload = %{last_fxload_ver} Obsoletes: fxload < %{last_fxload_ver} Note I have deliberately added a few extra bumps to the release field of the old fxload pkg here, in case it still gets a new build done before we retire it. As for using a different version for the fxload subpackage I don't think that is supported/works. I certainly have never seen that be used before, so even if it works it does not sound like something which we would want to do.
(In reply to Hans de Goede from comment #15) > I did not realize there also was an older fxload already packaged. > > In this case I think it is best to call the new package libusb-fxload (I was > expecting that as a name anyways) and then add: > > %global last_fxload_ver 2008_10_13-25 > > Provides: fxload = %{last_fxload_ver} > Obsoletes: fxload < %{last_fxload_ver} > > Note I have deliberately added a few extra bumps to the release field of the > old fxload pkg here, in case it still gets a new build done before we retire > it. I'll try that. As long as "dnf install fxload" and the Requires: used in firmware packages still works it should be fine. I'd probably just use 2009_01_01 or something, because there hasn't been any upstream release in ages. > As for using a different version for the fxload subpackage I don't think > that is supported/works. I certainly have never seen that be used before, so > even if it works it does not sound like something which we would want to do. It does work, and it is fully supported. Perl does it for example: %global perl_version 5.36.0 %global perl_epoch 4 Epoch: %{perl_epoch} Version: %{perl_version} Release: 491%{?dist} %package interpreter Version: %{perl_version} Epoch: %{perl_epoch} %package utils Epoch: 0 Version: %{perl_version} %package Archive-Tar Epoch: 0 Version: 2.40 %package Attribute-Handlers Epoch: 0 Version: 1.02 %package autodie Epoch: 0 Version: 2.34 %package AutoLoader Epoch: 0 Version: 5.74 %package AutoSplit Epoch: 0 Version: 5.74 %package autouse Epoch: 0 Version: 1.11 %package B Epoch: 0 Version: 1.83 %package base Epoch: 0 Version: 2.27 ...
> I'll try that. As long as "dnf install fxload" and the Requires: used in firmware packages still works it should be fine. I'd probably just use 2009_01_01 or something, because there hasn't been any upstream release in ages. Yes the Provides: should keep "dnf install fxload" + any Requires on it working. > It does work, and it is fully supported. Perl does it for example: Interesting I did not know that.
(In reply to Hans de Goede from comment #15) > %global last_fxload_ver 2008_10_13-25 > > Provides: fxload = %{last_fxload_ver} > Obsoletes: fxload < %{last_fxload_ver} I'm not sure about this. According to: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages "If a package supersedes/replaces an existing package without being a sufficiently compatible replacement as defined above, use only the Obsoletes: line from the above example." it should be something like this without the Provides: %global last_fxload_ver 2008_10_13-100 Obsoletes: fxload < %{last_fxload_ver} because the command line syntax is not 100% compatible with the old fxload as per my Comment #1. We'll also need to modify the 2 distro packages that are using fxload today to adjust the udev rules for the new syntax. I maintain midisport-firmware, so I can do that one. But I'm not sure yet how the old -D option should be converted to -d or -p.
(In reply to Charles R. Anderson from comment #18) > (In reply to Hans de Goede from comment #15) > > %global last_fxload_ver 2008_10_13-25 > > > > Provides: fxload = %{last_fxload_ver} > > Obsoletes: fxload < %{last_fxload_ver} > > I'm not sure about this. According to: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or- > replacing-existing-packages > > "If a package supersedes/replaces an existing package without being a > sufficiently compatible replacement as defined above, use only the > Obsoletes: line from the above example." > > it should be something like this without the Provides: > > %global last_fxload_ver 2008_10_13-100 > > Obsoletes: fxload < %{last_fxload_ver} > > because the command line syntax is not 100% compatible with the old fxload > as per my Comment #1. Hmm, but if you want: dnf install fxload to still work then you need the Provides, IMHO the Provides still makes sense here. > We'll also need to modify the 2 distro packages that are using fxload today > to adjust the udev rules for the new syntax. > I maintain midisport-firmware, so I can do that one. But I'm not sure yet > how the old -D option should be converted to -d or -p. Ok. Note I'm a proven packager so if you can adjust the other package too I can take care of pushing that out. We should probably start with F37 + rawhide and then a bit later push all 3 modified packages to F36 in a single bodhi update. I suggest that you also change the Requires in the modified packages to libusb-fxload so that they cannot accidentally be installed together with the old fxload (with the slightly different cmdline handling).
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.