[PATCH weston v12 00/40] Atomic modesetting

[Matt Hoosier]

On Fri, Nov 3, 2017 at 2:46 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 2 Nov 2017 14:13:42 -0500
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
>
> > What sort of testing on this series would be most helpful? I figure that
> > you and pq have most of the code review covered, so the main
contribution I
> > can make with the hardware available to me is to exercise this on
> > consumer-grade systems like Macbooks with Intel display controllers. Are
> > there are specific use-cases that will put the most stress on your new
> > stuff? I assume that doing some sub-fullscreen OpenGL windows will kick
in
> > the overlay selections to test that out.
>
> Hi,
>
> from my point of view, output hotplug is always a pain to test on DRM,
> so I would appreciate help with that. This kind of cases:
>
> - on a running compositor, add an output with hotplug
> - on a running compositor, remove an output with hot-unplug
> - hot-unplug all outputs, the compositor should remain running
> - after hot-unplugging all outputs, plug them back in
> - start the compositor without any outputs, then hotplug some
> - hotplug/unplug tests with MST, so that we have DRM connectors
>   appearing and disappearing
>
> At all times, weston-info should reflect the actual number of outputs,
> 0..N.
>
> All the cases could be taken further by hotplugging and hot-unplugging
> while VT-switched away. It is also possible that some of this is
> already broken in upstream master, so if you encounter failures, it
> would be good to know if it was already broken.
>
> Those are my wishes, Daniel probably has others. Any testing reports
> at all would be awesome.
>
>
> Thanks,
> pq


Okay, I'll see how many of those cases I can manage to exercise.

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.)

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:

  CRTC info
  ---------
  CRTC 31: pipe: A, active=yes, (size=2560x1600), dither=no, bpp=24
          fb: 72, pos: 0x0, size: 2560x1600
          encoder 46: type: DDI A, connectors:
                  connector 47: type: eDP-1, status: connected, mode:
                  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
          cursor visible? no, position (0, 0), size 0x0, addr 0x00000000,
active? no
          No scalers available on this platform
          --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)
          --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)
          --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)


So I think that everything is going through the primary plane.

(This behavior isn't seen in the last common point between master and
Daniel's wip/2017-10/atomic-v13 branch head.)

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171103/64ee5eb9/attachment.html>