Bug 853350

Hi, would you please provide the yast logs? See here: http://en.opensuse.org/openSUSE:Bugreport_YaST

Created attachment 570405 [details]
YaST2 log

*** Bug 853341 has been marked as a duplicate of this bug. ***

Do you have an option like video=1024x768 in /proc/cmdline? Or, even better,
can you attach /proc/cmdline?

Created attachment 572306 [details]
/proc/cmdline

Thanks!

As Xorg works, I'd suspect this is KMS having mode setting/monitor detection trouble.

Created attachment 572319 [details]
cmdline with manually added video=1024x768

I added video=1024x768 manually at boot start by 'e' in grub menu, see attachment. The monitor still shows 'CANNOT DISPLAY THIS VIDEO MODE' while booting and with Ctrl+Alt+F1.

After adding
"
video=VGA-1:1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin
"
to kernel boot parameters it works as expected.
"
video=VGA-1:1024x768
"
is not sufficient.

So, the culprit is a buggy EDID from the monitor?  If so, let's close the bug.

I don't think it is so simple. Xorg chooses the correct screen resolution with this monitor.
The problem is that boot parameter video=1024x768 does not switch to 1024x768 but to some higher resolution. It is especially a problem while booting with the install DVD and selecting 1024x768 at the boot menu. This doesn't work too, so the boot process is not visible on screen because of 'CANNOT DISPLAY THIS VIDEO MODE'. IIRC the install-GUI later switches to correct 1024x768.

If you boot with "video=1024x768" and "nomodeset" options, does the problem still happen?  I guess it's KMS who ignores the plain video=1024x768 option.  It requires more exact setting as done in comment 8.

If my guess is correct, the option works unless KMS is kicked off.

video=1024x768 nomodeset -> 'CANNOT DISPLAY THIS VIDEO MODE'
video=VGA-1:1024x768 nomodeset -> 'CANNOT DISPLAY THIS VIDEO MODE'

video=VGA1-1:* is useless for nomodeset, since nomodeset option makes KMS inactive.  And I forgot that vesafb doesn't take video option for its resolution.  The resolution has to be specified via vga option, such as vga=0x318.

That said, video=1024x768 doesn't help much in your use case, unfortunately.

OK, so the screen resolution selection in the bootloader setup is rather confusing, thus it should be dropped or rewritten.  As this is no kernel bug, I reassign it back to YaST guys.

What do you mean, confusing?

video=1024x768 should set the resolution, or not?

It won't work any longer in general, especially when KMS is used.  And, if KMS is deactivated and vesafb is used, and it doesn't take this option, either.
That said, video=1024x768 is applicable for very limited use cases.

Of course, it'd be great if any one double-checks whether I stated correctly...

Well, 'video' was an option introduced _by_ KMS. This is all about setting the video mode for KMS; we're not talking about vesa here.

So, how exactly should the mode be set, then?

For enabling the resolution in KMS, you must specify *each* output name such as VGA-1, etc.  And, more badly, the output name isn't consistent over drivers.
That being said, it's almost impossible to set the mode in the boot option properly for KMS unless you know the exact driver and the exact video output to control beforehand.

IMO, this option could be dropped, or at least, write some excuse in the help text that it may not work reliably in all cases.

Please remember that "video=VGA-1:1024x768" does not work in the test case, "video=VGA-1:1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin" is necessary. I attached another monitor which can display the KMS selected resolution. Same result, "video=VGA-1:1024x768" does not switch the console resolution.
Has anybody managed to switch console resolution by boot parameter? How can we switch console resolution if the "video=" option will be removed? "drm_kms_helper.edid_firmware=xxx" is not very convenient, especially if it is not possible to google the correct syntax because the monitor shows 'CANNOT DISPLAY THIS VIDEO MODE'. ;-)

And how should the situation be handled in case of installation by booting from installation DVD by a ordinary user?

