Hi folks,
there seems to be no method to enforce a specific output for the Nouveau
kernel module and to override the auto-detection.
The problem here persists for two systems behind a KVM switch (an ATEN
CS22D) that is not recognized as a valid monitor by the current
auto-detection algorithm.
I tried the following:
*) Enforce a correct EDID even without a monitor connection by kernel
parameters:
drm_kms_helper.edid_firmware=edid/edid.bin
The edid is validated correctly (with parse-edid) and stems from the
monitor. I also validated (in the kernel log and by checking
/sys/modules/drm-kms-helper/parameters/edid-firmware) that the edid was
loaded.
Still, if the monitor is not connected at boot time, the frame buffer
remains at 1024x768, and Xorg does not display anything at all.
The relevant section in xorg.conf is as follows:
Section "Device"
Identifier "NVIDIA"
Driver "nouveau"
# BusID "PCI:6:0:0"
Option "Monitor-DVI-I-1" "SyncMaster"
EndSection
so I'm enforcing output on DVI-I-1, which is the name of the connection
according to xrandr.
*) I also tried the "video" kernel parameter, namely "video=DVI-I-1:e".
According to the kernel log, this force-enables the DVI-I-1 output (it
was recognized correctly), but if I insert it into kernel command line,
I get *no image at all* regardless whether I connect the monitor at boot
time or not. Supposedly, it places the VGA console on the DVI-I-1
output, and hence locks out the nouveau frame buffer.
This is a rather aged FX 5200 Nvidia card, which is no longer supported
by the proprietary driver (which, otherwise, worked fine and included an
option in xorg.conf to enforce the DVI-I-1 output).
The kernel is the longterm 4.1.15 support kernel - which otherwise works
"fine enough" (3D acceleration is broken, i.e. etracer does not render
at all, but that's a different problem).
Anything else I should try?
Greetings,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel