Bug 100115 - How to enable planes for atomic
Summary: How to enable planes for atomic
Status: RESOLVED WORKSFORME
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-08 12:49 UTC by kevan.lan
Modified: 2018-06-04 07:17 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
weston error1 (11.36 KB, text/plain)
2017-03-11 10:25 UTC, kevan.lan
Details
weston error2 (10.08 KB, text/plain)
2017-03-11 10:26 UTC, kevan.lan
Details

Description kevan.lan 2017-03-08 12:49:53 UTC
weston version: 2.0.0

kernel version: Linux version 4.4.41
drm driver: support drm atomic.

gpu verion: Mali-T860 OpenGL ES 3.2 v1.r13p0-00rel0


How to enable planes for atomic?
Comment 1 Pekka Paalanen 2017-03-08 13:14:25 UTC
Hi,

what do you mean and how is it a bug or a feature request? I mean, this question might have been more suited for the mailing list.

Support for atomic modesetting has not yet been merged into Weston upstream:
https://patchwork.freedesktop.org/series/20655/
Comment 2 kevan.lan 2017-03-08 15:31:07 UTC
Thanks Pekka!

I have pulled Daniel Stone's code:
git://git.collabora.com/git/user/daniels/weston#wip/2017-03/atomic-v9

But weston could not be started normally,the  error log is:

......
               GL_EXT_color_buffer_half_float GL_EXT_color_buffer_float
               GL_EXT_YUV_target GL_OVR_multiview GL_OVR_multiview2
               GL_OVR_multiview_multisampled_render_to_texture
               GL_KHR_robustness GL_KHR_robust_buffer_access_behavior
               GL_EXT_draw_elements_base_vertex
               GL_OES_draw_elements_base_vertex
[08:51:26.358] GL ES 2 renderer features:
               read-back format: BGRA
               wl_shm sub-image to texture: no
               EGL Wayland extension: yes
[    3.906341] weston[230]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
[    3.907126] pgd = ffffffc0ecb73000
[    3.907428] [00000000] *pgd=00000000ecb71003, *pud=00000000ecb71003, *pmd=00000000ecb7c003, *pte=0000000000000000
[    3.908361] 
[    3.908502] CPU: 2 PID: 230 Comm: weston Not tainted 4.4.52 #62


It may be cause by this commit:

commit cf3a7c5be230cdfc290a3a6b636c28c865f85b6f
Author: Daniel Stone <daniels@collabora.com>
Date:   Mon Jan 16 19:20:32 2017 +0000

    Switch to global output repaint timer
    
    In preparation for grouping output repaint together where possible,
    switch the per-output repaint timer, to a global timer which iterates
    across all outputs.
    
    This is implemented by storing the absolute time for the next repaint
    for each output locally, and maintaining a global timer which iterates
    all of them, scheduling the repaint for the first available time.
    
    Signed-off-by: Daniel Stone <daniels@collabora.com>
    Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Comment 3 Pekka Paalanen 2017-03-09 08:46:26 UTC
Really? That's interesting, as I am about to land that patch in Weston upstream real soon now.

Does "unhandled level 3 translation fault (11) at 0x00000000" mean it segfaulted from dereferencing NULL? I'm not familiar with that message.

Can you get a backtrace with gdb when you are exactly at the first problematic commit, please?

Next time, please carefully explain the revision of weston you are running. It is not 2.0.0 because you have patches on top.
Comment 4 kevan.lan 2017-03-11 04:30:50 UTC
There is no segfaulted problem when I use Daniel Stone's code compile directly (git://git.collabora.com/git/user/daniels/weston#wip/2017-03/atomic-v9) .

[08:54:13.052] weston 2.0.90
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=2.0.90

The weston version is 2.0.90, I test 4k Video performance can get 60fps.
test_case = 1, display source=/mnt/3840x2160_nv12.bin
Fps = 60.016 mFrameConut=31 now=1883330336
Fps = 59.998 mFrameConut=62 now=1883847016
Fps = 59.982 mFrameConut=93 now=1884363840


But this patchs lead to  Wayland connection broke issue when HDMI hotplug?
[09:12:22.183] connector 74 disconnected
[09:12:22.194] caught signal: 11
The Wayland connection broke. Did the Wayland compositor die?


Pekka, Daniels
   Do you have the same problem ?
Comment 5 Pekka Paalanen 2017-03-11 08:40:43 UTC
I am a little confused. The patch is *in* the atomic-v9 branch you said works fine.

Are you saying that the branch works fine as a whole otherwise, but hot-unplugging an output causes Weston to segfault?

And you have bisected to confirm, that the segfault on hot-unplug starts happening on "Switch to global output repaint timer"?

When you do the hot-unplug, are there no connected outputs left after that?
I suspect it might be a crucial detail on whether at least one output still remains, or if there are none. Support for zero outputs is fairly young in Weston and probably not commonly tested. For me, testing hotplug behavior is always a pain.

On a quick glance I don't see anything in that particular patch that would crash with zero outputs, so a backtrace of the crash would be helpful.
Comment 6 kevan.lan 2017-03-11 10:25:20 UTC
Created attachment 130164 [details]
weston error1
Comment 7 kevan.lan 2017-03-11 10:26:37 UTC
Created attachment 130165 [details]
weston error2
Comment 8 kevan.lan 2017-03-11 10:30:11 UTC
The atomic-v9 branch works fine as a whole otherwise, but weston works abnormally when HDMI connected and disconnected.

