Можно ли в X11 настроить разный sub-pixel rendering type для разных мониторов?

Скорее, этот вопрос к конкретным тулкитам, т.к. X-сервер давно сам не рендерит текст, а получает его готовой картинкой. А X11 это вообще протокол, и я сильно сомневаюсь, что там такое было хоть когда-то.

Кстати, в тему будет вопрос. А хорошо ли в Wayland сделали, что клиент рисует всё сам? Я думаю так себе. Сколько всего надо реализовать на клиенте, в каждом клиенте (тулките): разное сглаживание, масштабирование, чтение с экрана и прочие штуки для людей с плохим зрением, т.д. Можно ещё долго перечислять. А могло бы быть одни раз - на сервере.

Я недостаточно компетентен чтобы ответить на этот вопрос. Мне кажется, что действительно лучше было бы все реализовать один раз на сервере. С другой стороны, есть подозрение, что Wayland разрабатывался с прицелом на единственный тулкит GTK.

Если у тебя нельзя это изменить через твое DE (допустим, что у тебя просто WM простенький), то можно через xrdb попробовать. Там есть переменная SCREEN_NUM.

~/.Xresources:

#if SCREEN_NUM == 0
Xft.dpi: 192
Xft.autohint: 0
Xft.lcdfilter:  lcddefault
Xft.hintstyle:  hintfull
Xft.hinting: 1
Xft.antialias: 1
Xft.rgba: rgb
#endif

#if SCREEN_NUM == 1
Xft.dpi: 192
Xft.autohint: 0
Xft.lcdfilter:  lcddefault
Xft.hintstyle:  hintfull
Xft.hinting: 1
Xft.antialias: 1
Xft.rgba: rgb
#endif

Параметры на свой вкус. Потом сделать:

$ xrdb ~/.Xresources

И расскажи, что получилось.

UPD: Но есть вероятность, что может не сработать - я сейчас не могу проверить, к сожалению. Дело в том, что это могут быть не те скрины, которые мониторы, а скрины типа :0.0, :0.1 и т .д.

Gtk и qt свои конфиги используют, можно запускать приложения с разным конфигом или напмсать скрипт проверяющий скрин и устанавливающий нужный

Не знаю. У меня GTK+3 (проверял на evince) вполне себе слушается параметра Xft.rgba и меняет рендеринг при различных значениях (rgb, vrgb и т .д.). Я вот только что проверил.

Xrandr делает один скрин, как и Xinerama. И чтобы понять на каком мониторе находится окно, клиенту надо кверить сервер. Ну или слушать Xrandr ивенты и поддерживать в клиенте актуальную копию раскладки мониторов по рутовому окну скрина.

Вобщем Xrandr создаёт больше проблем, чем решает. Надо возвращаться к оригинальном дизайну: несколько скринов, несколько рутовых окон, а окна, пересекающие границу скринов, пусть тулкит делает из кусков, и виндоу менеджеру говорит, с каких сторон куска декорации рисовать не надо, двигает и ресайзит окна при пропаже и появлении скринов.

Во какой я пиздун-собеседник!

Он делает один дисплей, а не скрин, а логически скрины будут обозначены. Вот, например, вывод xrandr двухмониторной конфигурации будет выдавать нечто такое:

Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
...
Screen 1: minimum 8 x 8, current 1200 x 1920, maximum 32767 x 32767
...

Это у тебя конфигурация ручная. Она не позволяет таскать окна между скринами. Потому что у каждого скрина свое рутовое окно. А по умолчанию Xrandr делает один скрин.

В общем, тут надо проверить. Либо оно заработает либо нет

Ресурсы клиент читает при запуске. Ты его запустил с DISPLAY=:0.0, он прочитал одни ресурсы. Но окно клиента перетащить на скрин 1 невозможно, это не поддерживает ни виндоу менеджер, ни тулкит клиента. И ресурсы клиент перечитает только при перезапуске.

Ты скорее всего путаешь screen и display.

Так и не надо делать, чтобы их перетаскивать. Пусть будет два отдельных скрина у ТС-а. Я вот, например, сразу даже и не пойму, какая логика и на каком уровне решать задачу для отрисовки окна, которое встало между мониторами с разным порядком rgb.

Она не позволяет таскать окна между скринами. Потому что у каждого скрина свое рутовое окно

К слову, но не к теме топика, но раз уж об этом заговорили: GTK вроде до сих пор умеет себя перерисовывать на другом дисплее. Но это должно использовать приложение, которое написано на этом GTK (то есть не универсально нифига). Вот в gtk-3-examples есть программа gtk3-demo, в которой есть пункт «Change Display»:

Change Display

Demonstrates migrating a window between different displays. A display is a mouse and keyboard with some number of associated monitors. The neat thing about having multiple displays is that they can be on a completely separate computers, as long as there is a network connection to the computer where the application is running.

Only some of the windowing systems where GTK+ runs have the concept of multiple displays. (The X Window System is the main example.) Other windowing systems can only handle one keyboard and mouse, and combine all monitors into a single display. This is a moderately complex example, and demonstrates:

- Tracking the currently open displays

- Changing the display for a window

- Letting the user choose a window by clicking on it

- Using GtkListStore and GtkTreeView

- Using GtkDialog

Постоянно растягиваю окна на два монитора.

