Overlap with FruityRazer work

[GuillaumeDIDIER]

https://github.com/FruityRazer/FruityUI and this project appear to have some overlap and it is A. unclear which one works or which use / what are the meaning fun difference B. probably some amount of duplicated force when joining forces could get a better experience.

[edualm]

(Repost from https://github.com/FruityRazer/FruityUI/issues/42)

From what I can see, both projects are based in OpenRazer, but the UI is very different - Razer macOS's one is based in Electron, while FruityUI's is based in SwiftUI.

FruityRazer is already separated - there's FruityKit which is the core driver code (and would be the duplicated work), while FruityUI is just the UI.

FruityKit would be a good place to "join forces", but I don't really know how easy it is to use a macOS framework from within Electron.

[1kc]

https://github.com/FruityRazer/FruityKit/tree/master/FruityKit/Core is the only place where both projects can directly share code.

In razer-macos the c functions are called via Node/C++, while in FruityRazer they are called with Swift.

I had a look and the best way to call Swift (if the backend was to be ported) is probably through a compile binary using child_process.execFile() in Node.

To achieve interoperability, we could even make a CLI binary of FruityKit that allows razer-macos to call it. Similar to how it's done in this cross platform wallpaper changer app.
Though I'm unsure of the differences in implementation and device support in our adaptations of openrazer.

@edualm Let me know your thoughts.

[edualm]

FruityKit also has some adaptations of openrazer, but I think we based it on the same project: https://github.com/kprinssu/osx-razer-blade

Adapting openrazer is, to be honest, the biggest pain point of maintaining the project. Joining forces on the backend, even if we both continued to have separate UI, would probably save us both work.

Would it be possible to convert our shared openrazer code into a C library? FruityKit actually uses Swift/C interop, so changing it to use a C library instead of using the C files directly would probably be viable. That way Razer macOS could also use that same library. How does that sound @1kc?

[1kc]

Adapting openrazer is, to be honest, the biggest pain point of maintaining the project. Joining forces on the backend, even if we both continued to have separate UI, would probably save us both work.

Agreed, exactly.

All of the C code called in razer-macos are actually in this one file here. So using a C library would definitely make it easy to switch.

The additional C driver implementations are under this directory. Some of which are different to how its done in openrazer.

Would also like to hear @dhobi's opinion if he's free. Happy to work with you on this.

[edualm]

All of FruityKit's implementations are also under a single directory here. The code seems similar to yours, we are much likely doing duplicated work.

Yours may be more mature though - I do not mind helping extract yours into a library that FruityKit would also be able to use.

I actually had some plans to create a utility to "convert" openrazer's C code into code that could be useable into macOS (by automatically converting calls to IOUSB, removing linux kernel headers, etc.) but I don't know if that is too much work. Maybe we could first extract the code into a library, then maybe work in that if it also seems useful to you?

[GuillaumeDIDIER]

I wonder if it might be worth working with upstream (aka open razer) to get their tree to support both ? (If it were possible to use some clever defines to get the right boilerplate for the plateform at compile time)

[edualm]

Thing is, the scope of openrazer is way bigger. It includes stuff like remapping keys, which is out of scope of FruityRazer and Razer macOS. Making the driver itself platform-agnostic would be certainly possible, but probably would require a lot of dev-hours and seems out of scope of the openrazer project.

[1kc]

Yours may be more mature though - I do not mind helping extract yours into a library that FruityKit would also be able to use.

That sounds good, we do have quite a few ported-over and tested device support from contributors.

I actually had some plans to create a utility to "convert" openrazer's C code into code that could be useable into macOS (by automatically converting calls to IOUSB, removing linux kernel headers, etc.) but I don't know if that is too much work. Maybe we could first extract the code into a library, then maybe work in that if it also seems useful to you?

Are you thinking of a IOUSB wrapper that calls struct usb_device *usb_dev? That would be ideal but I'm not sure how that can be implemented. Or using something like regex or a script to do the conversion.

[GuillaumeDIDIER]

Speaking of key-remapping, is there any recommended suggestion for that ? (I used to have a switch space shortcut on my razer mouse by remapping a pair of button to ^-Left and ^-Right, which has apparently stopped working due to Synapse demise)

/off topic

[edualm]

@1kc It would need both. It would need something to parse the C files, as we need to remove the linux kernel includes; and a wrapper around usb_device. I guess a spike could be done around that, it should not be that hard - just the automation around it. I'm just thinking if it's worth doing the porting first, get a library working that we both can use, and then maybe work on the automatic conversion if we think it's worth it.

@GuillaumeDIDIER I'm afraid I never tried to mess with remapping. :(

[1kc]

@1kc It would need both. It would need something to parse the C files, as we need to remove the linux kernel includes; and a wrapper around usb_device. I guess a spike could be done around that, it should not be that hard - just the automation around it. I'm just thinking if it's worth doing the porting first, get a library working that we both can use, and then maybe work on the automatic conversion if we think it's worth it.

@GuillaumeDIDIER I'm afraid I never tried to mess with remapping. :(

Porting over first to a C library first would be good. My concern is how 'automated' it's actually going to be, we might still have manually change things afterwards.

Speaking of key-remapping, is there any recommended suggestion for that ? (I used to have a switch space shortcut on my razer mouse by remapping a pair of button to ^-Left and ^-Right, which has apparently stopped working due to Synapse demise)

/off topic

@GuillaumeDIDIER Can I suggest Karabiner-Elements?

[GuillaumeDIDIER]

Speaking of key-remapping, is there any recommended suggestion for that ? (I used to have a switch space shortcut on my razer mouse by remapping a pair of button to ^-Left and ^-Right, which has apparently stopped working due to Synapse demise) /off topic

@GuillaumeDIDIER Can I suggest Karabiner-Elements?

This looks like it might do the trick, nice. (😇 let's integrate this as a backend to the UI for razer mice 😇 jk ) Thanks and good luck with the driver work.

[edualm]

Porting over first to a C library first would be good. My concern is how 'automated' it's actually going to be, we might still have manually change things afterwards.

Well it would have to be an iterative process. But porting first seems a good step, and would be useful even if we end up not automating it.

I don't have a lot of experience into making C libraries, but for our use cases, how about we extract https://github.com/1kc/razer-macos/tree/master/src/driver (without the addon.cc) into a separate repo, and use it as a git submodule in both our projects? I think that'd work quite nicely for both of us, what are your thoughts?

[1kc]

I’ll have a go at factoring out the C drivers and making it a library on the weekend.

[edualm]

Let me know of anything I may be of help!

[1kc]

@edualm I have refactored razer-macos's C drivers into a submodule. It is exposed as a C shared object librazermacos.so . When compiling the swyft app you will need link the library and add the include path for the headers.

For example, to compile the included sample C CLI. gcc -Wall -framework CoreFoundation -framework IOKit -L. -Isrc/include -o sample_cli src/sample_cli.c -lrazermacos

[edualm]

I've started work on implementing it into FruityKit as a submodule too (https://github.com/FruityRazer/FruityKit/tree/feature/librazermacos). Works, compiles, my early tests on my keyboard make it seem like it works just fine. 🥳

I've also opened a PR on librazermacos in order to fix some issues (https://github.com/1kc/librazermacos/pull/2), please take a look when you have some time.

I'm still going to see if there is anything I can port from my own old code to librazermacos. Would you have me as a contributor on that repo too? Will probably make things easier since we're going to be both working on it, and it's of interest of both of us to have that library be the best it can be.

[1kc]

Sure thing. I will have a look over soon. Adding you as a contributor to librazermacos😊

[edualm]

Thanks @1kc, 😄

[dhobi]

Just passing by to leave this: 😃👍

[WrathofthePast]

Since FruityUI uses Swift, it only support MacOS 10.15 (Catalina) & newer. In its current state, RazerMacOS supports 10.13 (High Sierra) & newer. Would this integration of FruityUI result in dropping support for MacOS 10.13 & 10.14 (High Sierra & Mojave, respectively)?

I saw there is a legacy version of FruityRazer which doesn't use Swift: FruityRazer/FruityUI-Legacy, if that is of any use. I welcome using Swift as that would likely decrease RAM usage by RazerMacOS. I only mention this because the supported MacOS versions will have to updated if any Swift code is utilized & the many people who still use Mojave (supported by Apple & is the newest version that still supports 32bit apps) would lose support.

[edualm]

@WrathofthePast Absolutely not. FruityUI and Razer macOS should not have their deployment targets changed by this change.

Razer macOS will also not start using Swift by this change.