<p>dunst n'utilise pas le DPI correct pour le rendu du texte</p>

+1 existe-t-il actuellement une solution de contournement pour cela?

+1, de plus en plus de personnes toucheraient cela car les moniteurs à résolution élevée sur les ordinateurs portables / ordinateurs de bureau deviennent populaires.

JFI: la solution de contournement évidente est d'augmenter la taille de la police, par exemple font = Ubuntu Mono 18 dans dunstrc.

Cela n'augmente cependant pas la taille des icônes. Cela rend également la configuration inter-machine ennuyeuse.

Oui, je suis actuellement confronté à ce qui me force à désinstaller dunst et à utiliser notifier-osd à la place :(

J'ai une succursale qui fonctionne. Il suffit de faire un peu plus de travail pour stocker le DPI et l'utiliser dans les endroits où 256 est actuellement codé en dur. En outre, le DPI doit être mis à jour et tout redessiné lorsque le moniteur est changé au cas où les moniteurs auraient des DPI différents.

@mathstuf Salut, une mise à jour à ce sujet? Comment pouvons nous aider?

Le code doit obtenir la valeur réelle au lieu de 256 au bas du diff. Je n'avais pas trouvé la fonction quand je cherchais et je n'y suis pas retourné depuis.

J'ai également rencontré ce problème. Heureux de voir que du travail est en cours.

Pour info, je n'ai toujours pas travaillé dessus depuis un moment: (. N'hésitez pas à mettre à jour ma branche pour obtenir le vrai DPI de X.

Je vais tirer et voir ce que je peux faire.

Voici un patch qui utilise un paramètre Xresources, dunst.dpi.

Beau travail @cliscum. Peut-être pouvons-nous utiliser le travail de @mathstuf pour obtenir automatiquement le DPI de X?

Beau travail @cliscum. Peut-être pouvons-nous utiliser le travail de @mathstuf pour obtenir automatiquement le DPI de X?

Je ne suis pas certain, mais le client n'a-t-il pas besoin des deux valeurs (ou simplement de la valeur XResource)? IIUC, xrandr --dpi ( xorg.conf / DisplaySize ) modifie ce que X croit être réel à propos de l'affichage physique, et le paramètre Xresources / Xft.dpi est ce que les clients devraient utiliser pour peindre. Ainsi, si l'utilisateur modifie Xft.dpi et que le client obéit, X fera la bonne chose et peindra avec tout ce qui est approprié (ou remplacé, si la détection automatique est incorrecte) DPI. Cependant, il n'est pas clair si X effectue l'application de mise à l'échelle ou si les clients X doivent le lui demander (soit sémantiquement, soit en effectuant eux-mêmes le calcul).

X n'effectue aucune mise à l'échelle, les clients doivent le faire eux-mêmes. Et oui, il ne faut utiliser que la valeur Xresources, ce que font toutes les grandes boîtes à outils et applications.

Hmm. Tout ce que je fais, c'est régler le DPI avec xrandr; aucun paramètre de ressource X du tout et les applications non GTK2 utilisant des boîtes à outils semblent correctes avec cela.

Certaines boîtes à outils définiront la ressource X pour vous en fonction du dpi X11.

Il semble que l'utilisateur dispose de deux niveaux de contrôle ici (en supposant que l'utilisateur puisse configurer le serveur X; je pense que ce n'est généralement pas le cas, mais généralement la plupart des systèmes sont mono-utilisateur, auto-administrés et donc ...):

1. via la configuration du serveur X, .../xorg.conf , xrandr (de ce qu'il pense que l'affichage est en réalité)
2. via la configuration du client X .../.Xresources , xrdb (de quel DPI l'utilisateur veut l'interface utilisateur) [* note]

Je pense que vous devriez préférer faire en sorte que la configuration de votre serveur X reflète la réalité et laisser les clients X faire ce qu'il faut, compte tenu des préférences / configuration de l'utilisateur. Le serveur X inclut des mécanismes de mise à l'échelle autres que ce paramètre DPI, que vous pourriez préférer ( xrandr --scale ?); AFAIU, le paramètre DPI est principalement utile lorsque X ne peut pas le déterminer correctement en raison d'un matériel défectueux / ancien.

J'ai récemment commencé à utiliser un ordinateur portable avec un écran 4K de 15,6 "; j'ai configuré X pour définir correctement les dimensions physiques de l'écran (§ Moniteur | DisplaySize ww hh ), et j'utilise Xft.dpi pour redimensionnez l'interface utilisateur à mon goût (~ 288 X DPI / PPI natif, 144 Xft.dpi ).

Il convient de noter que la configuration xorg.conf / DisplaySize X et xrandr de --dpi contrôlent la même chose;

* note: Comment se fait-il que Xft (X FreeType) finisse par contrôler le DPI (et via la configuration Xresources, pour démarrer)? À quel point est-ce "standard"? Et fontconfig?

Les clients qui ne respectent pas Xft.dpi ne peuvent pas être contrôlés; la seule façon de les amener à rendre _la même_ que les applications qui _do_ respectent Xft.dpi est de maintenir l'hypothèse DPI (généralement; 96 dpi; alors gardez Xft.dpi à 96). Ensuite, on peut utiliser le DisplaySize / DPI de X pour appliquer la mise à l'échelle DPI. Cela peut cependant être interrompu dans les configurations multi-écrans / moniteurs, c'est donc une grande mise en garde et devrait vraiment être correctement corrigé.

À mon humble avis, la bonne chose à faire est de respecter le paramètre xrandr . Le facteur le plus important est qu'il peut être défini par affichage ( Xft.dpi ne peut pas, donc nous aurions toujours un affichage cassé). Les utilisateurs peuvent également le modifier, il peut donc également s'agir de la configuration du client.

IMHO la bonne chose à faire est de respecter le paramètre xrandr. Le facteur le plus important est qu'il peut être défini par affichage (Xft.dpi ne le peut pas, nous aurions donc toujours un affichage cassé). Les utilisateurs peuvent également le modifier, il peut donc également s'agir de la configuration du client.

Xft.dpi peut également être défini par AFFICHAGE X11, par exemple en utilisant echo Xft.dpi: 192 | DISPLAY=:0 xrdb -merge .

Notez qu'un AFFICHAGE X11 n'est pas le même qu'une sortie RandR, et la plupart des configurations utilisent plusieurs sorties RandR sur le même AFFICHAGE X11 ces jours-ci. X11 ne prend _pas_ en charge différentes valeurs de dpi sur différentes sorties RandR.

Je recommande toujours fortement d'utiliser Xft.dpi en premier et de revenir aux valeurs RandR, le cas échéant.

J'ai découvert il y a quelques semaines que xrandr --help montre que l'option --dpi prend un <dpi>/<output> ; Je n'ai pas eu le temps de voir ce qu'il fait réellement, mais cela implique un paramètre DPI par sortie. Il n'y a rien dans la page de manuel à ce sujet.

Voir https://sources.debian.net/src/x11-xserver-utils/7.7%2B7/xrandr/xrandr.c/#L3514 pour la source. AFAICT, l'option recherchera le DPI de la sortie spécifiée (en fonction de sa hauteur physique) et le définira pour tout l'AFFICHAGE X11.

Ce n'est _pas_ un paramètre par sortie.

@stapelberg Désolé, "affichage" était un mauvais choix de mot pour moi. Je parlais d'un affichage physique (pas d'affichages Xorg), c'est-à-dire d'une sortie réelle. xrandr peut définir cette sortie par sortie, ce que Xft.dpi ne peut pas:

xrandr --output eDP1 --dpi 160

D'accord. Définir le DPI par sortie et s'appuyer sur des applications pour interroger ce paramètre implique:

• les applications doivent savoir sur quelle (s) sortie (s!) elles sont affichées et choisir le bon DPI en conséquence
• les applications devraient réinitialiser l'intégralité de leur rendu / boîte à outils /… lorsqu'elles sont déplacées d'une sortie à l'autre (ne s'applique pas à dunst)

Compte tenu de la nature particulière de Dunst (en utilisant des fenêtres de superposition non mobiles), je peux voir à quel point la valeur DPI par sortie semble être une bonne astuce. Je ne pense toujours pas que ce soit une solution propre, et étant donné le mépris abondant des paramètres DPI par les applications et les boîtes à outils populaires (qui utilisent tous simplement Xft.dpi à la place), il est probable que très peu d'utilisateurs remarqueront que cette fonctionnalité existe.

Cela étant dit, je me fiche à la fin de ce qui est implémenté - je veux juste que vous compreniez les compromis que vous faites en vous écartant de la norme de facto d'utilisation de Xft.dpi.

Xft.dpi est le standard, mais il est en fait cassé; il suppose que toutes les sorties ont le même DPI.

Comme vous l'avez dit, Dunst est dans une situation très particulière (fenêtres non mobiles). Mais il a aussi une autre nature particulière: il est généralement utilisé par des personnes qui savent comment RTFM (par rapport aux utilisateurs de gnome, par exemple), donc en documentant proprement la valeur DPI utilisée par dunst, cela devrait fonctionner correctement pour tous les utilisateurs intéressés.

En outre, la seule façon de rompre avec la norme de facto cassée est de commencer à utiliser l'autre qui fait réellement les bonnes hypothèses! 😄

Cela étant dit, je me fiche à la fin de ce qui est mis en œuvre

Je m'en soucie vraiment, car Xft.dpi signifie des notifications interrompues lorsque j'utilise un moniteur externe (ou vice versa).

Xrandr DPI est également par DISPLAY, pas par sortie (X lui-même ne prend en charge qu'une seule valeur DPI; Xrandr ne va pas résoudre ce problème). L'indicateur associé à un affichage en fait simplement celui utilisé pour les calculs plutôt qu'un autre affichage ou un DPI calculé d'une autre manière. Vous avez besoin de Wayland pour les paramètres DPI par sortie. Le placard que vous pouvez obtenir maintenant est de standardiser le DPI le plus bas sur vos écrans et d'utiliser Xrandr pour zoomer / agrandir les moniteurs DPI plus élevés.

Un effort a été fait pour résoudre ce problème dans la branche fixdpi . Quelqu'un avec un moniteur à résolution élevée peut-il tester ces modifications avant de les fusionner? Tout commentaire est apprécié.

Dunst devrait donner la priorité à la ressource Xft.dpi X, après quoi il y a un retour à un calcul naïf qui devrait gérer correctement plusieurs moniteurs avec des dpi différents.

Dernière écurie:

Branch fixdpi (avec Xft.dpi: 160 ):

Je vais devoir réajuster ma police, ma taille et tout (c'est trop gros et trop gras maintenant), mais il semble que cela fonctionne.

MISE À JOUR : On dirait que le calcul naïf ne fonctionne pas (c'est 15 ", @ 2880x1800).

Branch fixdpi (sans Xft.dpi ):

Bizarre, assurez-vous d'avoir compilé avec Xrandr activé (il devrait être activé par défaut si vous n'avez apporté aucune modification à config.mk)

Quelle est la sortie de xrandr ?

J'ai installé en utilisant ceci:

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)

J'ai poussé un commit avec une sortie de débogage (je devrais vraiment ajouter une journalisation appropriée parfois).
Que produit dunst après l'affichage d'une notification?

Désolé, en regardant la sortie de débogage, je regarde de plus près ma configuration, il s'avère que je définissais Xft.dpi: 106 sur ce dernier test (je supprimerais le remplacement 160 j'ai utilisé pour mon ordinateur portable , mais cela a laissé la valeur par défaut derrière).

Tester correctement à nouveau, la détection fonctionne bien:

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

Désolé pour la confusion.

J'admets cependant que cette police semble plus audacieuse et plus grande que prévu. S'agit-il simplement d'une mise à l'échelle ou la taille de la police elle-même est-elle augmentée?

J'admets cependant que cette police semble plus audacieuse et plus grande que prévu. S'agit-il simplement d'une mise à l'échelle ou la taille de la police elle-même est-elle augmentée?

Je suppose que la taille de la police est augmentée, mais je ne peux pas être sûr car tout ce que nous faisons en interne est de transmettre la valeur dpi au Caire et il gère la configuration et le rendu de la police.

Résultat du calcul: 220.869565

On dirait que le calcul du dpi pense que votre dpi est de 220, ce qui contredit le 160 que vous aviez défini comme valeur de dpi plus tard, c'est peut-être pourquoi la police semble plus grande que d'habitude.

Je suppose que la taille de la police est augmentée, mais je ne peux pas être sûr car tout ce que nous faisons en interne est de transmettre la valeur dpi au Caire et il gère la configuration et le rendu de la police.

TBH, le résultat est gras et gras. Une inspection plus approfondie me fait penser que la police est plus développée qu'elle ne le devrait:

Par exemple, voici la capture d'écran à 106 dpi, mise à l'échelle manuellement à 150% avec GIMP (voici à quoi devrait ressembler la mise à l'échelle à 160 dpi):

Voici une capture d'écran prise avec Xft.dpi: 160 :

Notez que la police est en fait plus grande que prévu.

On dirait que le calcul du dpi pense que votre dpi est de 220, ce qui contredit le 160 que vous aviez défini comme valeur de dpi plus tard, c'est peut-être pourquoi la police semble plus grande que d'habitude.

Oh, l'écran est physiquement de 220 dpi (donc cela fonctionne bien). Je l'ai réglé sur 160 dpi car c'est la mise à l'échelle que je préfère (mais c'est totalement personnel). À 220 dpi, tout me semble trop gros (et l'augmentation de la densité de pixels me permet de lire du texte plus petit, etc.).

Pour être plus clair là-dessus: le calcul était bon; 160 dpi est un ajustement personnel que je fais et ne reflète pas le dpi réel de l'écran.

Enfin, bravo pour la détection du dpi par écran, ce n'est (malheureusement) pas quelque chose de très courant.

J'ai enfin eu le temps de travailler à nouveau après 2 semaines d'inactivité.

TBH, le résultat est gras et gras. Une inspection plus approfondie me fait penser que la police est plus développée qu'elle ne le devrait

C'est peut-être à cause des décimales, j'ai fait le calcul arrondir le résultat, ce qui devrait améliorer, voire résoudre complètement le problème.

De plus, j'ai trouvé que l'utilisation d'un dpi différent par écran peut provoquer des incohérences visuelles si vous avez plusieurs écrans avec des dpis légèrement différents.J'ai donc déplacé la fonction de détection de dpi par écran comme option dans la fonction expérimentale dans le dunstrc jusqu'à ce que nous

Les changements ont été fusionnés pour maîtriser cela devrait maintenant être corrigé.

Dunst devrait donner la priorité à la ressource Xft.dpi X, après quoi il y a un retour à un calcul naïf qui devrait gérer correctement plusieurs moniteurs avec des dpi différents.

@tsipinakis , pouvez-vous clarifier cette déclaration, s'il vous plaît? Comment Dunst est-il capable de prendre en charge un DPI par moniteur (sortie X11)? Vous avez vous-même noté que X11 ne prend pas en charge cela, et qu'un tel support est un objectif majeur du projet Wayland. Si je comprends bien, la prise en charge de cela sous X11 obligerait l'utilisateur à configurer Dunst directement pour comprendre quelles sorties ont quels DPI; X11 n'a aucune spécification pour stocker ou communiquer ces données / configuration.

https://github.com/dunst-project/dunst/blob/master/dunstrc#L189 - semble indiquer que cette fonctionnalité ne fonctionne que lorsque l'on ne spécifie pas une Xft.dpi via Xresources. Mais Xft.dpi n'obtient-il pas une valeur "par défaut" dans ce cas? De, peut-être, 96 , même?
J'ai le sentiment que ce support expérimental a un cas d'utilisation réel très limité, en raison des hypothèses qu'il doit faire sur la façon d'interpréter la sortie par sortie DisplaySize X11 DPI (ils sont réciproques; c'est la même chose, essentiellement). Je ne pense pas qu'un client X11 devrait interpréter ces valeurs du tout.

J'aimerais tester cette fonctionnalité (principalement, l'objectif principal de faire respecter par Dunstrc Xft.dpi , mais en second lieu, comprendre ce mécanisme DPI de sortie par X11), si vous pouvez me donner quelques conseils.

Tout d'abord, en raison de certaines incohérences visuelles qui ont été modifiées d'une fonction de secours à une fonctionnalité expérimentale opt-in, voir l'exemple dunstrc .

La section dpi par moniteur fait référence à la sortie par randr. Nous utilisons les dimensions physiques de l'écran telles que rapportées par randr pour calculer approximativement le dpi des écrans. Voir ici pour le code (Ne me demandez pas comment fonctionne ce calcul, c'est toujours magique pour moi :)).

