Merge with OpenCorsairLink project ?

[mfp20]

Hi,

I've multiple corsair devices and I'd like to have a similar - and better - experience to the one it is possible to obtain on windows. In order to get my result - LEDs wise - there's the need to manage all corsair devices using a single profile manager. In a similar way to iCUE for Windows. By looking at linux kernel I guessed there was the need to develop some new modules; so in the past 2 days I started to work on kernel modules. But then I figured out that ckb-next was using usbfs instead, moving the corsair protocol to userland thanks to ckb-daemon. So I guessed that moving to userland might be safer than a kernel module, I dropped my kernel modules development, and start digging into the current projects: 1) OpenCorsairLink: PSUs, Commander Pro, Lighting Node Pro, ... . 2) ckb-next: keyboards, mices, ST100 (audio device and headphones stand).

Merging those two into a single 'libcorsair' (and daemon, cli, gui) would allow to use a single manager to manage (and sync) also similar products from other brands (ex: logitech, asus, roccat, razer, ...). I'd be happy to work on it but I can't/don't want to spawn a new project.

Is there a chance for the developers of both projects to work together on a single libcorsair (and daemon, cli, gui)?

A few extra notes: 1) MacOSX support can be dropped ( http://forum.corsair.com/v3/showpost.php?p=982647&postcount=1 ). 2) Corsair won't do a linux manager in a near future ( http://forum.corsair.com/v3/showpost.php?p=982788&postcount=4 ). 3) Some extra sysfs love might be useful: temp&fans interfaces for lm_sensors (/sys/class/hwmon ?), have a look at https://github.com/lm-sensors/lm-sensors/issues/163#issuecomment-460100556 ; LEDs interface (/sys/class/leds ?).

cheers

Cross-issue: https://github.com/audiohacked/OpenCorsairLink/issues/155

[Ravenslofty]

On Mon, 18 Feb 2019, 04:15 mfp20 <notifications@github.com wrote:

Hi,

I've multiple corsair devices and I'd like to have a similar - and better

• experience to the one it is possible to obtain on windows. In order to get my result - LEDs wise - there's the need to manage all corsair devices using a single profile manager. In a similar way to iCUE for Windows. By looking at linux kernel I guessed there was the need to develop some new modules; so in the past 2 days I started to work on kernel modules. But then I figured out that ckb-next was using usbfs instead, moving the corsair protocol to userland thanks to ckb-daemon. So I guessed that moving to userland might be safer than a kernel module, I dropped my kernel modules development, and start digging into the current projects:

  1. OpenCorsairLink: PSUs, Commander Pro, Lighting Node Pro, ... .
  2. ckb-next: keyboards, mices, ST100 (audio device and headphones stand).

Merging those two into a single 'libcorsair' (and daemon, cli, gui) would allow to use a single manager to manage (and sync) also similar products from other brands (ex: logitech, asus, roccat, razer, ...). I'd be happy to work on it but I can't/don't want to spawn a new project.

So you're asking us to undertake a new project so you don't have to?

Is there a chance for the developers of both projects to work together on a single libcorsair (and daemon, cli, gui)?

A few extra notes:

1. MacOSX support can be dropped ( http://forum.corsair.com/v3/showpost.php?p=982647&postcount=1 ).

Hah, no it can't. The CUE Mac betas have been, well, beta quality.

1. Corsair won't do a linux manager in a near future ( http://forum.corsair.com/v3/showpost.php?p=982788&postcount=4 ).

Yeah, we know.

1. Some extra sysfs love might be useful: temp&fans interfaces for lm_sensors (/sys/class/hwmon ?), have a look at lm-sensors/lm-sensors#163 (comment) https://github.com/lm-sensors/lm-sensors/issues/163#issuecomment-460100556 ; LEDs interface (/sys/class/leds ?).

We don't even support those at the moment, let alone in a new project.

cheers

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ckb-next/ckb-next/issues/376, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbx20--vhOQ9ZL1R59L1NaxnCHCN1T3ks5vOij5gaJpZM4bAD2D .

[tatokis]

Is there a chance for the developers of both projects to work together on a single libcorsair (and daemon, cli, gui)?

It was planned to add CLINK support to ckb-next, but the person doing it was pretty busy and I haven't heard from them for a while.

Merging those two into a single 'libcorsair' (and daemon, cli, gui) would allow to use a single manager to manage (and sync) also similar products from other brands (ex: logitech, asus, roccat, razer, ...). I'd be happy to work on it but I can't/don't want to spawn a new project.

Much easier said than done. Corsair has at least five different protocols, not all of them USB, varying between firmware versions, and some have more state than others, with varying levels of features and animations. And that's not including all the legacy devices they dropped support for.

The reason we haven't added support for CLINK is mostly because they didn't have software animation support until very recently with an update, if I recall correctly.

MacOSX support can be dropped

That's not happening.

Corsair won't do a linux manager in a near future

Nothing new there. I'll take it as a good thing.

Some extra sysfs love might be useful: temp&fans interfaces for lm_sensors (/sys/class/hwmon ?), have a look at lm-sensors/lm-sensors#163 (comment) ; LEDs interface (/sys/class/leds ?).

Last I checked you can't add sysfs entries from userspace. Also, the LEDs interface is unusable for wireless devices such as the dark core or the K63.

[mfp20]

I'd be happy to work on it but I can't/don't want to spawn a new project. So you're asking us to undertake a new project so you don't have to?

Negative. I'm saying that I can do the merge right now but I'd like to know in advance that the other developers will welcome this change, freeze the commits until the merge is done, and so on. Or even do it yourself, as you have better chances to do a better job in shorter time; I'd be happy to support writing docs and whatever else can be useful.

I've already a mashup of the two projects; and a draft of hid, hwmon and leds kernel modules. The two mentioned projects are some sort of compatible as they both use libusb/usbfs. But the code structure is different, obviously. It would take me another week to adopt one of the two approaches and translate the code to the chosen one. And that's not a problem.

The problem comes after: I'm not willing to maintain the project for life or even just a few years; I could do it easily for myself. But there are users screaming in pain all over for not having corsair stuff on their linux boxes, so... if developers with their hands already on project step in, it is worth it to give it a decent shape. Otherwise I just proceed by hack&slash until 'it works for me'. Not even bothering to sit the code into a git repo. And that would be a pity.

Simply: at this point in time there's no point to spawn thousands of more projects about corsair support. Have a search on corsair forums and github, and you'll figure out yourself...

[Ravenslofty]

Well, I'm officially abandoning this project, so I can't be that person. I can walk you through the protocol, but I really won't do much more.

On Mon, 18 Feb 2019, 16:19 mfp20 <notifications@github.com wrote:

I'd be happy to work on it but I can't/don't want to spawn a new project. So you're asking us to undertake a new project so you don't have to?

Negative. I'm saying that I can do the merge right now but I'd like to know in advance that the other developers will welcome this change, freeze the commits until the merge is done, and so on. Or even do it yourself, as you have better chances to do a better job in shorter time; I'd be happy to support writing docs and whatever else can be useful.

I've already a mashup of the two projects; and a draft of hid, hwmon and leds kernel modules. The two mentioned projects are some sort of compatible as they both use libusb/usbfs. But the code structure is different, obviously. It would take me another week to adopt one of the two approaches and translate the code to the chosen one. And that's not a problem.

The problem comes after: I'm not willing to maintain the project for life or even just a few years; I could do it easily for myself. But there are users screaming in pain all over for not having corsair stuff on their linux boxes, so... if developers with their hands already on project step in, it is worth it to give it a decent shape. Otherwise I just proceed by hack&slash until 'it works for me'. Not even bothering to sit the code into a git repo. And that would be a pity.

Simply: at this point in time there's no point to spawn thousands of more projects about corsair support. Have a search on corsair forums and github, and you'll figure out yourself...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ckb-next/ckb-next/issues/376#issuecomment-464796205, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbx23mo_KJgY9_Pjti4WK_qQp5dfjXuks5vOtKvgaJpZM4bAD2D .

[mfp20]

Is there a chance for the developers of both projects to work together on a single libcorsair (and daemon, cli, gui)?

It was planned to add CLINK support to ckb-next, but the person doing it was pretty busy and I haven't heard from them for a while.

Well, the beauty of git is that 'everything flows'. In other words there's no need to wait for that guy if he has some other things to do in his life. Moreover, OpenCorsairLink project has all that work already done in a very tidy&essential code architecture. I'm not familiar with cmake so I can't show you my progress as it would not compile at the moment. But I just rebased both projects in a common 'corsair-tools' root folder, having subfolders:

• corsair-cli: code moved from OpenCorsairLink/src/.
• corsair-daemon: code moved from ckb-next/src/daemon.
• corsair-gui: dumped ckb-next in there.
• kernel: my modules drafts (hid, hwmon, leds).
• libcorsair: dumped OpenCorsairLink in there because I liked the way they organized their code.

And the rest of your package must be adapted to this new structure; cmake of course, but also other scripts and docs.

Then there's the need to rename the ckb-next project into something that is: a) not corsair bound, as it could be easily linked to librazer, liblogitech, libasus and so on... at some point in time. The daemon, cli and the gui have the same function for different brands. b) not limited to 'kb', as it already support mices and audio devices. Our hardware already has RGB leds implanted everywhere: PSUs, AIOs, fans... why keyboard only? Example: I placed some leds behind my monitors in order to give some relief to my poor eyes, connected those led strips to Corsair Ligthing Node Pro. It would be useful to have those in sync with kb/mice/st100/fans. And the same applies for hw monitoring and thermal control; lm_sensors have always been pretty obscure... a gui that shed light on lm_sensors could be nice to have now that fans have leds :)

Example name: 'deskmacro-tools', or alike.

As I said, I can do it right now. It's my top priority at the moment; I woke up this morning and came here to search for instructions from you guys. I'm writing this with my first coffee in my mug.

Merging those two into a single 'libcorsair' (and daemon, cli, gui) would allow to use a single manager to manage (and sync) also similar products from other brands (ex: logitech, asus, roccat, razer, ...). I'd be happy to work on it but I can't/don't want to spawn a new project.

Much easier said than done. Corsair has at least five different protocols, not all of them USB, varying between firmware versions, and some have more state than others, with varying levels of features and animations. And that's not including all the legacy devices they dropped support for.

Well, I don't know about you but I'm not paid by corsair. I'm not Free Corsair's Software Development Service For All. I've their (awesome) hardware and I want to enjoy it, that's it. So, let's make the software good enough to reach our individual goals, but structured in a way that anybody willing to contribute can easily add support for their own new shiny devices. Free Software always worked like this, in the past 20 years...

This ' fancy leds' thing is relatively new, so there's the need of a project that people can refer to.

The reason we haven't added support for CLINK is mostly because they didn't have software animation support until very recently with an update, if I recall correctly.

Well, many of those products will never have any kind of animation; not even anything that is worth having in a gui. A small list of text labels+values is a good enough report. It isn't a blocking problem. They can be added later on, for beautification.

MacOSX support can be dropped

That's not happening.

Can I ask you why? Don't get me wrong. I don't want to tell you all what to do. I'm trying to figure out what I can do. I've just thought it could be a feature that could be dropped in order to spare time for other things. In any case ifdefs aren't a problem, as far as there's somebody willing to support that feature. Moreover, OpenCorsairLink code is already layered in order to split low level stuff from high level one. Have a look at their code; I'd like to adopt their schema from kernel to daemon, and use your from daemon to cli/gui.

Corsair won't do a linux manager in a near future

Nothing new there. I'll take it as a good thing.

I agree. Having the source could bring to more advanced features and better integration with the rest of the system and software. If WE do it...

Some extra sysfs love might be useful: temp&fans interfaces for lm_sensors (/sys/class/hwmon ?), have a look at lm-sensors/lm-sensors#163 (comment) ; LEDs interface (/sys/class/leds ?).

Last I checked you can't add sysfs entries from userspace. Also, the LEDs interface is unusable for wireless devices such as the dark core or the K63.

I think you are right. I searched for kernel docs but, as usual, there's a lot of obsoleted documentation.

I'm currently trying to figure out if I can have 2+ kernel modules accessing the same device at the same time; for instance: usbhid for base functionality (keyboard+mouse+sound always on); usbfs for special features, hwmon-corsair + leds-corsair for exposing temps, fans and leds to sysfs. If this is not possible, the best bet is to change the current hid-corsair (a stub for K70/K90 keyboards only) to an hw wrapper that claims the devices on boot to produce all the required char devices (hwmon, leds, usbfs)... more complicate, and inherently insecure, but it is 'the right thing'... as I'd like to avoid for the keyboard to stop working (even for a short period of time) when the daemon is loaded/unloaded (and the device is handled to/from usbfs).

cheers

[mfp20]

Well, I'm officially abandoning this project, so I can't be that person. I can walk you through the protocol, but I really won't do much more.

Well, you don't have to do it. Hands on is the imperative. So: I want it, I do it. But your experience and tutoring would be much appreciated.

Dude, you (all) have already done most of the work. There's no need of much maintenance more than the one you are doing right now, by speaking with me. I mean, your project already succeeded because it does what it was made for. Now it is time to evolve it in order to fully support the hardware capabilities (ex: LEDs everywhere, not keyboards only). Those extras are already out there; we need to consolidate all those goodies into a single project.

[tatokis]

@mfp20 Considering at this point I am the only active maintainer of this software, I do not have the time to do anything else. There are way too many things open at the moment that need to be worked on, and I'd appreciate those get fixed/implemented before we get anything else done.

b) not limited to 'kb', as it already support mices and audio devices.

Easier said than done. Lighting up a LED on the void is a huge pain in the ass, let alone any of the unimplemented extended features. https://github.com/ckb-next/ckb-next/blob/void/src/daemon/led_headset.c

a) not corsair bound, as it could be easily linked to librazer, liblogitech, libasus

