Dunst: Перечитайте DPI перед отображением нового уведомления

Я предполагаю, что вы иногда используете внешний монитор, а другие - экран ноутбука, и поэтому dpi меняется.

Вы пробовали установить per_monitor_dpi в экспериментальном режиме? Он был разработан с учетом аналогичного сценария использования.

Как я вижу из описания, эта опция вычисляет DPI непосредственно из геометрии монитора xrandr, минуя fontconfig / xrdb / xrandr --dpi . Так что это не совсем то, что мне нужно.
Меня устраивает единый DPI для всего фреймбуфера, поскольку именно так работает X. Я просто хотел бы, чтобы Данст еще раз проверил это значение.

В # 240 было довольно большое обсуждение обработки DPI из комментария в этой ветке:

Стоит отметить, что конфигурация X xorg.conf / DisplaySize и xrandr's --dpi управляют одним и тем же; изменение DPI обновляет определенный размер дисплея, а vv.

Так что теоретически на это должно влиять xrandr --dpi .

Я только что это проверил. Нет, он игнорирует xrandr --dpi и использует вычисленное отображение dpi.

Я не уверен, что xrandr --dpi и xorg.conf/DisplaySize управляют одним и тем же, поскольку параметр DisplaySize взят из контекста SectionMonitor, а xrandr --dpi влияет на весь экран X.

Похоже, ты прав, я займусь этим завтра.

Лучшим способом реализовать это, вероятно, будет повторный запрос Xft.dpi при получении события RRScreenChangeNotify .

Достоинства:

• Незначительные накладные расходы, поскольку ожидается, что это событие не будет часто приниматься (если кому-то действительно нравится изменять конфигурацию экрана)

Обратная сторона:

• Не будет работать для пользователей Xinerama. - Текущая реализация xinerama в dunst в любом случае не поддерживает изменение макетов экрана, поэтому, надеюсь, никого не затронет.

Кстати, dunst игнорирует настройку DPI fontconfig? Может быть хорошей идеей просто положиться на fontconfig для получения DPI, потому что это упростит и унифицирует вещи. Многие приложения фактически получают DPI из формы fontconfig, а сам fontconfig возвращается к xrdb, а затем [предположительно] к xrandr в случае, если его собственный DPI не установлен.

Кстати, dunst игнорирует настройку DPI fontconfig

В настоящее время да, вообще не заглядывал в fontconfig.
Логика dpi в основном

Если per_monitor_dpi включен, запросите xrandr и рассчитайте на основе размеров экрана
иначе, если установлен Xft.dpi используйте это
иначе предположим 96.

Ну, так или иначе fontconfig уже используется при рендеринге текста в dunst, поэтому было бы логично использовать его и для обработки DPI, когда per_monitor_dpi = false . Просто обновите при необходимости.

Я реализовал это в ветке feature/382-reload-dpi , согласно моим тестам, все работает нормально. Можете ли вы проверить это на своей стороне и убедиться, что он работает так, как задумано?

Я ожидаю, что вызов отрисовки также понадобится там, но если он отлично работает без него, даже лучше.

Ну так или иначе fontconfig уже используется при рендеринге текста в dunst.

Это из-за pango, dunst внутренне не использует fontconfig напрямую.

В моем случае это не работает.

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

Также попытался отключить и снова подключить внешний монитор для моего сценария rerandr3, чтобы автоматически применить в основном те же значения, что и выше. Данст не получает новый DPI.

Я использую Intel GPU с драйвером настройки режимов и Openbox + Compton в качестве WM.

К сожалению, я забыл опубликовать обновление по этому поводу, я подумал, что могу просто добавить код для перечитывания dpi, и существующая функция рендеринга возьмет на себя оттуда, но это не так, pango_cairo_context_set_resolution также должен быть вызван для обновления dpi, что, к сожалению, невозможно сделать, не коснувшись x.c который в настоящее время подвергается серьезному рефакторингу в другой ветке, и это может вызвать всевозможные конфликты.

Еще одна проблема, которая отложена в ожидании рефакторинга чертежа.

@ Vladimir-csp Не могли бы вы протестировать PR # 608. Я бы хотел, чтобы это было исправлено.

К сожалению, не вижу разницы. Следующее уведомление после изменения DPI появляется с размером, соответствующим условиям запуска dunst.

Ммм. Это не круто.

Изменить его с помощью echo "Xft.dpi: $DPI" | xrdb -merge по-прежнему невозможно (и он не предназначен для изменения). Вы также устанавливаете dpi с помощью xrandr --dpi <DPI> ?

Вы сбегаете с правильной ветки?

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

Какая у вас установка per_monitor_dpi в разделе experimental ?

Я использую сценарий, который устанавливает DPI через xrandr --dpi а также синхронизирует его с xrdb и fontconfig, поэтому охватываются все источники.

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

Я собрал из него пакет.

per_monitor_dpi = false

Что значит

    xdpyinfo | grep -B1 resolution

Сообщить после смены DPI?

он сообщает правильные значения

Итак, он сообщает о правильном DPI, совпадающем с DPI, установленным xrandr --dpi ?

да. Я переключаюсь между 96 и 120, изменения применяются правильно всеми тремя способами: xrandr, xrdb, fontconfig

Хорошо, я добавил еще одну отладочную фиксацию. Не могли бы вы перестроить его и запустить dunst с dunst -verbosity info ? А скажите, что говорит "Рисование с dpi экрана"?

Запустил dunst -verbosity info когда DPI был установлен на 96, переключил DPI на 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 , Данст сообщил:

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

Это не работает, потому что реализация в # 608 отдает предпочтение Xft над значением xrandr --dpi и, кроме того, screen_dpi_get_from_xft только читает из xft при первом вызове, а после этого возвращает кешированное значение. Таким образом, это будет работать только в том случае, если Xft.dpi правильное, когда dunst получит первое уведомление.

Можно ли отложить чтение до появления нового уведомления?

Ах да, @tsipinakis прав. Извините, мне не удалось передать собственный код: see_no_evil:

Можно ли отложить чтение до появления нового уведомления?

Когда мы должны его запросить? Нет никакой семантики событий, на которую можно было бы прислушиваться для изменения значений. Запрашивать БД на каждое уведомление - это огромные накладные расходы.

Единственный способ - либо аннулировать значение Xft:

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

Затем dunst будет использовать значение, указанное в xrandr --dpi . С xrandr у нас есть событие для смены экрана, и мы его слушаем.

Аннулирование значения xrdb повлияет на некоторое программное обеспечение, которое по какой-то причине полагается исключительно на него. Я много экспериментировал с настройкой DPI и пришел к выводу, что лучший способ связаться со всеми приложениями - это взорвать каждый источник значения: xrandr, xrdb, fontconfig. У меня есть крючок в autorandr, который делает именно это.

Чтобы избежать какой-либо гонки с настройками или накладных расходов из-за постоянных запросов, полагайтесь на событие xrandr, но отложите фактическое чтение до следующего уведомления.

@ Vladimir-csp # 608 был обновлен, чтобы сделать недействительным кешированное значение dpi при получении обновления экрана, как вы предложили. Можете ли вы попробовать это и посмотреть, работает ли это для вас?

Я не вижу никаких изменений в поведении, все еще использую загрузочную dpi и не реагирую на изменения.

Я наконец узнал. Короче говоря: это была одиссея.

@ Vladimir-csp Не могли бы вы проверить это еще раз? Это должно работать как шарм.

Когда мы должны его запросить? Нет семантики событий, на которую можно было бы прислушиваться при изменении значений. Запрашивать БД на каждое уведомление - это огромные накладные расходы.

Я должен отступить от этого. На самом деле есть событие, которое вы можете слушать. И слушать его очень легко. Единственное: xlib этого не делает: imp:

при фиксации 2d37902. Без изменений.

• Запущен dunst с dpi 120
• Изменено dpi на 96 в xrandr, xrdb, fontconfig
• Dunst по-прежнему показывает последующие уведомления с разрешением 120 dpi

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

@ Vladimir-csp Приведенные выше команды работают для меня для переключения dunst на 120 dpi с помощью 2d37902, можете ли вы попробовать еще раз с dunstrc по умолчанию?

Он работает с конфигурацией по умолчанию, но не работает с моей.
Вот разница:

$ 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"

Сообщения отладки с конфигурацией по умолчанию содержат 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'

но с моим конфигом их нет:

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'

В журнале отладки dunst должно быть сообщение XEvent: processing PropertyNotify for Resource manager .

Пожалуйста, перекомпилируйте с make clean и запустите echo "Xft.dpi: 120" | xrdb -merge вручную. Событие PropertyNotify должно где-то произойти.

Единственное, что может быть неправильным, это проверка атома:

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

Но на этот раз на моей машине он работает безупречно. Все проверил.

make clean ; make , запустил свежий двоичный файл из каталога сборки с опцией -config . То же самое. XEvent: processing PropertyNotify for Resource manager появляется только с конфигурацией по умолчанию.
Вот мой конфиг (без комментариев):

[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

Воспроизведено с предоставленным dunstrc.

@bebehei Нашел ошибку;)

Проблема с

follow = none

В любом другом режиме следования мы подписываемся на PropertyChangeMask который, по-видимому, включает события диспетчера ресурсов, но с follow = none мы их не получаем, поэтому мы не знаем, когда обновлять.

@bebehei кажется неактивным / занятым и не ответил на мои пинги или электронную почту, я возьму на себя ответственность до выпуска 1.4, и я не горжусь тем, насколько он задерживается.

@ Vladimir-csp Я исправил ошибку, упомянутую выше, можете ли вы подтвердить, что теперь это работает для вас?

Оно работает!

Потрясающий! После слияния он будет включен в выпуск 1.4, который выйдет на следующей неделе или около того.