Bug 1187

Summary:	X11 glamour vc4: X11 IOError Resource temporarily unavailable
Product:	[JogAmp] Newt	Reporter:	Xerxes Rånby <xerxes>
Component:	x11	Assignee:	Sven Gothel <sgothel>
Status:	CONFIRMED ---
Severity:	normal	CC:	gottfried.haider, xerxes
Priority:	---
Version:	tbd
Hardware:	embedded_arm
OS:	linux
Type:	---	SCM Refs:
Workaround:	---

Description Xerxes Rånby 2015-08-09 18:21:05 CEST

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.

Comment 1 Gottfried Haider 2015-08-09 18:25:41 CEST

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

Comment 2 Xerxes Rånby 2015-08-09 20:52:34 CEST

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?

Comment 3 Xerxes Rånby 2015-08-10 14:27:17 CEST

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

Comment 4 Sven Gothel 2015-08-10 22:00:55 CEST

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

Comment 5 Xerxes Rånby 2015-08-21 00:14:52 CEST

(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