Dunst: Vuelva a leer DPI antes de mostrar una nueva notificación

Supongo que a veces está usando un monitor externo y otras la pantalla de la computadora portátil y es por eso que los ppp cambian.

¿Has probado la configuración per_monitor_dpi en experimental? Fue diseñado con un caso de uso similar en mente.

Como veo en la descripción, esta opción calcula DPI directamente desde la geometría del monitor de xrandr, sin pasar por fontconfig / xrdb / xrandr --dpi . Entonces eso no es exactamente lo que necesito.
Estoy bien con un solo DPI para todo el framebuffer, ya que así es como funciona X de manera efectiva. Solo me gustaría volver a verificar ese valor.

Hubo una gran discusión sobre el manejo de DPI en el n. ° 240, a partir de un comentario en ese hilo:

Vale la pena señalar que la configuración xorg.conf / DisplaySize X y xrandr's --dpi controlan lo mismo; cambiar el DPI actualiza el tamaño de pantalla determinado, y vv.

Entonces, teóricamente, debería verse afectado por xrandr --dpi .

Lo acabo de probar. No, ignora xrandr --dpi y usa dpi de visualización calculados.

No estoy seguro de que xrandr --dpi y xorg.conf/DisplaySize gobiernen lo mismo, ya que el parámetro DisplaySize es del contexto de SectionMonitor, y xrandr --dpi afecta a toda la pantalla X.

Parece que tienes razón, lo investigaré mañana.

La mejor manera de implementar esto probablemente sería volver a consultar Xft.dpi al recibir un evento RRScreenChangeNotify .

Al revés:

• Sobrecarga insignificante ya que no se espera que ese evento se reciba con frecuencia (a menos que a alguien realmente le guste cambiar la configuración de su pantalla)

Abajo:

• No funcionará para usuarios de Xinerama. - La implementación actual de xinerama en Dunst no admite el cambio de diseño de pantalla de todos modos, por lo que es de esperar que no afecte a nadie.

Por cierto, ¿Dunst ignora la configuración de DPI de fontconfig? Puede ser una buena idea confiar en fontconfig para obtener DPI, porque simplificaría y unificaría las cosas. Muchas aplicaciones obtienen efectivamente DPI de fontconfig, y fontconfig en sí mismo recurre a xrdb y luego [supuestamente] a xrandr en caso de que su propio DPI no esté configurado.

Por cierto, ¿no ignora la configuración de DPI de fontconfig?

Actualmente sí, no he examinado fontconfig en absoluto.
La lógica de dpi es básicamente

Si per_monitor_dpi está habilitado, consulte xrandr y calcule según las dimensiones de la pantalla
de lo contrario, si Xft.dpi está configurado, use eso
de lo contrario, suponga 96.

Bueno, de una forma u otra, fontconfig ya se usa en la representación de texto en dunst de todos modos, por lo que sería lógico usarlo también para el manejo de DPI cuando per_monitor_dpi = false . Solo actualice cuando sea necesario.

Implementé esto en la rama feature/382-reload-dpi , funciona bien de acuerdo con mis pruebas. ¿Puedes probarlo también por tu cuenta y asegurarte de que funciona según lo previsto?

Espero que también se necesite una llamada de empate allí, pero si funciona bien sin ella, aún mejor.

Bueno, de una forma u otra, fontconfig ya se usa en la representación de texto en dunst de todos modos

Eso es por pango, dunst internamente no usa fontconfig directamente.

En mi caso no funciona.

DPI=96
echo "Xft.dpi: $DPI" |  xrdb -merge ; xrandr --dpi $DPI
notify-send -a ht test1 test1
# remove notifications
DPI=128
echo "Xft.dpi: $DPI" |  xrdb -merge ; xrandr --dpi $DPI
notify-send -a ht test2 test2

También intenté desconectar y volver a conectar el monitor externo para que mi script rerandr3 aplique básicamente los mismos valores que los anteriores automáticamente. Dunst no obtiene nuevos DPI.

