могу предоставить логи

с этого надо было начать

логи большие, поэтому загрузил сразу одним архивом 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

покупки dvi-кабеля

Но в этом мониторе есть DVI, какой смысл страдать? Это самое простое и лучшее решение проблемы.

В твоем DVI-выходе нет аналогового сигнала. Смирись.

[ 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

В твоем DVI-выходе нет аналогового сигнала. Смирись.

однако под оффтопиком у меня 1920x1080, пусть себе и с драйверами от nvidia

F10

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

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

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

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

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

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

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

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

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

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

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

F10

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

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

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

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

проверил два варианта
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, как знать)

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

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

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

нужно понять как включить 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...

увы, никак

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 и прочее в таком духе никаких изменений не даёт

а чем можно проверить 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, я тут придумал кое-что повеселее

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

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

вывод?

Про ключ –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.

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

openssh поставь и по сети терминал хотя бы со смарта можно получить

загрузился с помощью
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, то есть программно получить больше информации уже нельзя)

пока не забыл

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

Option «ReprobeOutputs» «boolean»

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

Посмотрел логи, наиболее информативный - 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, большое вам спасибо, решено

Можно попробовать написать явным образом 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

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

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