1

I'd like Conky to display things like the usage of each CPU core, but I don't see a way to do this other than by manually writing a Conky config file which explicitly enumerates which cores I'd like it to display, and manually figuring out the layout of those details, and hard-coding that knowledge into the configuration file. This makes the configuration file useless on another machine, which contains a CPU with a different set of existing core IDs.

This is especially true if I visually distinguish between 'performance' and 'efficiency' cores - the core IDs on other hardware won't have the same correspondence.

The same is true for other hardware components, such as the number and device names of drives, networking interfaces, etc.

I got a new laptop, and am setting up Conky on it. My old Conky file is next to useless because of things like the above. So does Conky require me to write and maintain different config files for every machine I want to use it on? (Or else forgo any detailed information that is specific to my actual hardware).

I can imagine a facility in Conky to tackle this, something like a config that specifies:

${for-each CPU N}
    ${cpubar $N} ${cpu$N} etc
${end-for}

But I'm failing to find such a thing in the man page. One difficulty with this hypothetical feature is that core IDs are not sequential numbers (e.g. on my system that means 0,4,8,16,20,24 and 25,26,27,28,29,30,31,32). So the for-loop would need to be smart about that. Similar smarts would be required so that the for-loop could iterate over extant network interfaces, hard drives, etc. I don't think a facility like this exists, am I wrong? Is there an alternative way to generalize config files to work on arbitrary hardware?

An acceptable answer might include a modern replacement for Conky, that learns from the once-trailblazing and venerable Conky's now well-understood design shortfalls? (eg. one, two)

4
  • Have you considered using Lua to provide your imagined loop? May 10, 2023 at 11:37
  • @DavidYockey Yes, I think that's a good suggestion, but it isn't sufficient. What would I loop over? I suppose, to take an example, I could loop over all possible Core IDs, and for each one, find a way to test whether it is valid for my hardware, and whether it is a performance or efficiency core, and whether it has a temperature sensor, and is that shared between any other cores, and depending on the results of all that, decide whether and how to include it in the graphical output. Perhaps caching would be needed, so that that wouldn't all have to be done every time conky updates. May 10, 2023 at 12:18
  • @DavidYockey The above sounds possible, but also a lot of work, and it's exactly the kind of work that I (perhaps foolishly) expected conky would do for me. Perhaps I just don't understand, or had the wrong expecations. May 10, 2023 at 12:24
  • @DavidYockey Perhaps, instead of trying to detect all that dynamically, we could have a big lookup table, that knew all the answers for each model of CPU. Again, it seems sensible to build that into conky, rather than expecting each user to compile it for themselves. May 10, 2023 at 12:25

0

You must log in to answer this question.

Browse other questions tagged .