Chameleon: DisplayPort video capture occasionally corrupts a single pixel in frame dumps
Reported by
cp...@redhat.com,
Jan 18 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Steps to reproduce the problem: 1. Get any system running a kernel close to upstream (so, no ChromeOS DUTs) 2. Log into a fbcon terminal on the machine 3. Connect a DisplayPort connector to the Chamelium 4. Run the attached script 5. Watch as frame dumps get corrupted. If the script says that there were no frame mismatches, try again except with this image https://people.freedesktop.org/~lyudess/archive/01-10-2017/ref.png (you can tell the script to draw an image on the screen by using the --image argument) What is the expected behavior? When displaying a static image on DisplayPort, the Chameleon should be able to return the exact same video frame for each capture without any pixels differing from the golden frame. What went wrong? On both amdgpu and all of the machines using i915 I've tried, frame dumps will occasionally differ from the actual expected output. Normally one would attribute this to driver bugs, but precisely how the frame dumps differ doesn't sound much like a driver issue. On the intel machines I tried this on (ThinkPad X1 Yoga 4th Gen, Intel All-in-One SKL SDP, ThinkPad T440s (Haswell)), I am able to get perfect frame dumps but only with certain images. For instance, when displaying this image: https://people.freedesktop.org/~lyudess/archive/01-10-2017/purrfect-frame.png I'm able to capture hundreds of frames, and every single one matches exactly with the golden frame. However, if I try to display this image: https://people.freedesktop.org/~lyudess/archive/01-10-2017/ref.png Then every ~30 frames that are captured, one frame has a single pixel that differs from the golden frame. On the amdgpu machines I've tried, there aren't any images I can display that don't show this pixel mismatching behavior. As well on both the intel and amdgpu machines I've tested this on, HDMI never shows this issue even after hundreds of consecutive frame dumps. Did this work before? N/A Chrome version: Chameleon Channel: stable OS Version: Fedora 25 Kernel 4.9.3-200.fc25.x86_64 Flash Version: N/A I've been discussing this on the Chameleon mailing list for a while now (using my thatslyude@gmail.com address), but I figured I should actually go and file an official issue for this. To make this easier for you guys to reproduce, this time around I've written up a python script (py3, requires pygame be installed) that is able to reproduce the issue reliably on my own machines. If with all of this you guys are still having trouble reproducing this issue, please don't hesitate to let me know. I'm more then willing to setup remote access to both the chamelium I have and the test machines I've been reproducing this on. As well I'm perfectly fine with leaving said test machines on 24/7, and rebooting them if they go out to lunch.
,
Jan 19 2017
,
Feb 16 2017
,
Feb 21 2017
I tried to reproduce it in my side with W740SU noteboo. But it's all ok for both ref.png and purrfect-frame.png with testing 5000 times. I print the ref_crc in standout. The following is the output of terminal. Could you setup a remote access for debugging this issue? Thanks. ------------------- [root@localhost ~]# dmidecode dmidecode | grep -A10 '^System Information' System Information Manufacturer: Notebook Product Name: W740SU Version: Not Applicable Serial Number: Not Applicable UUID: F8F59000-72EF-0000-0000-000000000000 Wake-up Type: Power Switch SKU Number: Not Applicable Family: Not Applicable -------------------------------- [root@localhost ~]# cat /proc/version Linux version 4.8.6-300.fc25.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016 ------------------- [root@localhost ~]# python3 frame-mismatch-example.py --count 5000 --image ref.png http://192.168.100.9:9992 Setting up a 1920x1080 display on port 1... Waiting for video to stabalize... ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused Searching for a frame mismatch in 5000 frames... ref_crc [16030, 50371, 31360, 40500] Finished, no frames mismatched -------------------------- [root@localhost ~]# python3 frame-mismatch-example.py --count 5000 --image purrfect-frame.png http://192.168.100.9:9992 Setting up a 1920x1080 display on port 1... Waiting for video to stabalize... ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused Searching for a frame mismatch in 5000 frames... ref_crc [36787, 19746, 11626, 7923] Finished, no frames mismatched -----------------------
,
Feb 21 2017
I'm actually going to say this bug should be closed. As it turns out not just one, but multiple of my displayport cables were bad. After getting some new cables the other day I've been able to get that test case to pass perfectly. Sorry about this!
,
Feb 21 2017
The DP cable were bad.
,
Feb 22 2017
Ugh. Okay, I'm sorry but it looks like I've misspoke. I thought that was the issue but suddenly the frame mismatches are back. Would you mind reopening this? I can set up a machine with remote access as well if you attach a public SSH key to use.
,
Feb 22 2017
ok. repoen it.
,
Mar 25 2017
Hi, has there been any changes with this? Like I said I'm willing to give you guys a machine to test this on, I'm just waiting for your public SSH key...
,
Mar 27 2017
Sorry, I didn't notice that we should attach a public SSH key. I attached one. BTW, do you have a new cable between chameleon board and video board? Maybe you can try to use another one.
,
Mar 27 2017
Awesome, I can't setup a machine for you today since I'm working from the office and need the machine I've got hooked up to the chameleon for nouveau dev, but I should be able to set you something up tomorrow. If you have any personal preference for distro btw, feel free to let me know. Otherwise I'll just throw Fedora on there. As for the cable, I'm assuming you're talking about the HSMC flex cable, unfortunately I don't happen to have any spares. This chameleon has been in transit a couple of times so I wouldn't be surprised if you thought that might be a likely culprit. I'll look into seeing if I can get my hands on a spare. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by waihong@chromium.org
, Jan 18 2017