Estoy usando Intel GPU con controlador de configuración de modo y Openbox + Compton como WM.

Vaya, aparentemente me olvidé de publicar una actualización sobre esto, pensé que simplemente podría agregar el código para volver a leer el dpi y la funcionalidad de render existente se haría cargo de allí, pero este no es el caso, pango_cairo_context_set_resolution también se debe llamar para actualizar el dpi, lo que desafortunadamente no se puede hacer sin tocar x.c que actualmente se encuentra bajo una refactorización importante en una rama diferente y hacerlo causaría todo tipo de conflictos.

Otro problema más que está en espera esperando la refactorización del dibujo.

@ Vladimir-csp ¿Podría probar el PR # 608? Me encantaría verlo arreglado.

Desafortunadamente, no veo ninguna diferencia. La siguiente notificación después de cambiar DPI aparece con un tamaño consistente con las condiciones de inicio de Dunst.

Mmm. Eso no es cool.

Cambiarlo a través de echo "Xft.dpi: $DPI" | xrdb -merge todavía no es posible (y no está previsto que se modifique). ¿Configura el dpi con xrandr --dpi <DPI> también?

¿Te estás saliendo de la rama correcta?

git clone https://github.com/bebehei/dunst.git dunst-bebehei
cd dunst-bebehei
git checkout xrandr-dpi
make -j
pkill dunst && ./dunst

¿Cuál es su configuración de per_monitor_dpi en la sección experimental ?

Utilizo un script que establece DPI a través de xrandr --dpi y también lo sincroniza con xrdb y fontconfig, por lo que se cubren todas las fuentes.

$ git status
On branch xrandr-dpi
Your branch is up to date with 'origin/xrandr-dpi'.

Construí un paquete a partir de él.

per_monitor_dpi = false

Que hace

    xdpyinfo | grep -B1 resolution

¿Informar después de cambiar el DPI?

informa valores correctos

Entonces, ¿informa el DPI correcto, coincidiendo con el DPI establecido por xrandr --dpi ?

Si. Estoy cambiando entre 96 y 120, los cambios se aplican correctamente en las tres formas: xrandr, xrdb, fontconfig

Ok, agregué otra confirmación de depuración. ¿Podrías reconstruirlo y empezar a dunst con dunst -verbosity info ? Y dime, ¿qué dice "Dibujo con ppp de pantalla"?

Se lanzó dunst -verbosity info mientras que el DPI se estableció en 96, se cambió el DPI a 120

$ xrdb -q | grep dpi
Xft.dpi:    120
$ xdpyinfo | grep -B1 resolution
  dimensions:    1920x1200 pixels (406x254 millimeters)
  resolution:    120x120 dots per inch
$ grep -ri dpi ~/.config/fontconfig/
~/.config/fontconfig/conf.d/90-xrandr-sync-dpi.conf:    <edit name="dpi" mode="assign"><double>120</double></edit>

notify-send test test , Dunst informó:

INFO: Drawing with screen DPI: 96.000000
INFO: Drawing with screen DPI: 96.000000

Esto no funciona porque la impementación en # 608 favorece a Xft sobre el xrandr --dpi y, además, screen_dpi_get_from_xft solo lee de xft en la primera llamada y luego devuelve el valor en caché. Por lo tanto, esto solo funcionará si Xft.dpi es correcto cuando dunst recibe la primera notificación.

¿Es posible retrasar la lectura hasta que se muestre una nueva notificación?

Oh sí, @tsipinakis tiene razón. Lo siento, no pude comunicar mi propio código: see_no_evil:

¿Es posible retrasar la lectura hasta que se muestre una nueva notificación?

¿Cuándo debemos consultarlo? No hay semántica de eventos para escuchar los valores cambiados. Es una gran sobrecarga consultar la base de datos por notificación.

La única forma es invalidar el valor de Xft:

echo "Xft.dpi: 0" | xrdb -merge
dunst &
echo "Xft.dpi: <olddpi>" | xrdb -merge

Entonces dunst usará el valor dado por xrandr --dpi . Con xrandr, tenemos un evento para cambios de pantalla y lo escuchamos.

La invalidación del valor xrdb afectará a algunos programas que, por alguna razón, dependen exclusivamente de él. He experimentado extensamente con la configuración de DPI y llegué a la conclusión de que la mejor manera de llegar a todas las aplicaciones es bombardear cada fuente del valor: xrandr, xrdb, fontconfig. Tengo un gancho en autorandr que hace precisamente eso.

Para evitar cualquier carrera con la configuración o la sobrecarga de consultas constantes, confíe en el evento xrandr, pero posponga la lectura real hasta la próxima notificación.

@ Vladimir-csp # 608 se ha actualizado para invalidar el valor de ppp en caché cuando se recibe una actualización de pantalla como sugirió. ¿Puedes probarlo y ver si te funciona?

No veo ningún cambio en el comportamiento, sigo usando dpi de inicio y no reacciono a los cambios.

Finalmente me enteré. Para resumir: fue una odisea.

@ Vladimir-csp ¿Podrías probar esto de nuevo? Debería funcionar a las mil maravillas.

¿Cuándo debemos consultarlo? No hay semántica de eventos para escuchar los valores cambiados. Es una gran sobrecarga consultar la base de datos por notificación.

Tengo que dar un paso atrás en esto. De hecho, hay un evento que puedes escuchar. Y es muy fácil de escuchar. Lo único: xlib no lo hace: imp:

en la confirmación 2d37902. Ningún cambio.

• Lanzado dunst con ppp 120
• Se cambió el ppp a 96 en xrandr, xrdb, fontconfig
• Dunst todavía muestra notificaciones posteriores en 120 ppp

echo "Xft.dpi: 96" | xrdb -merge
./dunst -config dunstrc &
notify-send -u critical Test 1234
echo "Xft.dpi: 120" | xrdb -merge

@ Vladimir-csp Los comandos anteriores me funcionan para cambiar dunst a 120 ppp con 2d37902, ¿puedes intentarlo de nuevo con el dunstrc predeterminado?

Funciona con la configuración predeterminada, pero no funciona con la mía.
Aquí está la diferencia:

$ diff /usr/share/dunst/dunstrc .config/dunst/dunstrc
18c18
<     follow = mouse
---
>     follow = none
32c32
<     geometry = "300x5-30+20"
---
>     geometry = "512x3+37-0"
44c44
<     transparency = 0
---
>     transparency = 14
57c57
<     padding = 8
---
>     padding = 4
60c60
<     horizontal_padding = 8
---
>     horizontal_padding = 4
64c64
<     frame_width = 3
---
>     frame_width = 1
84c84
<     idle_threshold = 120
---
>     idle_threshold = 60
88c88
<     font = Monospace 8
---
>     font = Monospace 12
128c128
<     format = "<b>%s</b>\n%b"
---
>     format = "%a:\n<b>%s</b>\n%b %p"
162c162
<     icon_position = off
---
>     icon_position = left
165c165
<     max_icon_size = 32
---
>     max_icon_size = 64
168c168
<     icon_path = /usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/
---
>     #icon_path = /usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/
177c177
<     history_length = 20
---
>     history_length = 50
185c185
<     browser = /usr/bin/firefox -new-tab
---
>     browser = xdg-open
260c260
<     close = ctrl+space
---
>     close = mod4+BackSpace
263c263
<     close_all = ctrl+shift+space
---
>     close_all = mod4+shift+BackSpace
269c269
<     history = ctrl+grave
---
>     history = mod4+ctrl+BackSpace
272c272
<     context = ctrl+shift+period
---
>     context = mod4+Insert
277,278c277,279
<     background = "#222222"
<     foreground = "#888888"
---
>     background = "#161616"
>     foreground = "#aaaaaa"
>     frame_color = "#aaaaaa"
284,285c285,287
<     background = "#285577"
<     foreground = "#ffffff"
---
>     background = "#323232"
>     foreground = "#dddddd"
>     frame_color = "#dddddd"
291c293
<     background = "#900000"
---
>     background = "#ff1616"
293c295
<     frame_color = "#ff0000"
---
>     frame_color = "#ffffff"

Los mensajes de depuración con la configuración predeterminada contienen Checking for active screen changes :

DEBUG: XEvent: processing 'Expose'
DEBUG: XEvent: Ignoring '65'
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: Ignoring '22'

pero con mi configuración están ausentes:

DEBUG: XEvent: Ignoring '22'
DEBUG: XEvent: processing 'RRScreenChangeNotify'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '17'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '17'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '21'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '17'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '17'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '18'
DEBUG: XEvent: Ignoring '17'
DEBUG: XEvent: processing 'CreateNotify'
DEBUG: XEvent: Ignoring '22'

Tiene que haber el mensaje XEvent: processing PropertyNotify for Resource manager en su registro de depuración de dunst.

Vuelva a compilar con make clean y active el echo "Xft.dpi: 120" | xrdb -merge manualmente. El evento PropertyNotify tiene que llegar a alguna parte.

Lo único que podría estar mal sería la verificación del átomo:

if (ev.xproperty.atom == XA_RESOURCE_MANAGER) {

Pero esta vez, funciona perfectamente en mi máquina. Revisé todo.

make clean ; make , lanzó un binario nuevo desde el directorio de compilación con la opción -config . La misma cosa. XEvent: processing PropertyNotify for Resource manager aparece solo con la configuración predeterminada.
Aquí está mi configuración (sin comentarios):

[global]
    monitor = 0
    follow = none
    geometry = "512x3+37-0"
    indicate_hidden = yes
    shrink = no
    transparency = 14
    notification_height = 0
    separator_height = 2
    padding = 4
    horizontal_padding = 4
    frame_width = 1
    frame_color = "#aaaaaa"
    separator_color = frame
    sort = yes
    idle_threshold = 60
    font = Monospace 12
    line_height = 0
    markup = full
    format = "%a:\n<b>%s</b>\n%b %p"
    alignment = left
    show_age_threshold = 60
    word_wrap = yes
    ellipsize = middle
    ignore_newline = no
    stack_duplicates = true
    hide_duplicate_count = false
    show_indicators = yes
    icon_position = left
    max_icon_size = 64
    sticky_history = yes
    history_length = 50
    dmenu = /usr/bin/dmenu -p dunst:
    browser = xdg-open
    always_run_script = true
    title = Dunst
    class = Dunst
    startup_notification = false
    verbosity = debug
    corner_radius = 0
    force_xinerama = false
    mouse_left_click = close_current
    mouse_middle_click = do_action
    mouse_right_click = close_all
[experimental]
    per_monitor_dpi = false
[shortcuts]
    close = mod4+BackSpace
    close_all = mod4+shift+BackSpace
    history = mod4+ctrl+BackSpace
    context = mod4+Insert
[urgency_low]
    background = "#161616"
    foreground = "#aaaaaa"
    frame_color = "#aaaaaa"
    timeout = 10
[urgency_normal]
    background = "#323232"
    foreground = "#dddddd"
    frame_color = "#dddddd"
    timeout = 10
[urgency_critical]
    background = "#ff1616"
    foreground = "#ffffff"
    frame_color = "#ffffff"
    timeout = 0

Reproducido con el dunstrc proporcionado.

@bebehei Encontré el error;)

El problema es con

follow = none

Con cualquier otro modo de seguimiento, nos suscribimos a PropertyChangeMask que aparentemente incluye eventos del administrador de recursos, pero con follow = none no los recibimos, por lo que no sabemos cuándo actualizar.

@bebehei parece inactivo / ocupado y no ha respondido a mis pings o correo electrónico, me haré cargo hasta la versión 1.4, que no me enorgullece cuánto se ha retrasado.

@ Vladimir-csp He enviado una solución para el error mencionado anteriormente. ¿Puedes confirmar que esto funciona para ti ahora?

¡Funciona!

¡Impresionante! Combinado, se incluirá en la versión 1.4, que será la próxima semana más o menos.