cromer/tuf-manager
1
0
Fork 0
Code Issues Pull Requests Releases 8 Wiki Activity

use gsettings for tuf-cli info #3

New Issue
Closed
opened 2021-11-12 19:03:33 -03:00 by lknop · 4 comments
lknop commented 2021-11-12 19:03:33 -03:00
Copy Link

tuf-gui and tuf-cli use different sources to display the same information.

On my machine tuf-cli info is useless as /sys/devices/platform/faustus/kbbl/* are write-only.

However, tuf-gui uses gsettings and provides the correct information - as long as tuf-manager is the only source of color change.

My proposal would be to add a flag to tuf-cli to optionally read the values from the settings rather that /sys

The color format could also be unified to use hex everywhere to avoid confusion and simplify script usage.

$ tuf-cli color "#008888"

$ tuf-cli info 
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Balanced
Current keyboard lighting: Static
Current keyboard speed: Slow
Current keyboard color: #000000

$ tuf-gui
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Balanced
Current keyboard mode: Static
Current keyboard speed: Slow
Current keyboard color: rgb(0,136,136)
`tuf-gui` and `tuf-cli` use different sources to display the same information. On my machine `tuf-cli info` is useless as `/sys/devices/platform/faustus/kbbl/*` are write-only. However, tuf-gui uses gsettings and provides the correct information - as long as tuf-manager is the only source of color change. My proposal would be to add a flag to tuf-cli to optionally read the values from the settings rather that `/sys` The color format could also be unified to use hex everywhere to avoid confusion and simplify script usage. ``` $ tuf-cli color "#008888" $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Balanced Current keyboard lighting: Static Current keyboard speed: Slow Current keyboard color: #000000 $ tuf-gui Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Balanced Current keyboard mode: Static Current keyboard speed: Slow Current keyboard color: rgb(0,136,136) ```
cromer commented 2021-11-13 18:42:47 -03:00
Owner
Copy Link

tuf-gui and tuf-cli use different sources to display the same information.

This is incorrect. Both the GUI and the CLI get their information from the same source which is the tuf-server which should be running in the background as a service. And that server gets all its information from the files in /sys. Here is proof:
https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/common.vala#L111
https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/server.vala#L258

On my machine tuf-cli info is useless as /sys/devices/platform/faustus/kbbl/* are write-only.

Again, incorrrect. Those files are writable if you are using the faustus driver module. That is how the tuf-server writes the values and the driver module can see those changes and make your keyboard and fan change their state. If they are not writable for you, then either your system doesn't have the faustus driver module installed, or something is configured wrong.

However, tuf-gui uses gsettings and provides the correct information - as long as tuf-manager is the only source of color change.

You have a big missunderstanding as to what gsettings is being used for. The kernel module has no way to know what color and mode the keyboard is in, nor the speed of the fan when the system boots. The files in /sys always contain the "default" values, not the real values after booting. So to get around that what I do is store the current configuration that a user does in gsettings. So when TUF Manager server starts it restores those values and places them into the /sys files so they reflect the true settings. This is a limitation of the driver module, and using gsettings gets around this problem. This isn't a perfect fix, but it does add a cool new feature. Because the color is stored in gsetting, and then I restore it when TUF Manager starts, it gives per user and per distro coloring. For exmaple, I have Artix Linux, Linux Mint, and Fedora all on the same machine. When I login to Artix Linux, it has red stored in gsettings and changes me keyboard to red. When I login to Fedora it has blue in gsettings so it turns blue when I login. And when I login to Linux Mint it turns green. However if you turn off the restore functionality in settings in TUF Manager, then switch between distros, it will always show the incorrect color because /sys does not have the current color on boot.

My proposal would be to add a flag to tuf-cli to optionally read the values from the settings rather that /sys

Due to the previous response, this makes 0 sense. /sys is the the only way to set values in the kernel driver module, and the value being read from either is either the default color, or the color restored from gsettings if restore is enabled. So reading from gsettings will contain the same values as what is in /sys.

The color format could also be unified to use hex everywhere to avoid confusion and simplify script usage.

If you are scripting then you should be using hex codes and the tuf-cli which also uses colors in hex mode. However tuf-gui is not for scripting, it is a GUI! And that GUI has a color picker which stores the colors in RGBA, not in hex! That is why it shows the RGBA color in the GUI.

As far as differences between the output of the GUI and the CLI, your problem is that your are not doing a restore in the CLI. If you open the GUI and check settings, you will notice the option "restore on start". What that does is when the GUI starts, it restores the values that are in gsettings by copying them into /sys.

In the CLI you have to do a restore with this command:

tuf-cli restore

Restore only needs to be run once, after booting. And in the case of the CLI, you have to do it by running the command, or make a startup script that runs it for you after you login to your session.

If you run "tuf-cli restore" at least once before you run tuf-cli info it will show the same output as the GUI. The only difference as I mentioned is that the CLI uses hex and the GUI uses RGBA and this is on purpose.

> tuf-gui and tuf-cli use different sources to display the same information. This is incorrect. Both the GUI and the CLI get their information from the same source which is the tuf-server which should be running in the background as a service. And that server gets all its information from the files in /sys. Here is proof: https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/common.vala#L111 https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/server.vala#L258 > On my machine tuf-cli info is useless as /sys/devices/platform/faustus/kbbl/* are write-only. Again, incorrrect. Those files are writable if you are using the faustus driver module. That is how the tuf-server writes the values and the driver module can see those changes and make your keyboard and fan change their state. If they are not writable for you, then either your system doesn't have the faustus driver module installed, or something is configured wrong. > However, tuf-gui uses gsettings and provides the correct information - as long as tuf-manager is the only source of color change. You have a big missunderstanding as to what gsettings is being used for. The kernel module has no way to know what color and mode the keyboard is in, nor the speed of the fan when the system boots. The files in /sys always contain the "default" values, not the real values after booting. So to get around that what I do is store the current configuration that a user does in gsettings. So when TUF Manager server starts it restores those values and places them into the /sys files so they reflect the true settings. This is a limitation of the driver module, and using gsettings gets around this problem. This isn't a perfect fix, but it does add a cool new feature. Because the color is stored in gsetting, and then I restore it when TUF Manager starts, it gives per user and per distro coloring. For exmaple, I have Artix Linux, Linux Mint, and Fedora all on the same machine. When I login to Artix Linux, it has red stored in gsettings and changes me keyboard to red. When I login to Fedora it has blue in gsettings so it turns blue when I login. And when I login to Linux Mint it turns green. However if you turn off the restore functionality in settings in TUF Manager, then switch between distros, it will always show the incorrect color because /sys does not have the current color on boot. > My proposal would be to add a flag to tuf-cli to optionally read the values from the settings rather that /sys Due to the previous response, this makes 0 sense. /sys is the the only way to set values in the kernel driver module, and the value being read from either is either the default color, or the color restored from gsettings if restore is enabled. So reading from gsettings will contain the same values as what is in /sys. > The color format could also be unified to use hex everywhere to avoid confusion and simplify script usage. If you are scripting then you should be using hex codes and the tuf-cli which also uses colors in hex mode. However tuf-gui is not for scripting, it is a GUI! And that GUI has a color picker which stores the colors in RGBA, not in hex! That is why it shows the RGBA color in the GUI. As far as differences between the output of the GUI and the CLI, your problem is that your are not doing a restore in the CLI. If you open the GUI and check settings, you will notice the option "restore on start". What that does is when the GUI starts, it restores the values that are in gsettings by copying them into /sys. In the CLI you have to do a restore with this command: ``` tuf-cli restore ``` Restore only needs to be run once, after booting. And in the case of the CLI, you have to do it by running the command, or make a startup script that runs it for you after you login to your session. If you run "tuf-cli restore" at least once before you run tuf-cli info it will show the same output as the GUI. The only difference as I mentioned is that the CLI uses hex and the GUI uses RGBA and this is on purpose.
lknop commented 2021-11-13 19:13:47 -03:00
Author
Copy Link

Both the GUI and the CLI get their information from the same source which is the tuf-server

This is incorrect. GUI reads it from settings and compares with the server. CLI gets it from the server only.

https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/gui-window.vala#L203
https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/cli.vala#L408

If you run "tuf-cli restore" at least once before you run tuf-cli info it will show the same output as the GUI.

This is incorrect.

I think you have misunderstood the line you quoted and based the whole answer on that.

Let me quote again:

On my machine tuf-cli info is useless as /sys/devices/platform/faustus/kbbl/* are write-only.

In other words, you can write to the files to set the color, but when read they always contain zeros.

The log I pasted are not random examples but the commands run in succession. Same as below:

$ tuf-cli info
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Balanced
Current keyboard lighting: Static
Current keyboard speed: Slow
Current keyboard color: #000000

$ tuf-cli color "#aafaaa"

$ tuf-cli info
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Balanced
Current keyboard lighting: Static
Current keyboard speed: Slow
Current keyboard color: #000000

$ tuf-cli restore

$ tuf-cli info
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Balanced
Current keyboard lighting: Static
Current keyboard speed: Slow
Current keyboard color: #000000

Note: please forgive my tongue in cheek tone but I simply couldn't resist :-) I seriously like the software and I just wanted to improve it.

> Both the GUI and the CLI get their information from the same source which is the tuf-server This is incorrect. GUI reads it from settings and compares with the server. CLI gets it from the server only. https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/gui-window.vala#L203 https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/cli.vala#L408 > If you run "tuf-cli restore" at least once before you run tuf-cli info it will show the same output as the GUI. This is incorrect. I think you have misunderstood the line you quoted and based the whole answer on that. Let me quote again: > On my machine tuf-cli info is useless as /sys/devices/platform/faustus/kbbl/* are **write-only**. In other words, you can write to the files to set the color, but when read they always contain zeros. The log I pasted are not random examples but the commands run in succession. Same as below: ``` $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Balanced Current keyboard lighting: Static Current keyboard speed: Slow Current keyboard color: #000000 $ tuf-cli color "#aafaaa" $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Balanced Current keyboard lighting: Static Current keyboard speed: Slow Current keyboard color: #000000 $ tuf-cli restore $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Balanced Current keyboard lighting: Static Current keyboard speed: Slow Current keyboard color: #000000 ``` Note: please forgive my tongue in cheek tone but I simply couldn't resist :-) I seriously like the software and I just wanted to improve it.
cromer commented 2021-11-13 21:00:48 -03:00
Owner
Copy Link

This is incorrect. GUI reads it from settings and compares with the server. CLI gets it from the server only.

All that comparison does is overwrite what is in /sys, which can be seen a few lines below that:
https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/gui-window.vala#L207

Basically if the color from gsettings is different from the color that is in /sys during the restore call it overwrites the value in /sys. So in this case both gsettings and /sys will have the same values so it doesn't matter which of the 2 I print.

The log I pasted are not random examples but the commands run in succession.

If those are in succession, then your problem is with the kernel driver module. When I run those same commands in the same order:

$ tuf-cli info
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Silent
Current keyboard lighting: Static
Current keyboard speed: Medium
Current keyboard color: #FF0000

$ tuf-cli color "#aafaaa"

$ tuf-cli info
Client version: 1.2.3
Server version: 1.2.3
Current fan mode: Silent
Current keyboard lighting: Static
Current keyboard speed: Medium
Current keyboard color: #AAFAAA

As you can see, when I do it my color changes and is being read from /sys, yours did not change when you ran that command, it still says #000000 which is not correct. Mine is not only writable, but it also is completely readable and changes values. I am curious, what model TUF do you have, and which kernel driver did you install? In my case I have the TUF FX505DT, and am using this driver: https://github.com/hackbnw/faustus

In other words, you can write to the files to set the color, but when read they always contain zeros.

This means something is wrong on the kernel module driver because when I read those files they do not have zeros in them:

$ cat /sys/devices/platform/faustus/kbbl/kbbl_red 
aa

As you can see it has the values that tuf-cli placed into them.

Note: please forgive my tongue in cheek tone but I simply couldn't resist :-) I seriously like the software and I just wanted to improve it.

Don't worry about it, I am known to have the same tone. ;) But that doesn't mean I am unwilling to work on things, improve them, etc. And glad that you like the software.

Changing the source of the settings from /sys to gsetting isn't the right solution here, your problem seems to be with the driver itself.

> This is incorrect. GUI reads it from settings and compares with the server. CLI gets it from the server only. All that comparison does is overwrite what is in /sys, which can be seen a few lines below that: https://git.cromer.cl/cromer/tuf-manager/src/branch/master/src/gui-window.vala#L207 Basically if the color from gsettings is different from the color that is in /sys during the restore call it overwrites the value in /sys. So in this case both gsettings and /sys will have the same values so it doesn't matter which of the 2 I print. > The log I pasted are not random examples but the commands run in succession. If those are in succession, then your problem is with the kernel driver module. When I run those same commands in the same order: ``` $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Silent Current keyboard lighting: Static Current keyboard speed: Medium Current keyboard color: #FF0000 $ tuf-cli color "#aafaaa" $ tuf-cli info Client version: 1.2.3 Server version: 1.2.3 Current fan mode: Silent Current keyboard lighting: Static Current keyboard speed: Medium Current keyboard color: #AAFAAA ``` As you can see, when I do it my color changes and is being read from /sys, yours did not change when you ran that command, it still says #000000 which is not correct. Mine is not only writable, but it also is completely readable and changes values. I am curious, what model TUF do you have, and which kernel driver did you install? In my case I have the TUF FX505DT, and am using this driver: https://github.com/hackbnw/faustus > In other words, you can write to the files to set the color, but when read they always contain zeros. This means something is wrong on the kernel module driver because when I read those files they do not have zeros in them: ``` $ cat /sys/devices/platform/faustus/kbbl/kbbl_red aa ``` As you can see it has the values that tuf-cli placed into them. > Note: please forgive my tongue in cheek tone but I simply couldn't resist :-) I seriously like the software and I just wanted to improve it. Don't worry about it, I am known to have the same tone. ;) But that doesn't mean I am unwilling to work on things, improve them, etc. And glad that you like the software. Changing the source of the settings from /sys to gsetting isn't the right solution here, your problem seems to be with the driver itself.
cromer commented 2022-01-01 15:22:34 -03:00
Owner
Copy Link

Going to close this since there wasn't any follow up.

Going to close this since there wasn't any follow up.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cromer/tuf-manager#3
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?