[Nouveau] Support for GP107(GL)M with Optimus
Ilia Mirkin
imirkin at alum.mit.edu
Thu May 30 14:28:44 UTC 2019
On Thu, May 30, 2019 at 4:23 AM Markus Wanner <markus at bluegap.ch> wrote:
>
> Hello Karol,
>
> On 5/29/19 4:04 PM, Karol Herbst wrote:
> > If you want you could try out those patches on a kernel and see if
> > those make any difference on your machine:
> >
> > https://github.com/karolherbst/linux/commits/runpm_fixes
>
> thanks, I tried, see below. This raises another question: where does
> nouveau development take place? In a tree based on the linux kernel
> (such as the above repo) or in some dedicated module-only repo like
> skeggsb/nouveau?
>
> I manually "rebased" the last five commits from the "runpm_fixes" branch
> of the repo above onto skeggsb/nouveau, which applied w/o conflicts.
> Results below are for a nouveau module built that way.
Nouveau development takes place on developers' computers :) We then
submit patches to Ben (nouveau maintainer) who in turn submits pull
requests to Dave (drm maintainer). The tree that these pull requests
come from is
https://github.com/skeggsb/linux
Ben does his own development on that "nouveau" repository, as it
enables him to do various clever things. However there's a trade-off,
and it's not always convenient to use. I exclusively develop against
the linux tree and send patches based off that. It's pretty trivial to
map patches back and forth with sed, so it's not a huge deal. It does
cause some frequent confusion, so probably worth documenting in the
wiki or something. [And I suspect if I had to do the things Ben has to
do, I'd find the trade-off to go in the other way and prefer his
approach. But I don't, so here we are :) ]
It's a bit unfortunate that this flow does not put nouveau development
into linux-next prior to Dave pulling the tree in. I'd encourage Ben
to do more frequent sync's to the linux tree and have a permanent,
rebasing, "next" branch, but ... not my call. Perhaps linux-next
frowns on that sort of thing.
> So, current status on skeggsb/nouveau fails that way for me, independent
> of the runpm setting. However, with the five patches from your
> runpm_fixes branch added, I see different results:
>
> * no such timeouts any more in kernel logs (yay!)
> * X11 recognizes the Dell display connected on HDMI-1 (independent
> of kernel module parameters or X11 config)
> * starting X11 with only the nouveau driver, a terminal appears
> on the display (yay!)
Sounds like nouveau is working fine then.
> * loading nouveau with `debug=debug` and starting X11, the display
> remains dark
That's weird. What's in the logs? I don't think we spam debug logs
THAT much by default...
> * loading nouveau and intel (for the internal display), the external
> display remains dark as well, xrandr does not show it, but
> `xrandr --listproviders` at least lists two providers (I'm not sure
> whether I can somehow enable the external display in this case).
You have to link the two providers together. See
https://nouveau.freedesktop.org/wiki/Optimus/ "Using outputs on
discrete GPU". Long story short, just run
xrandr --setprovideroutputsource 1 0
and the secondary GPU's outputs should magically appear in the RandR
output list.
Cheers,
-ilia
More information about the Nouveau
mailing list