Экранная блокировка Ubuntu 18.04 теряет самое высокое разрешение каждый раз

Question 1

Я нахожусь на рабочем столе Ubuntu 18.04 с Intel HD Integrated Graphics и синглом 2560x1440 экран, соединенный с DP (DisplayPort) кабель. У меня не было этой проблемы с помощью того же рабочего стола с маленькими мониторами.

На этом большом мониторе каждый раз я возобновляюсь от блокировки экрана (вводящий мой пароль для единственной учетной записи пользователя системы), самое высокое доступное разрешение прогрессивно устраняется из списка выбора и в Настройках GNOME и в опциях, отображенных xrandr. Первоначально, после начальной загрузки системы:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 699mm x 393mm
   2560x1440     59.95*+
   2880x1620     60.00
   2048x1152     60.00
   1920x1200     59.88

... затем после первой экранной блокировки и резюме, более высокое, чем естественное разрешение устраняется (посредством имения никакого видимого эффекта все же):

Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192 ...
   2560x1440     59.95*+
   2048x1152     60.00
   1920x1200     59.88

... затем вторая экранная блокировка и резюме уменьшают текущее разрешение до 2048x1152:

Screen 0: minimum 320 x 200, current 2048 x 1152, maximum 8192 x 8192 ...
DP-1 connected primary 2048x1152+0+0 (normal left inverted right x axis y axis) 699mm x 393mm
   2048x1152     60.00*
   1920x1200     59.88

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

Монитором является Acer EB321HQU - выключение, это и на снова не имеет никакого эффекта на разрешения, доступные, если система также не перезагружается. Существуют связанные отчеты об ошибках, но только подтвердили для видеокарт Nvidia, не применимых в моем случае. Я также попробовал их до сих пор без эффекта на проблему:

переключение со значения по умолчанию gdm3 кому: lightdm
обновление видеодрайвера xserver-xorg-video-intel/bionic от собственного компонента 2:2.99.917+git20171229-1 к более новой версии в Открывают Graphics Drivers PPA 2:2.99.917+git1903011933.6afed3~oibaf~b amd64
Править: разъединение и повторное подключение кабеля DP уменьшают максимальное разрешение еще больше, к 1024x768.

Question 2

Сначала генерируйте шаблон xorg.conf файл следующим образом (который должен работать, даже если Вы уже работаете X / GNOME / менеджер по оформлению):

sudo X :2 -configure

Затем скопируйте получающийся файл /root/xorg.conf.new кому: /etc/X11/xorg.conf который будет новым файлом на последних версиях Ubuntu, так как X параметров автоматически определяются по умолчанию. Вот то, куда мое собственное решение отличается от более более простого, общего:

1, общий), Пользователи некоторых видеокарт могут просто фиксировать это путем добавления строк, подходящих для неправильно себя ведущего монитора в начале раздела Section "Monitor":

Modeline "2560x1440" 241.50  2560 2608 2640 2720 1440 1443 1448 1481 -hsync -vsync
Option "PreferredMode" "2560x1440"

X-сервер использует систему под названием EDID для запросов разрешений автоматически и существует много проблем, о которых сообщают, и внешних дисплеев и дисплеев портативного компьютера, получающих неполные результаты (я сначала думал, что это происходило со мной после screenlock/unlock, и приостановите/возобновите). Установка Explicitly Modeline имеет тенденцию гарантировать, что это разрешение доступно X-серверу независимо от того, что ответ EDID. Я смог получить это Modeline 2 способами (существуют другие):

чтение его от X-сервера запускает файл журнала в /var/log/Xorg.0.log
подтверждение его с программой PowerStrip в Windows (учебное руководство)

Страница X/Config/Resolution документа Ubuntu> статически устанавливает в xorg.conf, дает хороший обзор X конфигураций и соответствующих проблем.

2, мое собственное решение), Однако в файле журнала Xorg я нашел это

Modeline игнорировался в пользу информации от EDID (появляющийся в журнале как DDC gathered Modelines)
PreferredMode был правильно проанализирован, но затем отклонен.

Я понял, что должен был заменить поврежденный EDID, который моя видеокарта получала от монитора с одним содержащим только Modeline для моего надлежащего разрешения. Но моя система находится на Intel HD Graphics, для который большинство опций, имеющих дело с EDID (UseEDID, UseEDIDFreqs, IgnoreEDID) не поддерживаются (отмеченный is not used в файле журнала), таким образом, я не имел никакого успеха, подавляющего EDID в целом.

Были и положительными и отрицательными отчетами (стемминг из этого отчета об ошибках) использования другой опции EDID Xorg CustomEDID предоставлять собственную конфигурацию EDID. Я попробовал процедуру здесь (для компиляции и edid.bin файла только с моим собственным modeline в нем), и это работало, несмотря на отчеты, что это не будет: Создание и использование edid.bin через xorg.conf> Метод 2: Генерируйте edid.bin из Xorg modeline (edid-генератор)

Моей в настоящее время рабочей конфигурации, с решенной проблемой, поэтому добавили эти две строки к "Screen" раздел (вместо соответствия "Monitor" строки в решении № 1):

Option  "ConnectedMonitor" "DP1"
Option  "CustomEDID" "DP1:/etc/X11/2560x1440.bin"

... где DP1 соответствует тегу Идентификатора в "Monitor" раздел и поэтому вывод xrandr. В следующий раз перезагружая с этим xorg.conf У меня был намного более короткий список разрешений в xrandr, который теперь сохраняется, неважно, сколько раз экран идет пробел на мониторе.

BTW, если отчеты на всем протяжении Интернета о драйвере Intel, не распознающем CustomEDID опция оказалась верной для меня (!Примечание! Я использую драйверы с открытым исходным кодом, упомянутые в OP!), у меня была бы еще одна опция в определении пользовательских данных EDID как параметр ядра: ArchLinux> установка Привилегированного режима> режимы Forcing и EDID

Почему это происходило во-первых? (Короткий ответ: монитор EDID был произведен и оставил поврежденным Acer, но это будет зафиксировано для большинства Windows "драйвером", который является действительно просто ключами реестра к твердому коду конфигурация EDID на сам компьютер.) Программа get-edid, упомянутый в связанной процедуре выше, извлек поврежденный EDID из моего монитора:

sudo get-edid -m 0 > edid.bin

... и при прокручивании его вывода edid-decode это показало, что только более низкие разрешения были классифицированы или как "Установленные синхронизации" или как "Стандартные синхронизации" и более высокие разрешения, которые продолжали отбрасывать, только появился как наборы синхронизации характеристик. Кроме того, при проведении, которые производят через третью программу parse-edid это показало режим 1920x1080 был на самом деле PreferredMode, который наконец объяснил, почему экранные перезапуски в конечном счете возвратились к тому режиму.

Question 3

Question 4

У меня была очень похожая проблема: иногда после приостановки пропадало самое высокое разрешение. Основная причина, по-видимому, заключается в несколько неисправном EDID в мониторе.

Решение 1. Обновите прошивку вашего монитора или замените ее. Решение 2.: когда у вас самое высокое разрешение (когда вы можете изменить это разрешение, например, с помощью xrand), затем прочитайте EDID вашего монитора и установите его как CustomEDID в xorg.conf.

Решение 2. у меня работает (дисплей AOC 24" с графической картой intel/i915 на ядре 4.19). Оба приведенных выше решения очень хорошо детализированы @rphair, большое спасибо! (до сих пор не могу добавить в качестве комментария еще..)

rphair · Accepted Answer · 2 December 2019 в 06:26

Сначала генерируйте шаблон xorg.conf файл следующим образом (который должен работать, даже если Вы уже работаете X / GNOME / менеджер по оформлению):

sudo X :2 -configure

Затем скопируйте получающийся файл /root/xorg.conf.new кому: /etc/X11/xorg.conf который будет новым файлом на последних версиях Ubuntu, так как X параметров автоматически определяются по умолчанию. Вот то, куда мое собственное решение отличается от более более простого, общего:

1, общий), Пользователи некоторых видеокарт могут просто фиксировать это путем добавления строк, подходящих для неправильно себя ведущего монитора в начале раздела Section "Monitor":

Modeline "2560x1440" 241.50  2560 2608 2640 2720 1440 1443 1448 1481 -hsync -vsync
Option "PreferredMode" "2560x1440"

X-сервер использует систему под названием EDID для запросов разрешений автоматически и существует много проблем, о которых сообщают, и внешних дисплеев и дисплеев портативного компьютера, получающих неполные результаты (я сначала думал, что это происходило со мной после screenlock/unlock, и приостановите/возобновите). Установка Explicitly Modeline имеет тенденцию гарантировать, что это разрешение доступно X-серверу независимо от того, что ответ EDID. Я смог получить это Modeline 2 способами (существуют другие):

чтение его от X-сервера запускает файл журнала в /var/log/Xorg.0.log
подтверждение его с программой PowerStrip в Windows (учебное руководство)

Страница X/Config/Resolution документа Ubuntu> статически устанавливает в xorg.conf, дает хороший обзор X конфигураций и соответствующих проблем.

2, мое собственное решение), Однако в файле журнала Xorg я нашел это

Modeline игнорировался в пользу информации от EDID (появляющийся в журнале как DDC gathered Modelines)
PreferredMode был правильно проанализирован, но затем отклонен.

Я понял, что должен был заменить поврежденный EDID, который моя видеокарта получала от монитора с одним содержащим только Modeline для моего надлежащего разрешения. Но моя система находится на Intel HD Graphics, для который большинство опций, имеющих дело с EDID (UseEDID, UseEDIDFreqs, IgnoreEDID) не поддерживаются (отмеченный is not used в файле журнала), таким образом, я не имел никакого успеха, подавляющего EDID в целом.

Были и положительными и отрицательными отчетами (стемминг из этого отчета об ошибках) использования другой опции EDID Xorg CustomEDID предоставлять собственную конфигурацию EDID. Я попробовал процедуру здесь (для компиляции и edid.bin файла только с моим собственным modeline в нем), и это работало, несмотря на отчеты, что это не будет: Создание и использование edid.bin через xorg.conf> Метод 2: Генерируйте edid.bin из Xorg modeline (edid-генератор)

Моей в настоящее время рабочей конфигурации, с решенной проблемой, поэтому добавили эти две строки к "Screen" раздел (вместо соответствия "Monitor" строки в решении № 1):

Option  "ConnectedMonitor" "DP1"
Option  "CustomEDID" "DP1:/etc/X11/2560x1440.bin"

... где DP1 соответствует тегу Идентификатора в "Monitor" раздел и поэтому вывод xrandr. В следующий раз перезагружая с этим xorg.conf У меня был намного более короткий список разрешений в xrandr, который теперь сохраняется, неважно, сколько раз экран идет пробел на мониторе.

BTW, если отчеты на всем протяжении Интернета о драйвере Intel, не распознающем CustomEDID опция оказалась верной для меня (!Примечание! Я использую драйверы с открытым исходным кодом, упомянутые в OP!), у меня была бы еще одна опция в определении пользовательских данных EDID как параметр ядра: ArchLinux> установка Привилегированного режима> режимы Forcing и EDID

Почему это происходило во-первых? (Короткий ответ: монитор EDID был произведен и оставил поврежденным Acer, но это будет зафиксировано для большинства Windows "драйвером", который является действительно просто ключами реестра к твердому коду конфигурация EDID на сам компьютер.) Программа get-edid, упомянутый в связанной процедуре выше, извлек поврежденный EDID из моего монитора:

sudo get-edid -m 0 > edid.bin

... и при прокручивании его вывода edid-decode это показало, что только более низкие разрешения были классифицированы или как "Установленные синхронизации" или как "Стандартные синхронизации" и более высокие разрешения, которые продолжали отбрасывать, только появился как наборы синхронизации характеристик. Кроме того, при проведении, которые производят через третью программу parse-edid это показало режим 1920x1080 был на самом деле PreferredMode, который наконец объяснил, почему экранные перезапуски в конечном счете возвратились к тому режиму.

forgi007 · Answer 2 · 2 October 2020 в 07:53

У меня была очень похожая проблема: иногда после приостановки пропадало самое высокое разрешение. Основная причина, по-видимому, заключается в несколько неисправном EDID в мониторе.

Решение 1. Обновите прошивку вашего монитора или замените ее. Решение 2.: когда у вас самое высокое разрешение (когда вы можете изменить это разрешение, например, с помощью xrand), затем прочитайте EDID вашего монитора и установите его как CustomEDID в xorg.conf.

Решение 2. у меня работает (дисплей AOC 24" с графической картой intel/i915 на ядре 4.19). Оба приведенных выше решения очень хорошо детализированы @rphair, большое спасибо! (до сих пор не могу добавить в качестве комментария еще..)

Экранная блокировка Ubuntu 18.04 теряет самое высокое разрешение каждый раз

2 ответа

Другие вопросы по тегам:

Похожие вопросы: