2 Jan 2024 |
diogotr7 | test script just sends a rainbow, it should look the same on all keyboards | 21:36:44 |
chr1sno | Ok, I'll go and check the upstream code also. Have you got a verbose log there I could look at also? | 21:38:29 |
chr1sno | * Ok, I'll go and check the upstream code also. Have you got a verbose log there I could look at? | 21:38:36 |
diogotr7 | One second | 21:38:37 |
diogotr7 | Download OpenRGB_20240102_213918.log | 21:39:49 |
k1_801 | Honestly, that didn't fully answer the question... | 21:40:11 |
diogotr7 | I don't know how much what you have is still based on Wooting's code, but here: https://github.com/WootingKb/wooting-rgb-sdk/pull/59 | 21:42:56 |
sir_qwex | I think we need that flag or its impossible to remove the plugin at least for windows(the default one for windows disallow that), because it has seg fault in linux I would just only set that flag in case of windows. | 22:20:56 |
sir_qwex | And it is also possible that the main issue with removing plugin is only present at windows | 22:21:47 |
3 Jan 2024 |
k1_801 | We get new releases approximately once or twice a year, yet there is no fixed release dates. We have a plan of what has to be done before the next release and there won't be one until those criteria are met. | 18:07:46 |
morg7672 | the protocol is similar to https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3551 | 20:52:37 |
morg7672 | same VID | 20:52:56 |
morg7672 | same batch of packets | 20:53:10 |
morg7672 | ^ | 20:57:19 |
morg7672 | we did not add it | 20:57:32 |
morg7672 | i just had a look at both captures | 20:57:43 |
4 Jan 2024 |
| .dark8088 changed their display name from dark8088 to .dark8088. | 03:52:10 |
theroguezeta | We don’t need the software, we need captures of the software talking to the device. #reverse-engineering is the place to get started in getting it supported. | 04:26:29 |
theroguezeta | See the pins for some guides. | 04:28:18 |
geo_bot | the last commit had a couple misspellings, I fixed them https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/2213 | 19:47:53 |
5 Jan 2024 |
k1_801 | calcprogrammer1 when you have the time, could you please explain to me why the JSON serialization code in SettingsManager::SaveSettings() uses settings_file << settings_data.dump(4); (with a conversion to a string, which is buffered, then dumped into a stream, and then destroyed) instead of a direct operator << , i.e. settings_file << settings_data; that dumps the data directly into the stream as the data gets serialized, with the indentation witdth set prior to the call? | 02:21:31 |
k1_801 | * calcprogrammer1 when you have the time, could you please explain to me why the JSON serialization code in SettingsManager::SaveSettings() uses settings_file << settings_data.dump(4); (with a conversion to a string, which is buffered, then dumped into a stream, and then destroyed) instead of a direct operator << , i.e. settings_file << settings_data; that dumps the data directly into the stream as the data gets serialized, with the indentation witdth set prior to the call? | 02:21:59 |
k1_801 | * calcprogrammer1 when you have the time, could you please explain to me why the JSON serialization code in SettingsManager::SaveSettings() uses settings_file << settings_data.dump(4); (with a conversion to a string, which is buffered, then dumped into a stream, and then destroyed) instead of a direct operator << , i.e. settings_file << settings_data; that dumps the data directly into the stream as the data gets serialized, with the indentation witdth set prior to the call? | 02:22:10 |
k1_801 | It doesn't look like a possible source of config corruption, but I'm spotting an inefficiency here, both in memory use and CPU time use. | 02:24:18 |
calcprogrammer1 | I don't know if I knew that was an option | 03:05:41 |
calcprogrammer1 | if it does the same thing but with more efficiency then I'm OK switching to it | 03:06:03 |
k1_801 | Download image.png | 04:28:15 |
| djmalachite changed their profile picture. | 09:28:23 |
7 Jan 2024 |
| yellobird changed their profile picture. | 15:57:03 |
森口友治 | #openrgb-tech-support | 22:29:25 |