I haven't seen much plans for PRIME power management outside of maybe upstreaming bbswitch into the kernel.
Is this something that won't be tackled until after on-the-fly switching?
I only mention optimus because the article talks about it. I'm on Linus' side when it comes to nvidia. It is my understanding that the AMD A6+ APUs actually can switch off the IGP when not in use, although I admit that the reference materials I've looked at may be incorrect for the sake of simplicity.
Nice job, Dave.
It's nice to see the fruits of your labor, starting to pay off. I, like someone else pointed out, probably won't be using this anytime soon - but it is something that is wanted/needed by others.
great stuff.
First of all, I'd like to give a heartfelt thanks and congratulations to everyone involved in this. It is a big achievement and is extremely important to me and many other users of notebooks with optimus graphics.
I'd like to know if this solution will work with the nvidia driver. I know there was a big license issue, and I think that this is what it was about. From what I could tell, the eventual decision was to allow the nvidia driver to use PRIME. Will it require a simple update to the nvidia driver to work, or is this something that won't be working for a considerable while?
What all would I need to install to get this running with nouveau in the meantime?
Best regards.
It requires unknown amounts of work by nvidia to make their driver work, also how to deal with the fact that nvidia trash system libraries and this means mesa's libGL will no longer work, which means your compositor won't work.
You need about 10 repos to get it working on top of Linus kernel, hopefully once its upstream in X.org this will be a bit easier. I'm not worrying abuot letting people run it before its been fully reviewed and shippable, I don't have the bandwidth to support people who can't work out all the bits.
Dave.
Will this allow the use of a DisplayLink adapter as a secondary / tertiary screen with xrandr? In the posted videos it looks like it might, but it is hard to dell if a new X session is started on that USB attached display, or if the desktop is extended to it.
Starting a new X session (without hardware 3D acceleration) on a DisplayLink device is already working in Fedora. This work introduces 3D acceleration on the DisplayLink-connected screen using the computer's built-in graphics. But you are right, it's not clear if he's using a seperate X server or an extended screen. I think it's still a seperate X server while getting extended screen working better (right now it requires Xinerama) is work for the future.
Last edited by AlbertP; 07-04-2012 at 02:44 AM.
I would think that using DisplayLink as an extended screen would have to happen before 3D acceleration from the primary graphics card could be made to work on it, but of course I don't know a lot about the internals of xorg. Looking through the patches on the mailing list however, comments like the following make me think this will allow slave devices to provide additional outputs for an existing X session.
(at http://lists.x.org/archives/xorg-dev...ly/032069.html)Current code constrains the cursor to the crtcs on the master
device, for slave outputs to work we have to include their crtcs
in the constrain calculations.
[edit] Patch 30 and a few of the previous ones too (http://lists.x.org/archives/xorg-dev...ly/032080.html) also seem to suggest that randr will be able to configure slave devices, which implies it can attach them to a running session.
Last edited by benklop; 07-05-2012 at 10:22 AM.
After watching the videos again, more closely in higher resolution, it looks like he is using xrandr to extend the desktop to the added DisplayLink device. sweet!