I have a J2-680L POS (Point Of Sale) that runs Manjaro Linux. The problem is that ANY kernel newer than 4.4.x will not enable the internal display and I am forced to use an external display. This has been duplicated by testing with the latest releases of Fedora, CentOS, Debian and Ubuntu. The internal display will work up untill GRUB, after GRUB the display will go blank and is not detected by the system. This happens whether I am using modesetting or xf86-video-intel. Here are a few bits of information relating to the system. If anything else is needed please let me know... inxi -Fz https://pastebin.com/zJmPFEak lsmod https://pastebin.com/yLLkmwDP xrandr - NOTE: the internal screen is detected as connected on DP-2 https://pastebin.com/rQKDaLf8 hwinfo --monitor https://pastebin.com/k4rvVSPW hwinfo --gfxcard https://pastebin.com/qHQFJM9F As a side note i also tried creating a x11 intel.conf containing: Section "Device" Identifier "Intel Graphics" Driver "modesetting" BusID "PCI:0:2:0" EndSection To no avail which has now lead me to believe this is an regression. Thanks.
Hi, is it possible that you test with latest kernel stable: https://www.kernel.org?
I have the exact same results of no internal display with kernels 4.9.86 & 4.14.25 and 4.15.8. The system works fine with an external monitor on the above mentioned kernels but the internal display does not function, it is not even detected.
Thank you for testing, could you please attach dmesg or kern.log, with drm.debug=0xe parameter on grub, on raw text, with boot information?
Hi, here is the output of dmesg with the flags set at boot as requested.. https://pastebin.com/5z5hSKCg
Created attachment 138112 [details] kernel_4-15_no_working_display
From dmesg: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:60:DP-2] [ 22.091324] [drm:intel_dp_detect [i915]] [CONNECTOR:60:DP-2] [ 22.091877] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00 [ 22.092216] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:60:DP-2] disconnected [ 22.092302] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1] [ 22.092322] [drm:intel_crt_detect [i915]] [CONNECTOR:48:VGA-1] force=1 [ 22.092345] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0x83f40018, result 1 [ 22.092364] [drm:intel_crt_detect [i915]] CRT detected via hotplug [ 22.131595] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 22.131618] [drm:drm_add_display_info [drm]] non_desktop set to 0 These lines look suspicious, but not sure if related. Could you attach another log of a working version to compare? Same with drm.debug parameter. Thanks.
Firstly just want to say thank you for you support in this matter, i really appreciate it. Here is the dmesg with drm.debug=0xe from kernel 4.4.120 where the internal screen works as expected. https://pastebin.com/uA0JTacq
Created attachment 138133 [details] kernel_4-4-120_working_display From the 4.4.120 dmesg: After the DP-2 is detected: [ 15.410309] [drm:intel_dp_detect] [CONNECTOR:39:DP-2] [ 15.410845] [drm:intel_dp_get_dpcd] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00 [ 15.410850] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source no, sink no [ 15.410853] [drm:intel_dp_print_rates] source rates: 162000, 270000 [ 15.410855] [drm:intel_dp_print_rates] sink rates: 162000, 270000 [ 15.410858] [drm:intel_dp_print_rates] common rates: 162000, 270000 The modes of that connector are probed: [ 15.424921] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:39:DP-2] probed modes : [ 15.424926] [drm:drm_mode_debug_printmodeline] Modeline 43:"1024x768" 60 65000 1024 1048 1184 1344 768 772 778 806 0x48 0xa [ 15.424930] [drm:drm_mode_debug_printmodeline] Modeline 45:"1024x768" 85 94500 1024 1072 1168 1376 768 769 772 808 0x40 0x5 [ 15.424934] [drm:drm_mode_debug_printmodeline] Modeline 44:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5 And the connector detected as enable is the DP-2(39): [ 15.424970] [drm:drm_enable_connectors] connector 27 enabled? no [ 15.424972] [drm:drm_enable_connectors] connector 30 enabled? no [ 15.424974] [drm:drm_enable_connectors] connector 35 enabled? no [ 15.424976] [drm:drm_enable_connectors] connector 37 enabled? no [ 15.424986] [drm:drm_enable_connectors] connector 39 enabled? yes Meanwhile, in the 4.15 dmesg: After the dp-2 is detected: [ 14.988279] [drm:intel_dp_detect [i915]] [CONNECTOR:60:DP-2] [ 14.988821] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00 [ 14.989157] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:60:DP-2] status updated from unknown to disconnected The connector probed is VGA instead: [ 14.989251] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1] [ 14.989298] [drm:intel_crt_detect [i915]] [CONNECTOR:48:VGA-1] force=1 [ 14.989328] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0xa3f40018, result 1 [ 14.989349] [drm:intel_crt_detect [i915]] CRT detected via hotplug [ 15.027723] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 15.027744] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 15.027822] [drm:intel_connector_update_modes [i915]] ELD: no CEA Extension found [ 15.027908] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1] probed modes : [ 15.027927] [drm:drm_mode_debug_printmodeline [drm]] Modeline 65:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 [ 15.027943] [drm:drm_mode_debug_printmodeline [drm]] Modeline 71:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 [ 15.027959] [drm:drm_mode_debug_printmodeline [drm]] Modeline 66:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 ... And the one detected as enable is the vga(48): [ 15.174252] [drm:drm_setup_crtcs [drm_kms_helper]] connector 48 enabled? yes [ 15.174264] [drm:drm_setup_crtcs [drm_kms_helper]] connector 51 enabled? no [ 15.174270] [drm:drm_setup_crtcs [drm_kms_helper]] connector 56 enabled? no [ 15.174275] [drm:drm_setup_crtcs [drm_kms_helper]] connector 58 enabled? no [ 15.174280] [drm:drm_setup_crtcs [drm_kms_helper]] connector 60 enabled? no
If possible, could you try to replicate on kernel 4.13?
[ 14.988821] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00 means we were able to read the DPCD, and it has a valid revision number. That leads me to suspect that the display might be saying that SINK_COUNT is zero. Please run this: dd if=/dev/drm_dp_aux1 bs=1 skip=$((0x200)) count=1 2>/dev/null | xxd -p Your kernel will need to be built with CONFIG_DRM_DP_AUX_CHARDEV=y for that to work.
Hi, Elizabeth i only have access to the LTS kernels and current mainline, so i'm unable to test with kernel 4.13. Ville, the output of that command returns "00". The screen still isnt working after reboots and typing the command. Here is the configs used by my current kernel, which has already CONFIG_DRM_DP_AUX_CHARDEV=y set. https://pastebin.com/XQKnN0mW Thanks.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Just updating to say that there is still no change using kernel 4.16.0 Here is the dmesg with drm.debug=0xe https://pastebin.com/7QBCCJkt Thanks.
Jani, Ville, any advice here?
(In reply to David S. from comment #13) > https://pastebin.com/7QBCCJkt Please always attach logs etc. on the bug. Pastebins go away, and then we're left with nothing.
Looks like this was broken for you by commit 30d9aa4265fe4b2b28239934770b2c2d59858df3 Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Date: Wed Mar 30 18:05:25 2016 +0530 drm/i915: Read sink_count dpcd always in v4.7. (Did you ever try v4.5 or v4.6? I suspect those should have worked.) I have seen very few displays with DPCD rev 1.0 like you have, and it's so old I've never been able to acquire the 1.0 or even 1.1 specs to see how the sink count part was written back then. It seems to me that the current code is okay for DP 1.2 and later. But maybe we should look assume sink count == 1 for non-branch devices with DPCD 1.0/1.1.
(In reply to Jani Nikula from comment #16) > Looks like this was broken for you by > > commit 30d9aa4265fe4b2b28239934770b2c2d59858df3 > Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> > Date: Wed Mar 30 18:05:25 2016 +0530 > > drm/i915: Read sink_count dpcd always > > in v4.7. (Did you ever try v4.5 or v4.6? I suspect those should have worked.) > > I have seen very few displays with DPCD rev 1.0 like you have, and it's so > old I've never been able to acquire the 1.0 or even 1.1 specs to see how the > sink count part was written back then. I have the 1.0/1.1. SINK_COUNT always worked the same way. Ie. this looks to be a broken DP sink we're dealing with here.
Please run this and report the result: # dd if=/dev/drm_dp_aux1 bs=1 skip=$((0x400)) count=12 2>/dev/null | xxd -p Let's see if there's any chance we could quirk just that one sink.
Hi, The output from running the above mentioned command is... 000000434837353131100100 Thanks.
(In reply to David S. from comment #19) > 000000434837353131100100 So in newer DP spec the first three bytes would be the sink OUI which we could use to quirk different behaviour for the sink. Alas DPCD 1.0 has that as sink specific, and it doesn't have the OUI. Seems a bit risky to use that for quirking. Ville, what do you think? Quirk all DPCD 1.0/1.1 or use unreliable stuff for quirking a specific device? Other ideas?
Can we get a full binary DPCD dump please? dd if=/dev/drm_dp_aux1 > dpcd If that returns an error then you will have to use ddrescue instead of dd. Uncompressed the complete dump should should 1MiB in size. Probably want to compress it with gzip before attaching. Also can we get a copy of the EDID as well? This needs to be done with the kernel where the display still works. cat /sys/class/drm/card0-DP-2/edid > edid
Created attachment 139221 [details] Output of dd if=/dev/drm_dp_aux1 > dpcd
Created attachment 139222 [details] Output of cat /sys/class/drm/card0-DP-2/edid > edid
Ville, have a look latest data
So we see "CH7511" in vendor specific bytes after the sink OUI. The OUI itself is 0. And we see that there are no downstream ports and SINK_COUNT==0 (which doesn't really make sense). Actually this looks like it could be a new incarnation of bug #92172. That one was closed without a fix. Based on all the other google hits it looks like CH7511 doesn't take the DP/eDP specs seriously at all. Not sure if all CH7511 suck or if it's just a matter of the device manufacturers not configuring the thing correctly. For instance in this case I also see the eDP cap bit being 0, but the registers at 0x700 have some backlight control junk at least. Although many of the values don't seem to make much sense when compared with the spec.
I have a POS computer that also uses CH7511. Just like in David's case, the internal display of the POS is broken with Linux kernels 4.5+. The display shows no output. I can confirm that commit 30d9aa4265fe is the first commit since v4.4 that does not work. For what it's worth, here is a patch for v4.19.35 that fixes the problem for me. Not sure if this is a proper fix or hacky workaround for broken hardware, but it works for me and maybe someone else finds it useful. --- drivers/gpu/drm/i915/intel_dp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f92079e19de8..ec908f605708 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3840,6 +3840,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count); + if (!drm_dp_is_branch(intel_dp->dpcd)) + return true; /* native DP sink */ + /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know @@ -3850,9 +3853,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count) return false; - if (!drm_dp_is_branch(intel_dp->dpcd)) - return true; /* native DP sink */ - if (intel_dp->dpcd[DP_DPCD_REV] == 0x10) return true; /* no per-port downstream info */ -- 2.17.1 The CH7511 is not a branch device according to DPCD, so intel_dp_get_dpcd() function will return without actually using the incorrect SINK_COUNT variable.
Created attachment 144239 [details] EDID and DPCD info from my hardware
Hmm. So it's an internal panel but it's not flagged as eDP. If it was I think we wouldn't be having this problem. Please attach a copy of /sys/kernel/debug/dri/0/i915_vbt
Created attachment 144247 [details] i915_vbt.gz copy of /sys/kernel/debug/dri/0/i915_vbt
(In reply to Peteris Rudzusiks from comment #29) > Created attachment 144247 [details] > i915_vbt.gz > > copy of /sys/kernel/debug/dri/0/i915_vbt Sadly it doesn't look like there's anything in the VBT that could help us. I think we'll need to quirk this.
Created attachment 144248 [details] [review] [PATCH 1/2] drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT
Created attachment 144249 [details] [review] [PATCH 2/2] drm/i915: Skip SINK_COUNT read on CH7511 Please test these patches to make sure I didn't fumble it.
Tested kernel v5.1.2 with your patches applied - it worked!
commit 6e93a3b3264ed21fc07dc247f757939f844fbdc7 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue May 28 17:06:50 2019 +0300 drm/i915: Skip SINK_COUNT read on CH7511 Fix pushed. Thanks for the bug report and testing.
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.