[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep application not running on machines with NVIDIA Optimus chip
Re: gnustep application not running on machines with NVIDIA Optimus chipset
Wed, 14 Dec 2011 14:05:46 +0100
> impressive how you come up with all these interesting issues
i wish i wouldn't be that impressive ;-)
> I think this time the default screen selection of GNUstep is causing you
> trouble. In most cases the default screen should be 0, but for this
> optimus technology things seem to be different. You should have a look
> at the code in XGServer.m, specifically at _initXContext, here we select
> the default screen to use.
> The first thing to test is to start the application with
> --GNU-Debug=dflt (See
> This should report back which screen gets used. Best pipe the error
> output stream into a file as we are currently a bit verbose (and also
> get quite a few errors report that way that I will have to look into).
> This is the line we are interested in:
> Opened display :0, display 0 screen 0
thanks for your information.
unfortunately i don't have the affected hardware, so i am unable to directly
fortunately the very same crash appears also on other hardware when just using
"VirtualGL" (which the NVIDIA Optimus support project Bumblebee uses) to launch
the output of "vglrun ./CoreBreach.sh --GNU-Debug=dflt" is
Initializing GNUstep x11 backend.
Opened display :0.0, display 0 screen 0
however, VirtualGL/vglrun doesn't set DISPLAY to something other than 0:0
(which i guess bumblebee does) and there also isn't an additional x-server
involved. but since the crash is the very same it doesn't seem to be related to
the screen number at all.
the good news to the GNUstep project is that other gnustep apps (helloworld)
run fine using vglrun, so they probaby run fine on bumblebee too.
i've filed a bugreport at bumlebee here - there is already some additional
Description: S/MIME cryptographic signature