Exporting and running a processing 3 sketch in "presentation" mode using Eric Anholt's "experimental" X11 glamour vc4 driver on a raspberry pi triggers the following error: FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable at jogamp.newt.driver.x11.WindowDriver.CreateWindow0(Native Method) at jogamp.newt.driver.x11.WindowDriver.CreateWindow(WindowDriver.java:445) at jogamp.newt.driver.x11.WindowDriver.createNativeImpl(WindowDriver.java:130) at jogamp.newt.WindowImpl.createNative(WindowImpl.java:460) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:975) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1026) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:150) - locked <0x65a60628> (a java.lang.Object) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) The processing 3 presentation mode is intended to create a fullscreen window with the sketch in the middle. I need to check the processing 3 codebase if it have tried to mix AWT and NEWT in a way that may cause the AWT to lock the X11 resources.
I am seeing this issue also (randomly) when running sketches outside of presentation mode (with processing-java ... --run). Thinking this could perhaps be a timing related thing, where you might see it more often with exported sketches since they start up faster (or do fewer context switches because they include less threads than the IDE & processing-java ons)?
It would be nice, if this can be reproduced w/ our unit tests or a new unit test! Do this bug only trigger when using Eric Anholt's "experimental" X11 glamour vc4 driver? Can this bug be reproduced using a "regular" raspbian system using the X11 framebuffer driver without the /opt/vc driver?
(In reply to comment #2) > Do this bug only trigger when using Eric Anholt's "experimental" X11 glamour > vc4 driver? Yes, this bug is confined to the experimental X11 glamour vc4 driver. The "Resource temporarily unavailable" error is returned from X11 to NEWT Thus the root cause of this bug is likely inside the X11 glamour driver. > Can this bug be reproduced using a "regular" raspbian system using the X11 > framebuffer driver without the /opt/vc driver? No. The exported processing 3 application runs fine using presentation mode using a "regular" raspbian system using the X11 framebuffer driver + mesa3d software rasterizer.
(In reply to comment #3) > (In reply to comment #2) > > Do this bug only trigger when using Eric Anholt's "experimental" X11 glamour > > vc4 driver? > > Yes, this bug is confined to the experimental X11 glamour vc4 driver. > > The "Resource temporarily unavailable" error is returned from X11 to NEWT > Thus the root cause of this bug is likely inside the X11 glamour driver. > > > Can this bug be reproduced using a "regular" raspbian system using the X11 > > framebuffer driver without the /opt/vc driver? > > No. The exported processing 3 application runs fine using presentation mode > using a "regular" raspbian system using the X11 framebuffer driver + mesa3d > software rasterizer. Hence the culprit could be either the 'X11 glamour' driver, _or_ the underlying 'VC4 OpenGL driver blob'. -> confirmed: since Xerxes can reliably produce this issue. Since this bug seems not to be ours, we can now either: - create a workaround or - simply reject this bug as invalid In any case, pls notify the author of 'X11 glamour' driver - maybe he can figure out the culprit and even fix it.
(2015-08-21 00:10:31) xranby_: sgothel: 1187 i can occasionally reproduce it but i have no clue what possible call from newt -> x11 cause x11 to return this (00:12:31) sgothel: hmm .. Xsync .. one sec .. (00:13:10) sgothel: -Dnativewindow.debug.X11Util.XSync (00:13:30) sgothel: ^^ test w/ that .. i.e. enables XSync .. i.e. x11 protocol w/ wait for reply always .. (00:13:46) sgothel: this shall give the x11-error when it happens .. if at all (00:14:03) sgothel: it is also an indication that communication is somewhat .. odd