Per monitor DPMS

Собственно, вопрос - можно ли при помощи DPMS тушить только один монитор? Или включить DPMS только для одного монитора? Или что вообще делать при такой хотелке?

Так?

xrandr --output DVI-D-0 --off
xrandr --output VGA-0 --off

Еща вариант: Менять primary и выключать xset:

$ xrandr --output DVI-D-0 --primary
$ xset dpms force off
$ xrandr --output VGA-0 --primary
$ xset dpms force off

Хотя ты используешь TwinView. А я вот точно не знаю, сработает ли xrandr.

Он не просто вручает на мониторе энергосбережение, а отключает его. Осом перебрасывает с него все окна на оставшийся, а при включении оного назад не возвращает ничего. Сильно хотелось бы как с DPMS. :)

Да ещё и композитник падает после --off у одного из мониторов, надо перезапускать.

Срабатывает, отключает монитор от иксов.

Срабатывает, отключает монитор от иксов.

Напрочь? И тоже окна перекидывает?

Ох, нет, это я тупанул.
xset dpms force off выключает оба монитора, без разницы какой из них выставлен как primary через xrandr.

А проконтролируй командой xrandr после каждого xrandr с primary, меняет ли он connceted primary. Хотя все равно он гасит оба. Хм. А primary там вообще есть сейчас?

Меняет, потыкал:

$ xrandr
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 16384 x 16384
VGA-0 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080     60.00*+
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080     60.00*+
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
DVI-D-1 disconnected (normal left inverted right x axis y axis)

А что если выключить TwinView и сконфигурировать через xrandr два монитора? Вроде бы проприетарные nvidia поддерживают xrandr.

Не совсем понимаю, как это.
Мне нужно чтоб оно работало ровно так, как оно сейчас: курсор гуляет по обеим мониторам, awesome заботится обо всём остальном (перетаскивание и позиционирование окон, etc), на каждом мониторе своя панелька от Особа.
Ты имеешь ввиду Xinerama? C Xinerama ни черта не работает, мне даже xrandr говорит что не может найти RANDR extension.

Я не шибко разбираюсь в этом всём, но всё равно спасибо, что отвечаешь в праздничный вечер :3

xset dpms force off выключает оба монитора, без разницы какой из них выставлен как primary через xrandr.

По логике он и должен два вуключать. В случае использованя RandR, Xinerama и TwinView оба монитора объединяются в один дисплей. xset отрабатывает по дисплею и ничего не знает про выходы, поэтому и погасит все. Я не знаю, что быдет со вторым монитором, если гасится primary.

Можно еще попробовать вместо off делать force stanby или force suspend или s blank. Но я не думаю, что это поможет. Попробовать все равно стоит.

neverloved@thecloneofmyown ~ $ xrandr --output VGA-0 --primary
neverloved@thecloneofmyown ~ $ xset dpms force standby
neverloved@thecloneofmyown ~ $ xset dpms force suspend

тушат оба монитора.

neverloved@thecloneofmyown ~ $ xset dpms s blank

не делает ничего.

C Xinerama ни черта не работает, мне даже xrandr говорит что не может найти RANDR extension.

Xinerama и RandR - это разные все-таки вещи. Xinerama это старый механизv, RandR - новый, а TwinView - проприетарная замена Xinerama. Но вроде всегда и везде писалось, что поддерживаются версии RandR 1.2, 1.3.

Просто я с проприетарным драйвером не очень-то знаком. Вот если сделать в xorg.conf минимальную конфигурацию, то есть без всего, а только драйвер указать. При включенных мониторах в терминале проверить, что показывает xrandr. Он видит второй выход VGA-0, монитор на нем и режимы?

Видит, запускается только один монитор. Второй я заводил уже с помощью nvidia-drivers, а до второго моника оно даже не было поставлен. Второй монитор включает при старте конкретно вот эта строка: Option "metamodes" "DVI-D-0: nvidia-auto-select +0+0, VGA-0: 1920x1080 +1920+0" в xorg.conf. Без неё даже с указанием TWinView в xorg.conf второй монитор не подхватывается, и десктоп на него не растягивается.

Видит, запускается только один монитор.

Если видит при простейшей конфигурации, то что происходит, когда ты пытаешься при помощи xrandr выстроить их в один десктоп? Или не выходит?

Блин, что-то поменялось. месяц назад определялся только один монитор. Сейчас запилил файл xorg.simple.conf:

Section "ServerLayout"
    Identifier     "Layout0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "evdev"
    Option         "Protocol"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection



Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "evdev"
EndSection

Section "InputClass"
	Identifier             "keyboard-layout"
	MatchIsKeyboard        "on"
	Option "XkbLayout" "us,ru"
	Option "XkbOptions" "grp_led:scroll,grp:caps_toggle"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2312HM"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 650 Ti"
