Обнаружение принудительного монитора, низкий уровень

Мой внешний монитор (dell) не обнаруживается на ноутбуке Asus, если я включаю его только после загрузки ноутбука.

Случай, подобный тому, как заставить linux обнаруживать / повторно проверять мониторы с драйвером intel i915? За исключением того, что в моем случае, когда он станет известен ноутбуку, я могу отключить его и снова подключить, чтобы он был обнаружен.

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

Решение с echo detect > /sys/class/drm/card0-DP-1/status не работает, поскольку соответствующим каталогом будет card0-DP-2 , которого просто не существует после загрузки, когда монитор выключен.

Другие решения, такие как CTRL-ALT-F1 и обратно, также не работают.

Отключение кабеля и подключение снова не имеет никакого эффекта. Чувствуется, что весь штекер DisplayPort ноутбука полностью отключен.

Странный вывод: если кабель displayport не подключен во время загрузки, то монитор обнаруживается, когда я включаю его и подключаю кабель после загрузки (:-( Таким образом, кажется, что комбинация «кабель подключен / монитор отключен во время загрузки» интерпретируется как msgstr “не надо больше с этим оборудованием”.

Есть ли какая-нибудь команда, сообщающая системе о необходимости пересмотреть вопрос о том, подключено ли что-либо к порту дисплея?

    2 Solutions collect form web for “Обнаружение принудительного монитора, низкий уровень”

    Это не совсем отвечает на ваш вопрос как таковой, но, возможно, является технически правильным ответом, поэтому я использую более приятное форматирование, которое предоставляется для ответов, так что это не 30 комментариев в виде текста.

    Скорее всего, вы не получите ответ по SO / SE, потому что просто недостаточно знаний о предметной области. Вам гораздо лучше поговорить напрямую с разработчиками драйверов ядра i915.

    https://01.org/linuxgraphics/documentation/how-report-bugs содержит очень подробные инструкции о том, как это сделать организованно.

    То, как вы сформулировали свой отчет об ошибке, подразумевает, что /sys/class/drm/card0-DP-2/status существует, когда вы подключаете кабель DisplayPort после загрузки, но не существует, когда кабель и экран не подключены. Что ж, все, что связано с /sys/* , определенно не связано с X11, и drm в пути абсолютно подтверждает, что вы хотите следовать разделу 1.1 - DRM Kernel по приведенной выше ссылке.

    Я взглянул на детали, запрошенные в этом разделе, и я достаточно уверен, что на самом деле невозможные для понимания биты не нужны. При этом информация о ядре и дистрибутиве, полное dmesg после перезагрузки с drm.debug=0xe и т. Д. – все это очень хорошие идеи.

    Как несколько очевидно, два dmesg бы логически уместны здесь; один из багажника без разъема присутствует, а другой с. Это может быть очень полезно, чтобы аннотировать точную или приблизительную точку, в которую вы фактически подключаете разъем.

    Мысль за 5 минут придумала удобный, но успешный способ легко комментировать:

     script -c 'dmesg -w | cat' dmesg.txt 

    запустит dmesg -w а также позволит вам набирать строки текста непосредственно в терминале, чтобы добавлять annotations , и вы можете ^C когда закончите сбор информации о dmesg. ( dmesg -w | cat короче, чем dmesg -w --color=never .)

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

    Кроме того … вы, возможно, не захотите это слышать, но, как всегда, нельзя быть на 100% уверенным, если неохотно заставить работать последнюю версию ядра не все волшебно исправит. 🙂

    К счастью, это гораздо менее страшно, чем вы могли бы опасаться: https://cgit.freedesktop.org/drm-tip/ – это целый клон ядра Linux с уже сложенными патчами drm-of-tree. Я могу сказать, просто клонировать и построить это, и вы должны быть готовы к работе.

    … При этом, из соображений осторожности, вы, возможно, захотите скачать последнюю версию ядра и сначала получить эту известную рабочую версию, а затем скопировать .config в drm-tip . Если вы не сделаете этого в первую очередь, и все взорвется вбок, проверка того, что вы можете собрать и загрузить kernel ​​магистрали, может быть хорошей первой проверкой работоспособности при пожаре.

    Вот страница bugzilla, которую вы хотите: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI

    На самом деле, это почти наверняка покажет вам вид входа в систему; в этом случае вам сначала понадобится этот URL: https://bugs.freedesktop.org/createaccount.cgi

    Наконец, если вы хотите задать вопросы, https://01.org/linuxgraphics/community/kernel упоминает # gfx-intel на freenode.

    FWIW, то, что я описал выше, является идеальным набором шагов. Вы можете открыть временную ошибку на freedesktop.org перед тем, как, например, пойти и выполнить перестройку ядра, чтобы узнать, нет ли других шагов отладки, которые вы можете попробовать. (На странице с сообщением об ошибке в разделе версии указывается только «drm git», поэтому они действительно хотят, чтобы вы использовали версию git … хе)

    У меня действительно есть хороший вопрос для канала IRC – я перечислил drm-tip git, потому что он упоминается в документации, но есть также drm-intel , и я не знаю, какова его актуальность. Он также выглядит как дерево ядра и обновляется каждые несколько минут.

    Это не решение, а возможный обходной путь:

     $ env DISPLAY=:0 xset dpms force off $ env DISPLAY=:0 xset dpms force on 

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

    Это U & L Q & A под названием: Как я могу определить, когда монитор подключен или отключен? был метод опроса, который может помочь и здесь.

    Linux и Unix - лучшая ОС в мире.