On Thu, May 30, 2019 at 4:23 AM Markus Wanner <markus@xxxxxxxxxx> 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 _______________________________________________ Nouveau mailing list Nouveau@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/nouveau