Using a display connection name fails (through NewtFactory)

CONTENTS DELETED

On 06/05/2013 03:40 PM, neothemachine [via jogamp] wrote:
> Hi
>
> I tried to use Newt with a custom display connection (use case: xvfb):
>
> Display display = NewtFactory.createDisplay(":99.0");
> Screen screen = NewtFactory.createScreen(display, 0);
> GLWindow window = GLWindow.create(screen, ..);
>

We have 2 unit tests, which shall work if executed manually
(see arguments of main).

TestRemoteGLWindows01NEWT.java
TestRemoteWindow01NEWT.java

It would be great, if you can create a bug report and add a tiny unit tests
provoking this threading issue.

Thank you.

~Sven

CONTENTS DELETED

Sorry. If you want, I can make a better patch before the end of the week.

@Sven please push another Maven build when you can. I know you're busy.

CONTENTS DELETED

You can pass an instance of AbstractGraphicsDevice when getting a GLProfile in CapsUtil (Ardor3D). If it doesn't solve your problem, there is something wrong in JOGL 2. Please can you reproduce your bug with a pure JOGL test case?

CONTENTS DELETED

On 06/09/2013 07:17 PM, neothemachine [via jogamp] wrote:
> @Sven Just one more question for clarification: Is it definitely
> possible with JOGL 2 to use a custom display connection _without_ having
> a default device configured (in Linux through the DISPLAY environment
> variable)?
>

1st: One default DISPLAY [must|should] be given to allow
     the default-device query - which should not be empty!
     We could change code .. but this somewhats makes things complicated.

2nd: You are able to use other devices than the default
     (currently _only_ on X11).
     I tested w/ the named unit tests TestRemoteGLWindows01NEWT, TestRemoteWindow01NEWT
     a while ago w/ another remote NV GPU.
     I have to admit, AMD to NV didn't work w/ the GLX protocol.

3rd: I have not tested [xvfb + mesa-soft] yet.
     Can you elaborate on this configuration ?
     I.e. post the 'glxgears -info' on that remote connection
     to your xvfb.
     I will the go ahead and test it.

Have you already added a bug report ?
Please do so, if not done yet - and pls use a simple JOGL unit test,
like
  com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
  com.jogamp.newt.opengl.GLWindow

you can see/edit them in
  jogl/make> vi scripts/tests.sh

and start them:
  jogl/make> bash scripts/tests-x64.sh

given that you have build the beast, and java/ant env. vars configured.

~Sven

CONTENTS DELETED

On 06/09/2013 08:52 PM, neothemachine [via jogamp] wrote:
> Sven Gothel wrote:
>> 1st: One default DISPLAY [must|should] be given to allow
>>       the default-device query - which should not be empty!
>>       We could change code .. but this somewhats makes things complicated.
>
> Ok, and when you say [must|should] be given, what does "given" refer to
> (for Linux)? I think you refer exclusively to the DISPLAY environment
> variable, right?
Yes.

> And a code change would be necessary to allow
> specifying the default device _within_ JOGL, right?

Yes.

A code change would also be required to not require a
valid default device in JOGL. Maybe it works already,
but not tested.

On X11, the default device is specified w/ the DISPLAY
environment variable, as the X11 spec states.

Note: I use the term 'remote' device (or better display server)
for all devices but the default, whether they are 'local' or not.

.. maybe I am too much exposed w/ networking stuff :).

>
>> 2nd: You are able to use other devices than the default
>>       (currently _only_ on X11).
>
> My use case does not include other devices, but just a single one (the
> xvfb display) --
Now I get it :)

Here .. as you state, it's the default device, set w/ DISPLAY .. and works.

> as the code is ultimately run on a server which doesn't
> have a regular hardware graphics device. The exception I referred to at
> the beginning actually only occured on my laptop where I _do_ have a
> default device in addition to the xvfb one (DISPLAY was set to :0, and
> through NewtFactory.createDisplay(":99.0") I used the "other" device). I
> can submit a bug report (in a while) for the exception but ultimately
> this is not my use case.

Yes, that is the erroneous case here.
I.e. you should work, i.e. able to explicitly connect to your 'remote' X11 server.
I don't know whether that works w/ JOGL, i.e. not a DISPLAY
specified for JOGL (see above).

>
> The whole fuzz is about the last point. If I just set the DISPLAY
> variable to :99.0, then JOGL is happy and everything works.
Yup.

> In my case
> though, it is quite inconvenient to set the DISPLAY variable because it
> complicates the automatic deployment and setup in our infrastructure --

The issue here is, that we query information at startup,
for which we do need the X11 server's default connection.
The latter (as stated above) is specified w/ env. var DISPLAY.

> compared to other (Java) server applications which are solely configured
> through configuration files that are then read on program start.
Well, then specify DISPLAY at startup :)
Note: JOGL is not exactly a server application .. but, well :)

> The
> programs itself can't influence their startup procedure (and with that
> environment variables) easily.

So before you launch JOGL, simply set the environment variable DISPLAY.

We could also work together to utilize a fall-back property,
but you would need to introduce it.
IMHO it is also possible to specify the DISPLAY env. var from Java itself,
i.e. before you initialize JOGL .. (e.g. via GLProfile.initSingleton()).

>
> Regards
> Maik
>
> PS: The output of 'glxgears -info' with DISPLAY set to :99.0, in case
> you still like to see it (don't be confused by 'VMware, Inc.', they are
> just the developers of the Gallium3D API):

Yup - thx.

All in all .. it's not a bug - but some 'misunderstanding'.

So .. let me know what way you prefer and how we can assist.

Cheers, Sven

CONTENTS DELETED

On 06/09/2013 11:10 PM, neothemachine [via jogamp] wrote: Though we have something like 'System.setenv("DISPLAY")' :)
At least from jenkins, as well as w/ glassfish you can set
environment vars .. well.
Ok .. pls file a bugreport as an enhancement,
then we can follow on this.
Pls. add your feature request in the bug report,
your description above is very well.

Even though you don't feel confident participating
in the implementation .. maybe you still like to try.

However, it's not a 1st prio feature .. but it will be done eventually.

Thank you.

Cheers, Sven

>
> Cheers
> Maik

CONTENTS DELETED

CONTENTS DELETED

On 06/10/2013 09:36 PM, neothemachine [via jogamp] wrote: ofc ..

- junit.run is the offical way to run _all_ unit tests.

- scripts/* are my private stash of 'convenient' build and test scripts.

- Note: Our builds environment is able to build multiple targets to their
        respective build folder to simplify building/testing for different
        OS and architectures.

- scripts/tests-x[32|64].sh
  - run a single test w/ given properties to enable debug

  - assume either build-x32 builds via scripts/make.jogl.all.linux-x86_64.sh, or
    build-x32 via scripts/make.jogl.all.linux-x86.sh
 
  - my build/test scripts utilize our ant build-time properties
      - rootrel.build  - to specify the build directory
      - os.arch - to force a 32bit build on 64bit OS
      See 'Note' above

  - when using the scripts/* stuff, pls check the scripts themselves and
    the locations/folder ..

  - I for example use the x86_64 build scripts and have a symbolic link to 'build',
    allowing eclipse workspace to pick it up.

       build -> build-x86_64

~Sven

CONTENTS DELETED

CONTENTS DELETED

CONTENTS DELETED

CONTENTS DELETED

On 06/12/2013 04:14 PM, neothemachine [via jogamp] wrote: if that works well w/ you - KUDOS, it's a small and smart change.

pls verify and send a git pull request.

~Sven