Radeontray: Monitor & change Radeon GPU power states from the systray

Stunts · 2013-11-10 17:09:01

Hi everyone! I have just updated my program "radeon-tray" to support DPM.
It seems to be working just fine in my laptop, but I would like some more testing before I update my AUR package for it.
Can anyone provide some feedback please?
You can find the code here: https://github.com/StuntsPT/Radeon-tray on the branch "DPM".
I still have to update the docs to match the changes from using DPM, but most of you here already know the differences. =-)
You can adapt the PKGBUILD from here (https://aur.archlinux.org/packages/radeon-tray/) if you wish to install via pacman.
Thank you very much for any feedback you may provide!

Edit: Changed title to be more descriptive

Last edited by Stunts (2013-11-19 23:32:59)

siavashserver · 2013-11-10 18:23:06

Stunts wrote:

Hi everyone! I have just updated my program "radeon-tray" to support DPM.
It seems to be working just fine in my laptop, but I would like some more testing before I update my AUR package for it.
Can anyone provide some feedback please?

Fails to run as super user:

# radeontray
No protocol specified
radeontray: cannot connect to X server :0

EDIT1:
I should have run it like this:

kdesu radeontray

This is on RadeonHD 4890:

EDIT2:
Nice work so far, here is my feedback on it ^_^ :
- It would be nice if tooltip balloon could blend with KDE plasma theme
- It would be nice to use colorful tray icons to indicate the current GPU usage/load
- Being able to set an interval for power state detection will be good

Last edited by siavashserver (2013-11-10 19:11:03)

skottish · 2013-11-11 03:10:59

Stunts wrote:

...snip...

Shouldn't this be in its own thread? This has little to do with drivers for radeon other than a monitor.

Last edited by skottish (2013-11-11 03:14:16)

Inxsible · 2013-11-11 03:20:48

It should. Stunts, please start threads in the correct forums. Do not hijack threads.

Stunts · 2013-11-11 08:55:23

Sorry about that! I did not mean to hijack the thread!
I just thought that that thread would be the best place to find the early adopters of DPM.
Please accept my sincere apologies, thank you Inxsible, for starting the new thread for me.

Stunts · 2013-11-11 09:05:57

@siavashserver:

First of all, thank you for your feedback. It is most welcome.

Regarding how to run the program:
you can either launch it via kdesu, or you can use the systemd service to start the daemon "/usr/bin/radeontrayserver" and then run "/usr/bin/radeontray client" without administrative privileges.

Regarding the screenshot - it seems to be a bug in Qt. Other Qt applications I have that use the "popup ballon" from system tray display the same shadow. I'm not sure it happens in other distros. Once I'll look into that, I might open a bug report in flyspray if it is justified.

As for your other points:
1. I wouldn't know how to support that. I'm an e17 user. But any help with it is very welcome.
2. I have thought about that, simply by monitoring the "power level" of the card. But AFAIK, that would require constant polling of a file, which should be a resource hog by itself. But if there is an alternative form to do this I will certainly go for it.
3. I'm not really sure what you mean by this, care to explain further?

siavashserver · 2013-11-11 10:21:51

Stunts wrote:

Regarding the screenshot - it seems to be a bug in Qt. Other Qt applications I have that use the "popup ballon" from system tray display the same shadow. I'm not sure it happens in other distros. Once I'll look into that, I might open a bug report in flyspray if it is justified.

I've noticed same behavior with VLC when minimized to system tray; It's probably a Qt bug, may be that's just my setup, never really cared about that

Stunts wrote:

1. I wouldn't know how to support that. I'm an e17 user. But any help with it is very welcome.

May be you need to use D-Bus for notifications? For example deadbeef music player pop ups looks native on both GNOME and KDE.

Stunts wrote:

2. I have thought about that, simply by monitoring the "power level" of the card. But AFAIK, that would require constant polling of a file, which should be a resource hog by itself. But if there is an alternative form to do this I will certainly go for it.

If that involves constant monitoring of a file, you might need to use inotify so you will be notified by OS whenever there is changes to that file. I think having tray icon being changed on GPU power level changes is far more useful than GPU active power state, and easier than manually clicking on tray icon to check for GPU usage.

Stunts wrote:

3. I'm not really sure what you mean by this, care to explain further?

I meant the interval your program is going to check for GPU power level or power state changes. I guess there will not be any need to this If you can use inotify.

Other minor improvements can be:
- Using correct units for shader and memory clocks (For example: sclk: 85000 -> sclk: 850MHz)
- Using correct unit for voltages (For example: vddc: 1313 -> vddc: 1.313v)
- Providing newbie/human readable output (For example: mclk -> Memory Clock)
Ofcourse all of those changes requires you being able to modify the input strings on the fly if possible.

Regards to the GPU temperature sensors, have I missed installing any specific package? I've lm_sensors installed and KDE system monitor works fine with that.

Stunts · 2013-11-12 10:01:38

Humm... d-bus interface... I've never played with that, but the idea sounds *very* interesting. I'm very likely to look into it in the future! Thanks!

I have used inotify in the shell before. I'll have to search for a python implementation or something like that. It also sounds like a very good idea. It's probably what I will look into next.

The program currently only updates the status when you click on it. But now I see what you meant.
Changing the units is in fact quite simple. I'll do that as soon as I have 15 minutes free time.

As for the missing temperature, as I have stated in the documentation, I only have the location of my own card's sysfs file.
If you can provide me with yours too, I can add it to the array.
Thanks once again for the feedback. Expect some of those changes to land soon. =-)

siavashserver · 2013-11-12 12:22:59

Stunts wrote:

As for the missing temperature, as I have stated in the documentation, I only have the location of my own card's sysfs file.
If you can provide me with yours too, I can add it to the array.

Mine (RadeonHD 4890) with similar location to yours is located here:

/sys/class/drm/card0/device/hwmon/hwmon0/temp1_input

In my humble opinion creating a list of sensor locations manually on compile time is pretty tedious. I recommend using a runtime based approach so you can easily deal with multiple cards on same setup later. So here is proposal:

1) Creating a list of all entries located in /sys/class/hwmon/. So for example we will have (This is on my system) :

/sys/class/hwmon/hwmon0/
/sys/class/hwmon/hwmon1/
/sys/class/hwmon/hwmon2/

2) Checking for existence of a file named name inside previous results :

/sys/class/hwmon/hwmon0/name
/sys/class/hwmon/hwmon1/name

3) Filtering entries which their name is equal to radeon :

/sys/class/hwmon/hwmon0/name  ->  radeon
/sys/class/hwmon/hwmon1/name  ->  atk0110  (This is my motherboard)

4) Reading file named temp1_input inside previous entries, which their name was radeon :

/sys/class/hwmon/hwmon0/temp1_input  ->  48500 (Graphics card temperature)

Sorry about just ordering do this and do that, unfortunately I have no experience with Python programming language otherwise I would be glad to give you a hand.

Thanks for your great work!

Stunts · 2013-11-13 09:53:25

That is a very clever idea!
I did not know I could find hwmonitors there.
I'll look into that.
Thank you for all the feedback. And don't worry about not knowing python. You have already helped a lot!
I'll update the thread after I implement some of these changes.

Stunts · 2013-11-17 00:34:35

Ok, just pushed some changes into the DPM branch.
You should now be able to read your temperature and the info box is a lot more detailed.
Let me know how it's working for you.
Next change coming up:
Dynamic hardware monitors detection! (probably next week)

siavashserver · 2013-11-17 05:15:21

It works like a charm, and I like the new compact look

I know this is going to be pretty overkill, but what do you think about a QML based interface?

Last edited by siavashserver (2013-11-17 05:23:36)

Stunts · 2013-11-17 15:11:15

Thanks!
I've never touched QML, but from what I read it's quite a delight to work with it.

Also, does anyone know what vclk and dclk stand for in UVD?
I just called them "D" and "V" clock, but I really have no idea what they represent...

siavashserver · 2013-11-18 15:46:50

Stunts wrote:

Also, does anyone know what vclk and dclk stand for in UVD?
I just called them "D" and "V" clock, but I really have no idea what they represent...

I asked Alex Deucher (developer behind new DPM patches) in a short conversation about what vclk and dclk are representing and he kindly explained :

Alex Deucher wrote:

They are the clocks for the UVD block on the GPU. Vclk is the vcpu clock and dclk is the decoder clock.

Stunts · 2013-11-18 22:39:45

Thanks!
Updated in the DPM branch with the new names.
I wish I had more time to improve this further and faster...

Stunts · 2013-12-07 15:39:06

Just added dynamic temperature path finding!
The list hack is gone now.

Up next: inotify support to make the icon colour change according to the current power level.

Last edited by Stunts (2013-12-07 15:41:34)

Arch Linux

#1 2013-11-10 17:09:01

Radeontray: Monitor & change Radeon GPU power states from the systray

#2 2013-11-10 18:23:06

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#3 2013-11-11 03:10:59

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#4 2013-11-11 03:20:48

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#5 2013-11-11 08:55:23

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#6 2013-11-11 09:05:57

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#7 2013-11-11 10:21:51

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#8 2013-11-12 10:01:38

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#9 2013-11-12 12:22:59

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#10 2013-11-13 09:53:25

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#11 2013-11-17 00:34:35

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#12 2013-11-17 05:15:21

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#13 2013-11-17 15:11:15

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#14 2013-11-18 15:46:50

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#15 2013-11-18 22:39:45

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

#16 2013-12-07 15:39:06

Re: Radeontray: Monitor & change Radeon GPU power states from the systray

Board footer