<p>dunst没有使用正确的DPI呈现文本</p>

+1目前是否有解决方法？

+1，因为笔记本电脑/台式机上的高dpi显示器越来越受欢迎，所以会有更多人对此感到满意。

JFI：明显的解决方法是增加字体大小，例如dunstrc中的font = Ubuntu Mono 18 。

但这并不会增加图标的大小。 这也使跨机器配置变得烦人。

是的，当前正在运行中，这迫使我卸载dunst并改用notify-osd :(

我有一个工作的分支。 只需要做一些更多的工作来存储DPI并在现在对256进行硬编码的地方使用它。 另外，如果监视器具有不同的DPI，则在更改监视器时应更新DPI，并重新绘制所有内容。

@mathstuf嗨，对此有任何更新吗？ 我们能帮你什么吗？

代码需要获取实际值，而不是差异底部的256。 我一直在寻找并且从未回过头来找到该功能。

我也遇到了这个障碍。 很高兴看到正在做一些工作。

仅供参考，仍然有一段时间没有使用它了:(。随时更新我的​​分支以从X获取真正的DPI。

我会拉，看看我能做什么。

这是使用Xresources设置dunst.dpi的补丁。

干得好@cliscum。 也许我们可以使用@mathstuf的工作从X自动获取DPI？

干得好@cliscum。 也许我们可以使用@mathstuf的工作从X自动获取DPI？

我不确定，但是客户端是否不需要两个值（或仅需要XResource值）？ IIUC， xrandr --dpi （ xorg.conf / DisplaySize ）更改X认为关于物理显示的真实设置以及Xresources / Xft.dpi设置客户在绘画时应该使用的东西。 因此，如果用户修改Xft.dpi并且客户服从，则X将做正确的事，并在适当的情况下（如果自动检测错误，则覆盖）DPI。 不过，目前尚不清楚X是否执行缩放应用程序，或者X客户端是否需要请求它（从语义上还是通过自己进行计算）。

X不进行缩放，客户端需要自己进行缩放。 是的，应该只使用Xresources值，这是所有大型工具箱和应用程序所做的事情。

唔。 我要做的就是用xrandr设置DPI； 完全没有X资源设置，使用工具箱的非GTK2应用看起来也不错。

一些工具箱会根据X11 dpi为您设置X资源。

似乎用户在这里具有两个级别的控制（假设用户可以配置X服务器；我认为通常不是这种情况，但是通常大多数系统是单用户的，自我管理的，因此...）：

1. 通过X服务器的配置.../xorg.conf ， xrandr （它认为显示是现实的）
2. 通过X客户端的配置.../.Xresources ， xrdb （用户希望用户界面使用什么DPI） [* note]

我认为您应该更喜欢使X服务器的配置反映现实，并在给定用户首选项/配置的情况下，让X客户端做正确的事情。 X服务器包含此DPI设置以外的缩放机制，您可能更喜欢这种缩放机制（ xrandr --scale ？）； 在AFAIU中，当X由于硬件损坏/过旧而无法正确确定DPI设置时，DPI设置主要有用。

我最近开始使用带15.6英寸4K显示屏的笔记本电脑；我已将X配置为正确设置显示屏的物理尺寸（§Monitor | DisplaySize ww hh ），并使用Xft.dpi按我的喜好缩放UI（〜288 X DPI /本机PPI，144 Xft.dpi ）。

值得注意的是，X的xorg.conf / DisplaySize配置和xrandr的--dpi控制相同的东西。

*注意： Xft（X FreeType）最终如何控制DPI（并通过Xresources配置启动）？ 这实际上有多“标准”？ 那么fontconfig呢？

不尊重Xft.dpi将无法控制； 使它们呈现与_do_尊重Xft.dpi的应用程序相同的唯一方法是保持DPI假设（通常为96 dpi；因此将Xft.dpi保持在96）。 然后，可以使用X的DisplaySize / DPI来应用DPI缩放。 不过，这可能会在多屏幕/显示器设置中崩溃，因此这是一个很大的警告，确实应该适当地修复。

恕我直言，正确的做法是尊重xrandr设置。 最重要的因素是可以按显示设置（ Xft.dpi不能，因此我们总是有一个坏的显示）。 用户还可以修改它，因此它实际上也可以是客户端配置。

恕我直言，正确的做法是尊重xrandr设置。 最重要的因素是可以按显示设置（Xft.dpi无法设置，因此我们总是有一个坏的显示）。 用户还可以修改它，因此它实际上也可以是客户端配置。

也可以按X11 DISPLAY设置Xft.dpi，例如，使用echo Xft.dpi: 192 | DISPLAY=:0 xrdb -merge 。

请注意，X11 DISPLAY与RandR输出不同，并且如今大多数设置在同一X11 DISPLAY上使用多个RandR输出。 X11在不同的RandR输出上不支持不同的dpi值。

我仍然强烈建议您先使用Xft.dpi，如果有的话，请回落到RandR值。

几周前，我发现xrandr --help表明--dpi选项需要<dpi>/<output> ； 我还没有时间去看它的实际功能，但这意味着每个输出的DPI设置。 手册页中没有关于它的任何内容。

来源请参阅https://sources.debian.net/src/x11-xserver-utils/7.7%2B7/xrandr/xrandr.c/#L3514 。 AFAICT，该选项将查找指定输出的DPI（基于其物理高度），并将其设置为整个X11 DISPLAY。

这不是每个输出的设置。

@stapelberg对不起，“显示”对我来说是一个错误的选择。 我指的是物理显示器（不是Xorg显示器），实际上是输出。 xrandr可以设置每个输出，而Xft.dpi不能：

xrandr --output eDP1 --dpi 160

好的。 设置每个输出的DPI并依赖于应用程序来查询该设置意味着：

• 应用程序需要知道显示在哪些输出上，并相应地选择正确的DPI。
• 在跨输出移动时，应用程序将需要重新初始化其整个渲染/工具包/…（不适用于dunst）

考虑到dunst的特殊性质（使用不可移动的重叠窗口），我可以看到如何选择每个输出的DPI值似乎是一个很酷的技巧。 我仍然认为这不是一个干净的解决方案，并且鉴于流行的应用程序和工具包（全部都只使用Xft.dpi来代替）对DPI设置的无视，可能只有很少的用户会注意到此功能的存在。

话虽这么说，我最终不关心实现什么—我只想让您通过偏离使用Xft.dpi的实际标准来了解正在做出的取舍。

Xft.dpi是标准，但实际上已损坏； 假定所有输出具有相同的DPI。

就像您说的那样，Dunst处于非常特殊的情况（不可移动的窗户）。 但是它还有另一个特殊的性质：通常由知道如何使用RTFM的人（相对于gnome用户）使用，因此干净地记录哪些DPI值被误用，对于任何有兴趣的用户来说，这些都应该可以正常使用。

同样，打破事实上的标准的唯一方法是开始使用实际上做出正确假设的另一种方法！ 😄

话虽这么说，我最终不关心实施了什么

我实际上在乎，因为Xft.dpi表示当我使用外部监视器时通知损坏（反之亦然）。

Xrandr DPI也是按显示的，而不是按输出的（X本身仅支持单个DPI值； Xrandr不会解决该问题）。 与显示相关联的标志仅使其成为用于计算的标志，而不是其他显示或以其他方式计算出的DPI。 您需要Wayland来进行每输出DPI设置。 您现在可以获得的壁橱是在整个屏幕上以最低的DPI进行标准化，并使用Xrandr缩放/放大较高的DPI监视器。

已在fixdpi分支中进行了修复。 具有高dpi监视器的人可以在合并之前测试这些更改吗？ 任何反馈表示赞赏。

Dunst应该优先考虑Xft.dpi X资源，此后是天真的计算的后备，它可以正确处理具有不同dpi的多台显示器。

最新稳定：

分支fixdpi（带有Xft.dpi: 160 ）：

我将不得不重新调整我的字体，大小和内容（现在太大了，太粗了），但看起来好像可以用了。

更新：天真计算似乎不起作用（这是15英寸，@ 2880x1800）。

分支fixdpi（无Xft.dpi ）：

很奇怪，请确保您在启用Xrandr的情况下进行了编译（如果未对config.mk进行任何更改，则默认情况下应启用该功能）

xrandr的输出是什么？

我安装使用此：

make X11INC=/usr/include/X11 X11LIB=/usr/lib/X11
make PREFIX=/usr install

$ xrandr
Screen 0: minimum 320 x 200, current 2880 x 1800, maximum 8192 x 8192
eDP1 connected primary 2880x1800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   2880x1800     59.99*+
   2048x1536     60.00
   1920x1440     60.00
   1856x1392     60.01
   1792x1344     60.01
   1600x1200     60.00
   1400x1050     59.98
   1280x1024     60.02
   1280x960      60.00
   1024x768      60.00
   800x600       60.32    56.25
   640x480       59.94
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)

我用一些调试输出推送了一个提交（我确实应该在某个时候添加一些适当的日志记录）。
显示通知后，dunst输出什么？

抱歉，查看调试输出使我更仔细地了解设置，结果发现我在后面的测试中设置了Xft.dpi: 106 （我将删除用于笔记本电脑的160覆盖） ，但将默认值留在了后面）。

再次正确测试，检测工作正常：

Tried to acquire dpi using Xresources(if 0 the operation failed): 0.000000
Trying dpi autodetection for screen:
Position: X: 0 Y: 0
Resolution: W: 2880 H: 1800
Size: mmH: 207

Calculation result: 220.869565

对不起，混淆了。

我确实承认，该字体看起来比预期的要大胆和大。 这仅仅是缩放，还是字体大小本身增加了？

我确实承认，该字体看起来比预期的要大胆和大。 这仅仅是缩放，还是字体大小本身增加了？

我假设字体大小正在增加，但是我不确定，因为我们在内部所做的所有操作都是将dpi值传递给cairo，并且它可以处理字体设置和渲染。

计算结果：220.869565

看起来dpi计算认为您的dpi为220，这与您稍后设置为dpi的值160相矛盾，因此这可能就是字体看上去比平常大的原因。

我假设字体大小正在增加，但是我不确定，因为我们在内部所做的所有操作都是将dpi值传递给cairo，并且它可以处理字体设置和渲染。

TBH，结果是大胆而肥胖。 更仔细的检查使我认为字体的增长超出了应有的程度：

例如，以下是屏幕截图，分辨率为106 dpi，并使用GIMP手动缩放了150％（这是缩放到160dpi的样子）：

这是使用Xft.dpi: 160拍摄的屏幕截图：

请注意，该字体实际上比预期的大。

看起来dpi计算认为您的dpi为220，这与您稍后设置为dpi的值160相矛盾，因此这可能就是字体看上去比平常大的原因。

哦，屏幕实际上是220dpi（所以可以正常工作）。 我将其设置为160dpi，因为这是我喜欢的缩放比例（但这完全是个人的）。 在220dpi的分辨率下，一切看起来对我来说都太大了（像素密度的增加使我可以阅读更小的文字，等等）。

需要特别清楚的是：计算很好； 160dpi是我进行的个人调整，不能反映实际屏幕的dpi。

最后，对每屏dpi的检测表示赞赏，这（很少）不是很常见。

闲置2周后，终于有时间再次进行此操作。

TBH，结果是大胆而肥胖。 仔细检查使我认为字体的增长超出了应有的程度

那可能是由于小数点后的原因，我对结果进行了四舍五入，如果不能完全解决这个问题，该结果应该会有所改善。

此外，我发现如果您的多个屏幕的dpi略有不同，则每个屏幕使用不同的dpi可能会导致一些视觉上的不一致，因此我将du-strc中的每个屏幕dpi检测功能作为可选实验功能，直到我们找出可以

更改已合并以掌握，现在应该已解决。

Dunst应该优先使用Xft.dpi X资源，此后便是天真的计算的后备，它可以正确处理具有不同dpi的多个监视器。

@tsipinakis ，您能澄清一下这个声明吗？ Dunst如何支持每个监视器（X11输出）DPI？ 您自己已经注意到X11不支持此功能，并且这种支持是Wayland项目的主要目标。 据我了解，在X11下对此的支持要求用户直接配置Dunst，以了解哪些输出具有哪些DPI。 X11没有规范来存储或传达此数据/配置。

https://github.com/dunst-project/dunst/blob/master/dunstrc#L189-似乎表明此功能仅在未通过Xresources指定Xft.dpi值时才有效。 但是，在这种情况下， Xft.dpi不会获得“默认”值吗？ 在96 ，甚至？
我觉得这种实验性支持在现实世界中的用例非常有限，这是因为它必须对如何解释X11的每输出DisplaySize / DPI （它们是互惠的；本质上说，它们是同一件事。 我不相信X11客户端应该完全解释这些值。

如果您可以给我一些指导，我想测试一下此功能（主要是使Dunstrc尊重Xft.dpi的主要目标，其次是了解每个X11输出DPI机制）。

首先，由于某些视觉上的不一致（从后备状态更改为选择加入实验功能），请参见示例dunstrc 。

每个监视器的dpi部分指的是每个randr输出。 我们使用randr报告的物理屏幕尺寸来近似计算该屏幕的dpi。 参见这里的代码（不要问我这个计算是如何工作的，对我来说仍然很神奇:)）。

这是我们将X11显示器扩展名从xinerama更改为randr的原因之一。

在发布下一个版本之前，文档是我的下一个主要目标，因此它也应该有助于弄清部分内容是如何工作的。

为了响应您的编辑，这是作为实验添加的，因为在该线程中之前提到它将是一个受欢迎的功能，并且由于我们实施dpi处理的方式，这是一个非常简单的更改。 目前尚不清楚它在实际情况下的效果如何，我自己甚至还没有对它进行很好的测试，因为我的所有显示器都具有基本相同的dpi，这就是实验性的原因。

根据我的测试，如果未设置Xft.dpi则不会返回值（用于检索它的函数调用将返回0）。 在这种情况下，如果per_monitor_dpi为true ，

我在这里测试了基本功能-效果很好。 本周我将使用第二台显示器后，将对实验位进行测试。

问题：dunst在我的设置（Debian Sid）上作为systemd用户服务运行-我已经构建了dunst并将其安装到~/.local ; 我试图在~/.config/systemd/user.conf设置DefaultEnvironment="PATH=/home/nmschulte/.local/bin:$PATH ，配置似乎有效，因为现在我必须手动启动Dunst守护程序。 但是，我如何才能使DefaultEnvironment正常工作，所以它只能修改所选用户的环境（如文档中的~/.config/systemd/user.conf那样；请参阅第1项https://wiki.archlinux.org /index.php/Systemd/User#Environment_variables），以使其与~/.profile （或~/.bash_profile / ~/.bashrc设置的用户PATH）相匹配）？ 与user.conf文件不同，ArchWiki似乎表明systemctl --user set-environment适用于所有用户。

