<div dir="ltr"><div dir="ltr"><div>Hello world,</div><div><br></div><div>  As posted at <a href="https://github.com/networkupstools/nut/issues/300#issuecomment-969385505">https://github.com/networkupstools/nut/issues/300#issuecomment-969385505</a> and <a href="https://github.com/networkupstools/nut/issues/300#issuecomment-970243340">https://github.com/networkupstools/nut/issues/300#issuecomment-970243340</a> in greater detail, during the past weekend I have updated the "libusb-1.0" and "libusb-1.0+0.1" branches in NUT repository, so their proposed changes are integrated over the past few years of development in the master branch, and benefit from diverse building scenarios and environments on the new NUT CI farm.</div><div><br></div><div>  On one hand, this allows for more relevant testing for end-users (without having to choose *either* trying recent master-branch updates to NUT drivers, *or* trying if newer libusb-1.0.x (with one of the implementations of NUT logic for using it) resolves connectivity and other issues.</div><div><br></div><div>  Of course, over time these branches and master would differ again (so I hope to merge one of them after community testing and review), but layering newer master changes on top of their current state should be easier for people who would build such mixed-not-stirred NUT codebase experimentally in the future.<br></div><div><br></div><div>  On another hand, for developers and maintainers this branch resync allows to revise how the two branches differ between themselves and from master. It seems that "libusb-1.0+0.1" started from some point of "libusb-1.0", but I am not instantly sure if it is a superset, or if "libusb-1.0" also evolved after that bifurcation (other than `configure` script support added by me in the past few days) -- and there are some change sets from both that need to get into NUT. It should be much easier than before to find out, and I hope to get to that part during some next weekends.</div><div><br></div><div>  What this merging effort did uncover however, is that the code (both "original" master and in those branches) is plagued with some magical numbers that probably mean macros (specific? bit-masks?) defined in libusb, and at that with different names for different versions. And it may be an issue for recently merged efforts to make USB "endpoint" and "interface" numbers configurable and not hardcoded.<br></div><div><br></div><div>  This is detailed with examples in the issue linked above, so the goal of this message is: if you, dear reader, know your way around the logic and data of libusb (0.1, 1.0 or both), please take some time to figure out what happens with those calls in libusb(0,1).c and very similarly in some driver sources, to post PRs that would comment the logic behind numbers that should remain, or replace with proper macros and bit/math operations for those that should not be hardcoded and magical.</div><div><br></div><div>Thanks in advance,</div><div>Jim Klimov</div><div><br></div></div></div>