Bug #12730

Laptop screen with lid closed is configured as the primary display

Added by goupille 2017-06-17 20:27:47 . Updated 2017-09-28 18:52:54 .

Status:
Resolved
Priority:
Low
Assignee:
Category:
Hardware support
Target version:
Tails_3.2
Start date:
2017-06-17
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

when booting Tails 3.0 on a docked laptop with an external monitor, Tails consider the laptop screen as primary, even if the laptop is closed and therefore, the screen is off. In Tails 2.* the display was cloned, allowing the user to set it up.

It seems that Debian-live testing (from 12 june) has the same behavior.

it was reported happening on Dell Latitude E6440 and Dell Lattitude E6410

Subtasks

Related issues

Blocked by Tails - Feature #12732: Upgrade Linux to 4.12 Resolved 2017-06-18
Blocks Tails - Feature #13234: Core work 2017Q3: Foundations Team Resolved 2017-06-29

History

#1 Updated by WMConey 2017-06-18 22:15:56

This behavior also occurs on an HP Elitebook 850 with an HP dock. Looks like Debian 9 / Tails 3.0 see both the laptop screen and the monitor attached to the dock but does not see that the laptop is closed and hence the laptop screen is inactive. Instead, it creates separate desktops for each display.As the “Welcome” display that allows unlocking persistance, etc, is now being shown on an inactive screen it is not possible to properly configure Tails prior to login.

Tails 2.x correctly used the attached monitor as primary during boot when the laptop was closed and docked.

At the very least, Tails 3.0 / Debian should start start with mirroring to all displays so that the welcome screen is accessible.

#2 Updated by intrigeri 2017-06-23 14:12:01

  • Subject changed from Tails should clone the display if multiple monitors are detected to Laptop screen with lid closed is configured as the primary display
  • Category set to Hardware support
  • Status changed from New to Confirmed

I think the new behavior is better than cloning, except a display whose lid is closed should be automatically disabled. Retitling accordingly.

goupille, this seems to clearly be an upstream matter. Where do we draw the line between your work and mine? I propose:

  1. You investigate why GNOME changed behavior this way. I would first look in the changelog for GNOME Shell, Mutter, and gnome-settings-daemon.
  2. You search the web for similar reports (and possibly workarounds) so we avoid reporting a duplicate.
  3. You report back about your preliminary research here.
  4. I’ll handle the next steps, i.e. I’ll report this upstream and will follow-up with them as needed.

Fair enough?

#3 Updated by goupille 2017-06-24 10:01:50

  • Assignee changed from goupille to intrigeri

intrigeri wrote:

> Fair enough?

I’m ok with this :)

> # You investigate why GNOME changed behavior this way. I would first look in the changelog for GNOME Shell, Mutter, and gnome-settings-daemon.
> # You search the web for similar reports (and possibly workarounds) so we avoid reporting a duplicate.
> # You report back about your preliminary research here.

ok, so, this behavior was reported on other distributions, like fedora :

https://bugzilla.redhat.com/show_bug.cgi?id=1430259),

and on gnome bug tracker :

https://bugzilla.gnome.org/show_bug.cgi?id=782380

It seems to be a kernel regression, reverted in 4.11.4 :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77e9a4aa9de10cc1418bf9a892366988802a8025

adding the boot parameter ‘button.lid_init_state=method’ should work around this

> # I’ll handle the next steps, i.e. I’ll report this upstream and will follow-up with them as needed.

reassigning you, then

#4 Updated by intrigeri 2017-06-28 16:59:23

  • Priority changed from Normal to Low
  • Target version set to Tails_3.2
  • Type of work changed from Research to Code

At least 5 users reported this; but 1. not that many people are impacted (you need an external screen to suffer from it) and; 2. it’s a minor annoyance that one can easily fix manually in the Displays settings, so at the help desk / foundations team meeting today, we deemed this ticket as low priority. It should be fixed by the kernel upgrade in Tails 3.2 anyway, but if it’s not I’m not going to spend time on it.

#5 Updated by intrigeri 2017-06-28 16:59:39

#6 Updated by intrigeri 2017-06-28 16:59:43

#7 Updated by intrigeri 2017-06-28 16:59:51

#8 Updated by intrigeri 2017-06-29 10:26:27

#9 Updated by intrigeri 2017-09-02 14:38:03

  • Assignee changed from intrigeri to anonym
  • QA Check set to Ready for QA

(Should be fixed by Feature #12732.)

#10 Updated by anonym 2017-09-13 13:42:54

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

#11 Updated by anonym 2017-09-28 18:52:54

  • Status changed from Fix committed to Resolved