Bug 99362 - no resolutions >=1080p with Acer P7500 and Thinkpad X1
Summary: no resolutions >=1080p with Acer P7500 and Thinkpad X1
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other Linux (All)
: high critical
Assignee: Michael Heide
QA Contact: Intel GFX Bugs mailing list
Keywords: bisect_pending, regression
Depends on:
Reported: 2017-01-11 16:23 UTC by Michael Heide
Modified: 2017-06-29 17:41 UTC (History)
1 user (show)

See Also:
i915 platform: SNB
i915 features: display/HDMI

dmesg: drm-tip (67.41 KB, text/plain)
2017-01-12 21:01 UTC, Michael Heide
no flags Details
dmesg with drm.debug=0xe (247.10 KB, text/plain)
2017-01-13 14:20 UTC, Michael Heide
no flags Details
hdmi2 monitor edid (256 bytes, application/octet-stream)
2017-01-13 14:21 UTC, Michael Heide
no flags Details
xrandr --verbose (human readable edid / modelines) (13.48 KB, text/plain)
2017-01-13 14:22 UTC, Michael Heide
no flags Details

Description Michael Heide 2017-01-11 16:23:51 UTC
Hardware: Thinkpad X1 1294-2NG and Acer P7500 (projector) 

With Ubuntu 14.04 everything is fine. 

Updating to Ubuntu 16.04 and by default the connected projector says: no signal. With other external monitors everything is fine, it's just the projector which doesn't like the default resolution 1080p. 

Using lower resolutions and/or timings like 1024x768 or 1920x1080i (25Hz, interlaced 50Hz) everything is fine. 

I tried several modelines and all manually calculated modelines like with gtf or other tools do not work even on Ubuntu 14.04. It's just the default recognized (DDC?) modeline with Kernels <=4.2 that work. 

Using Ubuntu 16.04 i tried different kernels:

* all official kernels coming with Ubuntu 14.04
  (i.e. using kernel 3.19 with Ubuntu 16.04 works)
* from http://kernel.ubuntu.com/~kernel-ppa/mainline/
 - v4.2.8-ckt13 
 - v4.3-rc1 with drivers/gpu/drm/i915 directory from v4.2.8-ckt13
* from git clone git://anongit.freedesktop.org/git/drm-tip
 - git checkout f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7

* all official kernels coming with Ubuntu 16.04 
  (i.e. using kernel 4.4 with Ubuntu 14.04 doesn't work)
* from http://kernel.ubuntu.com/~kernel-ppa/mainline/
 - v4.3-rc1 unmodified
* from git clone git://anongit.freedesktop.org/git/drm-tip
 - git checkout ca6e4405779ed56ebac941570615abd667c72c02

So I think the regression must be added between f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7 and ca6e4405779ed56ebac941570615abd667c72c02. 
I.e. between DRIVER_DATE 20150522 and 20150731. 

(I've copied the i915-directory from Kernel v4.2.8-ckt13 to Kernel  v4.3-rc1, fixed some incompatibilities to successfully compile the kernel and this works. So it's something inside i915 which causes this behaviour.)

Still digging further into it...
Comment 1 Jani Nikula 2017-01-12 08:37:03 UTC
Please try the drm-tip branch of the drm-tip repo. That's the bleeding edge. Let's see if we've fixed this already upstream.

If it doesn't, you have the starting points for a git bisect:

git bisect start
git bisect good f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7
git bisect bad ca6e4405779ed56ebac941570615abd667c72c02

and try the kernels git gives you, and tell git what the result was.
Comment 2 Michael Heide 2017-01-12 08:42:10 UTC
Sorry, my fault. I have already tried drm-intel and drm-tip with no success. 
Thanks for your advice to try bisect,  I'll do so.
Comment 3 yann 2017-01-12 14:28:14 UTC
looks likes connector is hdmi, isn't it?  Can you attached kernel log linked to drm-tip branch use ? 
BTW please follow Jani's advice and keep us posted on your result.
Comment 4 Michael Heide 2017-01-12 16:17:03 UTC
yes, hdmi. and it's a long wire (to the projector). 

current status:

git bisect start
# good: [f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7] drm/i915/skl: Buffer translation improvements
git bisect good f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7
# bad: [ca6e4405779ed56ebac941570615abd667c72c02] Merge tag 'drm-intel-fixes-2015-07-15' into drm-intel-next-queued
git bisect bad ca6e4405779ed56ebac941570615abd667c72c02
# good: [f7b08217c755e88a29b5bd53b4a1d10cd8b3c5f8] Merge branch 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
git bisect good f7b08217c755e88a29b5bd53b4a1d10cd8b3c5f8
# skip: [23908db413eccd77084b09c9b0a4451dfb0524c0] Merge tag 'staging-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect skip 23908db413eccd77084b09c9b0a4451dfb0524c0
# good: [22165fa79814e71e7a5974b3c37a5028ed16c8f9] Merge tag 'dm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
git bisect good 22165fa79814e71e7a5974b3c37a5028ed16c8f9
# good: [e22619a29fcdb513b7bc020e84225bb3b5914259] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect good e22619a29fcdb513b7bc020e84225bb3b5914259
# skip: [a611fb75d0517fce65f588cde94f80bb4052c6b2] Merge tag 'module-misc-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
git bisect skip a611fb75d0517fce65f588cde94f80bb4052c6b2

... window is shrinking, slowly ...
(skipping nonbootable and crashdumping kernels)
Comment 5 Michael Heide 2017-01-12 21:01:13 UTC
Created attachment 128919 [details]
dmesg: drm-tip
Comment 6 Michael Heide 2017-01-12 21:07:25 UTC
Are you referring dmesg? No problem to attach one. 

(btw. this log was created while trying hints from https://aboutsimon.com/blog/2016/07/20/Ubuntu-16.04-external-monitor-flickering-and-turning-off-on-intel-i915.html plus forced uxa in xorg.conf with no success)
Comment 7 Ville Syrjala 2017-01-13 09:54:41 UTC
(In reply to Michael Heide from comment #5)
> Created attachment 128919 [details]
> dmesg: drm-tip

We'll need a dmesg with drm.debug=0xe passed to the kernel. Otherwise there's not much useful infromation in the log.

Does the projector have an EDID? If so can you also attach that?
Comment 8 Michael Heide 2017-01-13 14:20:46 UTC
Created attachment 128930 [details]
dmesg with drm.debug=0xe
Comment 9 Michael Heide 2017-01-13 14:21:37 UTC
Created attachment 128931 [details]
hdmi2 monitor edid
Comment 10 Michael Heide 2017-01-13 14:22:35 UTC
Created attachment 128932 [details]
xrandr --verbose (human readable edid / modelines)
Comment 11 Michael Heide 2017-01-23 09:08:01 UTC
Status update: my bisect run has stalled so far... restart needed.

First there were good and bad kernels, besides a few unbootable builds. But later on there were only unbootable builds. First I thought "ok, someone has broken the kernel, find the commit when they fixed this". But then I've tried some commit which I had build successfully once before: now broken. 

It seems my local git database is broken, even cleaning the whole tree (git clean -df) is not enough. 

Stay tuned...
Comment 12 Michael Heide 2017-01-25 11:18:05 UTC
Sorry but I don't get it. 

ca6e4405779ed56ebac941570615abd667c72c02 and newer is bad while ccfb8b2ed4d4e12c3c35de3db5fbbbaa11277736 and olders (in that line) are good. 

But 8f539a83efa7dceb7c2257ca96e2dfc846bd12f6 - which is the other parent of ca6e4405779ed56ebac941570615abd667c72c02 besides ccfb8b2ed4d4e12c3c35de3db5fbbbaa11277736 - and all others I tested so far in that line do not boot at all. Grub loads initrd and kernel, then a black screen and (sometimes) a blinking cursor appears. 

What am I doing wrong?

I compiled all those commits and all of them do not boot into a running system:
ce65e47b78789b4f78be1fd7e4c884df74a9f075 346add7834557b5b9628b9bf2387106d42e631d4 

Are all those commits are indeed broken or am I missing something?

(btw: f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7 is one of those in the line of non-booting kernels. I don't get it, but either I have mistakenly used this as a "good" example in my initial bug report, or I indeed was able to successfully compile and boot it back then?)

What I do:
git clean -dfX # only if not a clean git clone
git checkout or bisect good/bad/skip
cp /boot/config-$(uname -r) .config
yes "" | make oldconfig
fakeroot make-kpkg -j5 --initrd --append-to-version=-sometag kernel-image
dpkg -i ...
Comment 13 Ricardo 2017-03-03 16:57:25 UTC
(In reply to Ville Syrjala from comment #7)
> (In reply to Michael Heide from comment #5)
> > Created attachment 128919 [details]
> > dmesg: drm-tip
> We'll need a dmesg with drm.debug=0xe passed to the kernel. Otherwise
> there's not much useful infromation in the log.
> Does the projector have an EDID? If so can you also attach that?

Ville anything else you can do to help Michael?
Comment 14 Ville Syrjala 2017-03-03 17:38:51 UTC
Everything looks fine based on the log. We are now using 12bpc though whereas in the past we would have used 8bpc. So that could explain the change in behaviour. If the signal quality is marginal it's possible the problem would only manifest in the modes that require the highest bandwidth, which seems to be the case here.

Are you using a HDMI<->HDMI, DVI<->DVI or HDMI<->DVI cable? Any extra dongles/adaptors? Trying to eliminate extra dongles and whatnot might help, or the cable itself might not be of sufficiently high quality so trying another cable might help. Also if you're using the HDMI connector on the projector it might make sense to try out the DVI connection instead (AFAICS that projector should have both?). In theory it should not report 12bpc capability over DVI which would force us to pick 8bpc.
Comment 15 steven.j.hockemeier 2017-04-12 19:35:20 UTC
Still waiting on feedback from Michael about Ville's questions.  It still shows High/Critical so wondering if that priority still makes sense?
Comment 16 Ricardo 2017-05-09 17:56:48 UTC
Assigning the bug to submitter to answer some questions from comment 14
Comment 17 Jani Saarinen 2017-05-24 07:17:08 UTC
Reporter, please comment or otherwise bug will be closed as no feedback.
Comment 18 Elizabeth 2017-06-29 17:41:28 UTC
(In reply to Jani Saarinen from comment #17)
> Reporter, please comment or otherwise bug will be closed as no feedback.

I'm changing the bug to CLOSE due to the lack of feedback. If there is any new information relevant in this case, please share it and mark as REOPEN. Thank you.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.