For years, I’ve set the DPI in Mate Appearances > Fonts > Details > DPI to 120 for my high res screen. Until the latest (12.2) versions, conky was unaffected by this. Now, goto, alignc, alignr, and probably a lot of other commands I don’t use are confused and move too far to the right. Was this intentional? Is there a command to compensate for changing system DPI?
The graphics is the on chip graphics for an AMD Ryzen 5 2500U. However, it was trivial to fix after thinking a bit. I just scaled everything by 96/120 = 0.8. So I set minimum_width and maximum_width to 1536, and scaled every goto by 0.8. So, goto 830 became goto 665. This fixed all the placements. Setting DPI in MATE does the same thing as setting the scaling in Windows. 120/96 = 1.25, which results in the same screen scaling in MATE that I get with 125% in Windows. Something in conky now pays attention to DPI, but it really is new to the latest version, 12.2.
I’m not the only one to notice this change. There is an issue on github, https://github.com/brndnmtthws/conky/issues/1097. The more I think about this, the more it seems like a bug. If I want to go to the middle of a line that is 1920 pixels long, goto 960 should work no matter what the DPI is. Perhaps they are trying to implement scaling and got it wrong?
Here is the history, the problem appeared after the first update, and the reversion made my original .conkyrc script work again. Changing my .conkyrc file as described in my earlier post allows me to use the new version.
Update that broke things.
2021-04-30 09:56:59 | install | conky | 1.12.2-1.1
Revert that fixed things.
2021-04-30 11:38:43 | install | conky | 1.12.1-1.3
Update now works with **modified** .conkyrc file.
2021-05-02 15:56:09 | install | conky | 1.12.2-1.1
I haven’t looked at the code yet, but the commit that broke things seems to multiply the move derived from “goto y” by the system DPI divided by the assumed default DPI of 96. So conky says " y’ = DPI/96 * y ", where y is from the .conkyrc file, then issues " goto y’ ". I fixed things by changing all my y values, including screen width, to the old value * 96/DPI and the multiplications cancel out. As I said, this seems like a bug, not a new feature.