It appears that bumblebee requires a display manager to run (e. g. xdm), but the bumblebee ebuild does not depend on a display manager. bumblebee didn't work for me until I installed xdm (I am simply using startx). /etc/init.d/bumblebee also says "need xdm vgl" in the depend() function.
xorg-server is the one providing the init.d service now, on the other hand, people running systemd will need to install the DM they want to use... and that is up to them :|
Actually, no, this is a packaging mistake. There's no reason why bumblebee would require xdm or vgl service started; no other distro does that, and Gentoo shouldn't as well. I've corrected the ebuild in the bumblebee overlay accordingly 5 months ago.
(In reply to Alexander Monakov from comment #2) > Actually, no, this is a packaging mistake. There's no reason why bumblebee > would require xdm or vgl service started; no other distro does that, and > Gentoo shouldn't as well. I've corrected the ebuild in the bumblebee > overlay accordingly 5 months ago. It is not true. VirtualGL requires XAUTHORITY to be set, but that is generated only when xdm starts. That was the reason for the dependency. It is possible to run it without xdm, but then you have to make sure yourself that XAUTHORITY is set correctly.
Reinis, you're mixing two different problems together. VirtualGL requires xauth set up when used as originally intended: as a tool letting a remotely logged in user to use a local X server for accelerated rendering. Note that a remotely logged in user normally wouldn't have a security token to access the local X server, which is why VirtualGL is supplied its own. However, in Bumblebee's use case, VirtualGL needs to access the bumblebee-started secondary X server (display :8), which won't even have xdm running, ever. It makes no sense to generate an xauth token for VirtualGL in this case, because the token is for the wrong X server (:0 instead of :8). Therefore, bumblebee service does not need to depend on either vgl or xdm services. Keeping vgl depend on xdm is ok for me.
(In reply to Reinis Danne from comment #3) > It is not true. VirtualGL requires XAUTHORITY to be set > VirtualGL requires > VirtualGL Not BumbleBee. Bumblebee even doesn't need exactly VGL anymore. It will work fine even with primus. So, not. This bug is INVALID || WONTFIX.
This bug is valid in the sense that "need xdm vgl" in /etc/init.d/bumblebee:depend is not helping and needs to be removed.
Created attachment 368482 [details, diff] new bumblee.initd mva I think your totally misunderstanding the origonal bug post.. this seems totally reasonable... please pull from overlay....
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #5) > (In reply to Reinis Danne from comment #3) > > It is not true. VirtualGL requires XAUTHORITY to be set > > VirtualGL requires > > VirtualGL > > Not BumbleBee. Bumblebee even doesn't need exactly VGL anymore. It will work > fine even with primus. > > So, not. This bug is INVALID || WONTFIX. you made this same response on github.. primus isn't even in portage tree, nor is it anywhere near stable... as package maintainer you should try remain reasonable about this.. bumblebee still supports virtualgl and so should you.
> mva I think your totally misunderstanding the origonal bug post.. this seems > totally reasonable... please pull from overlay.... As you should be noticed, I'm gentoo maintainer, but I'm not in-tree maintainer. Bumblebee in-the-tree exists using Pacho Ramos as a proxy-maintainer. Will it be my will, I'd already sent requests stabilize primus in the tree long time ago. But I can't force Pacho to do that. So, my responsibility ends up in bumblebee repo. // Although, I can finish quizes and become a developer, but I have totally no time for that. Talking on vgl: yes, as you probably noticed too, bumblebee in-gentoo still supports vgl (as far as original Bumblebee do). But preferable way in both cases is to use Alexander Monakov's primus, since it has no overhead, has much better performance and so on. Talking on vgl again: I doesn't prohibit anyone from using vgl. Moreover, I've fixing vgl init-script time-to-time, but I prefer primus myself and *recommend* at least to try it to all users compaining VGL.
and, also: I responded so harshly (about WONTFIX||INVALID) just because I've already tired with that VGL xauthority issue, that goes from antient times, while primus has nothing similar to that issue. Anyway, yes, I'm sorry for my harshness.
(In reply to Harvey Mittens from comment #8) > you made this same response on github.. > primus isn't even in portage tree, nor is it anywhere near stable... as > package maintainer you should try remain reasonable about this.. > > bumblebee still supports virtualgl and so should you. Why do you say primus is nowhere near stable? With the excpetion of bbswitch bumblebee is far less useful without it. What would it take to get primus in the portage tree. Ubuntu has it in it's stable repos so I would think that it's mature enough to be in the portage tree (mark it as as ~ if it makes you feel better).
