Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inefficient sendDataInternal #299

Open
iqqmuT opened this issue Dec 19, 2022 · 1 comment
Open

Inefficient sendDataInternal #299

iqqmuT opened this issue Dec 19, 2022 · 1 comment

Comments

@iqqmuT
Copy link

iqqmuT commented Dec 19, 2022

Bug solution in the commit d6d9763 maybe fixes a bug but it consumes CPU way too much in hidapi mode. The USB connection is re-established every time any data is sent to the wire.

When updating LEDs multiple times in a second in animation, the CPU usage gets high. I changed the code so that usleep is used again instead of re-establishing the connection and the CPU usage dropped to a minimal level even though I was updating LEDs 40 times in a second.

Related issues and PRs:
#45
#52
#63
#64

What would be the "Logitech" way to handle sending the data?

@ercksen
Copy link

ercksen commented Mar 11, 2023

I was also looking towards a solution to reduce CPU load. My G815 displays CPU and RAM load and some other metrics, plus, some keys are animated. To fluidly display everything, I need an update rate that causes g815-led to consume 100 % load on one core and after a minute or so the data jams and is delayed due to too much data being processed. I set all key colors in non-commit mode and do one commit after each whole update to reduce latency/overhead but that does not seem to work at all.

Now most importantly: What did you change to make it work? Can you make a PR? Or show me your changes? I would be really interested in a solution.

Note that G-Hub manages this with < 1 % CPU load, so it is definitely technically possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants