AnsweredAssumed Answered

Bug in Vivante i.MX6 Wayland drivers when destroying windows

Question asked by Andreas Cord-Landwehr on Apr 24, 2018
Latest reply on Sep 12, 2018 by Andreas Cord-Landwehr
Branched to a new discussion

Like • Show 0 Likes0
Comment • 29

We are getting the following client-side crash with our compositor when destroying windows. Apparently, the proxy object is nullptr though it never shall be.
We are using SDK release 5.0.11.p8.4.
 
Thread 2 (Thread 3662.3673):
#0  wl_proxy_add_listener (proxy=0x0, implementation=0x74b621cc <gcsWL_FRAME_LISTENER>, data=data@entry=0x5e424d0c) at /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:464
No locals.
#1  0x74b53544 in wl_callback_add_listener (data=0x5e424d0c, listener=0x74b621cc <gcsWL_FRAME_LISTENER>, wl_callback=<optimized out>) at /home/bamboo/automation/3.14.52-1.1.1/graphics_pkg/temp_build_dir/build-imx6qsabresd/tmp/sysroots/imx6qsabresd/usr/include/wayland-client-protocol.h:317
No locals.
#2  gcoOS_SetDisplayVirtualEx (Display=<optimized out>, Window=0x5e424c84, Context=0x5e424d0c, Surface=<optimized out>, Offset=0, X=0, Y=0) at gc_hal_user_wayland.c:1692
        swapInterval = -1
        ret = <optimized out>
        i = <optimized out>
        wl_window = 0x5e424c84
        egl_buffer = 0x5e424d0c
        wl_buffer = 0x5e457d40
        display = 0x19d608
#3  0x74a843ac in veglSetDisplayFlip (Display=Display@entry=0x19d6bc, Surface=<optimized out>, BackBuffer=BackBuffer@entry=0x5e4255dc) at gc_egl_platform.c:249
        status = <optimized out>
#4  0x74a7ec6c in veglSwapWorker (Display=0x19d6bc) at gc_egl_swap.c:741
        display = 0x19d6bc
        displayWorker = 0x5e4255cc
        currWorker = 0x5e4255cc
        bStop = 0
        __user_ptr__ = <synthetic pointer>
#5  0x75a4cf5c in start_thread (arg=0x65556440) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:335
        pd = 0x65556440
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {2123239463, 1853849923, 1700095040, 2130704288, 0, 338, 0, 0, 2130704288, 1700093820, 0 <repeats 54 times>}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        robust = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#6  0x75d42408 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:86 from /opt/sdk/cebis/sysroots/cortexa9hf-neon-mel-linux-gnueabi/lib/libc.so.6
No locals.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

No one else has this question

Outcomes

29 Replies

Bio_TICFSL Apr 27, 2018 10:01 AM
Mark Correct
Correct Answer
Hi Andreas,

Could you provide your test? I can not reproduced it.
Like • Show 0 Likes0
Actions
- Andreas Cord-Landwehr @ Bio_TICFSL on Apr 30, 2018 10:17 AM
  Mark Correct
  Correct Answer
  Hi, I created a small test case and put it on GitHub:
  
  GitHub - cordlandwehr/imx6_testcase_wayland-client-crash: Testcase for https://community.nxp.com/thread/474517?sr=inbox&…
  
  Please see the include README.md for how to reproduce the bug.
  Like • Show 0 Likes0
  Actions
  - Bio_TICFSL @ Andreas Cord-Landwehr on May 2, 2018 8:00 AM
    Mark Correct
    Correct Answer
    Hi Andreas,
    
    I believe there are some bugs fix for segfault and crashes in most recent driver. Could you try the attached most recent gpu 5.x p8 driver to see if your issue is fixed.
    Attachments
    gpu-p8-latest.tar.gz7.4 MB
    Like • Show 0 Likes0
    Actions
    - sanjeev sharma @ Bio_TICFSL on Jul 16, 2018 10:43 PM
      Mark Correct
      Correct Answer
      Dear Bio_TICFSl,
      
      We have tried with 5.0.11.p8.6 & v6.2.2.p0 Vivante gpu driver version and also tried wayland v1.11.1 but Crash is still observed. if you look at the application code GitHub - cordlandwehr/imx6_testcase_wayland-client-crash: Testcase for https://community.nxp.com/thread/474517?sr=inbox&…
      thread 2 looks like it's about to destroy the EGLSurface for this wl_surface which already got destroyed. So the question is why is this wl_surface destroyed before its EGLSurface is destroyed.
      Like • Show 0 Likes0
      Actions
Chris Healy May 3, 2018 11:10 AM
Mark Correct
Correct Answer
As an alternative to a potentially improved Vivante driver, it is now possible to run the latest upstream Weston (4.0) with mainline kernel, libdrm, and Mesa. There are optimizations in upstream Weston specifically for the Vivante GPU that result in very good performance on the i.MX6 when running with mainline kernel, libdrm, and Mesa. (Mesa is what provides the opensource driver for the Vivante GPU in the i.MX6 when running a non NXP-BSP based kernel.)

I've been running with this stack for some time now and it works quite well. It would require you move from whatever version of kernel you are currently running to Linux 4.16 though which may not be an option in your case.
Like • Show 0 Likes0
Actions
- Jrtiger Lee @ Chris Healy on May 7, 2018 5:02 AM
  Mark Correct
  Correct Answer
  Hi Chris ,
  
  Do you have any guideline to porting weston 4.0 with mainline kernel can share with us?
  Like • Show 0 Likes0
  Actions
  - Chris Healy @ Jrtiger Lee on May 10, 2018 2:01 PM
    Mark Correct
    Correct Answer
    Hi Jrtiger,
    
    There isn't really much in the context of "porting" it. If you take stock Linux 4.16 (or newer) with stock libdrm 2.4.89 (or newer) with stock Mesa 18.0 and build stock Weston 4.0, you should have a working stack that just works.
    
    In the kernel, libdrm, and Mesa, you need to make sure "etnaviv" is enabled. (etnaviv is vivante spelled backwards....)
    
    With this stack, LVDS and HDMI output should work correctly and the GPU will be used to accelerate Weston for compositing as well as the GPU being available for any applications that use OpenGL ES 2.0. (Qt 5.10.1 is a good example of this. It's will use OpenGL ES 2.0 for acceleration.)
    
    With a 1080p display and the i.MX6qp, many applications operate at 60fps.
    
    With the mainline stack, not only is the GPU properly supported but the VPU (Video decoder) also just works. You'll want to have gstreamer 1.14. With this combination, no special NXP plugins are required and 1080p video playback will be ~1% CPU load.
    
    Regards,
    
    Chris
    Like • Show 0 Likes0
    Actions
    - Jrtiger Lee @ Chris Healy on May 10, 2018 7:02 PM
      Mark Correct
      Correct Answer
      Hi Chris ,
      
      I was using Yocto morty to build system, and will try to use Yocto rocko or sumo to create this new stuff.
      Thanks for your experience sharing.
      I'll glad that if you have more GPU benchmark sharing , like glmark2 score in 1080P resolution.
      Like • Show 0 Likes0
      Actions
      - Chris Healy @ Jrtiger Lee on May 11, 2018 6:35 PM
        Mark Correct
        Correct Answer
        Hi Jrtiger,
        
        Below is the output of glmark2-es2-wayland. The display is 1920x1080. The SoC is the i.MX6qp and it's running Weston (Wayland compositor). Performance is a bit lower than should be expected as our HW platform has the GPU shader clock reduced from the default 720Mhz to 594Mhz. Within the next few months, I expect the framerate going up substantially as there is a compositor bypass feature being worked on for Weston that gets turned on when running an application fullscreen. (Composition is not needed when there's only one application on the screen.)
        
        root@RDU2:~ glmark2-es2-wayland --fullscreen
        =======================================================
            glmark2 2014.03
        =======================================================
            OpenGL Information
            GL_VENDOR:     etnaviv
            GL_RENDERER:   Vivante GC3000 rev 5450
            GL_VERSION:    OpenGL ES 2.0 Mesa 18.0.0.20180404-1
        =======================================================
        [build] use-vbo=false: FPS: 295 FrameTime: 3.390 ms
        [build] use-vbo=true: FPS: 360 FrameTime: 2.778 ms
        [texture] texture-filter=nearest: FPS: 333 FrameTime: 3.003 ms
        [texture] texture-filter=linear: FPS: 331 FrameTime: 3.021 ms
        [texture] texture-filter=mipmap: FPS: 322 FrameTime: 3.106 ms
        [shading] shading=gouraud: FPS: 267 FrameTime: 3.745 ms
        [shading] shading=blinn-phong-inf: FPS: 191 FrameTime: 5.236 ms
        [shading] shading=phong: FPS: 129 FrameTime: 7.752 ms
        [shading] shading=cel: FPS: 95 FrameTime: 10.526 ms
        [bump] bump-render=high-poly: FPS: 168 FrameTime: 5.952 ms
        [bump] bump-render=normals: FPS: 217 FrameTime: 4.608 ms
        [bump] bump-render=height: FPS: 164 FrameTime: 6.098 ms
        libpng warning: iCCP: known incorrect sRGB profile
        [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 46 FrameTime: 21.739 ms
        libpng warning: iCCP: known incorrect sRGB profile
        [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 12 FrameTime: 83.333 ms
        [pulsar] light=false:quads=5:texture=false: FPS: 205 FrameTime: 4.878 ms
        libpng warning: iCCP: known incorrect sRGB profile
        [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 26 FrameTime: 38.462 ms
        libpng warning: iCCP: known incorrect sRGB profile
        [desktop] effect=shadow:windows=4: FPS: 96 FrameTime: 10.417 ms
        [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 46 FrameTime: 21.739 ms
        [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 45 FrameTime: 22.222 ms
        [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 58 FrameTime: 17.241 ms
        [ideas] speed=duration: FPS: 162 FrameTime: 6.173 ms
        [jellyfish] <default>: FPS: 58 FrameTime: 17.241 ms
        [terrain] <default>: FPS: 4 FrameTime: 250.000 ms
        [shadow] <default>: FPS: 132 FrameTime: 7.576 ms
        [refract] <default>: FPS: 20 FrameTime: 50.000 ms
        [conditionals] fragment-steps=0:vertex-steps=0: FPS: 243 FrameTime: 4.115 ms
        [conditionals] fragment-steps=5:vertex-steps=0: FPS: 63 FrameTime: 15.873 ms
        [conditionals] fragment-steps=0:vertex-steps=5: FPS: 231 FrameTime: 4.329 ms
        [function] fragment-complexity=low:fragment-steps=5: FPS: 135 FrameTime: 7.407 ms
        [function] fragment-complexity=medium:fragment-steps=5: FPS: 64 FrameTime: 15.625 ms
        [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 132 FrameTime: 7.576 ms
        [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 116 FrameTime: 8.621 ms
        [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
        =======================================================
                                          glmark2 Score: 146
        =======================================================
        Like • Show 0 Likes0
        Actions
sanjeev sharma Jul 19, 2018 11:36 PM
Mark Correct
Correct Answer
I discussed this issue with QT Community on #IRC channel(qt-labs) and described them this issue in detail. As per Thiago Macieira(Software Architect at Intel; Open Source advocate), The bug is not in Qt Code. GPU Vivante driver seems has some issues. This is caused by a race condition between the main thread and thread 2 (the thread that crashed). Thread 2 looks like it's about to destroy the EGLSurface for this wl_surface which already got destroyed)

He pointed out that "Main thread is doing a usleep() indicates that this software package has issue"
In backtrace he pointed out below section of code snippet which creating issue, mainly gcoOS_Delay which is highlighted.
#1 0x75dc7420 in usleep (useconds=useconds@entry=10000) at /usr/src/debug/glibc/2.24-r0/git/sysdeps/posix/usleep.c:32
ts =
{tv_sec = 0, tv_nsec = 10000000}
#2 0x755d7574 in gcoOS_Delay (Os=Os@entry=0x0, Delay=Delay@entry=10) at gc_hal_user_os.c:4033
_user_ = 1 '\001'
_user_ptr_ = <synthetic pointer>
#3 0x75503cf8 in _DestroySurfaceObjects (Thread=Thread@entry=0x3e2f4, Surface=Surface@entry=0x6636bc7c) at gc_egl_surface.c:1123
i = <optimized out>
status = gcvSTATUS_OK
#4 0x75503f80 in _DestroySurface (Thread=Thread@entry=0x3e2f4, Surface=Surface@entry=0x6636bc7c) at gc_egl_surface.c:2316

In my opinion,We can't insert delays/sleeps in our code, if we need to support multi-threading properly. since the crashing thread is running software from the same package that isn't doing multi-threading correctly, So problem looks like improper multi-threading.

Any input would be highly appreciated.
Like • Show 0 Likes0
Actions
sanjeev sharma Jul 31, 2018 2:22 AM
Mark Correct
Correct Answer
Hello All,

is anyone from NXP who can look and help in this issue.

Regards
Sanjeev Sharma
Like • Show 0 Likes0
Actions
- Prabhu Sundararaj @ sanjeev sharma on Aug 1, 2018 7:06 AM
  Mark Correct
  Correct Answer
  Hi Sanjeev,
  Could you please try with our latest 6.2.4P1 release with weston 4.0. There are lot improvements in the EGL related to buffere management.
  
  may be you can send the test binary it will be quick to test.
  Like • Show 0 Likes0
  Actions
  - sanjeev sharma @ Prabhu Sundararaj on Aug 6, 2018 7:50 AM
    Mark Correct
    Correct Answer
    Thanks Prabhu,
    
    please find attached test binaries.
    #XDG_RUNTIME_DIR=/var/run compositor -platform eglfs #XDG_RUNTIME_DIR=/var/run client -platform wayland
    
    By iterative clicking with your finger at the red rectangle and the created yellow rectangle, you can reproduce the crash.
    
    Note: compositor is based on QtWayland.
    
    Thanks in advance.
    Attachments
    test_binaries.tar.gz900.0 KB
    Like • Show 0 Likes0
    Actions
    - Chingling Wang @ sanjeev sharma on Aug 16, 2018 12:48 PM
      Mark Correct
      Correct Answer
      Hi, Sharma,
      How can I unzip the attached binary? tar, bzip2 and window unzip are not working.
      Thanks
      Like • Show 0 Likes0
      Actions
  - sanjeev sharma @ Prabhu Sundararaj on Aug 13, 2018 12:05 AM
    Mark Correct
    Correct Answer
    Hi Prabhu,
    Did you get time to execute test binary on 6.2.4P1 release ?
    I would really appreciate your feedback here.
    Regards
    Sanjeev Sharma
    Like • Show 0 Likes0
    Actions
    - Chingling Wang @ sanjeev sharma on Aug 17, 2018 12:53 PM
      Mark Correct
      Correct Answer
      Hi, Sharma,
      How can I unzip the attached binary? tar, bzip2 and window unzip are not working.
      I can clone your gitHub, But, could you give me the instructions how to build it for imx6q?
      
      Thanks
      Like • Show 0 Likes0
      Actions
      - sanjeev sharma @ Chingling Wang on Aug 29, 2018 12:43 AM
        Mark Correct
        Correct Answer
        Hi, Wang,
        i am attaching unpack binaries for your reference. please try it and let me know.
        Regards
        Sanjeev Sharma
        Attachments
        compositor.zip91.0 KB
        client.zip222.2 KB
        Like • Show 0 Likes0
        Actions
        Chingling Wang @ sanjeev sharma on Aug 29, 2018 1:46 PM
        Mark Correct
        Correct Answer
        Are your running commands:
        XDG_RUNTIME_DIR=/var/run compositor -platform eglfs &
        
        XDG_RUNTIME_DIR=/var/run client -platform wayland ?
        
        This is wayland backend, it cannot find or load eglfs plugin, I got error. And
        
        I tried this way
        ./compositor -platform wayland &
        ./client -platform wayland
        
        When I touched red rect, a yellow rect appears, no crash. The gpu I used is 6.2.4.p2, I used the latest sum xwayland sd card image.
        Like • Show 0 Likes0
        Actions
        sanjeev sharma @ Chingling Wang on Aug 29, 2018 10:08 PM
        Mark Correct
        Correct Answer
        Thanks Wang, you have to run client with wayland plugin only.
        ## Test Setup
        - run compositor:
        XDG_RUNTIME_DIR=/var/run compositor -platform eglfs &
        - run client:
        XDG_RUNTIME_DIR=/var/run client -platform wayland
        
        Note: Compositor is based on QtWayland Qt 5.9.
        
        ## Trigger the Crash
        - touch on the red window creates another green window
        - touch an a green window destroys the latest green window
        
        For performing the crash, just click on the red window, then the green (if it did not crash yet, repeat this).
        After a couple of attempts, I get the crash.
        
        We have tried 6.2.4P1 at our end. Compositor runs fine but client stuck after clicking 1 or 2 iteration, we don't see any crash but client is not taking more clicks(input).
        Like • Show 0 Likes0
        Actions
        sanjeev sharma @ Chingling Wang on Aug 30, 2018 12:43 AM
        Mark Correct
        Correct Answer
        Hi Wang,
        From where we can download gpu version 6.2.4.p2.
        Like • Show 0 Likes0
        Actions
        Chingling Wang @ sanjeev sharma on Aug 30, 2018 3:24 PM
        Mark Correct
        Correct Answer
        I can only run this way:
        ./compositor &
        ./client.
        
        my system cannot recognize XDG_RUNTIME_DIR=/var/run, and default qt plugin is wayland, --platform eglfs will return error.
        
        I ran my way, yes I saw red rectangle, touch it, got green one, touch the green one, it became yellow and disappear. I tried many times, no crash.
        
        p2 is not released yet, date is Nov 14.. If you cannot wait, I can try to see if there are patches to fix this issue and built gpu p1 with patches. If this not working, I can build gpu p2 driver binaries and gave p2 gpu driver kernel code so that you can replace gpu libs and rebuild your kernel image with gpu kernel p2.
        
        I just tried p1, it also works OK, no seg fault. Behaves the same as p2.
        the gpu version: Galcore version 6.2.4.150331
        And, BSP is NXP i.MX Release Distro 4.9.88-2.1.0 imx6qpdlsolox ttymxc0.
        
        Where do you download the BSP with p1?
        Like • Show 0 Likes0
        Actions
        sanjeev sharma @ Chingling Wang on Aug 31, 2018 12:26 AM
        Mark Correct
        Correct Answer
        Really appreciated your prompt reply.
        
        Still your and our environment is not the same to reproduce the problem.
        As i said, compositor binary, you are running is own created compositor using Compositor API based on QtWayland Qt 5.9.This represent the server side of Wayland. These type of use case do not use the wayland platform plugin, Generally this is going to be eglfs,however to reproduce the problem, please enable --platform eglfs at your end to run the compositor.
        
        In your case, you are running a nested compositor because you are running QT wayland compositor binary with the wayland platform plugin along with default Weston compositor in background.
        
        In our case we don't use default Weston compositor,instead we are using own created Wayland compositors based on 5.9.
        Like • Show 0 Likes0
        Actions
Chingling Wang Aug 31, 2018 9:12 AM
Mark Correct
Correct Answer
Can you share me how to set up these environment? I don't know how to make both eglfs and wayland plugin working at the same time. I can only test in our available environment. Or you can give me your images so that we can concentrate on gpu side. It is always painful experience to build user flavored image by myself, usually lots of failures to overcome every time.

And, what did you see when you do dmesg |grep galcore

Thanks
Like • Show 0 Likes0
Actions
- Andreas Cord-Landwehr @ Chingling Wang on Sep 3, 2018 12:36 AM
  Mark Correct
  Correct Answer
  Chingling Wang, actually you do not have to setup both, since the QtWayland Compositor from the example is a fully self-contained Wayland compositor that creates the wayland-0 socket. However, the QtWayland Compositor renders on EGL via the Qt platform abstraction EGLFS.
  
  So, the setup is as follows:
  1. disable Weston (or any other compositor) that is running on your image
  2. run the compositor from the example with the parameter "-platform eglfs" (note the single dash; there is a typo in Sanjeev's post); this command then creates a Wayland compositor and you should see a colored background; this compositor creates the default Wayland socket to which Wayland client applications can bind
  3. run the client application with the parameter "-platform wayland", which then binds to the default Wayland socket that is created by the compositor
  
  Moreover, check your Qt configuration that actually "eglfs" option is enabled for your build.
  Like • Show 0 Likes0
  Actions
  - Chingling Wang @ Andreas Cord-Landwehr on Sep 4, 2018 9:36 AM
    Mark Correct
    Correct Answer
    I tried stop weston
    systemctl stop weston
    Then I run XDG_RUNTIME_DIR=/var/run ./compositor -platform eglfs &, I still got error. This application failed to start because it could not find or load the Qt platform plugin "eglfs"
    
    I also tried export QT_QPA_PLATFORM=eglfs, the same error.
    
    It looks like eglfs option is not enabled in our build, I experienced so many "not accessible" error when I build my own yocto,
    And it may seems silly, I don't know to enable both eglfs and wayland in yocto build.
    
    Could you share me your image so that we can concentrate on gpu side. I don't think it is good idea to take pains to set up your enviroment.
    
    Thanks
    Like • Show 0 Likes0
    Actions
    - sanjeev sharma @ Chingling Wang on Sep 12, 2018 4:51 AM
      Mark Correct
      Correct Answer
      you mean to say complete yocto image environment ?
      @Andreas Cord-Landwehr please provide the image, if possible.
      Like • Show 0 Likes0
      Actions
      - Chingling Wang @ sanjeev sharma on Sep 12, 2018 12:57 PM
        Mark Correct
        Correct Answer
        Yes.
        In our build, we only have wayland qt5 plugin, not eglfs.
        eglfs plugin is for FB backend. wayland interfaces frame buffer through weston compositor which makes more sense.
        If both eglfs and wayland exist, there are two processes that will interact with frame buffer, it doesn't make sense.
        Do you have any special reason to run your application using eglfs plugin and wayland plugin? You cannot run all applications in wayland plugin?
        Since we don't build this way, you need either to show me how to enable both in yocto build or giving the sd card image you are using so that I can reproduce the issue.
        
        Thanks
        Like • Show 0 Likes0
        Actions
        Andreas Cord-Landwehr @ Chingling Wang on Sep 13, 2018 10:13 AM
        Mark Correct
        Correct Answer
        Chingling Wang, I think there is a big misunderstanding. Let me try to explain the big picture.
        
        The scenario, we are looking at:
        1. there is a device with i.MX6 that provides
        2. there are multiple applications with multiple windows that we want to render. Thus, we need a compositor to compose them next to each other. With today's technologies it only makes sense to use a Wayland compositor (no X11).
        3. there are certain functionalities that we want to have in the compositor, which are not supported by Weston. That is the reason why we are NOT using Weston. Instead, we are using ANOTHER Wayland compositor (note that Weston is not the only Wayland compositor, but one of many different existing ones). Our choice is to use the QtWayland Compositor (actually, we are extending the basic QtWayland compositor with the features we need).
        
        Now, the graphics stack is as follows:
        - Vivante provides EGL
        - the QtWayland compositor directly renders at EGL via EGLFS; QtWayland compositor acts as the Wayland compositor for the system
        - the applications let their windows be rendered by the QtWayland compositor
        
        Does that make sense for you or do you have any problems with that?
        There are many projects around that have the stack exactly like this.
        
        The following two packageoptions for the qtbase Yocto recipe should activate the eglfs support:
        PACKAGECONFIG_GL = "gles2"
        PACKAGECONFIG += "eglfs"
        
        You can check that the options are correctly picked up by looking into the config.summary file in the Yocto build folder for package qtbase.
        
        Best regards,
        Andreas
        Like • Show 0 Likes0
        Actions
      - Andreas Cord-Landwehr @ sanjeev sharma on Sep 13, 2018 10:13 AM
        Mark Correct
        Correct Answer
        We have to look at some legal topics to check if that is possible.
        Like • Show 0 Likes0
        Actions

Bug in Vivante i.MX6 Wayland drivers when destroying windows

Outcomes

Attachments

Attachments

Attachments

Related Content

Recommended Content