[PATCH v14 00/41] Atomic modesetting

[Ucan, Emre (ADITG/ESB)]

Hi Daniel,

I tested these patches in this setup:

Hardware: Intel MRB with Apollo Lake SoC, Two Full HD  touch Displays
Kernel: 4.9 + this patch (drm: Pass CRTC ID in userspace vblank events 5db06a8a98f515f67446a69c57577c4c363ec65d)
Libdrm: 2.4.83
Mesa: 13.0.6

I disabled first atomic modesetting in kernel. I saw that legacy cursor plane worked fine. Display hot-plug, hot-unplug works. DPMS works. I did not find any issue.

Then, I activated atomic modesetting. I saw that weston put application buffer to scanout_plane, and it stopped rendering. Display hot-plug and unplug works perfectly.
I saw a small regression with DPMS. When weston turned off the display first time, the display stayed black after I touched it. I saw from the LED of the display that it was activated. But display was black.
After maybe 20-30 secs weston turned off the display again. Afterwards DPMS worked every time. Compositor woke up every time correctly.

Did you see a similar issue before ? I can try to find out the root cause if you want.

But anyway I think it is a minor regression.

Therefore: Tested-by: Emre Ucan <eucan at de.adit-jv.com>

Next week I will try to test it on RCAR HW.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937
> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Daniel Stone
> Sent: Mittwoch, 20. Dezember 2017 13:27
> To: wayland-devel at lists.freedesktop.org
> Subject: [PATCH v14 00/41] Atomic modesetting
> 
> Hi,
> Please find attached another iteration of the atomic series. This round
> has mostly seen cleanups and correctness fixes through 03-11.
> 
> The biggest change is around output disables, which necessitated the
> introduction of patch 1, and now ensures a relatively complicated
> disable/destroy/shutdown ordering of plane vs. output disabling. Patch
> 11 has now also grown to include a synchronous state application mode,
> which is used by output disabling.
> 
> I didn't want to bulk up patch 11, and spent some time trying to pull
> various bits of it out so they could be introduced in earlier, smaller,
> patches. The most promising line was, patch by patch:
>   * split state application out of repaint
>   * add a (mostly unused) DPMS enum to output state
>   * add drm_output_get_disable_state and drm_pending_state_apply_sync
>     and use these from output disable
>   * move all DPMS handling to output state at the same time as moving
>     state application to repaint flush
> 
> At the end of it, it was still quite fiddly and I felt it made the
> intermediate patches more difficult to review; it seemed more
> straightforward to just read patch 11 with the above in mind. But if
> anyone feels strongly about it, I'm happy to re-try the split along
> those lines.
> 
> I did test hotplug and hot-unplug, which managed to tease out the
> plane_state fixes now seen in patch 06. But beyond that, it seemed
> entirely stable with whatever I threw at it. Hopefully this means we're
> actually good to go by now.
> 
> Hope you all have a great Christmas and New Year.
> 
> Cheers,
> Daniel
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel