LINUX.ORG.RU

нет видеосигнала (no video input) через переходник vga-dvi

 , ,


0

1

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

Есть монитор Philips 227EL, подключенный vga-кабелем к dvi-разъёму видеокарты nvidia geforce gt440 через переходник (так как vga-разъём видеокарты перегорел, увы). Где-то начиная с ядер версии 4.x появилась возможность использовать при загрузке параметр drm.edid_firmware=edid/1920x1080.bin , однако он не помогает. Можно добавить drm.debug=0x1e log_buf_len=1M video=VGA-1:e, и это тоже ничего особо не даёт - экран просто гаснет, и всё.

Собственно вопрос - может быть кому-то всё же удалось решить эту проблему?

PS. монитор сам рабочий, nomodeset и vga=ask это подтверждают.
PPS. интересует именно простой способ решения проблемы, без доустановки драйверов nvidia, покупки dvi-кабеля, новой видеокарты/монитора, пересборки ядра/initrd и тд и тп. В идеале - вставляем livecd ubuntu/debian/fedora, прописываем нужные параметры ядру - и загружаемся в live-систему с nouveau на максимальном разрешении для данного монитора
PPPS. могу предоставить логи, но ничего там особо нету

решено:
необходимо передавать ещё один параметр ядру video=VGA-1:d
тем самым принудительно отключив vga коннектор видеокарты (который не задействован, перегорел и тд)
в конце темы есть пример получения 1920х1080 (или других разрешений) =без= указания ядерных edid (которых всего 6 штук на данный момент)


Ответ на: комментарий от anonymous

логи большие, поэтому загрузил сразу одним архивом https://drive.google.com/open?id=1zZUxhmLQ_cmlrwGkjptnJWkyg_pIGMn-

сами по себе сообщения ошибок в логах малоинформативные, вот некоторые примеры

dmesg
[ 16.686704] kernel: nouveau 0000:01:00.0: DRM: core notifier timeout

dmesg.0
[ 14.330583] kernel: nouveau 0000:01:00.0: DVI-I-1: EDID is invalid:
[ 14.330595] kernel: nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-I-1

Xorg.0.log
[ 30.145] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

kern.log
May 18 03:33:50 john-pc kernel: [ 16.686704] nouveau 0000:01:00.0: DRM: core notifier timeout
May 18 03:33:52 john-pc kernel: [ 18.686646] nouveau 0000:01:00.0: DRM: base-0: timeout
May 18 03:33:54 john-pc kernel: [ 20.686593] nouveau 0000:01:00.0: DRM: base-1: timeout

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

[ 14.330583] kernel: nouveau 0000:01:00.0: DVI-I-1: EDID is invalid:

[ 14.330595] kernel: nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-I-1

с внешним edid (drm.edid_firmware=edid/1920x1080.bin) что показывает

