Closed 4e6 closed 9 years ago
Good catch, but I suspect it might be not enough?. DPI can be set per-output using XRandR (yes, I'm actually changing DPI to 150+ but didn't notice this problem so far?), so at minimum we need to get the DPI of self.monitor
. Depends on where pango gets his DPI value.
Strictly speaking, the output window is auto-sized, so it would be nice to set the font size by pixel-size directly. It looks like this is not supported by pango?...
Of course there's also an absolute size attribute (AttrSizeAbsolute), which avoids the DPI scaling. I briefly tested it here by manipulating the Xft.dpi
resource and seems to work as intended. Could you give it a shot?
My Xft.dpi
set to 210
> grep dpi ~/.Xresources
Xft.dpi: 210
> xdpyinfo | grep -B2 resolution
screen #0:
dimensions: 2560x1440 pixels (311x176 millimeters)
resolution: 209x208 dots per inch
Nice detail, didn't know about absolute version of AttrSize
function. I can confirm that 5fdc19feb5c1d30a09f16e1ca9c329320e7fe706 fixes the issue.
On 06/09/15 11:59, Dmitry Bushev wrote:
My |Xft.dpi| set to 210
I re-discovered I had set manually Xft.dpi to 96 due to the external monitor usually being lower-res :/. It was causing me headaches when moving windows from-to the external monitor.
It looks like almost nobody actually does per-output scaling correctly, and those who do use the XRandR value instead of the X resource.
https://github.com/wavexx/screenkey/commit/5fdc19feb5c1d30a09f16e1ca9c329320e7fe706 fixes the issue.
Did you notice any other issue? If not, I think this deserves a quick release.
Tried different sizes, positions and custom geometry. Looks good to me.
Although, I've managed to find another small one #11
Oh well, I also fixed another issue involving the stored geometry (couldn't reset after an interactive resize).
Calculate font size considering DPI of the current display. Function
get_screen_dpi
returns DPI based ongtk-xft-dpi
Screen setting with fallback to default value (original logic).fixes #9