On Mon, Mar 18, 2013 at 12:22 AM, Ritesh Raj Sarraf <r...@researchut.com> wrote: > On Monday 18 March 2013 11:44 AM, Vincent Cheng wrote: >> >> I wasn't actually done with primus' packaging; for some reason I kept >> on getting a strange error ("primus: fatal: failed to open secondary X >> display") every time I tried running primusrun, even though it works >> with the optirun+virtualgl backend, so I'm surprised that it worked >> for you. That prompted me to dig deeper to find out what was causing >> the issue for me; it turns out that, for whatever reason, reverting >> one of my previous changes (overriding CXXFLAGS with dpkg-buildflags' >> default build flags) fixed the problem for me, although I'm still >> unsure why build hardening flags would've been the root cause. Oh >> well... > > I already purged the virtualgl packages, so I am pretty sure that it is > using the primus backend. > >> Please pull in my latest commits and test primusrun without >> uncommenting the above line. The primusrun wrapper script should still >> work correctly. > > Yes. It works but there's a catch. See below. >>> The NEW queue is big already and there's very little progress (has to do >>> with the freeze). But you would want to push primus now for review. >> Agreed, at this point I think bumblebee and primus are ready for >> review (bbswitch is already in the NEW queue and I'm happy with it >> as-is). If you're offering to review the package and/or sponsor it, >> thanks in advance! And feel free to make changes directly in the git >> repo if you want to change anything. :) > > I am too new and haven't investigated much about this whole dual > graphics display. But I am willing to sponsor if there are no takers.
Thanks! I'll take you up on your sponsorship offer if I don't hear back from Aron in a while. :) > By the way, with bumblebee + primus installed, you still will want to > recommend users to call apps with the optirun interface. > primus just sets some library variables and calls the application. The > application is never run on the discrete nvidia card. Errr, no. As I understand it, that's exactly what primus is supposed to do (offload glx calls to nvidia card, hence the purpose of adding primus' own libGL to LD_LIBRARY_PATH). optirun just makes it convenient to switch between virtualgl or primus through a configuration setting. Try testing with: # apt-get install mesa-utils $ optirun -b primus glxgears -info $ primusrun glxgears -info They should give you the same results. Refer to the following screenshots [1] [2]. > Where as, if you run optirun (or -b primus), you will notice it running > on nvidia. > > Easiest way to verify this is to watch /proc/acpi/bbswitch when using > either of the interface. That's not reliable way of verifying this because you can force the secondary X server to be permanently on, and running on your nvidia GPU. It's as simple as s/KeepUnusedXServer=false/KeepUnusedXServer=true/ in /etc/bumblebee/bumblebee.conf, or "optirun bash". Regards, Vincent [1] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png [2] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_ta0zp6clpqsjizo5xfptftverc89y8e3tpa4xbldfl...@mail.gmail.com