desktop-packages team mailing list archive

[Madper Xie <madper.xie@xxxxxxxxxxxxx>]

I have verified the Proposed-package. It fixed the split-screen issue.
Works good for me:

My test bed: 
a ThinkPad t450 laptop with Nvidia Device 1347.

Reproduce:
before I install the proposed-package, the version is:
ii  xserver-xorg-video-intel                              2:2.99.910-0ubuntu1.3                               amd64        X.Org X server -- Intel i8xx, i9xx display driver

The attached picture shows the problem

Verification:
after I install the proposed-package in Comment #7, I can't reproduce the same issue. 

So I believe the issue is fixed by the new package.

** Attachment added: "reproduce.png"
   https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1405325/+attachment/4299770/+files/reproduce.png

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1405325

Title:
  [I+N] Split screen after setting the monitors configuration to
  extended

Status in HWE Next Project:
  Invalid
Status in HWE Next trusty series:
  New
Status in xserver-xorg-video-intel package in Ubuntu:
  Invalid
Status in xserver-xorg-video-intel source package in Trusty:
  Fix Committed

Bug description:
  Steps:
  1. Install trusty image and log in to system
  2. Connect an external DP monitor.
  3. Press the display hot key to change the monitors configuration

  Actual result:
  Split screen after set the monitors configuration to extended mode.

  Expected result:
  The video signal can be mirrored, extended, displayed on external or onboard only.

  [Analysis from NVIDIA]
  I tracked down the culprit to an Ubuntu patch applied to xf86-video-intel 2.99.910: patches/10-handle-rotated-slaves.diff. That patch is a cherry-pick of upstream commit a45b2ea11c15f35c36330ff27cb45854a29c2e2c. The Ubuntu version of the patch is significantly different from the upstream commit, so somebody must have done quite a bit of porting. Either they messed it up during porting, or they missed cherry-picking another upstream commit that fixes the problem.

  It looks like what's happening is that the Intel driver is applying
  the RandR CRTC offset even though it's actually scanning out from a
  CRTC-sized private scanout buffer. Since it's a linear buffer, this
  shifts all of the lines over by however many pixels the CRTC offset is
  set to, wrapping lines around in the process.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1405325/+subscriptions