另外，Dunst是否支持“重新加载配置”信号（例如i3）？ i3使用此信号重新检查Xft.dpi / Xresources的值，这对于Dunst也是明智的。 但是，在某些方面，守护程序生命周期似乎是不可思议的（由于d-bus？实际上管理守护程序生命周期的原因是什么？），并且在立即恢复守护程序的情况下干掉它就可以了。 它在启动时获取新值。

@tsipinakis ，此变更集未正确增加通知图标的比例。

我不明白您在第一个问题中想要完成的工作，您能否提供更多详细信息？ 为什么要尝试设置PATH？

此外，Dunst是否支持“重新加载配置”信号

目前不是， killall dunst尽可能接近。 随时提交功能请求。

此变更集无法正确增加通知图标的比例。

如果您使用max_icon_size设置，则该设置不会有意缩放，因为该值以像素为单位，并且对于所使用的显示器dpi，应该将其设置为合理的像素值。

关于我的第一个问题：我正在尝试使在系统设置中运行的Dunst实例（来自Debian Sid的现成配置）使用我用PREFIX=~/.local构建的版本。 我通过~/.profile将此目录设置在我的PATH上。 我试图配置systemd来执行此操作，认为systemd是管理Dunst实例的对象（因为htop显示了dunst属于systemd --user ）。 这没有用，实际上似乎已经完全破坏了Dunst实例。

实际上，Dunst由dbus管理，而dbus由systemd管理。 在grep ，我发现/usr/share/dbus-1/service/org/knopwob.dunst.service文件具有Exec=/usr/bin/dunst ，这是我一直在寻找的魔术。

回复： max_icon_size -了解。 当前的默认值为32 ； 默认情况下，最小的改进可能是0 。 否则，比率/比例因子似乎是合适的，也许具有可配置的（或智能的，假设是必要的）基础。 或者，交换智能（或“主要”变量），或者也允许_that_作为首选项。 我认为，如果您对此有所关注，那么实验性的内容将直接适用（阅读：对字体大小的用法相同）。

〜我不知道我已经打破了什么; 在我用PREFIX=~/.local编译并安装Dunst并设置为~/.profile PATH=/home/nmschulte/.local/bin:$PATH之后，D-Bus似乎不再运行Dunst。 此后，我删除了~/.config/dunst/dunstrc ，以为可能导致Dunst崩溃，随后又删除了实际的~/.local/bin/dunst二进制文件，以为它可能崩溃或干扰了D-Bus / SystemD以某种方式执行。 但是，现在我被困住了，而# aptitude reinstall dunst却无济于事。 我很乐意为您提供帮助，但是我不想让这个话题出轨。〜
〜我将~/.local/share/dbus-1/移到~/.local/share/dbus-1.bak/ ，看来Dunst再次运行了。 我不知道这里出了什么问题； 也许dbus不会加载服务，因为它们具有相同的名称或名称？〜
好吧，我发现了问题； 打包的D-Bus服务文件调用了系统服务dunst.service ，它是以前不习惯的。 似乎我不需要此配置，但是我不确定为什么要引入它。
dbus-daemon[1056]: Activation via systemd failed for unit 'dunst.service': Unit dunst.service not found.

好吧，我发现了问题； 打包的D-Bus服务文件调出了它不曾使用过的systemd服务dunst.service。 似乎我不需要此配置，但是我不确定为什么要引入它。

我假设您在systemd下运行dbus，因此它以--systemd-activation标志开始，这是在＃295中添加的，但是显然我忘记考虑了dbus由systemd管理但未安装dunst服务文件的情况。

请注意，无论如何，systemd并不真正支持会话DBus服务。 请参阅systemd / systemd＃892。

正确，我们已经劫持了这个问题，因此可以将讨论移至＃314。