[yakkety] desktop is black and/or flickering after plugging in a second monitor

Status changed to 'Confirmed' because the bug affects multiple users.

Confirmed. In my case the HDMI display rendered correctly but while plugged in, the desktop on the laptop screen flickered badly (cycling through triple buffers without any glClear()).

Someone who knows better how the background is drawn on unity/compiz should probably comment what changed. With -intel X driver it's still the same, so defaulting to modeset X driver didn't cause this.

Well I used to maintain compiz so have a rough idea.

The desktops is just a window from nautilus that is composited by compiz. The bug probably lays between those. Not Mesa.

Status changed to 'Confirmed' because the bug affects multiple users.

yeah I moved it to mesa until I've verified with the older version, and it's still happening even with -intel + mesa 11.2

Also not a compiz bug. The problem still happens if I replace compiz with metacity.

Workarounds:
  (a) Plug your monitor in before logging in; or
  (b) Kill and restart nautilus.

Given that the desktop selection rectangle still works while the black/flickering is happening around it, it appears the only thing that's broken is nautilus' wallpaper logic.

Is this a modesetting driver issue? I believe I've seen this happen when hotplugging an external monitor. It only happens for me with the modeset driver, though, not the intel driver. The modesetting driver is excellent for some things (eg it doesn't tear on the external monitor like the intel driver does), but it does struggle a bit when changing resolutions and screen layouts (eg every time I log in, it completely unnecessarily changes my laptop screen resolution from 1920x1080 to 640x480 and then back again to 1920x1080).

I thought it was plausible the underlying cause was the modesetting driver but up in comment #4 Timo said that it happens without modesetting and in intel too. So which is true?

I've the impression this is due to nautilus not being properly resized when display size changes (in a VM) or a new one is added...

nautilus -q

and starting the filemanager again should fix this.

Yep, that's one of two workarounds mentioned in comment #10.

Whatever the logic in nautilus listening for xrandr display layout changes is, is what seems to be broken. It should be reconfiguring itself when xrandr reports the displays have changed.

GTK or nautilus itself somehow changed the order that things are realized in, which broke an assumption in nautilus that this would happen after the widget was constructed.

I'm fixing this by explicitly calling the signal handler once if the widget is already realized when we connect the signal.

Uploaded

Hello Yung, or anyone else affected,

Accepted nautilus into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nautilus/1:3.20.3-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Status changed to 'Confirmed' because the bug affects multiple users.

It looks like this bug is reproducible in VirtualBox by resizing the guest window. After the nautilus update in yakkety-proposed, the bug is fixed for that use case.

Cool. That would also be the nautilus-in-Xmir wallpaper bug I encountered recently when you resize the desktop window. I thought it was Xmir's fault but it's probably this one.

This bug was fixed in the package nautilus - 1:3.20.3-1ubuntu4

---------------
nautilus (1:3.20.3-1ubuntu4) zesty; urgency=medium

  * debian/patches/ubuntu_revert_no_wallpaper.patch: Ensure that
    widget_realized_cb is always called, as this sets up the signals that set
    things up on monitor change, amongst other things. The constructor might
    be called after the widget is realized, meaning the signal handler doesn't
    fire (LP: #1626935)

 -- Iain Lane <email address hidden> Thu, 27 Oct 2016 11:15:35 +0100

Perhaps someone would like to verify the SRU?

Verified bug is fixed on yakkety using nautilus 3.20.3-1ubuntu3.1

Although I saw some concerning artifacts when running zesty in a VirtualBox VM the other day (and resizing the window). Those might have been caused by this fix(?). Needs investigating.

This bug was fixed in the package nautilus - 1:3.20.3-1ubuntu3.1

---------------
nautilus (1:3.20.3-1ubuntu3.1) yakkety; urgency=medium

  * debian/patches/ubuntu_revert_no_wallpaper.patch: Ensure that
    widget_realized_cb is always called, as this sets up the signals that set
    things up on monitor change, amongst other things. The constructor might
    be called after the widget is realized, meaning the signal handler doesn't
    fire (LP: #1626935)
  * debian/control{,.in}: Update Vcs-Bzr for yakkety

 -- Iain Lane <email address hidden> Thu, 27 Oct 2016 11:31:53 +0100

The verification of the Stable Release Update for nautilus has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

I also saw artefacts this morning all along the bottom 10% of the desktop background on the laptop monitor (the launcher was rendered without issues). I'm not sure what triggered it, but I had resumed the laptop and plugged in a new monitor earlier in the morning. Killing nautilus and restarting it fixed the problem.

Rocko (rockorequin), you may be affected by another bug outside of the scope of this report. Hence:

1) Are you referring to a physical, or virtual machine?
2) Are you using Ubuntu 16.10 or some other version?
3) Do you have any PPA/3rd party software installed or is it the default configuration?

This also fixes a defect we are seeing in a VMWare guest with Ubuntu 16.10. The issue was wallpaper does not get resized when changing to a higher desktop resolution, leaving a black border around the wallpaper, and corruption occurs when when dragging a window over that black border.

@Christopher:

1) It's a physical machine (my laptop).

2) I'm using Ubuntu 16.10.

3) Graphics-wise, it's a standard installation except for the 4.9-rc3 kernel from mainline and a PPA for nvidia graphics drivers (but I wasn't using the nvidia card at the time this happened, it was all on the Intel GPU).

I only mentioned it because it looked exactly like what this bug would have looked like if the laptop screen had been resized to a larger vertical resolution, say from 1920x900 to 1920x1080, and because just like this bug, killing and restarting nautilus fixed it (and I *was* already running the updated nautilus 1:3.20.3-1ubuntu3.1).

I haven't seen it happen again, though, so it's not worth following up on at this stage since I can't readily reproduce it.

Was this tested with HiDPI? On fully updated VM (zesty) with scaling-factor set to 2 initially window size is correct, but after resizing VM, nautilus desktop window is 1/4 from size it should have.

I think that I have same problem also on my main pc (also zesty) - desktop window is only 1/4 after resolution changes. Restarting nautilus "fixes" problem until next resolution changes.

Alright, sounds like there's still work to do.

Alberts, please log a new bug describing the remaining issue so it's more clearly still open :)
Just run: ubuntu-bug nautilus
Or if that fails then: https://bugs.launchpad.net/ubuntu/+source/nautilus/+filebug

Done, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1645701