Screen resolution no longer works

[Jeroen T. Vermeulen]

My display's native resolution is 2560×1440 pixels. Prior to, I think, Saucy I could only reach this resolution by adding it using xrandr, and then calling xrandr on boot/login to select that resolution. The Display preferences did not show any higher options than 1920×1200.

In Saucy, the native resolution just worked, and I could stop using xrandr. It also worked in Trusty in the alpha releases, up to (and I think including) beta-1. But today (this is not an April's fool, is it?) I rebooted after an upgrade, and found myself back in 1920×1200. Again, the Display preferences list that resolution as the highest possible. But this time, attempts to ‘xrandr --addmode’ my native resolution failed.

The error message wasn't very helpful; I'll try to reproduce it later but it throws my display into yet a lower resolution that's hard to work with.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xorg 1:7.7+1ubuntu8
ProcVersionSignature: Ubuntu 3.13.0-20.42-generic 3.13.7
Uname: Linux 3.13.0-20-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.14-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Tue Apr 1 09:59:00 2014
DistUpgraded: 2014-01-22 17:01:10,909 DEBUG enabling apt cron job
DistroCodename: trusty
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd Device [1458:d000]
InstallationDate: Installed on 2013-08-03 (240 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Gigabyte Technology Co., Ltd. Z87-D3HP
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-20-generic root=UUID=12085c8d-328f-4c75-a04c-184c592f61ee ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to trusty on 2014-01-22 (68 days ago)
dmi.bios.date: 05/16/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F4
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z87-D3HP-CF
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd05/16/2013:svnGigabyteTechnologyCo.,Ltd.:pnZ87-D3HP:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnZ87-D3HP-CF:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: Z87-D3HP
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.11+14.04.20140328-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.0-1ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.0-1ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.15.0-1ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.910-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2
xserver.bootTime: Tue Apr 1 09:52:36 2014
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 16510
 vendor DEL
xserver.version: 2:1.15.0-1ubuntu7

[Jeroen T. Vermeulen (jtv)]

I'm trying the BIOS upgrade as per those instructions. The only applicable option was the flashrom one, which seems to have hosed my BIOS. It's still on now, but I won't be able to boot it again. Kindly mark this bug New again to give me time to recover and retry!

[Jeroen T. Vermeulen (jtv)]

Okay, I got out of that situation with the help of the flashrom people. My BIOS is now updated.

It helped a bit in that I can now define and add my resolution again using xrandr. It won't stay added though: I need to define and add it every time I boot. Otherwise, the resolution is not in the Displays settings dropdown.

The dmidecode output is:

F7
08/12/2014

[penalvch (penalvch)]

Jeroen T. Vermeulen, could you please test for this via http://cdimage.ubuntu.com/daily-live/current/ and advise to the results?

[Jeroen T. Vermeulen (jtv)]

Something happened to this bug's conversation: the message asking me to upgrade the BIOS has been removed/hidden.

[Jeroen T. Vermeulen (jtv)]

I first upgraded to 14.10; that didn't change anything. Trying 15.04 now.

[Jeroen T. Vermeulen (jtv)]

 No change in 15.04. I can add the resolution with xrandr, and after that I can use it. But after reboot, I have to do it again.

The upgrade got stuck with a black screen and no networking, but I eventually got out of it with the "apt-get dist-upgrade" dance from the console. I hope that hasn't messed things up.

It may matter that I've got the monitor's DVI port hooked up to my computer's HDMI port. It was the only way to get things working: the monitor doesn't support its full native resolution on HDMI, and the Haswell builtin graphics only supports the resolution on HDMI. But, the hardware can do it and it used to work from the settings GUI without hackery.

[penalvch (penalvch)]

Jeroen T. Vermeulen, could you please advise what packages were upgraded precisely on 2014-04-01 that correlates to this issue?

[Jeroen T. Vermeulen (jtv)]

According to the dpkg.log for that date, quite a lot: libc-bin for amd64. Also gcc-4.8, gcc-4.9, along with g++, cpp, libgcc1, libstdc++6 etc, for amd64 and i386; and libitm1, libgomp1, libgfortran3, libasan0, libatomic1, libtsan0, libquadmath0, libthumbnailer0, apport, apport-gtk, python3-problem-report, python3-apport, binfmt-support, dh-apport, libgtk2-perl, python-boto, python-lxml, python3-lxml, unity-webapps-qml, mobile-broadband-provider-info, python-keystoneclient,

The day before I upgraded among other things libffi6 (for i386 and amd64) and libffi-dev, dconf-gsettings-backend, dconf-service, libdconf1, various dconf tools and frontends, libglib2.0-*, libunity-control-center1 and unity-control-center, libido3-0.1-0, lxc and related packages, libapparmor1 and apparmor, libqt5positioning5, libunity-gtk3-parser0, openjdk-7 and icedtea-7, ubuntu-release-upgrader and update-manager, libcompizconfig0, compiz-gnome, compiz-plugins-default, libdecoration0, compiz-core, compiz, im-config, kerneloops-daemon, indicator-*, unity-scope-*, libreoffice, unity, libunity-core-6.0.9, unity-services, ubuntu-mono, libvirt, the kernel, and dh-apparmor.

[penalvch (penalvch)]

Jeroen T. Vermeulen, which kernel version specifically was updated (i.e. from what version to what version)?

[Jeroen T. Vermeulen (jtv)]

The version that was installed on March 31 was 3.13.0.20.24. The version I uninstalled right after that was 3.13.0.18.38.

[penalvch (penalvch)]

Jeroen T. Vermeulen, could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-3.XY-rcZ

Where XY and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-3.XY-rcZ

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Jeroen T. Vermeulen (jtv)]

The latest upstream version I found there was v4.0-rc4-vivid. It boots, but it doesn't fix the problem.

[penalvch (penalvch)]

Jeroen T. Vermeulen, could you please boot into a kernel from Saucy following https://wiki.ubuntu.com/Kernel/KernelBisection and advise if this issue is still reproducible?

[Jeroen T. Vermeulen (jtv)]

Trying 13.11.0-17. There was a problem while installing linux-headers though... "fwts-efi-runtime-dkmis 15.03.00-0ubuntu1: fwts-efi-runtime-dkms kernel module failed to build." Somewhere along the way it said:

run-parts: executing /etc/kernel/postinst.d/dkms 3.11.0-17-generic /boot/vmlinuz-3.11.0-17-generic
ERROR (dkms apport): kernel package linux-headers-3.11.0-17-generic is not supported
Error! Bad return status for module build on kernel: 3.11.0-17-generic (x86_64)
Consult /var/lib/dkms/fwts-efi-runtime-dkms/15.03.00/build/make.log for more information.

That's being reported separately. Meanwhile I'll see if I can get it to run...

[Jeroen T. Vermeulen (jtv)]

Okay, I got a seemingly successful install of the last Saucy kernel. But it's not working very well: I get a super-low-res login screen, and the system doesn't respond to keyboard or mouse. (It does notice the power button, so it's not frozen). This happens both with the default boot on that kernel version, and with the Upstart boot.

So I can't say for certain whether things would still work correctly with a Saucy kernel. It wasn't this broken at the time!

[penalvch (penalvch)]

Jeroen T. Vermeulen, working at it from a different angle, would you be able to boot into a Saucy environment, and then test the latest mainline kernel?

[Jeroen T. Vermeulen (jtv)]

I could temporarily swap out the hard drive and install Saucy on the spare. More after the weekend.

[Jeroen T. Vermeulen (jtv)]

Well, I did some bisecting but the results are disappointing. Actually I ended up trisecting. On Saucy, kernel...

3.11.0-12 was OK. Recognised my full native resolution and enabled it by default. Wonderful.

3.11.0-13 to 3.11.0.24 inclusive were completely messed up. They booted in some ultra-low resolution and were not responsive to my mouse and keyboard.

3.11.0-25 wasn't available in the archive.

3.11.0-26 gives me a maximum resolution of 1920 by 1200, which is the same behaviour I observed with 14.04, 14.10, and the daily 15.04 test versions.

So it looks like between 3.11.0-12 and 3.11.0-13 something broke, and it took until 3.11.0-26 to get it more or less working again, but the old functionality was never completely regained. I guess that means there are no easy answers for this one.

[Jeroen T. Vermeulen (jtv)]

Hurray, the problem just got a little worse!

After the upgrade to kernel 3.19.0-14.14, when I define my monitor's native resolution using xrandr, I get the right *resolution* but still not the right number of *pixels*. So I'm getting (as far as I can see) one logical pixel per physical pixel on the monitor — but the right-hand and lower edges stay black. It's not just the background picture; I can't move the mouse pointer there or make windows extend into it.

However, after changing the resolution in the System Settings UI and then canceling the change, I finally get a full screen in native resolution like I used to with the previous kernel version.

[Jeroen T. Vermeulen (jtv)]

Correction: that last upgrade was *from* 3.19.0-14.14, not *to* it. It was the upgrade to 3.19.0-15.15.

[Jeroen T. Vermeulen (jtv)]

After another reboot this effect seems to have gone away. So I still don't have my native resolution available by default, but at least I can get it back by defining it with xrandr.

[Jeroen T. Vermeulen (jtv)]

Marking this bug as "Confirmed" to avoid timeout. It was marked Incomplete pending testing against Saucy, but as of a few months ago the results are shown above.

[penalvch (penalvch)]

Jeroen T. Vermeulen, could you please test the latest mainline (kernel 4.1-rc7) and advise to the results?

[Jeroen T. Vermeulen (jtv)]

No Tried 4.1-rc7. No change.

[Jeroen T. Vermeulen (jtv)]

Tried 4.1-rc8 as well for good measure. Still no improvement. Highest resolution offered in the System Settings is 1920×1200.

[penalvch (penalvch)]

Jeroen T. Vermeulen, the next step is to fully commit bisect from kernel 3.13.0.18.38 to 3.13.0.20.24 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Jeroen T. Vermeulen (jtv)]

Using the ubuntu-vivid kernel branch, 3.13.0-18.38 works OK.

That branch has no tag Ubuntu-3.13.0.20.24 or Ubuntu-3.13.0-20.24. The closest tags I see are Ubuntu-3.13.0-19.40 and Ubuntu-3.13.0-20.41. I'll try 3.13.0-19.40 next.

[Jeroen T. Vermeulen (jtv)]

3.13.0-19.40 also works OK! So it broke sometime after that.

I'm now trying to find 3.13.0-20.24 in one of the kernel branches from before Vivid. It's not in the Trusty branch. I can't get the Quantal, Raring, or Saucy ones, presumably because those releases are no longer supported. Downloading the Precise and Utopic ones, but it'll take a few more hours so I'll have to get back to it tomorrow.

[Jeroen T. Vermeulen (jtv)]

The Precise kernel repository finished downloading, but it doesn't have 3.13.0-20.24. It has 3.13.0-19.39 and 3.13.0-20.41, nothing inbetween. Pinning my hopes on the Utopic branch...

[Jeroen T. Vermeulen (jtv)]

Nope, the Utopic kernel branch only has 3.13.0-19.40 and 3.13.0-20.41, nothing inbetween.

So, all I know is up to and including 3.13.0-19.40 it still works OK. The problem must have been introduced later than that.

[Jeroen T. Vermeulen (jtv)]

Oh, one other thing: with the older kernels I can play AssaultCube again! I couldn't really do that with the current Vivid kernels because the frame rate was too low. Reported frame rate would be around 60 fps, but it looks more like 10 fps. With these old kernels it plays smoothly.

[Jeroen T. Vermeulen (jtv)]

Once again: with the given instructions I can't bisect kernel commits any further. Is there another way to obtain the kernel source versions we need?

Marking as Confirmed again until then, to avoid this bug timing out.

[penalvch (penalvch)]

Jeroen T. Vermeulen, instructions for commit bisecting are fully defined in the previously provided article. So, it is unclear how precisely you can't find kernel sources.

[Jeroen T. Vermeulen (jtv)]

Read back and it will become clear.

[Jeroen T. Vermeulen (jtv)]

If you don't have time to read what I wrote, or if something I wrote is not clear, just say so and I will understand. Let's not get caught in the endless Confirmed/Incomplete circle.

I'll summarise what I said before, to make it easier to digest:

You asked me to bisect between 3.13.0.18.38 and 3.13.0.20.24.

That latter revision is not tagged in any of the Ubuntu kernel branches I could still find. I tried all branches from Precise to Vivid, but many of them are no longer available.

The closest I could find was 3.13.0-19.40. The problem started sometime *after* that version.

And then we were stuck at the point where I asked for suggestions on where to find the missing version(s) so I can bisect further. Any ideas?

[penalvch (penalvch)]

Jeroen T. Vermeulen, just to advise, you asking follow up questions doesn't make this less Incomplete, or more Confirmed. Until this is bisected, it's most difficult for a developer to attend to this, let alone have this Triaged and upstreamed.

Despite this, I want to confirm you have read the entire bisect article in its entirety, as it contains answers to questions like this.

[Jeroen T. Vermeulen (jtv)]

Thanks for following up. I read most of that document, but it's difficult in places. My understanding is that what you're asking me to do is what's described under “Commit bisecting Ubuntu kernel versions,” correct? That's the only part of the main page (excluding the FAQ below) that seems to apply.

But I don't see anything on the page addressing the question of “what if you want to bisect revisions that are not tagged in the branch.” Are you saying you don't want me to bisect Ubuntu kernels in that case, and go to the upstream kernels instead?

[penalvch (penalvch)]

Jeroen T. Vermeulen, as advised in https://wiki.ubuntu.com/Kernel/KernelBisection#Map_Ubuntu_kernel_to_mainline_kernel_for_mainline_bisection it would be best to switch to commit bisecting the mainline kernel.

[Jeroen T. Vermeulen (jtv)]

Thanks. Could you also update that section? It says that it applies in two situations, but it never actually lists those two situations. I *think* (but without already knowing of course I can't be sure) that it's meant to refer to a list of three headings, “BISECTING: A MERGE BASE MUST BE TESTED” etc. I don't see any mention of the situation I ran into, so it may be worth adding that too.

[Jeroen T. Vermeulen (jtv)]

This is getting awkward. The upper-bound version you wanted me to bisect is also missing from the Ubuntu/upstream version mapping. So even if I want to bisect upstream versions I still have the same problem. Are you sure you gave me the correct versions for bisection? Maybe you meant 3.13.0-20.42 instead of 3.13.0.20.24?

[Jeroen T. Vermeulen (jtv)]

It just got a bit weirder.

I've got my custom xrandr-defined 2560×1440 resolution going. But for purposes like window placement, resizing windows, and maximising windows, the UI seems to think it's 1920×1080 or thereabouts.

So if I open a whole bunch of editor windows from the shell, they all appear in (and eventually fill up) the upper-left part of the screen that looks like it's about 1920×1080 pixels large. I can move a window out of that zone, but I can't resize its lower or right-hand edges outside of it. If I move a window over the edge and then try to resize the window, the edge(s) I'm resizing immediately jump back to fall within that zone.

When I move a window completely outside the zone and try to resize it, really strange things happen. A terminal window outside the zone immediately disappears when I try to resize its right-hand edge, as if it's been closed. I can get it back by clicking on the terminal icon in Unity's icon bar, but it's very narrow, and it looks to be dead! It's got a piece of my desktop background in it, and nothing I do convinces it to repaint itself. When I widen it, I just get to see more background, or whatever else was in its path, plus some pollution from the resizing UI. I can still close it with ctrl-d though. I can still type commands into the shell I guess, but "clear" doesn't help.

[Jeroen T. Vermeulen (jtv)]

This last weird effect was transient; it went away after a reboot.

[Jeroen T. Vermeulen (jtv)]

Hello? Any corrections for that revisions range you wanted me to bisect?

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]