Add libusb impl #87
Add libusb impl #87
Conversation
|
I don't want to put non-Razer SDK stuff in the same RazerChroma.cpp, and if I'm going to add the alternative Razer drivers it'd be better to build it against Terry Cain's drivers with the patches to make it work on Windows rather than reimplementing it for one cherry-picked device. If you made this for yourself, that's fine, but I don't like merging things that don't work for all supportable devices equally, especially when they bring in more dependencies. I don't like adding tons of dependencies which is why I've avoided libusb-win32 up to now, its use of USB device filters is ugly compared to using Windows' HID library, but I'm finding that I might have to implement it for the Poseidon Z RGB as I could only make it work using libusb-win32 on Windows. What I might do is change RazerChromaLinux.cpp, maybe rename it RazerDrivers.cpp since that's what Terry's project is called, and add a second Initialize function for Windows. Then use a device flag such as razer_use_unofficial_drivers or something to enable the use of that driver rather than the SDK. I like modularity, and keeping the unofficial drivers separate from the SDK is best. |
|
Understood. I didn't really expect you to put it in as-is anyway. I
was just trying to provide the code as more of a simplified one-off
piece of test code that you could easily modify. I am still trying to
work out some of the kinks with my windows implementation to Terry's
driver, but I thought a simpler library to handle just the custom
messages might be more applicable.
As it is now, your code does not run on my setup without modification.
Nothing to do with your implementation, but more shortcomings of the SDK
itself. It seems somewhere in the internals of the SDK, the BladePro
keyboard does not work all the way. Particularly you cannot control the
touchpad or media key LEDs. However with libusb call you can. Another
interesting side effect is that the firefly SDK code also activates part
of the touchpad (you cannnot control the two individually though). I
have mentioned this bug on Razer forums a few months ago and although
acknowledged, seems to have gotten no attention.
I also thought an implementation with libusb-win32 might work out better
and allow others to more easily step though the code and make
modification based on their devices. Ideally Razer should just
opensource their SDK and the bugs would probably get fixed overnight.
I am not to crazy about having to "install" a filter driver either and
would rather use winusb.sys (which is what WIndows HID library uses),
but I cannot seem to get it to initialize and this seems to be a common
problem among many on the internet as well. If anything the code I put
in there should be the simplest form for communication with a Razer
device and might even be able to be further simplified (open device,
init device send control transfer message). Maybe you can make the
WIndows HID library do the same thing with their equivalent calls.
The way I have this coded, it could easily be modified to handle the
custom message for other razer devices, just by putting in the
appropriate wireshark capture results.
…On 2/19/2017 1:04 PM, Adam Honse wrote:
I don't want to put non-Razer SDK stuff in the same RazerChroma.cpp,
and if I'm going to add the alternative Razer drivers it'd be better
to build it against Terry Cain's drivers with the patches to make it
work on Windows rather than reimplementing it for one cherry-picked
device. If you made this for yourself, that's fine, but I don't like
merging things that don't work for all supportable devices equally,
especially when they bring in more dependencies.
I don't like adding tons of dependencies which is why I've avoided
libusb-win32 up to now, its use of USB device filters is ugly compared
to using Windows' HID library, but I'm finding that I might have to
implement it for the Poseidon Z RGB as I could only make it work using
libusb-win32 on Windows.
What I might do is change RazerChromaLinux.cpp, maybe rename it
RazerDrivers.cpp since that's what Terry's project is called, and add
a second Initialize function for Windows. Then use a device flag such
as razer_use_unofficial_drivers or something to enable the use of that
driver rather than the SDK. I like modularity, and keeping the
unofficial drivers separate from the SDK is best.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKs-kgDM01sDRLIFM1yLOWS8QVr_uedaks5reJI6gaJpZM4MFGy_>.
|
|
In a roundabout way, I am "completing" this merge request. I've forked your Win32 OpenRazer fork on GitHub: https://github.com/CalcProgrammer1/openrazer-win32 and added some improvements to it, got it building with the latest upstream OpenRazer code. It's supported and working on my OpenRGB program, which aims to be a complete replacement for all the proprietary OpenRGB programs on Windows and also support Linux: https://gitlab.com/CalcProgrammer1/OpenRGB I'm moving KeyboardVisualizer to the OpenRGB SDK. It's still in development, but I have a test build working in the OpenRGB_SDK branch. |
Not sure if you want to use this. I just forced in some libusb-win32 support. Currently only work with RBP2016 when razer_use_alternate_effect=1 in settings.