<div dir="ltr">On Fri, Nov 3, 2017 at 2:46 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>><br>> On Thu, 2 Nov 2017 14:13:42 -0500<br>> Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>><br>> > What sort of testing on this series would be most helpful? I figure that<br>> > you and pq have most of the code review covered, so the main contribution I<br>> > can make with the hardware available to me is to exercise this on<br>> > consumer-grade systems like Macbooks with Intel display controllers. Are<br>> > there are specific use-cases that will put the most stress on your new<br>> > stuff? I assume that doing some sub-fullscreen OpenGL windows will kick in<br>> > the overlay selections to test that out.<br>><br>> Hi,<br>><br>> from my point of view, output hotplug is always a pain to test on DRM,<br>> so I would appreciate help with that. This kind of cases:<br>><br>> - on a running compositor, add an output with hotplug<br>> - on a running compositor, remove an output with hot-unplug<br>> - hot-unplug all outputs, the compositor should remain running<br>> - after hot-unplugging all outputs, plug them back in<br>> - start the compositor without any outputs, then hotplug some<br>> - hotplug/unplug tests with MST, so that we have DRM connectors<br>>   appearing and disappearing<br>><br>> At all times, weston-info should reflect the actual number of outputs,<br>> 0..N.<br>><br>> All the cases could be taken further by hotplugging and hot-unplugging<br>> while VT-switched away. It is also possible that some of this is<br>> already broken in upstream master, so if you encounter failures, it<br>> would be good to know if it was already broken.<br>><br>> Those are my wishes, Daniel probably has others. Any testing reports<br>> at all would be awesome.<br>><br>><br>> Thanks,<br>> pq<br><br><br><font face="monospace, monospace">Okay, I'll see how many of those cases I can manage to exercise.<br><br>At the moment, I already noticed what looks like some sort of failure to handle wl_surface damage regions as submitted by weston-simple-egl. (Only part of the triangle refreshes while the remainder is stuck at its initial frame's contents.)<br><br></font><font face="monospace, monospace">It doesn't look to me like this has anything to do with overlay usage. The contents of /sys/kernel/debug/dri/0/i915_display_info show:<br><br></font><div><font face="monospace, monospace"><div>  CRTC info</div></font><font face="monospace, monospace"><div>  ---------</div></font><font face="monospace, monospace"><div>  CRTC 31: pipe: A, active=yes, (size=2560x1600), dither=no, bpp=24</div></font><font face="monospace, monospace"><div>          fb: 72, pos: 0x0, size: 2560x1600</div></font><font face="monospace, monospace"><div>          encoder 46: type: DDI A, connectors:</div></font><font face="monospace, monospace"><div>                  connector 47: type: eDP-1, status: connected, mode:</div></font><font face="monospace, monospace"><div>                  id 0:"2560x1600" freq 60 clock 268500 hdisp 2560 hss 2608 hse 2640 htot 2720 vdisp 1600 vss 1603 vse 1609 vtot 1646 type 0x48 flags 0x9</div></font><font face="monospace, monospace"><div>          cursor visible? no, position (0, 0), size 0x0, addr 0x00000000, active? no</div></font><font face="monospace, monospace"><div>          No scalers available on this platform</div></font><font face="monospace, monospace"><div>          --Plane id 25: type=PRI, crtc_pos=   0x   0, crtc_size=2560x1600, src_pos=0.0000x0.0000, src_size=2560.0000x1600.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)</div></font><font face="monospace, monospace"><div>          --Plane id 27: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)</div></font><font face="monospace, monospace"><div>          --Plane id 29: type=CUR, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)</div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">So I think that everything is going through the primary plane.</font></div><div><font face="monospace, monospace"><br></font></div>(This behavior isn't seen in the last common point between master and Daniel's wip/<wbr>2017-10/atomic-v13 b</font><span style="font-family:monospace,monospace">ranch head.)</span></div><div><font face="monospace, monospace"><br>-Matt</font><br></div></div>