EndSection

Запускаю xinit /usr/bin/awesome -- /usr/bin/X :1 -config xorg.simple.conf - получаю Awesome на двух мониторах, по панельке на каждом мониторе, как при запуске с настроенным xorg.conf.

В свежезапущенных иксах сделал те же процедуры (xrandr --primary, xset dpms force standby/force suspend) - тот же результат: оба монитора тухнут.

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

1. ServerLayout зачем?

2. А без InputDevice мышка уже не определяется автоматом?

3. InputDevice с клавиатурой вообще не ясно зачем. Все должно автоматом без этой секции.

4. Section «InputClass». А какой дистрибутив? В Debian/Ubuntu, например, эти настройки конфигурируются системно и их необязательно в xorg.conf вписывать.

5. Зачем «Monitor»? У него битый кабель и его карточка по DDC через EDID не определяет?

По большому счету кроме секции Device тут вообще ничего не нужно, как мне кажется.

Прямо вообще? Окей, сейчас подрежу.

Дело в том, что этой Генте уже лет шесть как минимум, и некоторые секции указывались давно, и на всякий случай (тогда ещё ноутбук был, там без указания драйвера для мыши можно было вполне остаться без тачпада после следующей загрузки).
А Monitor туда записал nvidia-settings, судя по всему.
А InputClass с клавой для указания раскладки, очевидно же. Я не пользуюсь DE с их назначалками, проще сказать иксам, в каких раскладках я хочу писать и как я хочу между ними переключаться. Лишние сущности - это плохо.

====

$ cat /etc/X11/xorg.simple.conf 
Section "InputClass"
	Identifier             "keyboard-layout"
	MatchIsKeyboard        "on"
	Option "XkbLayout" "us,ru"
	Option "XkbOptions" "grp_led:scroll,grp:caps_toggle"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 650 Ti"
EndSection

Дело в том, что этой Генте

А, раз гента, то другой вопрос. Просто в Debian/Ubuntu есть конфигурационный файл, где эти настройки для иксов лежат при системной (не графической, а консольной) настройке. Просто потом из этого файла и иксы конфигурируются.

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

Тогда, да. Все верно. Эту секцию тогда оставляй, раз гента.

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

Понятно.

Просто в Debian/Ubuntu есть конфигурационный файл

там просто куски конфига, раскиданные по нескольким файлам в xorg.conf.d. Делаем cat /etc/X11/xorg.conf.d/* - получаем файл xorg.conf, как мне помнится :)
Ну а так - основной xorg.conf я чистить не буду, вдруг ноут куплю снова, да склонирую систему. У меня до сих пор где-то валяется скрипт для настройки синаптиксовского тачпада через xinput, чтоб на нём можно было даже игрушки гамать.

Ну, ман по xset я посмотрел, там ничего по этому поводу нет вообще, потому и пришёл сюда плакаться.
В любом случае, спасибо за попытку помочь. Может завтра кто-то набежит с однострочным решением проблемы, или ещё как.

Если судить по этому тексту, то возможность управлять DPMS per-output пока отсутсвует:

http://www.phoronix.com/scan.php?page=news_item&px=NzMyMg

Написано, что в версии RandR 1.4 это планировалось (заметка 2009 года), но в спецификации нет этого.

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

http://lists.x.org/archives/xorg-devel/2010-May/008030.html

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

Если никакой штатной штуки до сих пор нет (а сейчас, зимой, готовится к релизу новый xorg), то надо подумать, можно ли как-то обмануть awesome, чтобы он не пересчитывал геометрию, когда выключается выход, то есть когда --output --off делается. Сейчас в общих чертах понятно, что происходит: ты выключаешь выход, X-сервер шлет сообщение awesome, что исчез выход, awesome реагирует пересчетом раскладки. Поэтому окна перекидываются на оставшийся монитор. Остается вопрос: реально ли сделать так, чтобы он этого не делал. Об этом же и вопрос по последней ссылке.

Если никакой штатной штуки до сих пор нет (а сейчас, зимой, готовится к релизу новый xorg), то надо подумать, можно ли как-то обмануть awesome, чтобы он не пересчитывал геометрию, когда выключается выход, то есть когда --output --off делается.

Надо изучить подробно инфраструктуру, начав отсюда.

http://awesome.naquadah.org/wiki/Using_Multiple_Screens

Далее надо поковыряться. Есть предопределенное поведение (скрипт по умолчанию): Awesome is distributed with a sample configuration file (/etc/xdg/awesome/rc.lua with v3.0 and above) which is already setup for multiple displays; regarding wiboxes, taskbars and widgets but also has keybindings which allow you to move clients between multiple screens and switch focus between them.

Надо посмотреть, что делает awesome, когда исчезает какой-то вход (--off). Возможно, скрипт в поставке объяснит, что делает awesome, когда он перекидывает окна на другой монитор. Задача: попробовать сделать так, чтобы он это не делал, написав свой скрипт или дополнив как-то штатный. В awesome не спец, сорри.

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

Вся «мультимониторность изкоробки» заключается в том, что там в цикле перебираются дисплеи:

-- Define a tag table which hold all screen tags.
 tags = {
   names  = { "BROW",     "TERM",     "DEV",      "IM",       "AU",       "GAME" },
   layout = { layouts[3], layouts[3], layouts[3], layouts[3], layouts[3], layouts[1] }
 }
 
 for s = 1, screen.count() do
     tags[s] = awful.tag(tags.names, s, tags.layout)
 end
-- }}}

X-сервер шлет сообщение awesome, что исчез выход, awesome реагирует пересчетом раскладки. Поэтому окна перекидываются на оставшийся монитор.

Не-а...
Просто при --off одного монитора осом тупо перезапускается, и перекидывает все окна на один монитор, который собственно, остаётся один.
Можно попробовать вместо screen.count() вставить «2», но я не знаю... Даже если это сработает - всё равно нужно будет перезапускать композитник, ибо он отваливается, если запущен до старта WM. А это костыльно. Плюс на одном из столов вполне может висеть какая-нибудь игрушка, которой вряд-ли понравится, когда дисплей с ней отключится.

X-сервер шлет сообщение awesome, что исчез выход, awesome реагирует пересчетом раскладки. Поэтому окна перекидываются на оставшийся монитор.

Не-а... Просто при --off одного монитора осом тупо перезапускается, и перекидывает все окна на один монитор, который собственно, остаётся один.

Так все равно он это делает по сообщению от расширения RandR. Не важно как. Вернее, важно. То, что он перезапускает awesome, выглядит грубоватым, конечно. Исходник awesome:

/** The randr screen change notify event handler.
 * \param ev The event.
 */
