LINUX.ORG.RU

Per monitor DPMS

 , ,


0

2

Сап, ЛОР, с наступающим (ну или наступившим) новым годом!

Кейс: смотрю фильм на одном мониторе, второй в это время тоже работает, что напрягает. Хотелось бы, чтобы неактивный [=без фуллскриновых окон] монитор тух после указанного в DPMS времени.

Сейчас делаю такое через лютые костыли - переключаю второй монитор в виртуалку с виндой, в ней запускаю фильм. Фильм играет, а первый монитор [с линуксом] тухнет по DPMS.

Карточка - nvidia, с последним кактусом, если это важно. WM - awesome, с костылём для отключения DPMS при наличии окон в фуллскрине.

$ cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 331.20  (root@thecloneofmyown)  Пт. янв. 10 22:40:04 EET 2014


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/conf.d/gpm"
    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"
    Option	   "TwinView"
EndSection

Section "Screen"

# Removed Option "metamodes" "nvidia-auto-select +0+0"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-1"
    Option         "metamodes" "DVI-D-0: nvidia-auto-select +0+0, VGA-0: 1920x1080 +1920+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

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

Спасибо.

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

Так?

xrandr --output DVI-D-0 --off
xrandr --output VGA-0 --off
Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)

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

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

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

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

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

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

NeverLoved ★★★★★ ()
Ответ на: комментарий от NeverLoved

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

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

$ 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)
DVI-D-1 - основной моник, VGA-0 - тот, что я переключаю на винду (Потому и VGA. В прокинутой карточке только DVI-D и mini DP, потому один шнурок из монитора воткнут в VGA линуксовой карты, а второй шнурок в DVI виндовой карты. Но это не важно в данном контексте).

NeverLoved ★★★★★ ()
Ответ на: комментарий от NeverLoved

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

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

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

NeverLoved ★★★★★ ()
Последнее исправление: NeverLoved (всего исправлений: 1)
Ответ на: комментарий от NeverLoved

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

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok
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

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

NeverLoved ★★★★★ ()
Последнее исправление: NeverLoved (всего исправлений: 1)
Ответ на: комментарий от NeverLoved

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

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

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

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

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

NeverLoved ★★★★★ ()
Ответ на: комментарий от NeverLoved

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

Блин, что-то поменялось. месяц назад определялся только один монитор. Сейчас запилил файл 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) - тот же результат: оба монитора тухнут.

NeverLoved ★★★★★ ()
Ответ на: комментарий от NeverLoved

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

1. ServerLayout зачем?

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

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

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

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

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

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

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

Дело в том, что этой Генте уже лет шесть как минимум, и некоторые секции указывались давно, и на всякий случай (тогда ещё ноутбук был, там без указания драйвера для мыши можно было вполне остаться без тачпада после следующей загрузки).
А 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
Запуск иксов с этим конфигом аналогичен Per monitor DPMS (комментарий)

NeverLoved ★★★★★ ()
Последнее исправление: NeverLoved (всего исправлений: 3)
Ответ на: комментарий от NeverLoved

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

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

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

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

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

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

Понятно.

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

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

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

NeverLoved ★★★★★ ()

Если судить по этому тексту, то возможность управлять 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 реагирует пересчетом раскладки. Поэтому окна перекидываются на оставшийся монитор. Остается вопрос: реально ли сделать так, чтобы он этого не делал. Об этом же и вопрос по последней ссылке.

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 3)
Ответ на: комментарий от Zubok

Если никакой штатной штуки до сих пор нет (а сейчас, зимой, готовится к релизу новый 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 выход, получив примерно то, что тебе нужно. Ну и процедуру включения всего назад тоже надо продумать.

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

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

-- 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. А это костыльно. Плюс на одном из столов вполне может висеть какая-нибудь игрушка, которой вряд-ли понравится, когда дисплей с ней отключится.

NeverLoved ★★★★★ ()
Последнее исправление: NeverLoved (всего исправлений: 2)
Ответ на: комментарий от NeverLoved

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 перерисовался или перезапустился?

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 2)
Ответ на: комментарий от Zubok

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

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

Zubok ★★★★★ ()
Ответ на: комментарий от NeverLoved

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 туда-сюда работает. Может быть, на проприетарном драйвере другое поведение будет.

Zubok ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.