(In reply to comment #19)
> Please remember that "video=VGA-1:1024x768" does not work in the test case,
> "video=VGA-1:1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin" is
> necessary. I attached another monitor which can display the KMS selected
> resolution. Same result, "video=VGA-1:1024x768" does not switch the console
> resolution.

It's because your monitor gives the bogus EDID :)  It's rather a hardware problem specific to your monitor, and the EDID override is merely a workaround.  So, it's not required normally.

How can you say that? Xorg seems to get the resolution right. So it may well be a KMS driver bug.

Why do you think it is not required that KMS accepts that I want to work with a specific console resolution? Are you sure that KMS always knows better than the user what the user needs? Sometimes a specific console resolution is necessary.
I am not sure with the "bogus EDID". Xorg selects a useful resolution for the "bogus" monitor and console resolution switching does not work with another not bogus monitor.

The mode is controlled by KMS solely.  If the resolution works with Xorg, it's handled also by KMS, too.  In other words, the same mode must be available for the framebuffer, too.

The fact that simple "1024x768" doesn't work with the given monitor implies that there are multiple 1024x768 mode definitions and the default one the kernel parameter took is bogus.  Xorg might have chosen another one accidentally or heuristically.  But it doesn't mean any KMS bug.  As long as the modes are taken from EDID, all they should be applicable.  If not, it's a fault of hardware.

We will never know unless we look at the actual edid from the monitor.

That's true.  There is a very slight possibility where the KMS parsed EDID wrongly.  But I bet this is really low; otherwise we'd have hit more bugs.

The other possible two cases are:
A. All EDID entries look correct
B. Some EDID entries have wrong values

In case A, it's the hardware fault who advertizes the modes that don't work.
In case B, it's the hardware fault who gives the wrong values.

KMS does not select 1024x768. If I unplug the 1024x768 monitor after booting and connect a CRT-monitor, a higher resolution is visible. The question remains:
Should "video=VGA-1:1024x768" switch console resolution to 1024x768?
Currently it will not, independent if the "bogus" LCD or the CTR-monitor is connected while booting. If it should switch to 1024x768, does it work for you?

The video option doesn't restrict the modes.  It just sets the default mode to be set initially.

> The video option doesn't restrict the modes.  It just sets the default mode to
> be set initially.
So the answer of
"Should "video=VGA-1:1024x768" switch console resolution to 1024x768?" is:
"Yes, providing "video=VGA-1:1024x768" as kernel parameter should switch console resolution to 1024x768, it does work for me."?

No, it doesn't *switch*.  It merely picks up the very first mode to be used for VGA-1 output (if used as framebuffer).  That's what I wrote as it doesn't restrict.  The higher resolutions are still available, and allowed to be picked up.

And, this option won't affect any other outputs.  If there are other outputs, other higher resolution might be taken fro the console, too.

All that implies that the video= option doesn't work reliably for your purpose, unfortunately.  It neither forces or restricts to the given mode.

How do you set the console resolution (the console which will be showed by pressing Ctrl+Alt+F1 for example) to 1024x768?
What does "It merely picks up the very first mode to be used for
VGA-1 output (if used as framebuffer)" mean? Does it mean "The mode which will be picked up for VGA-1 output (if used as framebuffer) is independent of the "video=VGA-1:1024x768" kernel parameter."?
What is the purpose of the "video=" parameter then? I am very confused, sorry.

Well, the situation is complicated when there are multiple outputs.

In principle, video=1024x768 would work as long as all outputs are connected at boot time, and the mode 1024x768 from EDID is really valid.  But, the output that is plugged later isn't always considered, and if the given mode doesn't match with the available size, it doesn't work, either.

You should check what outputs are really available on your system at the boot *without* any video and EDID override options.  Check /sys/class/drm/card0-*/modes.  For specifying 1024x768, all active outputs should contain this resolution, too.

If there is 1024x768, and if it gives the wrong output the monitor can't accept, it's the fault of the monitor, as already mentioned.  And your EDID override is a workaround for that.

The video option without the output prefix is a hint, which is taken as the default value when no other specific setups are present.  There can be multiple ways to set up the mode, and that can be the reason if the simple video=1024x768 doesn't work, too.  The "VGA-1:" prefix specifies the output, so that it has a higher priority to be picked up.  (But still you can set up other modes, like X does.)

> You should check what outputs are really available on your system at the boot
> *without* any video and EDID override options.  Check
> /sys/class/drm/card0-*/modes.

Boot with LCD-monitor connected:
/sys/class/drm/card0/card0-VGA-1/modes:
"
1024x768i
1024x768
1024x768
1024x768
1024x768
832x624
800x600
800x600
800x600
800x600
640x480
640x480
640x480
640x480
640x480
720x400
"
/sys/class/drm/card0/card0-DVI-D-1/modes:
"
"
/sys/class/drm/card0/card0-SVIDEO-1/modes:
"
"

Boot with CRT-monitor connected:
/sys/class/drm/card0/card0-VGA-1/modes:
"
1280x1024
1024x768
1024x768
1024x768
832x624
800x600
800x600
800x600
640x480
640x480
640x480
720x400
"
/sys/class/drm/card0/card0-DVI-D-1/modes:
"
"
/sys/class/drm/card0/card0-SVIDEO-1/modes:
"
"

Oh, so the driver goes for the interlaced mode?

Unless specified with "i" suffix, no interlace mode should be enabled, AFAIK.

OK, let's start from the beginning.  Suppose the outputs above are the result without any extra boot option.  Now, plug the LCD monitor and boot with video=1024x768 option only.  This results in "CANNOT DISPLAY THIS VIDEO MODE", right?  If so, boot with drm.debug=0x0e option together with video=1024x768 option, and attach the whole kernel log.

As you can see, there are multiple definitions for the same resolution, and some of them might be broken.  Either EDID is broken or the VESA compatible mode isn't supported by the monitor (unlikely).  But it's hard to tell without any real logs...

If I connect the CRT-Monitor after booting with the LCD-monitor where the LCD monitor shows 'CANNOT
DISPLAY THIS VIDEO MODE' the CRT-monitor shows a higher resolution than 1024x768.

Confusing...  I didn't ask about CRT monitor.  Does LCD monitor work as is?
If so, forget about LCD monitor.

Instead, connect only CRT monitor from the beginning and boot up only with "video=1024x768 drm.debug=0x0e 3" options.  This will boot in runlevel 3.
Does it result in "CANNOT DISPLAY THIS VIDEO MODE", right?

If so, login from another machine (or via typing blindly) to get the kernel boot message at this moment (the output of "dmesg" command), and attach the output to bugzilla (don't paste).

Created attachment 582638 [details]
var/log/messages with drm.debug=0x0e

Comment #36 is answer for #34.

Answer for #35:
> Now, plug the LCD monitor and boot with
> video=1024x768 option only.  This results in "CANNOT DISPLAY THIS VIDEO MODE",
> right?

Correct.

> If so, boot with drm.debug=0x0e option together with video=1024x768
> option, and attach the whole kernel log.

See uploaded messages.gz.

The driver seems trying to connect with 1024x768i.  And this is apparently what your monitor doesn't like.  Interesting, I thought the interlace flag is considered for the mode string validation, but it seems that it just takes the matching resolution.

In anyway, the reason for non-working LCD output should be this.  The monitor gives wrongly a mode that itself doesn't support.

> If so, login from another machine (or via typing blindly) to get the kernel
> boot message at this moment (the output of "dmesg" command), and attach the
> output to bugzilla (don't paste).

See uploaded dmesg.gz.

Created attachment 582641 [details]
dmesg result

> The driver seems trying to connect with 1024x768i.

And why shows the CRT-Monitor an image with resolution > 1024x768 in this state and no 1024x768i? And why does booting with the CRT-monitor and "video=VGA-1:1024x768" not show a 1024x768 image but something higher (possibly 1280x1024)?

You reconnected the monitor?  Then the mode will be fully reset and the original mode isn't kept, especially since 1024x768i doesn't match with the CRT...
You can see more details with drm.debug=0x0e.  But I see no trace of that action.

That being said, attach the dmesg output before and after re-connecting from LCD to CRT.

Created attachment 582645 [details]
dmesg results

dmesg_lcd1: booted with LCD, LCD connected.
dmesg_crt: LCD disconnected, CRT connected.
dmesg lcd2: CRT disconnected, LCD connected.

There is no difference between dmesg_lcd1 and dmesg_crt at all.  It means that the VGA hotplug isn't detected properly, thus you had to trigger the detection manually (xrandr does it usually).  Without it, the driver assumes that the same device is connected, thus the interlace mode is kept for CRT, which may result in strange size.

This is what happened in your tests.

> It means that the VGA hotplug isn't detected properly

Yup, I thought the same. ;-)

> thus the interlace mode is kept for CRT, which may result in strange size.

The CRT shows a clear image with more text rows than in 1024x768 mode. I would not expect this in a interlaced 1024x768 mode...

Hm, still strange that there is no kernel log.  If the mode is changed, it must show something when drm.debug=0x0e is set.  Please double-check whether you get any relevant kernel logs when you replug the monitor from LCD to CRT and see the higher resolution.  If really no log is found, it means that there is no mode switch indeed.

Another thing to be tested is to boot with CRT (nor LCD) and "video=1024x768 drm.debug=0x0e 3" options.  Does this result in the error, too?  Attach the log again in this case.

Created attachment 582748 [details]
boot with CRT

- attach CRT
- boot with "video=1024x768 drm.debug=0x0e 3"
- CRT shows 48 text rows -> probably 1024x768
- dmesg >crt1.txt
- disconnect CRT
- connect LCD
- LCD shows 'CAN NOT DISPLAY THIS VIDEO MODE'
- blindly dmesg >lcd.txt
- disconnect LCD
- connect CRT
- CRT shows 48 text rows -> probably 1024x768
- dmesg >crt2.txt

I'll repeat the procedure booting with LCD.

Created attachment 582753 [details]
boot with LCD

- attach LCD
- boot with "video=1024x768 drm.debug=0x0e 3"
- LCD shows 'CAN NOT DISPLAY THIS VIDEO MODE'
- login blindly
- blindly dmesg >lcd1.txt
- disconnect LCD
- connect CRT
- CRT shows black screen
- blindly dmesg >crt.txt
- disconnect CRT
- connect LCD
- LCD shows 'CAN NOT DISPLAY THIS VIDEO MODE'
- blindly dmesg >lcd2.txt

So, CRT works as expected without extra setup?  That's a good start.

There are two things behind your problem:
1. LCD monitor doesn't work as it advertises with the interlace mode
2. Replugging the monitor doesn't trigger the mode reset

1 can be worked around by the edid override.  It's rather the hardware issue.
2 is because the driver doesn't detect the VGA hotplug always, and it doesn't react intentionally.  This is again no bug of the driver.  Usually user-space daemon like gnome-settings-daemon listens to the event and reconfigures the display.  Or, manually, running xrandr on X would trigger the mode probing.

If you can still see the issue with edid override and the manual mode reconfiguring, get the log again with drm.debug=0x0e from the beginning of the procedure.

> 1. LCD monitor doesn't work as it advertises with the interlace mode

Or the video card does not produce a correct interlaced signal. Has this ever been tested?
I suggest that KMS should not pick up an interlaced mode if there are non-interlaced modes of the wanted resolution and if not explicitly requested to use interlaced.

With "video=VGA-1:1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin" the LCD-monitor shows a 1024x768 console.

Yes, the kernel parser behavior could be improved.  But, the current behavior is no bug, per se.  And, yes, interlace mode was tested in the past.

@Takashi Iwai
Why is NEEDINFO set? What do you expect from me?

(In reply to comment #53)
> If you can still see the issue with edid override and the manual mode
> reconfiguring, get the log again with drm.debug=0x0e from the beginning of the
> procedure.

In addition, give the kernel log of "video=1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin 3" options, too.  We need to see exactly why it doesn't work without the output prefix.

With "video=VGA-1:1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin" the
LCD-monitor shows a correct 1024x768 console.

With "video=1024x768 drm_kms_helper.edid_firmware=edid/1024x768.bin" the
LCD-monitor shows a correct 1024x768 console too.

OK, regarding about video option (about the original bug issue), the problem is only about switching between CRT and LCD?

The EDID thing is very like WONTFIX for openSUSE 13.1.  This is the designed behavior although it's suboptimal.  We can improve the behavior but it's for the future upstream kernel.

> OK, regarding about video option (about the original bug issue), the problem is
> only about switching between CRT and LCD?

For me switching between CRT and LCD is no problem because I usually do not replace the monitor in a running system.
The problem is that there is no simple possibility to force KMS to use the not interlaced mode, especially while booting with the OpenSUSE 13.1 install DVD. Anyway, googling the problem most likely will show the "drm_kms_helper.edid_firmware=edid/1024x768.bin" trick to other users now. ;-)

> The EDID thing is very like WONTFIX for openSUSE 13.1.  This is the designed
> behavior although it's suboptimal.  We can improve the behavior but it's for
> the future upstream kernel.

OK.

Below is a patch for improving the drm driver behavior.  I'm going to submit it to the upstream and merge to SUSE kernel git once when it's accepted.

Created attachment 582808 [details]
Patch to improve the cmdline mode parser

The upstream took my patch, so 3.15 kernel will pick up the non-interlace mode properly as default.

FWIW, I also backported the patch to opensUSE 13.1 and SLE12 branches.

openSUSE-SU-2014:0678-1: An update that solves 17 vulnerabilities and has 23 fixes is now available.

Category: security (important)
Bug References: 639379,812592,81660,821619,833968,842553,849334,851244,851426,852656,852967,853350,856760,857643,858638,858872,859342,860502,860835,861750,862746,863235,863335,864025,864867,865075,866075,866102,867718,868653,869414,871148,871160,871252,871325,875440,875690,875798,876531,876699
CVE References: CVE-2013-4579,CVE-2013-6885,CVE-2013-7263,CVE-2013-7264,CVE-2013-7265,CVE-2013-7281,CVE-2014-0069,CVE-2014-0101,CVE-2014-0196,CVE-2014-1438,CVE-2014-1446,CVE-2014-1690,CVE-2014-1737,CVE-2014-1738,CVE-2014-1874,CVE-2014-2523,CVE-2014-2672
Sources used:
openSUSE 13.1 (src):    cloop-2.639-11.7.1, crash-7.0.2-2.7.1, hdjmod-1.28-16.7.1, ipset-6.19-2.7.1, iscsitarget-1.4.20.3-13.7.1, kernel-docs-3.11.10-11.3, kernel-source-3.11.10-11.1, kernel-syms-3.11.10-11.1, ndiswrapper-1.58-7.1, openvswitch-1.11.0-0.25.1, pcfclock-0.44-258.7.1, virtualbox-4.2.18-2.12.1, xen-4.3.2_01-15.1, xtables-addons-2.3-2.7.1

Martin, I have in the past encountered CANNOT DISPLAY THIS VIDEO MODE, and solved it by using video=1024x768@60. I find it hard to believe this bug has 66 comments without already suggesting to try simply appending a refresh rate to the mode.