Good. I assume PsychHID did output a big chunk of text with troubleshooting instructions. Let’s see if they are clear enough to help you fix your script, should be a one-line fix. Then those warnings should go away. Also, if you do a
sudo dmesg | grep claim
right now, you should see something similar to …
“[52226.184396] usb 1-1: usbfs: process 19115 (PTB mainthread) did not claim interface 0 before use” ? → Indication that the bug is the bug i think it is.
Btw. you should also try to manually install that argyll config file in your repo into the /etc/udev/rules.d/ subfolder, so you can run Matlab without sudo. The config file that comes with Ubuntu does not contain the SpyderX, only the Spyder1 - Spyder5 i think.
Bed time here,
-mario
Dear Mario,
Yes, as you pointed out, the bug is caused by did not claim interface 0 before use, as can be seen from the info list below:
>> [XYZ] = spyderXComProtocol('initial')
PsychHID-WARNING: No kernel driver attached, or usbfs kernel driver attached, to interface 0 after libusb_claim_interface() with auto-detach!
PsychHID-WARNING: This is known to happen if the calling (user) script has a certain bug. Specifically if the
PsychHID-WARNING: script called PsychHID('USBControlTransfer', ...) on an USB endpoint other than endpoint zero,
PsychHID-WARNING: or directly on a interface, *and* it didn't first manually claim the USB interface (associated with
PsychHID-WARNING: that endpoint if any), as required by USB spec, and the associated interface did not have a kernel
PsychHID-WARNING: driver attached already. At least the Linux kernel (maybe also other operating systems?) would try
PsychHID-WARNING: to fix/workaround this mistake by auto-claiming the interface. This may work for the control transfer,
PsychHID-WARNING: but it can cause successive failure, if the script afterwards claims the same interface manually via
PsychHID-WARNING: PsychHID('USBClaimInterface', ...), or indirectly via attempting a bulk-/interrupt-/iso-transfer.
PsychHID-WARNING: I will try to fix this problem now, which may or may not work to keep your script going. We'll see...
PsychHID-WARNING: However, please fix the offending user script properly by explicitely claiming the proper interface
PsychHID-WARNING: before issuing a control transfer to such a non-zero endpoint or to an interface directly.
PsychHID-WARNING: Note: bmRequestType bits 0-4 select the recipient, wIndex defines the endpoint address or interface.
XYZ =
[]
yang@yang-MacBookPro:~$ sudo dmesg | grep claim
[ 0.266732] pci 0000:03:00.0: can't claim BAR 6 [mem 0xfffff800-0xffffffff pref]: no compatible bridge window
[ 91.662932] usb 3-1: usbfs: process 7372 (PTB mainthread) did not claim interface 0 before use
However, following the instruction of the WARNING info, I tried to add an extra command line, “PsychHID('USBClaimInterface', usbHandle, 0);” before the first use of bulk transfer, the warning info was still there. Any suggestions?
BTW, I have tested the script under the normal user mode of MATLAB, and it works since I already have a config file in the rules.d directory.
Best, and thank you again for your warm help.
-Yang
Great. The instructions of PTB-WARNING try to tell you that that ‘USBClaimInterface’ call should go before the very first USBControlTransfer, not before the first Bulk/Interrupt transfer. Iow. best put it immediately after PsychHID('OpenUSBDevice', ...);
Then both the PsychHID warnings and warnings in the kernels dmesg log should no longer show on successive use.
-mario
Dear Mario,
Thanks, after claiming the interface just after OpenUSB, the warning info is gone.
Now, I am moving toward testing PsychHID for windows and will let you updated.
-Yang
Best
1 Like
Dear Mario,
Thanks for your kind and generous help in extending PsychHID to support bulk transfers!
I have finished all tests for controlling spyderX with spyderXComProtocal.m and PsychHID across Windows, Linux, and Mac OS, and confirmed that spyderXComProtocal.m can work fine across the three platforms.
A little surprise under Windows is that spyderXComProtocal works fine with Windows’ built-in driver (
) instead of the customized driver from argyll, which is a slight bit headache in installation.
So now I was wondering if it is possible to add spyderXComProtocal.m (I have changed the name to spyderX.m to follow the name rules of PTB) into Psychtoolbox just like ColorCal2?
Best
-Yang
Dear Mario,
I have carefully tested spyderXComProtocol.m (now renamed to spyderX.m) across the three platforms and confirmed that it is ready to move to the next step. We are prepared to integrate spyderX.m into PTB without relying on spotread.
However, the latest beta version of PTB (svn 13009) does not contain the new PsychHID file supporting bulker transfer. Do you mind letting me know to get the latest version of PsychHID automatically via SVN instead of downloading from the addresses list in this thread?
Below is the version info of the latest version of PTB updated via SVN:
PsychtoolboxVersion
ans =
'3.0.18 - Flavor: beta - Corresponds to SVN Revision 13009
For more info visit:
https://github.com/Psychtoolbox-3/Psychtoolbox-3'
>> PsychHID('Version')
ans =
struct with fields:
version: '3.0.18.602983213'
major: 3
minor: 0
point: 18
build: 602983213
date: 'Oct 3 2021'
time: '23:20:13'
module: 'PsychHID'
project: 'OpenGL Psychtoolbox'
os: 'Microsoft Windows'
language: 'Matlab 64-Bit'
authors: [1×5 struct]
Thank you very much for your kind help!
-Yang
Ja, there’s further delays. New ETA for the initial 3.0.19 release with new PsychHID and lots of other stuff is last third of January, but expect it to slip further. This will be one of those monster releases where everything depends on everything else, so intermediate releases are not safely possible, mostly because a lot of dependencies will change, with potential for mayhem. E.g., Matlab upgraded from R2022a → R2022b, macOS 10.15 → 12.x, XCode updated from something to something, GStreamer updated to 1.20.x, fontconfig updated in highly backwards incompatible ways, libusb, …
The main blocker is the new OpenXR driver for virtual reality/augmented reality/mixed reality, which is a pig of complexity that keeps delaying releases since many months. Turns out all the proprietary OpenXR runtimes are piss-poor in software quality and require tons of workarounds. Only the Monado open-source runtime for Linux has proven to be of so far excellent quality, but that one has some other limitations, and the point of OpenXR is that it “works” (muwahahahahaha) with many different vendors runtimes and VR/AR/MR devices on different operating systems. That and a barrage of constant interruptions by unrelated work that brings in occassional pennies of money, as we are so poorly funded we need to chase every buck, now often to the detriment of what would be good in the greater scheme of things…
You could look at SwitchToNewPsychtoolboxHoster.m for example code on how to temporarily svn switch your existing PTB repo from the GitHub Psychtoolbox-3 account to the kleinerm account. Or git checkout my master branch. Or just wait - there’s nothing more recent than what you have right now.
I hoped to get this stuff done before the 2 week christmas break, but nope, some awful bugs and limitations in the proprietary SteamVR OpenXR runtime for Linux and Windows threw new wrenches into my planning. And christmas is around the corner, so at some point it is time to give up and enjoy the sound of deadlines whoosing by…
-mario
All that said, I agree it would make sense to integrate your SpyderX.m driver into PTB’ general colorimeter routines, so it can be automagically used like other devices, e.g., the ColorCal-II or various PR-xxx photometers/colorimeters.
Btw. I’m also surprised your stuff would just work on MS-Windows without that custom (winusb?) usb driver (bundled with Argyll?) and just with Windows built-in driver? Have you retested this on a “virgin” MS-Windows machine you haven’t used before, to see if you weren’t tricking yourself there somehow? My understanding was that the builtin backend just (ab-)uses the Windows HID subsystem, and seems to be the most limited one of four(!) different Windows USB backends for MS-Windows - Windows seems to be quite a complexity nightmare in the USB department. A nice side-effect of our little PsychHID bulk-transfers project was a bug-fix by myself to the MS-Windows USB support of libusb, queued for release in upcoming v1.0.27, so I spent learning quite a bit of extra stuff about Windows USB that i never intended to have to learn…
I’d go even further. I had a quick skim of spotread’s Argyll CMS C-source code for the Spyder-X. In principle it should be relatively straightforward to translate more Argyll USB drivers to equivalent M-Files using PsychHID. That spares the USB protocol reverse engineering and you learn about all the hacks Argyll uses to workaround what seems to be various poor quality firmware and kinks of common measurement devices out there. E.g., iirc Argyll didn’t use USB control transfers at all during Spyder-X init, doing with simpler code. Given that this is not literally copying code, but just concepts, no licensing restrictions should apply, apart from giving credit to that fantastic software.
Even if licenses would have to be taken into account, Argyll’s code is GPL licensed afaics. Normally something we do stay far away from in most cases, as GPL code is incompatible with use under proprietary host applications like Mathworks Matlab, and with various proprietary vendor libraries. But in this case, no 3rd party non-system libraries are involved and all the code would be one or a few M-Files which are open-source anyway, so GPL in this specific case would not be a problem.
Long story short: I’d encourage you to see if you could use this translation approach to relatively easily and fast add open-source PTB/PsyCalibrator support for a whole host of colorimeters/photometers.
In general we should advertise nice open-source toolboxes like yours more on the forum or the psychtoolbox.org website or Wiki. It’s a shame if such good work like yours gets less use than what would be possible.
-mario