[BUG] Unable to use light on Windows #87
Comments
|
This is a duplicate of issue #56 unfortunately. I wrote BusyLight with the assumption that files are generally opened with exclusive access (meaning the file gets opened once and successive opens fail until the file is closed). The entire light discovery strategy hinges on this behavior, which Windows does not honor. This will remain broken until I have time to fix it or someone kindly contributes a fix. |
|
My bad - I did not read #56 as the title did not hint at the same issue. I will play a bit around if I can get it to work using Python in WSL2 (Debian 11) on the same machine - maybe it does something differently when inside the de-facto WSL VM. |
|
Knowing more people are interested in using it on Windows helps motivate me to fix it, thanks for the bug report. I'm curious if WSL has the same problem (I suspect it does not). |
|
Indeed - it works! Followed instructions from https://devblogs.microsoft.com/commandline/connecting-usb-devices-to-wsl/ , installed usbipd-win from https://github.com/dorssel/usbipd-win/ (also available via Windows packet manager), attached the USB device to the WSL-VM: dmesg shows it nicely: and does exactly what it was intended to do - controls the light nicely. However, found an 2 errors in debug output when calling I believe USB devices are kind of pass-thru to the (under-the-hood) Hyper-V based VM, but directly on (raw) device level. Your code - resp. Python - seems to work on one abstraction layer higher, "device control level". That name might be completely wrong, but I hope you get what I'm trying to convey. |
|
Thank you for the report that it works on Windows from within WSL. The "errors" in the debug output are expected, as you surmised. |
|
Windows tests as of version 0.22.2 are passing, indicating that the change in software architecture might have benefited Windows users. Any reports good or bad for this latest version on Windows? |
|
On Windows with busylight v0.26.0 the devices are correctly detected but nothing happens when I try to set a color, the device light is still off. Note I tried on MacOSX and I works fine. |
This is the interesting part of the debug output, both writes to the Blinkstick Square devices failed "wrote -1" and the flag write succeed with a 9 but the command word is seven bytes (I think there is a 0x0000 prepended which would bring it up to nine bytes, I have to go back and look at the code). @remss if you have some time and are willing, could you try running this fragment in a repl? from busylight.lights import Flag
l = Flag.first_light(exclusive=False)
l.on((0,255,0)) |
|
Here the result, and the light of the Luxafor device is still off |
|
Well, darn. Until I have a windows machine to debug on (or someone submits a patch) this is going to stay broken for now. We could try to verify that import hid
device = hid.device()
device.open(0x04d8, 0xf372)
device.write([ 0x1, 0xff, 0, 0xff, 0, 0, 0]). # cmd, leds, red, green, blue, fade, repeat
# flag should be on with a green color |
|
The hidapi is working well, the light comes green (I had to change a little the data to send, an initial 0 was missing) My 2 cents about Windows machine,: you might use VirtualBox and prebuilt images from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ |
|
That is odd. AFAIK the first byte in the Luxafor instruction buffer of eight bytes is a command whose valid values are 1, 2, 3, 4, and 6. Also there are only eight items in the list you passed to |
|
I'll have a windows machine to test on in the near future, I guess stay tuned. >>shudder<< |
|
Hi, was not sure if it was best to add to this on #56 or here but I would like to say that the problem is also happening with Win 10 under python 3.7. and 3.11. busylight.lights.hidlight:available_lights:50 - Flag found 1
2023-05-03 23:43:50.765 | INFO | busylight.lights.hidlight:acquire:106 - Flag open_path(b'\\\\\\HID#VID_04D8&PID_F372#a&172874d6&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}') succeeded
2023-05-03 23:43:50.765 | INFO | busylight.lights.light:all_lights:160 - Flag found 1 lights.
(...)
busylight.lights.light:all_lights:153 - Light found 1 lights total.
2023-05-03 23:43:51.698 | INFO | busylight.lights.light:exclusive_access:529 - Entering exclusive access for Flag
2023-05-03 23:43:51.706 | INFO | busylight.lights.light:update:557 - data:7 = b'\x01\xff\x00\x80\x00\x00\x00' wrote 9
2023-05-03 23:43:51.706 | INFO | busylight.lights.light:exclusive_access:543 - Exiting exclusive access for FlagHope that helps. If there is anyway I can support, please let me know. Thank you for looking into it. |
|
Hey this is still broken, I have Kuando Busylight Alpha and while the program seems to pretend to be doing something, nothing happens on the light itself. |
|
Hi @Gunni, no new progress has been made on getting Busylight working in the Windows environment. My plans for a Windows development machine have not yet come to fruition. |
Software Versions:
General Type of Problem
Describe the Problem
USB-connected Embrava BLYNC USB 30s.
Command line parameters "list" and "supported" never return. Debug output shows endless loop of iterating over same device.
Any control command hangs as well, does not control the light and never returns.
Same behavior running with and w/o admin-privileges.
Having installed Embrava Software does not change behavior.
Expected Behavior
Listing compatible resp. supported device, in my case Embrava BLYNC USB 30s
Error Output
see attached debug log
busylight_list_debug.txt
The text was updated successfully, but these errors were encountered: