[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