for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n «${con#*/card?-}: »; cat $p; done

video=VGA-1:e

форсить включение надо я так понимаю для DVI-I-1, у него должен быть свой VGA-енкодер иначе всё бессмысленно

vga-разъём видеокарты перегорел, увы

https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID

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

что показывает

for p in /sys/class/drm/*/status

не могу сказать, у меня нету serial console, ssh и прочь


форсить включение надо я так понимаю для DVI-I-1

судя по Xorg.0.log, форсить его не нужно, он и так connected

d00fy ()

Запускал картинку на amd-шке, у которой был отгоревший пин передачи edid, по инструкции

https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes

Там же команда как получить имена всех разъёмов всех видеокарт (надо иметь ввиду что нумерация сквозная по видеокартам, т.е. если есть встроенная - её коннекторы тоже могут быть в списке и что список активируется только при загруженном nouveau - т.е. его надо получать когда картинки нет)

Судя по вашему логу - интерфейс называется DVI-I-1 Значит его и надо передавать в командной строке ядра где video= У вас там VGA-1, это точно неправильно - вполне вероятно что после правильного указания всё заведётся.

drm.edid_firmware указываете правильно, это нужный в таком случае параметр (но синтаксис зависит от версии ядра, опять же см. по ссылке выше.

То что его надо запустиьт в аналоговом редиме - оно по идее должно само догадаться по букве e.

GPFault ()
Ответ на: комментарий от anonymous

F10

а можно чуть подробнее?
если имеется ввиду загрузочное меню livecd, то по F10 отображается Copyrights and warranties (только что пересмотрел файл xubuntu-19.04-desktop-amd64.iso -> isolinux/en.hlp)

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

судя по Xorg.0.log, форсить его не нужно, он и так connected

Если connected, а edid неопределился - то нужно.

В винде c драйверами nvidia - 3d работает? Если драйвер nvidia диагностирует погорелость видеокарты, то он может откатываться на стандартный (VESA или что там у них, не знаю), который в новых виндах умеет большие разрешения. Самый надёжный способ - проверить это - запустиьт 3d.

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

проверил два варианта
drm.edid_firmware=edid/1920x1080.bin video=DVI-I-1:D и
drm.edid_firmware=edid/1920x1080.bin video=DVI-I-1:e
безрезультатно

а чем можно проверить 3d под винду? (кроме скачивания/установки игрушек по 20-30гиг). Я только что запустил тест FurMark и kkrieger-beta - работают (хотя они могут работать на софте или opengl'e, как знать)

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

а чем можно проверить 3d под винду?

не важно это - аналоговый сигнал есть на DVI и это главное, нужно понять как включить VGA-енкодер на DVI-I коннекторе в драйвере ядра Linux, если это вообще возможно.

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

нужно понять как включить VGA-енкодер на DVI-I коннекторе в драйвере ядра Linux

попробуй зафорсить включение HDMI-1 и подсунуть для него EDID

[    20.771] (II) NOUVEAU(0): Output DVI-I-1 connected
[    20.771] (II) NOUVEAU(0): Output HDMI-1 disconnected
[    20.771] (II) NOUVEAU(0): Output VGA-1 connected

есть подозрение что за ним скрывается VGA от DVI-I

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers...

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

увы, никак


drm.edid_firmware=HDMI-1:edid/1920x1080.bin video=HDMI-1:D
drm.edid_firmware=HDMI-1:edid/1920x1080.bin video=HDMI-1:e
drm.edid_firmware=VGA-1:edid/1920x1080.bin,HDMI-1:edid/1920x1080.bin,DVI-I-1:edid/1920x1080.bin video=HDMI-1:D video=DVI-I-1:D video=VGA-1:e и прочее в таком духе никаких изменений не даёт

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

а чем можно проверить 3d под винду? (кроме скачивания/установки игрушек по 20-30гиг). Я только что запустил тест FurMark и kkrieger-beta - работают (хотя они могут работать на софте или opengl’e, как знать)

FurMark и kkrieger-beta - вполне удачные инструменты для проверки. FurMark на софте даёт меньше 2 fps (правда на софте его можно запустить только на онтопике вроде, в винде он на софте просто не запустится). Если было больше - то с картой нормально всё и используется NVIDIA драйвер, а не стандартный.

Вообще получение EDID от монитора - асболютно одинаково в DVI-D и DVI-A режимах - и там и там по одним и тем же линиям I2C уровня 5V, и то что оно судя по логу фейлится - говорит о том что проблема НЕ в переключении в аналоговый режим, а где-то ранее.

Можно в сочетании с drm.edid_firmware=edid/1920x1080.bin video=DVI-I-1:e попробовать параметры ядра

nouveau.nofbaccel=1 nouveau.runpm=0 nouveau.noaccel=1

Тогда оно не будет пытаться инициализировать блоки ускорения, если у него с ними какие-то проблемы.

Если есть возможность заранее отредактировать параметры загрузчика и сохранить логи ядра в файл - то можно ещё запустить с макимальным уровнем логгирования nouveau:

nouveau.debug=BUS=spam,DRM=spam,BIOS=spam,DEVICE=spam,DMAOBJ=spam,PBSP=spam,PCE0=spam,PCE1=spam,PCE2=spam,PCRYPT=spam,PDISP=spam,PFIFO=spam,PGRAPH=spam,PMPEG=spam,PPM=spam,PPPP=spam,PVP=spam,SW=spam,BARCTL=spam,DEVINIT=spam,GPIO=spam,I2C=spam,INSTMEM=spam,MXM=spam,PBUS=spam,PIBUS=spam,PLTCG=spam,PTHERM=spam,PTIMER=spam,VBIOS=spam

Какая версия ядра? Работало ли это ядро с этой видеокартой ранее, когда vga ещё был исправен?

Винда сама подхватила 1920x1080 или пришлось ставить вручную? (это косвенный признак того работает ли получени edid в винде)

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

GPFault, я тут придумал кое-что повеселее

после того, как экран гаснет, я дожидаюсь загрузки иксов (загорается индикатор numlock'a), нажимаю вслепую win+t (стартует xfce4-terminal), набираю вслепую xrandr --verbose > foo
теперь перезагружаюсь под винду и перебрасываю этот foo себе на виндовую систему
открываю его, и что я вижу - а я вижу, что всё ок - edid прочитан, разрешение выставлено как надо

этот файл получен путём загрузки с единственным параметром
drm.edid_firmware=edid/1920x1080.bin (никаких video= и тд и тп)
вот он https://pastebin.com/XRS0aqnn
есть ещё вывод xrandr без verbose, но он малоинформативен

вывод?

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

Про ключ –verbose толко из сообщения узнал, спасибо!

Судя по xrandr - драйвер инициирует отправку на монитор сигнала 1920x1080, на основании переданного edid. А монитор почему-то не может на него синхронизироваться и сичтает что сигнала нет.

Никакого признака «включись» в vga нету, т.к. i2c для запроса edid асболютно независимо от собственно передачи картинки. Активация монитора происходит если он воспрнимает аналоговые сигналы hsync/vsync/r/g/b как валидные.

Если он был активирован, и гаснет, знаичт что-то в них меняется.

Также у меня появилось воспоминание, что с каким-то монитором у меня не работал стоковый «1920x1080.bin», но работал непосредственно взятый с монитора - т.к. на высоких разрешениях по vga уже могут быть нюансы частот. В эту же сторону немного смущает что в выводе xrandr - аж 2 режима 1920x1080 с разными знаками hv/sync.

Так что можно попробовать как будет работать drm.edid_firmware=edid/800x600.bin

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

Ещё хорошо бы dmesg в файл перенаправить (со стандартным уровнем логирования) - убедиться что там нет сообщений о проблемах от nouveau.

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

загрузился с помощью
drm.edid_firmware=edid/1280x1024.bin drm.debug=0x7e log_buf_len=16M nouveau.debug=debug video=DVI-I-1:D

(пробовал загружаться через spam для всех подсистем nouveau - получаются логи по 360M, сохранил только dmesg на 9М)

попробовал вслепую сменить разрешение с 1280х1024 на 800х600 (из расчёта, что хоть какая-то ошибка в логах вылезет) - всё ок
$ xrandr --verbose --output DVI-I-1 --mode 800x600 &> foo
//содержимое файла foo

crtc 0: disable
screen 0: 800x600 211x158 mm 96.09dpi
crtc 0: 800x600 60.32 +0+0 «DVI-I-1»

вот логи https://drive.google.com/open?id=1uq5BNLeMeKAuF9xqyavfT9zQZ4QjQwML
в них кроме сообщения

DRM: core notifier timeout

особо смотреть не на что

вопрос - имеет ли смысл постить баг в таком случае?
(уровень drm.debug=0x7e является максимальным для мониторов без DisplayPort, то есть программно получить больше информации уже нельзя)

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

пока не забыл

для интеловских карточек есть чудо опция

Option «ReprobeOutputs» «boolean»


откопал здесь (или man 4 intel , у кого она есть)
быть может, нечто подобное появится и у nouveau на эту тему в (не)обозримом будущем

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

Посмотрел логи, наиболее информативный - 1280/syslog.

По нему видено 3 странности и одну явную проблему. Странность1 - несущественная - Убунту-специфичная утилита gpu-manager, лично у меня с ней не сложилось - были одни проблемы. В debian её нет и всё нормально)) Есть шанс что она что-то запутывает.

Странность2 - более существенная. Оно почему-то вначале в районе 12.945704 определяет что подключены как DVI-I-1, так и VGA-1.

May 21 22:25:11 john-pc kernel: [   13.019862] [drm:drm_setup_crtcs [drm_kms_helper]] connector 48 enabled? yes
May 21 22:25:11 john-pc kernel: [   13.019867] [drm:drm_setup_crtcs [drm_kms_helper]] connector 51 enabled? no
May 21 22:25:11 john-pc kernel: [   13.019873] [drm:drm_setup_crtcs [drm_kms_helper]] connector 53 enabled? yes

Может быть он сломался так, что всегда трактуется как подключенный и оно пытается выводить именно на него и вообще от этого ему как-то сносит крышу. Т.к. edid указан общий на все, то оно и разрешения для него находит. Можно попробовать написать явным образом video=VGA-1:d чтоб он выключился

Странность3 - передаётся edid/1280x1024.bin а в логе максимальное -

[drm:drm_mode_debug_printmodeline [drm]] Modeline 64:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa

Можно попробовать edid/800x600.bin

А явная проблема видная по нему - то что для DVI-I используется цифровой encoder, а не аналоговый.

May 21 22:25:11 john-pc kernel: [   13.046240] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:48:DVI-I-1] using [ENCODER:49:sor-0002-03c1] on [CRTC:43:head-0]
May 21 22:25:11 john-pc kernel: [   13.046274] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:53:VGA-1]
May 21 22:25:11 john-pc kernel: [   13.046280] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:53:VGA-1] using [ENCODER:54:dac-0000-0304] on [CRTC:47:head-1]
May 21 22:25:11 john-pc kernel: [   13.046286] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:43:head-0] needs all connectors, enable: y, active: y

Судя по (случайный кусок кода в сети) https://git.sphere.ly/dtc/kernel_moto_falcon/commit/ec7fc4a1a7b322380d053fb04bfc4537be3cdfe5#c7f730142ea082f344a60cb8693897156269e65f_455_446 sor - это цифровой выход, а dac - аналоговый. И в логе ENCODER:49:sor для DVI-I-1.

вполне вероятно что причина в том, что ядру передан параметр video=DVI-I-1:D, который и означает использовать цифровой режим. Для аналогового - по идее video=DVI-I-1:e

Итого я предлагаю

video=DVI-I-1:e video=VGA-1:d drm.edid_firmware=edid/800x600.bin

Насчёт бага - фиг знает, если на карте не работает vga, то она явно повреждена, есть риск что неработоспобность nouveau из-за того что у неё вцелом какие-то проблемы с частью чипа отвечающей за определение мониторов. Особенно настораживают сообщения

May 21 22:25:11 john-pc kernel: [   13.072492] nouveau 0000:01:00.0: disp: supervisor 00000020 000007f0
May 21 22:25:11 john-pc kernel: [   13.072495] nouveau 0000:01:00.0: disp: head-0: supervisor 2.0
May 21 22:25:11 john-pc kernel: [   13.072496] nouveau 0000:01:00.0: disp: head-0: on DAC-1
May 21 22:25:11 john-pc kernel: [   13.072506] nouveau 0000:01:00.0: disp: outp 01:0000:0302: missing IEDT for 0000:0102
May 21 22:25:11 john-pc kernel: [   13.072507] nouveau 0000:01:00.0: disp: head-1: supervisor 2.0
May 21 22:25:11 john-pc kernel: [   13.072509] nouveau 0000:01:00.0: disp: head-1: nothing attached
May 21 22:25:11 john-pc kernel: [   13.072511] nouveau 0000:01:00.0: disp: outp 01:0000:0302: release DAC-1
May 21 22:25:11 john-pc kernel: [   13.072512] nouveau 0000:01:00.0: disp: outp 03:0000:0304: acquire DAC-2
May 21 22:25:11 john-pc kernel: [   13.072514] nouveau 0000:01:00.0: disp: outp 00:0002:03c1: acquire SOR-0
May 21 22:25:11 john-pc kernel: [   13.072515] nouveau 0000:01:00.0: disp: head-0: supervisor 2.1 - 65000 khz
May 21 22:25:11 john-pc kernel: [   13.072525] nouveau 0000:01:00.0: disp: head-1: supervisor 2.1 - 65000 khz
May 21 22:25:11 john-pc kernel: [   13.072528] nouveau 0000:01:00.0: disp: head-0: supervisor 2.2
May 21 22:25:11 john-pc kernel: [   13.072529] nouveau 0000:01:00.0: disp: head-0: to SOR-0
May 21 22:25:11 john-pc kernel: [   13.072582] nouveau 0000:01:00.0: disp: head-1: supervisor 2.2
May 21 22:25:11 john-pc kernel: [   13.072583] nouveau 0000:01:00.0: disp: head-1: to DAC-2
May 21 22:25:11 john-pc kernel: [   13.072591] nouveau 0000:01:00.0: disp: outp 03:0000:0304: missing IEDT for 0000:0204
May 21 22:25:11 john-pc kernel: [   13.922322] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   14.922317] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   15.048184] nouveau 0000:01:00.0: DRM: core notifier timeout
May 21 22:25:11 john-pc kernel: [   15.922310] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   16.922305] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   17.048127] nouveau 0000:01:00.0: DRM: base-0: timeout
May 21 22:25:11 john-pc kernel: [   17.922291] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   18.922277] nouveau 0000:01:00.0: therm: FAN target request: 36%
May 21 22:25:11 john-pc kernel: [   19.048074] nouveau 0000:01:00.0: DRM: base-1: timeout
May 21 22:25:11 john-pc kernel: [   19.048877] [drm:drm_update_vblank_count [drm]] updating vblank count on crtc 0: current=1, diff=0, hw=0 hw_last=0
May 21 22:25:11 john-pc kernel: [   19.049075] [drm:drm_update_vblank_count [drm]] updating vblank count on crtc 1: current=1, diff=0, hw=0 hw_last=0
May 21 22:25:11 john-pc kernel: [   19.049084] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 616b40 [ IBUS ]

И если это действительно так, то ситуация «не работает на частично повреждённых картах» - не баг, а скорее фича-реквест. (а nvidia-драйвер например работает, потому что в нём забили на проверку кодов возврата ошибок от железа).

Ещё у меня лежит gtx 550ti (6pin питание), которая по моим расчётам должна была давно отказать, но уже полгода не отказывает, и кроме как на потестить никуда её не употребить. Могу подарить boxberry или лично в московском регионе - как раз из той же серии Fermi - если и на ней воспроизведётся - то точно баг. Если интересно - яндекс-почта с ником galkin.vv

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

решено

GPFault, большое вам спасибо, решено

Можно попробовать написать явным образом video=VGA-1:d чтоб он выключился

именно это и нужно было сделать
таким образом, получаем итоговую строку параметров вида

video=VGA-1:d drm.edid_firmware=edid/1920x1080.bin

правда, здесь я не остановился и решил копнуть чуток глубже.


Сам собой возник такой вопрос - можно ли получить 1920х1080 _без_ указания edid вообще?
Оказывается - можно
(как пример - актуально для ноутбуков с разрешениями, для которых в ядре нету edid - 1280x800 1366x768 и тд либо мой случай, когда монитор подключен через переходник)

для этого загружаемся с параметрами video=VGA-1:d video=1920x1080

в моём случае получились такие результаты:
debian stretch выдаёт картинку 1024х768 , которую с помощью xrandr можно «поднять» до 1920х1080
xubuntu 19.04 выдаёт 1400х1050 , которую тоже можно поднять выше через xrandr
fedora-30 сразу выдаёт 1920х1080 (я даже попробовал, справится ли она без video=VGA-1:d -> увы, нет)

во всех трёх случаях

lspci -k |grep -A2 VGA
подтверждает, что вывод идёт через nouveau , а в syslog видно, что вместо edid передаются нули

d00fy ()
Ответ на: решено от d00fy

Раз помогло явное указанние на отключение VGA-1 - скорее всего первопричина глюков - не баги драйвера, а повреждение карты, которая видит монитор, которого на самом деле нет. Хорошо что удалось обойти проблему.

Отсюда же и менее утешительная статистика - подобные выгорания - часто повреждения внутри чипа. И велик шанс, что в ближайшие месяцы оно сдохнет совсем (не будет инициализироваться драйвер или артефакты на экране при использовании драйвера отличного от vesa - даже в 2d на рабочем столе в awesome)

GPFault ()