Про Xrandr был не прав. Оказывается протокол поддерживает хранение свойства subpixelOrder для каждого output-а. Так что один клиент (утилита xrandr или диалог Monitors из центра управления) может это свойство задать, а остальные клиенты могут его использовать. Вот только реализовано ли это в клиентах?

Миграция с дисплея на дисплей это миграция с сервера на сервер. Хорошо, что это есть в gtk. Но клиентам передаётся адрес только одного сервера в переменой окружения DISPLAY, и только при запуске, откуда они узнают адрес другого сервера?

У меня вот xrandr не показывает свойство subpixel_order:

$ xrandr --listmonitors
Monitors: 2
 0: +*eDP-1 1920/476x1080/268+0+0  eDP-1
 1: +HDMI-1 2160/1440x3840/810+1920+0  HDMI-1
$ xrandr --prop
Screen 0: minimum 320 x 200, current 4080 x 3840, maximum 8192 x 8192
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
	scaling mode: Full aspect 
		supported: Full, Center, Full aspect
	max bpc: 12 
		range: (6, 12)
	Broadcast RGB: Automatic 
		supported: Automatic, Full, Limited 16:235
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 85 
		supported: 85
	non-desktop: 0 
		range: (0, 1)
HDMI-1 connected 2160x3840+1920+0 left (normal left inverted right x axis y axis) 1440mm x 810mm
	Content Protection: Undesired 
		supported: Undesired, Desired, Enabled
	max bpc: 12 
		range: (8, 12)
	content type: No Data 
		supported: No Data, Graphics, Photo, Cinema, Game
	aspect ratio: Automatic 
		supported: Automatic, 4:3, 16:9
	Broadcast RGB: Automatic 
		supported: Automatic, Full, Limited 16:235
	audio: auto 
		supported: force-dvi, off, auto, on
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 93 
		supported: 93
	non-desktop: 0 
		range: (0, 1)

При изменении ориентации монитора в Monitors вижу subpixel_order в событиях, но оно SubpixelOrderUnknown:

$ xev -root -event randr

RRNotify event, serial 18, synthetic NO, window 0x1a7,
    subtype XRRCrtcChangeNotifyEvent
    crtc 64, mode 3840x2160, rotation RR_Rotate_90
    x 1920, y 0, width 3840, height 2160

RRNotify event, serial 18, synthetic NO, window 0x1a7,
    subtype XRROutputChangeNotifyEvent
    output HDMI-1, crtc 64, mode 3840x2160 (3840x2160)
    rotation RR_Rotate_90
    connection RR_Connected, subpixel_order SubPixelUnknown

Миграция с дисплея на дисплей это миграция с сервера на сервер. Хорошо, что это есть в gtk. Но клиентам передаётся адрес только одного сервера в переменой окружения DISPLAY, и только при запуске, откуда они узнают адрес другого сервера?

Да просто добавляешь его в список, и все. А потом жмешь Change и он перескакивает. Я только что проверил - открыл Xephyr :1, добавил в список демо-приложения ":1", нажал кнопку Change, он попросил указать top-level window, я щелкнул в демо-приложение, и окно мигом перескочило в Xephyr. В Xephyr уже выбрал :0 и опять Change - перескочило назад.

В демоприложении предусмотрен список адресов, в обычных приложениях не предусмотрен, есть только один адрес, полученный при старте из переменной окружения DISPLAY.

Ну так я и написал, что эта возможность есть в тулките, но приложение, которое хочет этим пользоваться, должно это специально реализовывать, то есть как-то получить адрес другого дисплея и перерисоваться на нем. Любое приложение нельзя переместить и нет никаких договоренностей, чтобы это реализовывалось хотя бы во всех GTK-приложениях. Про это и написал выше, что это не универсально.

Попробовал сделать два скрина

$ xdpyinfo |grep 'screen\|dimension\|root'
default screen number:    0
number of screens:    2
screen #0:
  dimensions:    1920x1080 pixels (508x285 millimeters)
  root window id:    0x2b1
  depth of root window:    24 planes
screen #1:
  dimensions:    384$ xdpyinfo |grep 'screen\|dimension'
default screen number:    0
number of screens:    2
screen #0:
  dimensions:    1920x1080 pixels (508x285 millimeters)
screen #1:
  dimensions:    3840x2160 pixels (998x561 millimeters)
0x2160 pixels (998x561 millimeters)
  root window id:    0x2b3
  depth of root window:    24 planes

$ xrandr --screen 0 |grep '^[^ ]'
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm

$ xrandr --screen 1 |grep '^[^ ]'
Screen 1: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1440mm x 810mm

Я пользуюсь mate. Один процесс mate-panel отображает панельки на обоих мониторах (т.е. скринах). Можно на втором скрине в панельку добавить меню запуска. Но запускаемые из него программы всё равно оказываются на первом скрине (наследуют переменную окружения DISPLAY=:0, используют скрин 0 потому что он default). Мышкой окна со скрина на скрин не перетаскиваются (ожидаемо). Пользоваться невозможно. А чем ты пользуешься в многоскринной конфигурации?

А чем ты пользуешься в многоскринной конфигурации?

Пользовался. :0.0 и :0.1. В данный момент у меня нет необходимости. Я все равно не могу работать в многоэкранной конфигурации, мне тяжело охватывать такую область и крутить головой и глазами постоянно. У меня работа только на основном экране. Второй экран, когда был, предназначался для вывода логов в реальном времени.