static void
event_handle_randr_screen_change_notify(xcb_randr_screen_change_notify_event_t *ev)
{
    /* Code  of  XRRUpdateConfiguration Xlib  function  ported to  XCB
     * (only the code relevant  to RRScreenChangeNotify) as the latter
     * doesn't provide this kind of function */
    if(ev->rotation & (XCB_RANDR_ROTATION_ROTATE_90 | XCB_RANDR_ROTATION_ROTATE_270))
        xcb_randr_set_screen_size(globalconf.connection, ev->root, ev->height, ev->width,
                                  ev->mheight, ev->mwidth);
    else
        xcb_randr_set_screen_size(globalconf.connection, ev->root, ev->width, ev->height,
                                  ev->mwidth, ev->mheight);

    /* XRRUpdateConfiguration also executes the following instruction
     * but it's not useful because SubpixelOrder is not used at all at
     * the moment
     *
     * XRenderSetSubpixelOrder(dpy, snum, scevent->subpixel_order);
     */

    awesome_restart();
}

Получается, что awesome при получении notification oт RandR принудительно перезапускается. Скриптом это не управляется.

Можешь проверить, действительно ли это так: через утилиту xrandr просто меняешь разрешение экрана на какое-то пониже. В этом случае awesome получит сообщение. awesome перерисовался или перезапустился?

Может, вообще тело event_handle_randr_screen_change_notify закомментировать и пересобрать awesome? xcb_randr_set_screen_size тоже надо комментировать, чтобы не менял параметры экрана. Если у тебя RandR никак не используется в повседневной жизни, то, может, прокатит? Тогда по идее awesome перезапускаться не будет.

Хотя есть момент. Даже если событие notify не обработается, то новое значение размера экрана все равно может установиться. Я это предполагаю, но точно можно узнать из документации на RandR. Если так, то надо при помощи xcb_randr_set_screen_size в обработчике прописать прежние размеры экрана до выключения выхода. Для тупой проверки можно просто фиксированные числа проставить.

xset dpms force off выключает оба монитора, без разницы какой из них выставлен как primary через xrandr.

Какой-то Workaround изобрел, но у меня тут нет двух мониторов, поэтому не могу проверить, работает ли он, как задумано. На одном монике вроде срабатывает. Идея такая: гасим оба и тут же пытаемся пробудить один из мониторов:

$ xset dpms force off && xrandr --output DVI-D-0 --rotate inverted && xrandr --output DVI-D-0 --rotate normal

Я пытаюсь пробудить выход сначала переворачивая картинку, а потом возвращая ее в нормальное положение. У меня не получилось пробудить при помощи --output --auto, --output --rotate normal, то есть каким-то одним действием, а вот flip туда-сюда работает. Может быть, на проприетарном драйвере другое поведение будет.