desktop-packages team mailing list archive

[Alberto Milone <alberto.milone@xxxxxxxxxxxxx>]

I created a merge request of Tim's branch into the 14.04 branch.

** Changed in: unity-settings-daemon (Ubuntu)
       Status: Triaged => In Progress

** Description changed:

  OEM LP private bug: https://bugs.launchpad.net/bugs/1466441
  
  Title: Sometimes system turns a black screen when resume from S3 via Lid
  Close
  
- Summary:
+ [Impact]
+ 
  Sometimes system turns a black screen when resume from S3 via Lid Close
  It only has cursor on screen but still can switch to tty1.
  Failure rate ~ 1/5
  
- Steps:
+ [Test Case]
  1. install Ubuntu 14.04.2 & 3.19+ kernel and boot to OS
  2. Close the lid
  3. Open the lid
  4. check the display status
  
  Expected results: System should resume to the log in screen when open
  the lid
  
  Actual results:
  System sometimes fails to resume back to the log in screen but blackscreen instead.
  (Failure rate~ 1/5)
+ 
+ [Regression Potential]
+ Low. Delaying touchscreen mapping by 3 seconds should not affect any other input device.
+ 
  
  Details:
  
  unity-settings-deamon will call "xinput --map-to-output 11 eDP1" at background,
  and it's being blocked so only cursor will show on screen.
  
  1. Switch to tty1 when this happen
  2. Login with user account on tty1.
  3. Use "DISPLAY=:0 xrandr " on commandline you'll see it's being blocked.
  
  Since xinput is being blocked for some unknown reason (in gdb it shows
  polling on xcb_connect_to_fd() in XOpenDisplay() ),
  
  a possible workaround is to set a timeout for xinput in u-s-d.
  
  === modified file 'plugins/xrandr/gsd-xrandr-manager.c'
  --- plugins/xrandr/gsd-xrandr-manager.c	2014-06-05 11:56:15 +0000
  +++ plugins/xrandr/gsd-xrandr-manager.c	2015-07-01 08:59:56 +0000
  @@ -2199,7 +2199,7 @@
-          if (gnome_rr_output_info_is_active(output)) {
-                  g_debug ("Mapping touchscreen %d onto output %s",
-                           device_id, name);
+          if (gnome_rr_output_info_is_active(output)) {
+                  g_debug ("Mapping touchscreen %d onto output %s",
+                           device_id, name);
  - sprintf (command, "xinput --map-to-output %d %s",
  + sprintf (command, "timeout 3s xinput --map-to-output %d %s",
-                           device_id, name);
-                  status = system (command);
-          }
+                           device_id, name);
+                  status = system (command);
+          }

** Summary changed:

- For skylake system, u-s-d cause a black screen when resume from S3 via Lid Close
+ SRU: For skylake system, u-s-d cause a black screen when resume from S3 via Lid Close

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/1471708

Title:
  SRU: For skylake system, u-s-d cause a black screen when resume from
  S3 via Lid Close

Status in OEM Priority Project:
  New
Status in OEM Priority Project trusty series:
  New
Status in unity-settings-daemon package in Ubuntu:
  In Progress

Bug description:
  OEM LP private bug: https://bugs.launchpad.net/bugs/1466441

  Title: Sometimes system turns a black screen when resume from S3 via
  Lid Close

  [Impact]

  Sometimes system turns a black screen when resume from S3 via Lid Close
  It only has cursor on screen but still can switch to tty1.
  Failure rate ~ 1/5

  [Test Case]
  1. install Ubuntu 14.04.2 & 3.19+ kernel and boot to OS
  2. Close the lid
  3. Open the lid
  4. check the display status

  Expected results: System should resume to the log in screen when open
  the lid

  Actual results:
  System sometimes fails to resume back to the log in screen but blackscreen instead.
  (Failure rate~ 1/5)

  [Regression Potential]
  Low. Delaying touchscreen mapping by 3 seconds should not affect any other input device.

  
  Details:

  unity-settings-deamon will call "xinput --map-to-output 11 eDP1" at background,
  and it's being blocked so only cursor will show on screen.

  1. Switch to tty1 when this happen
  2. Login with user account on tty1.
  3. Use "DISPLAY=:0 xrandr " on commandline you'll see it's being blocked.

  Since xinput is being blocked for some unknown reason (in gdb it shows
  polling on xcb_connect_to_fd() in XOpenDisplay() ),

  a possible workaround is to set a timeout for xinput in u-s-d.

  === modified file 'plugins/xrandr/gsd-xrandr-manager.c'
  --- plugins/xrandr/gsd-xrandr-manager.c	2014-06-05 11:56:15 +0000
  +++ plugins/xrandr/gsd-xrandr-manager.c	2015-07-01 08:59:56 +0000
  @@ -2199,7 +2199,7 @@
           if (gnome_rr_output_info_is_active(output)) {
                   g_debug ("Mapping touchscreen %d onto output %s",
                            device_id, name);
  - sprintf (command, "xinput --map-to-output %d %s",
  + sprintf (command, "timeout 3s xinput --map-to-output %d %s",
                            device_id, name);
                   status = system (command);
           }

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1471708/+subscriptions