Jetpack 4.3 eglInitialize occasionally hangs thread in a new Weston Wayland window


We are using the Weston 6.0 version that comes with Jetpack 4.3 to create a window using the Wayland-EGL API. After creating the window, we initialize EGL:

  EGLNativeDisplayType eglDisplay = m_pDisplay;
  m_Display = eglGetDisplay( eglDisplay );

  if( m_Display == EGL_NO_DISPLAY )
    throw std::runtime_error( "Failed to get EGL display" );

  if( !eglInitialize( m_Display, NULL, NULL ) )
    throw std::runtime_error( "Failed to initialize EGL" );


This usually works, and our application can run and render without a problem. However, we use an HDMI switch between two TX2is. Because of a Weston bug, after an HDMI hot plug the rendered window is shifted ~50% offscreen and the API calls to move or make if fullscreen do not work. You can destroy and recreate the window as a workaround, but in that case you must also re-initialize EGL for the new window. Occasionally when re-initializing EGL, the main thread hangs upon calling eglInitialize(). To my understanding, this should never happen.

I make sure to free the existing EGL resources when destroying the window, and because this failure can happen on the 1st or 2nd time creating the window I don’t believe it is the cause of a GPU memory leak. I also verify that EGL is no longer using the window before destroying it, and that the window is valid before trying to initialize EGL in it.

Though this issue is an edge case, it happens frequently enough that it is a serious issue for us. I don’t believe it is due to destroying and re-creating the window, rather that we stumbled upon this issue because destroying and re-creating the window gives it more chances to occur. Bottom line if eglInitialize() fails, it is supposed to return false and maybe set an error. It should not hang unless something more serious is going on.

TLDR: The eglInitialize() function sometimes causes the thread it is run from to hang. To my understanding this is not expected behavior of the EGL API. What are your thoughts on a potential cause?

1 Like

We would need a test sample so that we can reproduce it and investigate further. Would need your help to share a test sample.

So I work with Dylan and would like to know what you mean by that? @DaneLLL

We have guidance of starting Weston and running with nveglglessink in developement guide

And samples in


Would need your help to share a patch on the existing sample so that we can reproduce the hang issue.

I just got back to work on this issue. At this point I have recreated the issue with weston where hotplugging the monitor shifts the window off-screen.

Steps to re-create:

  1. Launch weston (steps can be found in the development guide)

  2. Launch the gearscube sample application
    cd /usr/src/nvidia/graphics_demos/prebuilts/bin/wayland
    ./gearscube -windowsize 1920 1080

  3. Turn off the display

  4. Turn on the display ( this triggers the hot plug event )

Sometimes this crashes the gearscube sample application. This may be related to weston itself crashing. We have weston running as a systemd service so it always comes back up. You can repeat turning the monitor off then on until the application does not crash, then you will see the shifted window.

Window before turning display off then on:

Window after turning display off then on:

Note that we have customized the weston desktop to be all black. If we had a background image you would see it in the second picture. I will now try to re-create the issue where eglInitialize() appears to hang the thread.

Due to the Weston bug shown above and the fact that Wayland Gnome has a bug where locking the screen or monitor hot-plugging breaks Gnome (see this post), I decided to switch to using X11 + Gnome. I don’t have funding to investigate the potential eglInitialize() issue, so this thread has run its course.


Would like to confirm the two steps. Do you mean pressing power button of the monitor to turn the monitor off and on?

We have tried r32.3.1 and r32.4.2. It is seen on r32.3.1 and cannot be reproduced on r32.4.2. Since r32.4.3 is around the corner, would suggest you upgrade to new release.

Yes that is what he meant. This will hot plug the monitor.

Do you see any stability issues in terms of the sample software crashing? I know that when I was reproducing the issue, the application would usually crash. I think this is due to weston itself crashing during hot plug events.

I know that weston was improved quite a bit when going from Jetpack 4.2 to Jetpack 4.3 ( I think it went from v3.0 to v6.0 ), and its good to see that it is still being worked on.

On Jetpack 4.3, we observe the second picture in the comment but the application gearscube keeps running. Don’t hit segment fault.

We have released Jetpack 4.4 Production Release. Please upgrade and give it a try.