Again, easier said than done. Some Corsair devices function in a completely different way. We looked into integrating libratbag, and all they do is tell devices to switch to modes or to switch to a specific DPI and the devices do it.

Many of the NXP corsair devices are dumb, to the point of us needing to manually set the DPI stage LED depending on what stage we set the mouse to, or manually animate, render, and feed RGB data for every single LED on it.

The reason the wireless devices haven't been fully implemented is because they aren't streaming RGB data. On top of that, the Harpoon Wireless RGB and a few upcoming devices switched to a brand new protocol that we haven't yet reverse engineered, which also seems to function in a different way.

Then there are devices such as the RGB DRAM, which work in a different way with register writes.

The problem comes after: I'm not willing to maintain the project for life or even just a few years; I could do it easily for myself.

And I am not willing to maintain someone else's codebase that I have to relearn how it is implemented. I barely have the energy to work on this, let alone switch to a kernel driver.

Can I ask you why? Don't get me wrong. I don't want to tell you all what to do. I'm trying to figure out what I can do. I've just thought it could be a feature that could be dropped in order to spare time for other things.

Because people still use it, and after being fucked over by Corsair's software personally, I do not want to make people who don't want to use it, use it. I should also bring this to your attention https://github.com/ckb-next/ckb-next/compare/windows

Well, I don't know about you but I'm not paid by corsair. I'm not Free Corsair's Software Development Service For All. I've their (awesome) hardware and I want to enjoy it, that's it. So, let's make the software good enough to reach our individual goals, but structured in a way that anybody willing to contribute can easily add support for their own new shiny devices. Free Software always worked like this, in the past 20 years...

I only have a K70 RGB and an M65 Pro which I bought just to develop this software further. I don't have an ST100, I don't have an MM800, I don't use macOS, I don't have any flavour of the void headsets, I don't have RGB RAM, I don't have a Dark Core RGB, I don't have a Sabre, I don't have a Harpoon Wireless RGB, I don't have an M95, I don't have [insert device supported by ckb], yet I still maintain them, and add support for them. I think that's a poor excuse, IMO.

I'm currently trying to figure out if I can have 2+ kernel modules accessing the same device at the same time; for instance: usbhid for base functionality (keyboard+mouse+sound always on); usbfs for special features, hwmon-corsair + leds-corsair for exposing temps, fans and leds to sysfs.

This was possible until Corsair decided to change the USB interfaces around in a FW upgrade and break URB Control support.

Standardising all the quirks and oddities Corsair devices have, even with the same protocol is pretty difficult. If you have a look at how iCUE is implemented, you will see what I mean.

Well, many of those products will never have any kind of animation; not even anything that is worth having in a gui. A small list of text labels+values is a good enough report. It isn't a blocking problem. They can be added later on, for beautification.

Even the Lighting Node Pro protocol differs wildly to the NXP wired hid protocol.

tl;dr if you're willing to add support for new devices in ckb-next, you are welcome. At the moment I do not have the time, or the energy to work on this.

[tatokis]

Breaking portability aside by creating a linux kernel module, I should also add that I would rather not have to deal with the constant breakage of kernel APIs, or the amazing documentation.

By keeping this in userspace, we do not need to worry about any of that. And the few seconds that it takes for the daemon to take over from the kernel driver are barely an issue.

It's already annoying enough having to deal with devices not being recognised by the linux kernel because they changed something and now we need to tell everyone to add usbcore quirks in their cmdline.

[mfp20]

@mfp20 Considering at this point I am the only active maintainer of this software, I do not have the time to do anything else. There are way too many things open at the moment that need to be worked on, and I'd appreciate those get fixed/implemented before we get anything else done.

@tatokis

I can imagine the hell you're in. That's why I suggested both to: 1) to drop the macos port (and the windows one, that you pointed out to me). 2) to not add new devices / improve existing devices support yourself, but let new users add them. eventually.

Many projects have been able to survive the long run by dropping features and adopting more conservative policies. Developer time conservation. You're talking about Void and other devices you don't even have!!! That's crazy! You are just a single person, not a team, and not paid for it. You won't last much more if you keep going like that... and once you give up... most of your effort will be lost. This will be just another forgotten project in github's belly. If you use your next effort to turn the project into a more general purpose one, instead, you might get more developers working on it.

Anyway, don't worry. I'm willing to help you, if you let me do it.

First of all, I have:

• HX1200i
• Dominator Platinum RAM (with monitoring connectors, but I don't have the cooler with LINK connector yet)
• K95 Platinum
• Dark Core SE
• ST100
• Commander Pro
• multiple Lighting Node Pro
• multiple ML fans.
• idea to buy a corsair headset in the near future.

Those are the only devices I'd work for. But I'm happy to make it using a wider perspective; I mean, if you allow me to change the architecture, I'd be happy to port all the existing devices as well. There's no need for you to do it; we can manage it by opening a new branch for me to work in alone, and eventually turn it into the next major release once we have the certainty that the new branch is the way to go. At that point, you can freeze ckb-next, clone that branch to a new project repo, and write a disclaimer on github to send all the people to the new project.

The only thing I need from you is to give the project a clean separation between its components: driver, lib, daemon, cli, gui. Working in that direction, at least. The driver is the only part that is OS-dependent; and I'd take that part on me entirely, linux wise, without breaking macos/windows ports. I'll write more details about that in the message after this one. The lib depends on libusb/usbfs only, that is cross-platform already; so, once moved the corsair details into the lib, the daemon can be 100% abstracted both from HW and OS. Daemon and GUI don't need to be changed at all at the moment. I'd give a look at those only AFTER have done the core changes to the underlying code. And the CLI can be built using the same API currently in use between daemon and gui. The folders aren't a big job; cmake is. I've been messing a bit with cmake in the past but I can't really remember much, and I don't have idea how to integrate cmake in my development tools.

Can we do this? Separate the components by using different folders and adapt cmake. So I can proceed...

note: I use a windows vm and I placed all the corsair USB stuff on one isolated USB tree; in other words, by flipping a single switch, I can pass the entire corsair hw to windows and manage it from there, then reconnect to the linux host one the profiles are saved in hw, without even the need to reboot. But I loose the online features and it's uncomfortable, overall speaking. That's why I'm messing with this project!

[mfp20]

@tatokis

And I am not willing to maintain someone else's codebase that I have to relearn how it is implemented. I barely have the energy to work on this, let alone switch to a kernel driver.

There's no need of. Separate the components and then focus on the daemon+GUI only. I'll manage the rest of it, until the new branch will convince us all to make it master.

Because people still use it, and after being fucked over by Corsair's software personally, I do not want to make people who don't want to use it, use it. I should also bring this to your attention https://github.com/ckb-next/ckb-next/compare/windows

Well, I don't know about you but I'm not paid by corsair. I'm not Free Corsair's Software Development Service For All. I've their (awesome) hardware and I want to enjoy it, that's it. So, let's make the software good enough to reach our individual goals, but structured in a way that anybody willing to contribute can easily add support for their own new shiny devices. Free Software always worked like this, in the past 20 years...

I don't have [insert device supported by ckb], yet I still maintain them, and add support for them. I think that's a poor excuse, IMO.

The People that don't want to use Corsair's shiny software and end up like you, can stop buying Corsair products OR file a complaint to Corsair OR pay for your good heart. Ruin your life for supporting The People isn't good for yourself. IMHO. Anyway, your life is not my business, and I apologize for talking about it; we all did that mistake once in life... good luck with that... in the while: given corsair's bad attitude to us financiers, can you please just work together with me in order to provide both of us the software we need? The world don't need to be saved... our owned devices do!

Standardising all the quirks and oddities Corsair devices have, even with the same protocol is pretty difficult. If you have a look at how iCUE is implemented, you will see what I mean.

Even the Lighting Node Pro protocol differs wildly to the NXP wired hid protocol.

tl;dr if you're willing to add support for new devices in ckb-next, you are welcome. At the moment I do not have the time, or the energy to work on this.

This is the point: we don't have to standardize ALL the quirks and oddities. We just need to standardize the ones we care (because we have the devices) and the ones that have been already figured out in the current code base. All the rest is Corsair's users problem. Not our problem.

[mfp20]

@tatokis

Finally a note about the linux kernel modules.

Breaking portability aside by creating a linux kernel module, I should also add that I would rather not have to deal with the constant breakage of kernel APIs, or the amazing documentation.

No need to break portability. If the HW layer is strictly separated from the lib layer, and the lib from daemon, there's no breakage. Each port would use a different driver/lib code.

Linux wise, as you stated, Corsair broken something in the USB protocol so that the hw can't be accessed concurrently by more than one driver. So, the only option left is for me to

change the current hid-corsair (a stub for K70/K90 keyboards only) to an hw wrapper that claims the devices on boot to produce all the required char devices (basic HID, hwmon, leds, usbfs)

The idea is that the corsair module would parse the commands to feed the hwmon and leds sysfs, then forward to the usbfs char device without modifing anything. In this way the libusb-based apps (like ckb-next) would keep going as usual. It's a kind of router/proxy. The only question mark is added latency; but it should be tolerable, even more considering we are talking about kernel space.

Anyway, this can be made a separate project and pushed to the linux developers. There are already drivers working like that. Have a look at Roccat's drivers. I took those drivers as a starting point for producing my corsair's drafts...

By keeping this in userspace, we do not need to worry about any of that. And the few seconds that it takes for the daemon to take over from the kernel driver are barely an issue.

It's already annoying enough having to deal with devices not being recognised by the linux kernel because they changed something and now we need to tell everyone to add usbcore quirks in their cmdline.

With the corsair routing/proxying module this small nuances would be gone.

[fleischie]

@mfp20 I really appreciate your enthusiasm.

Still, you need to be wary of suggesting harsh changes to the overall architecture of multiple projects. Especially if it's for unifying them.

I don't want to make any definitive statements, though. I just find it a tiny bit presumptuous to downplay the implications of such an undertaking. Maybe it really is best, that you start the effort for now and keep us updated on the progress.

I really urge you to make this work publicly available for everybody to use. This way you can see what the problems and focusses are for the end users, and you ultimately didn't waste your time.

Sorry though, that you didn't get the super positive response, that you (maybe) hoped for. It's just difficult to get excited with the prospect of more maintenance work.

:v:

[mfp20]

@fleischie

@mfp20 I really appreciate your enthusiasm.

Still, you need to be wary of suggesting harsh changes to the overall architecture of multiple projects. Especially if it's for unifying them.

Well, that's the need (unify); in order to get the maximum out of the hardware.

And in this case harsh changes are not really needed. The part I appreciate most is the command-rich daemon/gui part; that in turn relies on libusb. I'm talking about rehashing the lower level part, and add a console application (CLI) that would use the same API that the daemon/GUI are using. So nobody here would be in need of re-learning most of the code; code that I'm not going to touch at all.

I don't want to make any definitive statements, though. I just find it a tiny bit presumptuous to downplay the implications of such an undertaking. Maybe it really is best, that you start the effort for now and keep us updated on the progress.

Naive, rather than presumptuous. And as I said more than twice... I'm already working on it...

I really urge you to make this work publicly available for everybody to use. This way you can see what the problems and focusses are for the end users, and you ultimately didn't waste your time.

That's not really possible. In order to make something for everybody to use there's the need to increase the overall complexity. This means to increase the developing time. So, If I have to do it for myself only, I just hack&slash: drop macos, windows, and once done that... cmake (as 'make' is quicker but linux only). And keep going removing support for most supported devices... because I don't have those... instead of layering to standardize the components. The end result would be something that anybody else can put the hands on, because there's no clear separation between its parts, and strictly tailored to my needs (and my hw); a pretty messy spaghetti. But it doesn't waste my time, it uses just the time needed to satisfy my needs. On the contrary, it would be a huge waste of time, to make it work for anybody else; but it is worth in the case someone else joins the party (ie: two people working, so, again, no huge waste for a single person). Actually, in the case of 2 or more people, working in the opposite direction is strictly needed: two people can't hack&slash together, they must use coding standards and follow a common project.

Sorry though, that you didn't get the super positive response, that you (maybe) hoped for. It's just difficult to get excited with the prospect of more maintenance work.

It's not the first time for me to discuss with software deus ex'es. And I've always failed to raise my point. So I wasn't expecting anything. To get the importance of this point (ie: unify), is not my call. My call is to raise the point, only.

[audiohacked]

I really don't see this happening, OpenCorsairLink took me many hours (for each protocol) how to get just basic functionality implemented. Trying to work around quirks is like @tatokis said, "easier said than done". Just making OpenCorsairLink was a huge amount of work. Integrating "every" Corsair device into a single library would take years.

[mfp20]

@audiohacked

I really don't see this happening, OpenCorsairLink took me many hours (for each protocol) how to get just basic functionality implemented. Trying to work around quirks is like @tatokis said, "easier said than done". Just making OpenCorsairLink was a huge amount of work. Integrating "every" Corsair device into a single library would take years.

Again: I can imagine the hell you've been in. But you're already out of it. BTW, I was thinking to use the same code architecture you produced, to add the other devices. It is mostly a cut&paste work out of ckb-next devices support code.

And Again: I'm saying all the way the opposite of 'integrating every Corsair device'. I'm speaking about integrating the devices we have, only. The others can be reworked to be kept in the new code base but not in functional state; mere stubs to be worked as soon as a new owner pops up...

@tatokis @audiohacked

Another option would be to open the devices and rework their firmwares but ... it may end up being even more work than just cut&paste what we have at driver level. And a pain in the ass for users willing to use these softwares...

[audiohacked]

Reworking the firmware would be even worse in terms of development time. And I mean at least a year or two FOR EACH DEVICE you want supported.

I mean, I love your enthusiasm, but dealing with any kind of software that interfaces with hardware IS a HUGE undertaking.

[mfp20]

@audiohacked

I agree. It would have been much better to have arduino-like boards in those products; rpi0 cost 5 bucks and it's small enough. Aaaaanyway...

That's why I suggest to keep going at driver level. Look: @tatokis is alone. With you, 2 developers. With me 2,5 developers. It's already better than 3 messages ago.

[Ravenslofty]

Actually they use NXP ARM microcontrollers; LPC11Uxxx if I remember correctly.

I promise you, 2/3 developers is not enough manpower for this.

On Tue, 19 Feb 2019, 02:38 mfp20 <notifications@github.com wrote:

@audiohacked https://github.com/audiohacked

I agree. It would have been much better to have arduino-like boards in those products; rpi0 cost 5 bucks and it's small enough. Aaaaanyway...

That's why I suggest to keep going at driver level. Look: @tatokis https://github.com/tatokis is alone. With you, 2 developers. With me 2,5 developers. It's already better than 3 messages ago.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ckb-next/ckb-next/issues/376#issuecomment-464956278, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbx2-WWnnK23MLtzqoZjeSJofbSsilJks5vO2OYgaJpZM4bAD2D .

[mfp20]

@ZirconiumX

Thanks but I'm not going down that route. Each silicon - and each of their SDKs - has its own peculiarities; and one company change silicon often. No worth spending time learning those peculiarities. In this case we are talking of about 10 years of products... so... And it is even worse in the case we would proceed by logic analyzer, oscilloscope and alike...

But still, I don't understand why you all are negative about the idea to re-structure the code base. The reverse engineering has been done, and working drivers are in place. All the code is usbfs (devtmpfs) based so... the hard part is already there :)

Anyway, the two repo owners are active and open minded. That's enough for me to give it a go and report back. Maybe I just need to hands-on a bit deeper in order to figure out the warnings that you all are giving to me; or maybe I can do it alone. Let's see...

Thank you all for the time spent reading my rants. Please, leave the issues open for a few weeks. So I've a log where to report back.

[Ravenslofty]

But still, I don't understand why you all are negative about the idea to re-structure the code base. The reverse engineering has been done, and working drivers are in place.

Working drivers you wish to drop. How would you feel if someone suddenly removed support for your keyboard without warning? If they then said "well I don't have that keyboard so it's not my responsibility to maintain it".

All the code is usbfs (devtmpfs) based so... the hard part is already there :)

No, CKB has Mac support. The hard part is already there and you plan to drop it.

Even better, @tatokis mentioned that you can't register LEDs from userspace, and that even if you could it doesn't help wireless devices, which Corsair are pumping out with increasing frequency.

Anyway, the two repo owners are active and open minded.

Glad my contributions to the code are welcomed, after having reversed the NXP protocol and written a Wireshark decoder for it.

That's enough for me to give it a go and report back. Maybe I just need to hands-on a bit deeper in order to figure out the warnings that you all are giving to me; or maybe I can do it alone. Let's see...

Start by writing a driver for the K95 Platinum. We know the NXP protocol the best (you're welcome for the hours I put into reverse engineering it), but you'll find that scaling it to the entire suite of keyboards and mice, plus the Polaris and ST100, across all three (more?) major firmware revisions quickly becomes impractical.

[mfp20]

But still, I don't understand why you all are negative about the idea to re-structure the code base. The reverse engineering has been done, and working drivers are in place.

Working drivers you wish to drop.

Negative. Never said, nor wish, that. I wrote about rewriting the working ones, and reduce priority in advancing the not working ones or adding the missing features. In order to spare time for working on the core itself.

How would you feel if someone suddenly removed support for your keyboard without warning? If they then said "well I don't have that keyboard so it's not my responsibility to maintain it".

That's not the case. People that already use the software won't be let down, 'cause they already have it and use it. Generally speaking, keyboards and mices work properly without the need of ckb-next. The kernel modules already take care of those kind of devices. ckb-next adds bells&whist... macros&leds :) So, what I'd say is not "not my responsibility", but "please urge Corsair to support our development, or send to me your keyboard to help development for other unlucky guys, and buy a new one from a different company".

All the code is usbfs (devtmpfs) based so... the hard part is already there :)

No, CKB has Mac support. The hard part is already there and you plan to drop it.

In this case I wrote 'drop', but then @tatokis has been pretty definitive in his answer so I asked if it was possible to change the folders layout in order to update cmake. As a workaround to not 'drop'. In general: if a developer want to keep a feature, can maintain it. In this case the portability feature forces the project to use cmake cause gnu make doesn't really fit in osx and windows.

Even better, @tatokis mentioned that you can't register LEDs from userspace,

Well, registering leds in userspace isn't a huge problem. The URB Control thing that @tatokis said worries me more. This is why I'm working on a kernel module; not a 'libcorsair' mashup.

and that even if you could it doesn't help wireless devices, which Corsair are pumping out with increasing frequency.

I don't uderstand why you all look so much concerned about supporting more and more devices, and corsair devices only. Other brands suffer the same problems on linux; and the suggested architectural changes would make much more people happy.

I've one of those wireless mices, so I might spend time to decode that protocol. But it is not a priority for me: first I use it wired, second I don't have the proper macros (and lighting) setup because I miss a unified manager. Different priorities.

Anyway, the two repo owners are active and open minded.

Glad my contributions to the code are welcomed, after having reversed the NXP protocol and written a Wireshark decoder for it.

Don't get me wrong. I said 'two repo owners' because I don't know who did what and how you organized your work in the past. Of course, all contributors brought us where we are today.

That's enough for me to give it a go and report back. Maybe I just need to hands-on a bit deeper in order to figure out the warnings that you all are giving to me; or maybe I can do it alone. Let's see...

Start by writing a driver for the K95 Platinum. We know the NXP protocol the best (you're welcome for the hours I put into reverse engineering it), but you'll find that scaling it to the entire suite of keyboards and mice, plus the Polaris and ST100, across all three (more?) major firmware revisions quickly becomes impractical.

Dude, I want to avoid as much as possible to understand the protocol. I just want to take what exist in this box, and place it in a new box. I don't really care what's inside the old and the new box, as far as it works. I know that there might be the need to understand a bit of it, but I hope to not have to dig it too deep...

[davidbdyer]

The Mac Beta of iCUE is garbage. You can't map any of the modifiers to a button on the scimitar.

[mfp20]

The Mac Beta of iCUE is garbage. You can't map any of the modifiers to a button on the scimitar.

So: fix it. You have the chance here: there are 2,5 developers currently active on this 2 projects; plus another one that is available for questions about the protocols. If you are an OSX user, step up to be the OSX maintainer ...

In general: open source projects can't be companies' support services because none of these people are paid for it. Some (ex: @tatokis ) care about The People, some others (ex: me) don't. In other words: if you want something, you must do it yourself. So, give availability to spend your time, and for sure you'll get a better OSX support thanks to your effort. I mean, ckb-next better than Corsair's beta.

[davidbdyer]

@mfp20 You misunderstand. I never suggested anyone needed to be tech support for me? I was relaying that iCUE for Mac has essential features missing. iCUE itself has some UX flaws, and Corsair needs to hire a UX designer. I don't need either driver in Mac OS. I programmed a hardware profile in windows to use in Mac OS, and Linux and my Corsair AIO is controlled by my motherboard fan headers. I'm learning C++ now and might be able to help in the future with coding and could help improve the UX.

[mfp20]

@davidbdeath more than one misunderstanding. I was inviting you to jump on the bandwagon.

I don't care what Corsair needs. I know what I need: decent software support for the (awesome) hw I bought. The current problem I have is bouncy keyboard switches; my keyboard chat by itself... this thing could be mitigated in software, if the software would be open source. If corsair does it, I'm happy. Otherwise, next time I need to buy something I'll stay away from Corsair. I did the same choice about 15 years ago with Logitech as their software has always been crap; and even today I just don't take Logitech into consideration for any keyboard more expensive than 20 bucks. And 20 bucks are enough for a good chinese keyboard; to give myself the chance to find a new good brand. Last year I went for Roccat as there was a guy that developed the linux kernel modules and a good interface for those devices; but the quality of materials was a bit disappointing (ex: a whining mousewheel, bulky pastics, etc); so I gave a second look and found that Corsair protocols were under assault by brave Free engineers ... and switched to corsair. Not a problem to switch again within a year or two.

What we know today (well, we knew in novemmber 2018) is that Corsair have no plan to support UX systems; they gave a try to OSX, without success, apparently. Probably their major problem is not the host GUI, but the devices' firmwares; because looks like they didn't stick to standard (ie: USB) protocols, nor developed their own protocol for internal use. They probably gave in outsourcing the development of their products; a different source (and differrent platform) for each new product; and ended up in having a mess in their firmwares. It's pretty common nowadays. Companies are in the hands of business scholars, not engineers; they tend to approach complex organizations using socioeconomic engineering instead of common sense (ie: real needs) and science (ie: real solutions); and those are the results. Actually, modern companies are just 'brand management studios'; they do not develop anything in house. If this is the case, as the developers stated, we can't fix this mess. We'd better focus on what we need and hope that Corsair too will do something about it.

Developing a cross-platform app nowadays isn't that hard. Well: much easier than before. There are dozens of cross-platform libraries (ex: Qt, libusb) to rely on. Even C/C++ standardized many more things that used to be part of 'external libraries' (ex: threading). But evidently Corsair didn't have 'cross-platform' (and security! we're talking about keyboards here... the main human-computer interface) in their business/design rules. Too busy with spreadsheets... So, here we are. May I suggest you to put together your need (of having a working corsair desktop, I guess) and your current C/C++ learning activity? Jump on, semi-empirical approach (ie: hands on!) is the quickest way to learn how to do something, and having something useful at the end doesn't let you watch behind and say yourself "I've spent X weeks of my life learning something but having nothing useful back".

Digging a bit into the subject. I've been reworking the usbip kernel module in order to turn it into a usb router. I'm pretty far from success yet, but it looks to me the best bet to recycle what we have. Because there's the need to intercept raw usb traffic, and eventually mangle it, before handling over to the devtmpfs char device in use by libusb (and then both OpenCorsairLink and ckb-next). And the usbip modules already contain a virtual usb host and a virtual usb hub, both for 2.0 and 3.0 usb standards. In other words it allows to attach the usb devices to a virtual host, and reroute their traffic to the virtual usb hub, where the devices are then accessed (again, via libusb). I tested the current usbip against the lightning node, commander pro and darkcore; and it works. My current attempt is to make the tcp/ip transport to be not the only option, but one of the options; others being anything that need to manage that usb traffic before it is delivered to the usbfs char device. Example: a corsair specific module. The same could apply, by the way, to any usb device, from any brand... At that point we would have some kernel modules that can clone the traffic; ex: to send the LINK traffic to lm_sensors and the macro&lighting to ckb-next. Or just fix some quirks corsair might have introduced in their firmwares.

A kernel module is a good HelloWorld project for a C/C++ student. Just open a repo somewhere so that we can work together on this thing, before going back to disturb @tatokis and @audiohacked ; we need to produce the solution to the problems they have been so kind to raise. I apologize for not doing it myself but ... I don't consider those 'web tools' a technology advancement, so I tend to expose my name on web for Pr0n&Fun only. Don't want to waste my time in managing those. Github then ... it's not a coincidence that Microsoft bought it. They have a weird (and sick) concept of 'business incubator'.

[audiohacked]

A kernel module is a good HelloWorld project for a C/C++ student.

A kernel module is NOT a "HelloWorld" project. Doing a quality Linux kernel module is something very few people are capable of doing. The kernel module projects mentioned have strict use cases and are most likely not going to work in helping us....Because I've looked into it myself.

I think it's time we close this issue, because I think this discussion is devolving into conspiracy theories on how companies work by some.

@mfp20 What you want is just not feasible. It would take 2 years even with Corsair's help (with documentation and programming contribution) and their products sharing a common hardware platform or protocol.

I can tell you that developing one CorsairLink-compatible product isn't easy, because this past year I had to develop a hardware platform for a product. And coordinating the hardware and software sides isn't easy when you have a whole team (10s of people) developing a single project with a single goal in mind. And some of the people on said team are contributing work on both the hardware and software sides of the project. (This is what I do for a living..)

Developing cross-platofrm software and hardware is not easy, otherwise Corsair would already be doing it.

[mfp20]

@audiohacked

A kernel module is a good HelloWorld project for a C/C++ student.

A kernel module is NOT a "HelloWorld" project. Doing a quality Linux kernel module is something very few people are capable of doing.

The kernel module is the perfect "HelloWorld" project: all the goodies are in there, it allows you to plug directly into a living thing, and you can hack and rebuild at will. Nowadays is much easier as you can do your test in virtual machines; don't need to break service continuity of the machine you're using to develop. I didn't ask him to do a 'quality linux kernel'; I asked him to use the kernel as his new toy, and focus on a common target. He plays, I make it work. I hope. I mean: we need to have something that works, first. In the second round we can make it good enough for kernel inclusion. Somewhere in the docs there should be the rules to follow in order to have the code accepted in the mainstream kernel.

The kernel module projects mentioned have strict use cases and are most likely not going to work in helping us....

Sure, because it is made for a single purpose. I'm making it more abstract and general. I've already changed the name of it into 'usbvirt'. Then I isolated the 'socket' related part. Now I'm building the alternative transport layer.

Because I've looked into it myself.

Awesome! So, what's the blocking issue you've found? Because I haven't found any, yet. And maybe you can save me from wasting my time as well! If that code is able to remove the usb management bits and wrap the payload with tcp headers, without breaking USB communication (not even the EP0!!!) ... well ... I don't see why it shouldn't be working. From what I can see now, the worst result possible is ... added latency; but for our purpose there's no need to re-wrap, route, re-wrap; we're talking of mere cpu-time for a kernel-level job. Even in the case we can't just memcopy, can't be a blocking amount of latency. And even if we miss the target, Linux will have a cleanup in its module; it currently looks like a mashup of different projects and there's a note in the code stating some TODOs. I'm not developing something to make better corsair products; I'm developing something to make my life better, given the externality to give back to Linux users something even in the case I can't fix my own problem. Is that so... absurd?

More in general: can you please be a bit more useful instead of +1 messages (heart emoji!? Seriously?), and keep repeating that 'isnt feasible'? This is Github, not Facebook: different task, different app, different goal. We manage code here, not people.

I think it's time we close this issue, because I think this discussion is devolving into conspiracy theories on how companies work by some.

I think you have out-of-band reasons for breaking the comms about this project: baiting young videogamers to turn them into new code monkeys? working for Corsair? A software developer worried for his professional future? You're a bit in late, dude. Microsoft sent people in half-world's parliaments saying that "Free Software destroys the market", about 20 years ago! In english they are called 'lobbyists', not 'conspirationists' because there are public records of those auditions; no need to invent yourself any conspiracy. Your people win that battle 20 years ago and they didn't tell you! After that there have been Bruce Perens / E.S.R. and their Open Source Initivative ... please, look at OpenSource's history yourself. Finaly we arrived here: Github, git (ie: a distributed tool) on the leash (ie: a centralized authority). It happened to everything spanning from silicon to github, via napster, skype and bitcoin. Then an american officer admitted 'not wittingly'. Then Zukkaberg made his show in the american parliament. There's people in USA waiting for Snowden with ropes in their hands. And you keep talking of conspiracies... did you read some of those 'Success for Dummies' books, perhaps? Schopenhauer's 'The Art of Controversy: stratagems', maybe? Facts, no wanks.

Whatever: what's wrong with you is not my business. But I'm not a earth-flatter; my house is not very far from the tower where Galileo proven the earth was moving, and I'm not baptized (a Roman Chatolic Church arcane ritual done to unarmed kids): it's a kind of tradition in my place to stick to facts. And facts are that things like Github concentrate in a single hub a huge amount of Free Work that companies can get without paying a cent to any worker. And because of this reason, there are plenty trolls paid to manipulate this Free Work. As I said: a weird (and sick) concept of 'business incubator'.

@mfp20 What you want is just not feasible. It would take 2 years even with Corsair's help (with documentation and programming contribution) and their products sharing a common hardware platform or protocol.

Ok, we ALL got your point: isn't feasible, and if it is, even at best conditions it would take too long. It was clear long before your first message appeared, from the position and the amount of 'heart emoji' you've left in the previous posts. You don't need to repeat this again in the future. Thank you.

Can we keep going anyway or ... ?

I can tell you that developing one CorsairLink-compatible product isn't easy, because this past year I had to develop a hardware platform for a product. And coordinating the hardware and software sides isn't easy when you have a whole team (10s of people) developing a single project with a single goal in mind. And some of the people on said team are contributing work on both the hardware and software sides of the project. (This is what I do for a living..)

I'm sure you do it for living. But ... again ... what all this have to do with us? Here we are talking about getting the 1-year you've spent on OpenCorsairLink, the 1-year that @tatokis spent on ckb-next, and add another 6-months to make those 2-years serve better our lives. I've never been talking about developing a product; nor I'm willing to do it. I want: 1) remove bouncing from my keyboard. 2) have macros. 3) make the million-leds useful instead of being a permanent Christmas tree in my room. I'd like to see colors only when I buy LSD, not when I buy Corsair...

