Re: Using a display connection name fails (through NewtFactory)
Posted by Sven Gothel on Jun 09, 2013; 8:31pm
URL: https://forum.jogamp.org/Using-a-display-connection-name-fails-through-NewtFactory-tp4029333p4029361.html
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.
>
>> 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'm not sure why you call it a "remote" connection. In my case, it is
> the only one on the server and I would say it's just a regular local
> connection.
>
> Let my clearly state my use case again:
>
> I run a Java renderer using JOGL 2 on a headless server, which:
> - uses Linux
> - has no graphics card
> - has an xvfb renderer running at display :99.0
> - has _no_ DISPLAY variable configuredI 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
URL: https://forum.jogamp.org/Using-a-display-connection-name-fails-through-NewtFactory-tp4029333p4029361.html
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.
>
>> 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'm not sure why you call it a "remote" connection. In my case, it is
> the only one on the server and I would say it's just a regular local
> connection.
>
> Let my clearly state my use case again:
>
> I run a Java renderer using JOGL 2 on a headless server, which:
> - uses Linux
> - has no graphics card
> - has an xvfb renderer running at display :99.0
> - has _no_ DISPLAY variable configured
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
signature.asc (911 bytes) | Free forum by Nabble | Edit this page |