You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been checking through our USBD module, while implementing the missing functions (auto loader registration, unregistration and sceUsbdChangeThreadPriority).
I noticed that our module has got different values from the official USBD module, when it comes to timeouts. For example, the one in this line is 5 in the original, while ours is now 10. I saw that it was once 4 too, until commit 381ba62.
The value used for DEVICE_READY seems to be different too; ours is 5, while the Sony USBD used 7.
In 2010, I had a USB enclosure that would not be properly communicated with by USBD. Unfortunately, I wasn't that good with PS2 development yet and did not try to use the Sony module. I no longer have that enclosure either.
I wrote about it here, although I did not (and still don't) understand the logic behind the things I tried: http://psx-scene.com/forums/f19/usb-mass-device-driver-usbhdfsd-compatibility-fix-some-usb-devices-73420/
I suspect that our module was based on some really early version, but I don't seem to have a module that shares the same values.
The earliest module that I have is v0.13, from August 2000. Does anybody know where I can get an earlier module to check against? Or how these differences in values came about?
I also noticed this patch (a8c9a3a) by Radad in 2009. He added a connected device list.
I don't really understand what advantage this patch would give. If USB devices are connected in a tree, shouldn't the parse order be no different from when the device tree is traversed in prefix order from root?
I took a while to figure out why we had two tree-parsing functions until I realized that we're using an unofficial version. If it offers no advantage but actually increases the complexity of the code, I am in favour of rolling back that patch.
The text was updated successfully, but these errors were encountered:
I have rolled back a8c9a3a, so that it will fit with the documented behaviour under the IOP overview device library documentation. The original code was also simpler.
Hi all,
I have been checking through our USBD module, while implementing the missing functions (auto loader registration, unregistration and sceUsbdChangeThreadPriority).
I noticed that our module has got different values from the official USBD module, when it comes to timeouts. For example, the one in this line is 5 in the original, while ours is now 10. I saw that it was once 4 too, until commit 381ba62.
The value used for DEVICE_READY seems to be different too; ours is 5, while the Sony USBD used 7.
In 2010, I had a USB enclosure that would not be properly communicated with by USBD. Unfortunately, I wasn't that good with PS2 development yet and did not try to use the Sony module. I no longer have that enclosure either.
I wrote about it here, although I did not (and still don't) understand the logic behind the things I tried: http://psx-scene.com/forums/f19/usb-mass-device-driver-usbhdfsd-compatibility-fix-some-usb-devices-73420/
I suspect that our module was based on some really early version, but I don't seem to have a module that shares the same values.
The earliest module that I have is v0.13, from August 2000. Does anybody know where I can get an earlier module to check against? Or how these differences in values came about?
I also noticed this patch (a8c9a3a) by Radad in 2009. He added a connected device list.
I don't really understand what advantage this patch would give. If USB devices are connected in a tree, shouldn't the parse order be no different from when the device tree is traversed in prefix order from root?
I took a while to figure out why we had two tree-parsing functions until I realized that we're using an unofficial version. If it offers no advantage but actually increases the complexity of the code, I am in favour of rolling back that patch.
The text was updated successfully, but these errors were encountered: