You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Not sure if the feature is related to a problem, but sorry for another "lighting feature request". Maybe this one is simpler. I have a Logitech G815, and it works perfectly with libratpack-piper. One of the limitations is that the lighting options for piper are limited to solid, circle, breathing or off. While this is nice, I can't assign specific colors for specific keys. For example, I set numbers as purpler, while AWSD is set as red, and letters are light blue, etc. I can achieve this setup using OpenRGB and works perfectly fine.
The main issue I'm having is when I click the key for change profile (M1, M2 and M3), libratpack overrides the OpenRGB configuration and messes the colors. I need to reload my OpenRGB profile and fix the colors every time I change profile. The issue also happens if I change the profile color through the piper GUI.
Describe the solution you'd like
It would be nice to have an extra option in the LED profiles to disable or preventing changing colors. The name could be "Disabled" or "Do not change", sorry I can't think on another name. This option means that changing into the profile can't change the colors that were previously set in the keyboard. For example, if the keyboard is set by any tool as breathing, choosing this option shouldn't change the LED configuration, just the configuration assigned to the G buttons. That way, when libratpack-piper changes a profile, it doesn't mess the LED setup made by another tool.
Describe alternatives you've considered
Another possibility is to have something like g810-led. The user can submit a text file with the configuration color for each key. Then read that config file and set the colors for the keys. The tab could be called "Customized" or "User specific". This could be super awesome, because everything handled by one tool would be the best, but any route that is simpler to implement works fine.
Thanks for putting this tool together and sharing it.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Not sure if the feature is related to a problem, but sorry for another "lighting feature request". Maybe this one is simpler. I have a Logitech G815, and it works perfectly with libratpack-piper. One of the limitations is that the lighting options for piper are limited to solid, circle, breathing or off. While this is nice, I can't assign specific colors for specific keys. For example, I set numbers as purpler, while AWSD is set as red, and letters are light blue, etc. I can achieve this setup using OpenRGB and works perfectly fine.
The main issue I'm having is when I click the key for change profile (M1, M2 and M3), libratpack overrides the OpenRGB configuration and messes the colors. I need to reload my OpenRGB profile and fix the colors every time I change profile. The issue also happens if I change the profile color through the piper GUI.
Describe the solution you'd like
It would be nice to have an extra option in the LED profiles to disable or preventing changing colors. The name could be "Disabled" or "Do not change", sorry I can't think on another name. This option means that changing into the profile can't change the colors that were previously set in the keyboard. For example, if the keyboard is set by any tool as breathing, choosing this option shouldn't change the LED configuration, just the configuration assigned to the G buttons. That way, when libratpack-piper changes a profile, it doesn't mess the LED setup made by another tool.
Describe alternatives you've considered
Another possibility is to have something like g810-led. The user can submit a text file with the configuration color for each key. Then read that config file and set the colors for the keys. The tab could be called "Customized" or "User specific". This could be super awesome, because everything handled by one tool would be the best, but any route that is simpler to implement works fine.
Thanks for putting this tool together and sharing it.
The text was updated successfully, but these errors were encountered: