Bug 100115

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/

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>

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.

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 ?

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.

Created attachment 130164 [details]
weston error1

Created attachment 130165 [details]
weston error2

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.

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

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

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

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

(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

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

(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?

> 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 ?
                             ^

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

Much of the atomic patchset landed in 4.0, and there are newer versions for the rest on the list.