Original report is at https://bugs.tizen.org/jira/browse/TIVI-2912. I felt we needed to track this upstream (here) to hopefully gain some traction on getting this issue resolved sooner. On a NexCom VTC-1010, the VGA port is always detected by kms as being "connected" even if no display is connected to it. When a display is connected on the display port, Weston thinks there are two displays available (reported by kms) and creates two outputs, one for VGA and one for DP. It follows that, only one output is visible in this case. You would expect that adding "mode=off" for VGA in weston.ini would circumvent this issue. However, doing so results in Weston not rendering anything to the DP output at all, even though Weston correctly disables VGA. When using the gl-renderer, toggling a vt-switch results in various EGL errors and desktop-shell crashing. When using the pixman-renderer, toggling a vt-switch **corrects** the problem and Weston starts rendering to the DP output just fine after that. Regardless of the kms and hardware issues involved with the VGA port, Weston should be able to properly function with VGA explicitly disabled in weston.ini.
In a similar case with DP connected, if a VGA display *is* connected too and you specify its "mode=off" in weston.ini... we still encounter this issue.
I tried to reproduce this with the latest Tizen IVI image I found here [1], which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it on a VTC 1010, but I didn't see the bug. The DP output was rendering properly on both cases, with VGA enabled or disable. Do you have anything interesting in dmesg when you see the bug? [1] http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/
(In reply to comment #2) > I tried to reproduce this with the latest Tizen IVI image I found here [1], > which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it > on a VTC 1010, but I didn't see the bug. The DP output was rendering > properly on both cases, with VGA enabled or disable. > > Do you have anything interesting in dmesg when you see the bug? > > > [1] > http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/ I forgot to mention that I tested and reproduced this with Fedora 20 and updated kernel package (3.13.9ish) installed on the VTC 1010. Perhaps tizen recently patched/updated something that fixed it for them?? I'll do more investigation next time my VTC 1010 is within reach.
(In reply to comment #2) > I tried to reproduce this with the latest Tizen IVI image I found here [1], > which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it > on a VTC 1010, but I didn't see the bug. The DP output was rendering > properly on both cases, with VGA enabled or disable. > > Do you have anything interesting in dmesg when you see the bug? > > > [1] > http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/ Ander, It's possible that the IVI images have appended "video=VGA-1:d" to the kernel command line to workaround this issue. The point is not to have to do that. Could you verify that the VGA is not disabled in the kernel before attempting to reproduce?
(In reply to comment #4) > (In reply to comment #2) > > I tried to reproduce this with the latest Tizen IVI image I found here [1], > > which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it > > on a VTC 1010, but I didn't see the bug. The DP output was rendering > > properly on both cases, with VGA enabled or disable. > > > > Do you have anything interesting in dmesg when you see the bug? > > > > > > [1] > > http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/ > > Ander, > It's possible that the IVI images have appended "video=VGA-1:d" to the > kernel command line to workaround this issue. The point is not to have to > do that. Could you verify that the VGA is not disabled in the kernel before > attempting to reproduce? I don't see any occurrence of video=VGA-1:d in the loader config. Moreover, I did test with VGA enabled in which case I got image on both outputs. This is what I have: boot/loader/loader.conf: # Generated by setup-gummiboot-conf timeout 0 default vmlinuz-3.13.3-17.2-x86-ivi boot/loader/entries/vmlinuz-3.13.3-17.2-x86-ivi.conf: # Generated by setup-gummiboot-conf title Tizen 3.0.0 (Tizen Next) version 3.13.3-17.2-x86-ivi efi /vmlinuz-3.13.3-17.2-x86-ivi options rootwait rootfstype=ext4 quiet root=PARTUUID=23DADB8A-B065-480E-8BFC-94D7548D5B52 I wonder if this could be a link training issue with a specific monitor. I only tested with the monitor I have on my desk.
Yup, dmesg prints a few errors: Apr 24 01:41:49 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:49 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:50 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:50 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:51 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:51 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:52 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up Apr 24 01:41:52 BYT-I-VTC1010-1 kernel: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting I am using an Active HDMI->DisplayPort adapter to connect my monitor. I tried a DELL S2240T and a Giantec 11.6" Touchscreen monitor.
Artie, I believe this would be a drm driver issue, so I'm reassigning it. I believe they'll want the full output of dmesg with the kernel booted with drm.debug=0x06 in the kernel command line. Summary of the previous comments: On a VTC 1010 device (BayTrail based), no image is displayed on a monitor connected to a DisplayPort with an active HDMI->DisplayPort adapater. Tested with Fedora 20 and "updated kernel package (3.13.9ish)".
I don't know if you have any backported commits in your kernel, but there's plenty of BYT DP related fixes we've added lately. Please try the drm-intel-nightly branch of [1], and attach dmesg with drm.debug=0xe module parameter. Thanks. [1] http://cgit.freedesktop.org/drm-intel
(In reply to comment #7) > Artie, I believe this would be a drm driver issue, so I'm reassigning it. I > believe they'll want the full output of dmesg with the kernel booted with > drm.debug=0x06 in the kernel command line. > > I agree with your conclusion... thanks for recategorizing. > Summary of the previous comments: > > On a VTC 1010 device (BayTrail based), no image is displayed on a monitor > connected to a DisplayPort with an active HDMI->DisplayPort adapater. Tested > with Fedora 20 and "updated kernel package (3.13.9ish)". I would also add that, this only happens when VGA is disabled at startup.
(In reply to comment #8) > I don't know if you have any backported commits in your kernel, but there's > plenty of BYT DP related fixes we've added lately. Please try the > drm-intel-nightly branch of [1], and attach dmesg with drm.debug=0xe module > parameter. Thanks. > > [1] http://cgit.freedesktop.org/drm-intel The kernel I'm using is a pristine release from Fedora updates... I'll try the drm-intel-nightly and report back.
Created attachment 98130 [details] drm-intel-nightly 11ddb59 - dmesg dmesg output with drm.debug=0xe using drm-intel-nightly 11ddb59.
It does not seems like a highest/Critical Bug, downgrade to high/major severity.
Which active DP->HDMI adapter are you using? Is this still happening with the latest -nightly? I have a VTC1010 here that I can investigate this on. I'll source the same active adapter and see about reproducing this problem. -T
(In reply to comment #13) > Which active DP->HDMI adapter are you using? Is this still happening with > the latest -nightly? I have a VTC1010 here that I can investigate this on. > I'll source the same active adapter and see about reproducing this problem. > > -T I tested with a StarTech DisplayPort to HDMI Active Adapter DP2HDS. I have not tested against -nightly for a few months, so not sure if it's still an issue there... I'll try to carve some time aside this week to see if it's still reproducible with latest -nightly.
(In reply to comment #14) > (In reply to comment #13) > > Which active DP->HDMI adapter are you using? Is this still happening with > > the latest -nightly? I have a VTC1010 here that I can investigate this on. > > I'll source the same active adapter and see about reproducing this problem. > > > > -T > > I tested with a StarTech DisplayPort to HDMI Active Adapter DP2HDS. I have > not tested against -nightly for a few months, so not sure if it's still an > issue there... I'll try to carve some time aside this week to see if it's > still reproducible with latest -nightly. Tested again with drm-intel-nightly 778206252. I can no longer reproduce this issue. Furthermore, I couldn't reproduce on a more recent F20 kernel (3.14.5) either. Closing.
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.