I thought I was speaking with Free Random Developers, and I feel like being in one of those industrial consortiums (ex: USB Implementers Forum, United Nations Security Council) where every delegate has his own agenda dictated from his company instead of pursuing the common consortium's goal.

Developing cross-platofrm software and hardware is not easy, otherwise Corsair would already be doing it.

As I said: easier than before. A month ago I've built a QMainWindow app on both Windows and Linux, without changing anything in the code. And judging from what I can see here, libusb is cross-platform as well. And, C/C++ is more cross-platform than anything else. So the idea I have is that Corsair didn't even try to make a cross-platform app; and it is understandable: videogames are windows-only, their target were videogamers. Why to bother with (and spend for) the rest of us? As I said: decision making people in companies are business scholars, not engineers. Their perspective is money, not engineering. Anyway, their products aren't a fail. Materials are awesome, assembly is awesome, style is awesome; electronics looks good from the pictures I've seen. I mean: anything that can be appreciated from a business scholar (and a monkey), by looking and touching, is good. The only (huge) problem is software; and ain't that big issue once we consider it to be 'soft' (ie: it can be changed without breaking the things a part). So... once again... let's do it...

[davidbdyer]

By UX I meant user experience. I don't have a clue where to start with writing a kernel extension or framework for Mac OS.

[audiohacked]

@mfp20 How about you just go and do it and stop posting here? STOP WASTING everyone's time discussing it! I much rather you improve OpenCorsairLink and ckb-next instead of going down the road of building a new project. The things you keep bringing up that you want fixed isn't going to get fixed with your "project". And in about 2 months you're going to abandon the project.

[tatokis]

That basically sums it up. This thread has been derailed. If you want to contribute something, you are welcome to open a PR.