C'est l'une des raisons pour lesquelles nous avons changé l'extension de moniteur X11 que nous utilisons de xinerama à randr.

La documentation est mon prochain grand objectif avant de publier la prochaine version, elle devrait donc également aider à clarifier le fonctionnement de certaines parties de dunst.

Pour répondre à votre modification, cela a été ajouté à titre d'expérience car il a été mentionné plus tôt dans ce fil de discussion que ce serait une fonctionnalité bienvenue et en raison de la façon dont nous avons implémenté la gestion du dpi, il s'agissait d'un changement très simple . On ne sait toujours pas si cela fonctionnera dans un scénario réel, je ne l'ai même pas testé moi-même puisque tous mes moniteurs ont fondamentalement le même dpi, c'est pourquoi c'est expérimental.

D'après mes tests, Xft.dpi ne renvoie pas de valeur si elle n'est pas définie (l'appel de fonction pour la récupérer renvoie 0). Dans ce cas, soit nous utilisons le calcul mentionné ci-dessus si per_monitor_dpi est vrai, soit nous

J'ai testé la fonctionnalité de base ici - cela fonctionne bien. Je testerai le bit expérimental une fois que j'arriverai à un deuxième moniteur cette semaine.

Question: dunst fonctionne comme un service utilisateur systemd sur ma configuration (Debian Sid) - J'ai construit et installé dunst sur ~/.local ; J'essaie de définir DefaultEnvironment="PATH=/home/nmschulte/.local/bin:$PATH dans ~/.config/systemd/user.conf , et la configuration semble être efficace car je dois maintenant démarrer manuellement le démon Dunst. Mais, comment puis-je faire fonctionner DefaultEnvironment , de sorte qu'il ne modifie que l'environnement de l'utilisateur sélectionné (comme le dit la documentation ~/.config/systemd/user.conf ; voir l'élément 1 https://wiki.archlinux.org /index.php/Systemd/User#Environment_variables), afin qu'il corresponde au PATH de l'utilisateur défini dans ~/.profile (ou ~/.bash_profile / ~/.bashrc si vous vous limitez aux shells Bash )? L'ArchWiki semble indiquer que systemctl --user set-environment est pour tous les utilisateurs, contrairement au fichier user.conf .

De plus, Dunst prend-il en charge un signal de «configuration de rechargement», comme par exemple i3? i3 utilise ce signal pour ré-inspecter la valeur de Xft.dpi / Xresources dans son ensemble, et cela semble également judicieux pour Dunst. Cependant, il semble que le cycle de vie du démon soit magique à certains égards (à cause du d-bus? Qu'est-ce qui gère réellement le cycle de vie du démon?), Et simplement tuer le démon fonctionne dans les cas où il revient immédiatement; il récupère les nouvelles valeurs au démarrage.

@tsipinakis , cet ensemble de modifications n'augmente pas correctement l'échelle de l'icône de la notification.

Je ne comprends pas ce que vous essayez d'accomplir dans votre première question, pouvez-vous donner quelques détails supplémentaires? Pourquoi essayez-vous de définir le CHEMIN?

De plus, Dunst prend-il en charge un signal de «configuration de rechargement»

Pas pour le moment, killall dunst est aussi proche que possible. N'hésitez pas à déposer une demande de fonctionnalité pour cela.

cet ensemble de modifications n'augmente pas correctement l'échelle de l'icône de la notification.

Si vous utilisez le paramètre max_icon_size , il n'est pas mis à l'échelle exprès car la valeur est en pixels et il devrait être défini sur une valeur de pixel raisonnable pour le ppp du moniteur que vous utilisez.

Concernant ma première question: j'essaie d'obtenir l'instance Dunst qui s'exécute dans la configuration de mon système (une configuration prête à l'emploi de Debian Sid) pour utiliser la version que j'ai construite avec PREFIX=~/.local . J'ai défini ce répertoire sur mon PATH via ~/.profile . J'essayais de configurer systemd pour ce faire, pensant que systemd était ce qui gérait l'instance Dunst (comme htop montré dunst appartenant à systemd --user ). Cela n'a pas fonctionné, et à son tour semble avoir complètement cassé l'instance de Dunst.

En fait, Dunst est géré par dbus, qui est géré par systemd. Après grep ing, j'ai trouvé que le fichier /usr/share/dbus-1/service/org/knopwob.dunst.service avait Exec=/usr/bin/dunst , ce qui est la magie que je recherchais.

Re: max_icon_size - compris. Cela a une valeur par défaut de 32 , actuellement; une amélioration minime peut être la valeur par défaut de 0 . Sinon, un facteur ratio / échelle semble approprié, peut-être avec une base configurable (ou intelligente, en supposant que cela soit justifié). Ou, permutez l'intelligence (ou la variable «primaire»), ou permettez à _que_ d'être une préférence aussi. Je pense que le bit expérimental s'appliquerait directement (lire: de la même manière qu'il le fait pour la taille de la police), si cela vous préoccupe.

~ Je ne peux pas comprendre ce que j'ai cassé; il semble que D-Bus ne lance plus Dunst après avoir compilé et installé Dunst avec PREFIX=~/.local , et avoir défini dans ~/.profile PATH=/home/nmschulte/.local/bin:$PATH . J'ai depuis supprimé mon ~/.config/dunst/dunstrc , pensant que cela pourrait causer le crash de Dunst, puis le binaire ~/.local/bin/dunst réel, pensant qu'il pourrait planter ou interférer avec le D-Bus / SystemD exécution en quelque sorte. Mais maintenant je suis coincé et # aptitude reinstall dunst n'a pas aidé. J'apprécierais de l'aide, mais je ne veux pas dérailler le sujet. ~
~ J'ai déplacé ~/.local/share/dbus-1/ vers ~/.local/share/dbus-1.bak/ , et il semble que maintenant Dunst fonctionne à nouveau comme il l'a fait. Je me demande ce qui ne va pas ici; peut-être que dbus ne chargera pas les services parce qu'ils ont le même nom ou quelque chose? ~
D'accord, j'ai découvert le problème; le fichier de service D-Bus intégré appelle un service systemd, dunst.service , auquel il n'était pas habitué. Il semble que je n'ai pas besoin de cette configuration, mais je ne sais pas pourquoi elle a été introduite.
dbus-daemon[1056]: Activation via systemd failed for unit 'dunst.service': Unit dunst.service not found.

D'accord, j'ai découvert le problème; le fichier de service D-Bus intégré appelle un service systemd, dunst.service, auquel il n'était pas habitué. Il semble que je n'ai pas besoin de cette configuration, mais je ne sais pas pourquoi elle a été introduite.

Je suppose que vous exécutez dbus sous systemd donc il a commencé avec le drapeau --systemd-activation , cela a été ajouté dans # 295 mais apparemment j'ai oublié de tenir compte des cas où dbus est géré par systemd mais le fichier de service dunst n'est pas installé.

Notez que les services DBus de session ne sont pas vraiment pris en charge par systemd de toute façon. Voir systemd / systemd # 892.

Bien, nous avons suffisamment détourné ce problème pour déplacer la discussion vers le # 314.