I have added two error log files.Please see the attachment.
Comment 9 Pekka Paalanen 2017-03-13 14:02:30 UTC
(In reply to kevan.lan from comment #6)
> Created attachment 130164 [details]
> weston error1

weston: libweston/compositor-drm.c:2453: drm_output_start_repaint_loop: Assertion `scanout_plane->state_cur->output == output' failed.
[08:51:12.475] caught signal: 6

This assert is added in patch "compositor-drm: Use drm_plane for scanout plane", so it cannot be caused by "Switch to global output repaint timer" which comes much earlier.
Comment 10 Daniel Stone 2017-03-13 14:55:45 UTC
(In reply to Pekka Paalanen from comment #9)
> (In reply to kevan.lan from comment #6)
> > Created attachment 130164 [details]
> > weston error1
> 
> weston: libweston/compositor-drm.c:2453: drm_output_start_repaint_loop:
> Assertion `scanout_plane->state_cur->output == output' failed.
> [08:51:12.475] caught signal: 6
> 
> This assert is added in patch "compositor-drm: Use drm_plane for scanout
> plane", so it cannot be caused by "Switch to global output repaint timer"
> which comes much earlier.

I'll fix that, but again, that's nothing to do with the global-repaint series itself; it only comes in with the patch to move the scanout plane to using a drm_plane.

I haven't seen the crash on disconnect, mind.

Hm. More hotplug testing required.
Comment 11 Pekka Paalanen 2017-03-13 15:08:30 UTC
(In reply to kevan.lan from comment #7)
> Created attachment 130165 [details]
> weston error2

[09:02:08.924] connector 74 disconnected
[09:02:08.934] caught signal: 11

And nothing else. This could really use a gdb backtrace.

What code exactly you ran to get this output? Which git sha1 from Daniel's branch?

I could not reproduce this on a quick try. I did see "function is no-op" messages only during HDMI was disconnected, coming from Mesa src/mapi/table.c I believe.
Comment 12 Pekka Paalanen 2017-03-13 15:11:11 UTC
(In reply to Pekka Paalanen from comment #11)
> I did see "function is no-op"
> messages only during HDMI was disconnected, coming from Mesa
> src/mapi/table.c I believe.

And that also happens without the patch, so a red herring.
Comment 13 kevan.lan 2017-03-13 15:20:12 UTC
(In reply to Pekka Paalanen from comment #11)
> (In reply to kevan.lan from comment #7)
> > Created attachment 130165 [details]
> > weston error2
> 
> [09:02:08.924] connector 74 disconnected
> [09:02:08.934] caught signal: 11
> 
> And nothing else. This could really use a gdb backtrace.
> 
> What code exactly you ran to get this output? Which git sha1 from Daniel's
> branch?
> 


* wip/2017-03/atomic-v9                                   bf2d03a [XXX] compositor-drm: Support modifiers with GBM
Comment 14 kevan.lan 2017-03-21 16:17:56 UTC
I using following branch:
* wip/2017-03/atomic-v9       bf2d03a [XXX] compositor-drm: Support modifiers with GBM

It seems these two client API work failure:
wl_surface_set_buffer_transform(window->surface, WL_OUTPUT_TRANSFORM_270);
wp_viewport_set_destination(window->viewport, 1536, 2048);
Comment 15 Daniel Stone 2017-03-21 16:20:35 UTC
(In reply to kevan.lan from comment #14)
> I using following branch:
> * wip/2017-03/atomic-v9       bf2d03a [XXX] compositor-drm: Support
> modifiers with GBM
> 
> It seems these two client API work failure:
> wl_surface_set_buffer_transform(window->surface, WL_OUTPUT_TRANSFORM_270);
> wp_viewport_set_destination(window->viewport, 1536, 2048);

What do you mean by 'failure'? What did you expect to happen? What was the actual result?

Can you please try wip/2017-03/atomic-v10-WIP, and provide some more detailed comment?
Comment 16 kevan.lan 2017-03-22 09:16:51 UTC
> What do you mean by 'failure'? What did you expect to happen? What was the
> actual result?
> 
> Can you please try wip/2017-03/atomic-v10-WIP, and provide some more
> detailed comment?

Compile error when i try wip/2017-03/atomic-v10-WIP:

libweston/compositor-drm.c: In function 'init_kms_caps':
libweston/compositor-drm.c:3381:29: error: 'DRM_CAP_CRTC_IN_VBLANK_EVENT' undeclared (first use in this function)
  ret = drmGetCap(b->drm.fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, &cap);

I think it need another drm and kernel patch ?
                             ^
Comment 17 Daniel Stone 2017-03-22 14:16:47 UTC
(In reply to kevan.lan from comment #16)
> > What do you mean by 'failure'? What did you expect to happen? What was the
> > actual result?
> > 
> > Can you please try wip/2017-03/atomic-v10-WIP, and provide some more
> > detailed comment?
> 
> Compile error when i try wip/2017-03/atomic-v10-WIP:
> 
> libweston/compositor-drm.c: In function 'init_kms_caps':
> libweston/compositor-drm.c:3381:29: error: 'DRM_CAP_CRTC_IN_VBLANK_EVENT'
> undeclared (first use in this function)
>   ret = drmGetCap(b->drm.fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, &cap);
> 
> I think it need another drm and kernel patch ?

Yes, those are available in the drm and kernel trees in the same place as my weston tree.
Comment 18 Daniel Stone 2018-06-04 07:17:11 UTC
Much of the atomic patchset landed in 4.0, and there are newer versions for the rest on the list.


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.