SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a new laptop with the Optimus technology. I followed a tutorial on the Slackware Documentation Project and it looks like everything went ok. Still I can't seem to switch to the nvidia card. Perhaps I'm missing the point but I thought that if a command is preceded with primusrun, it will activate the nvidia card (see the glxgears output below - it doesn't seem to happen for me). As per the tutorial, I've disabled nouveau and installed the nvidia binary driver as described in the tutorial.
sycamorex@slackdell:~$ optirun
[ 704.138302] [ERROR]Missing argument: application to run
Try `optirun --help' for more information.
sycamorex@slackdell:~$ optirun glxgears -info
[ 714.092410] [ERROR]No bridge found. Try installing primus or virtualgl.
sycamorex@slackdell:~$ ls /var/log/packages | grep primus
primus-0.1.4-x86_64-1_bbsb
primusrun glxgears -info (looks like the intel card is in operation)
I think it is working. If you run a 3D program without prefixing it with primusrun/optirun, then it will fail. The fact that glxgears worked means that you did it right. You will never see millions of frames per second, as the actual update of the memory buffer (from nvidia) to your display card (intel) will only take place at most about 60 times per second. Which is (I think) faster than your eye can perceive, hence the reason that they can pull off this trick. I still hate the whole concept. When I recently rebuilt my laptop from scratch (new slack 14.1, new hybrid hdd) I scrapped optimus and just setup the intel graphics. I don't play games, so it suits me fine.
I think it is working. If you run a 3D program without prefixing it with primusrun/optirun, then it will fail. The fact that glxgears worked means that you did it right. You will never see millions of frames per second, as the actual update of the memory buffer (from nvidia) to your display card (intel) will only take place at most about 60 times per second. Which is (I think) faster than your eye can perceive, hence the reason that they can pull off this trick. I still hate the whole concept. When I recently rebuilt my laptop from scratch (new slack 14.1, new hybrid hdd) I scrapped optimus and just setup the intel graphics. I don't play games, so it suits me fine.
Thank you for your reply. Hmmm, I just ran glxgears without prefixing the command and got exactly the same output. ???
The output can be confusing tho, but it is I think working properly.
In short, primusrun (which should at this point always be used as the other is just... slow now) renders on the nvidia card, then pushes the image THROUGH your intel to your x screen. Optirun does this as well, but as it was initially built for network streaming it adds some extra network overhead and is therefore slower.
After spending a month working with folks to improve the article, the author deleted the updates and reverted it, requiring that all future updates be put in as requests into the discussion page.
I really don't have time to deal with such folks as the author, so I just point them to my github page and it's writeup instead. I'm just not going to waste my time and have the page reverted again and again.
Glad it helped.
Last edited by WhiteWolf1776; 04-20-2014 at 06:28 PM.
After spending a month working with folks to improve the article, the author deleted the updates and reverted it, requiring that all future updates be put in as requests into the comments page.
I really don't have time to deal with such folks so I just point them to my github page and it's writeup instead.
Glad it helped.
A general rule on the SDP is that anyone should feel free to make some small changes to articles. If, however, the changes are considerable, it's recommended to discuss it with the author in the discussion tab first. I can understand, however, how frustrating it must have been for you when the author dismissed all your changes.
On the plus side, nothing is lost in dokuwiki so your version is still accessible in the 'old version' sections.
I think the subject of bumblebee is going to be increasingly important as more and more laptops are equipped with such technology so it's essential that Slackware users read correct and up-to-date information. Personally, I think SDP would benefit from your contribution as you maintain the bbsb scripts but I understand that you might be reluctant to get involved again.
In any case, thank you for maintaining the scripts and replying in this thread.
As the author of the article I feel I should clarify a few points.
1.
Quote:
WhiteWolf1776:
After spending a month working with folks to improve the article, the author deleted the updates and reverted it, requiring that all future updates be put in as requests into the discussion page.
As we discussed over IRC about your changes, I referred you to the StyleGuide for SlackDocs. sycamorex has referenced it for you again in his post:
Quote:
sycamorex:
A general rule on the SDP is that anyone should feel free to make some small changes to articles. If, however, the changes are considerable, it's recommended to discuss it with the author in the discussion tab first.
Typo changes such as the ones sycamorex and the users before him have provided have not been touched by me. As everybody wants, they improve the quality of the article.
2. Another problem that I had to deal with due to being referenced as the article's author is that the changes primarily centered around Slackware(64)-current only (this version of -current would later become Slackware 14.1). Imagine the flurry of questions I received when 13.37 and 14.0 users were pondering why their laptops running Bumblebee could not work due to the fact that mesa was not built with "--enable-shared-glapi" for all Slackware versions up until 14.1. Hence, the changes made would fail for users who were not running -current at the time as well as for users who aren't running 14.1 or newer now. Therefore it added content but did not assist in the quality of the article or users who were and are still using other stable and supported versions of Slackware.
3. I kept WhiteWolf1776's github page for those who were interested in tracking his SlackBuilds (that primarily centered around -current) back when the original creator of the Bumblebee SlackBuilds were still maintaining his scripts for Slackware's stable versions (which also worked on -current).
Later in September, WhiteWolf1776 removed his github repo from the Sources section. Because it was his repo, I felt I had no right to put his repo back in without him agreeing to it:
Quote:
2013/09/20 11:36 ... – [Sources] whitewolf1776
Because the maintainer of the original Bumblebee SlackBuilds no longer maintains them, I changed the github download link on the wiki to WhiteWolf1776's.
I would not tho understand anyone having an optimus video card setup not using at least slackware 14.1 as slackware 13.37 and 14.0's kernels had poor support for this hardware, at best. As such, I do not see it worth anyones time to continue to maintain builds for these systems as the systems would be better supported by a move to slackware 14.1
For these reasons, I have focused on the version of slackware with the best support for the systems with optimus, and left older versions of slackware alone.
I removed references to my repo from your page ealier as I was not the official maintainer of the slackbuilds and found your references to the 'other' repo pointless and confusing to new users.
As I said, do as you will with your page, I have no interest in it.
I really hope that you guys will eventually come to some sort of agreement. Probably, not here but via private messages / email / SDP discussion tabs, etc.
Listen, I'll continue to maintain these slackbuilds for 14.1+ of slackware in the best way I know how and I'll keep the write-up on my github as clear and direct as I can. Anyone that wishes can take from there as they wish and put it where they wish. I simply was giving my opinion and reasons for not adding / updating the SDP article.
Thank you for your reply. Hmmm, I just ran glxgears without prefixing the command and got exactly the same output. ???
This bit worries me. As I said before, I used to run this setup over a year ago, but no longer do so as I don't game. But my understanding was that your intel card does the actual display. Then, when you run a game (or something that requires opengl), you use opti/primusrun to access the nvidia card. This requires the opengl libraries (mesa ?) that interact with nvidia. Not the ones that interact with intel. Thus a different set of libraries, but with the same name. Hence they can't be mixed or installed simultaneously. So - if your glxgears works without prefixing 'opti/primusrun', then I suspect something is wrong and you're not actually using the nvidia card at all. However, it may well be that the latest versions of bumblebee has got this behavior correct. If so, then I'm super impressed. And thanks to whitewolf too - in the days when I did get it working, I did it all off his work. But in the year that I had the laptop, and before i installed 14.1, I never really played any games and the whole installation became moot. While programs like googleearth do use it, I found I had high temperatures in my laptop. Somehow the fan-control was never right. Now with the intel 3D stack, when I run google-earth, the performance is totally acceptable and no high temperature. I have vowed that I will NEVER buy a laptop again with this cr@ppy solution.
Yea, bumblebee / mesa / linux kernel fixed this some time back and I use the intel vid card to play some of the lower requirement / retro games in my steam account. It renders pretty well, just has a limit... i.e. dota 2 won't play at anywhere near native resolution without primus.
Pre 14.1 mesa there were issues, and from the boards newer mesa's also had issues. Looks like again Pat picked the Goldilocks spot for the release. The issues tho are being corrected and I think the latest mesa patch has things working properly again for the other distros.
Time will tell if this solution to power limitations is going to be the only option going forward, but it's gotten pretty tough to find any laptop with a different one.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
