On 19.10.2016 17:03, Karol Herbst wrote:> You don't get why I try to say. We have to actually find out when to > apply this workaround, not to create some silly whitelist/blacklist. > It's the last option, we never want to actually use. >Well if you do not say, who can understand!? :) Besides, you can mock with "silly" whitelist/blacklist", however there is nothing wrong with the method as such, it is used practically everywhere.> And even if we would have to create such lists, who tells us, that if > affects every GPU with your device id? Usually quirks are applied > depending on the sub-vendor-id and sub-device-id if actually required. > > In the end we need something like this: If byte X in table Y is set in > the vbios or if bits A-B in reg Z in the MMIO space are set to > whatever, we have to apply that workaround. > > In the end we should also wait until Ben replies, because he might > know the exact reasons why this workaround was actually needed. >If you eager to leave it broken even more than three months that have already been passed since the original commit ...> We might have a GPU with the same chipset like yours and we might be > able to verify the issue >Ah, I see. You do not have confidence in my test results, good to know. Oh! Carol
Hello, On 07:37 pm - Oct 19 2016, poma wrote:> On 19.10.2016 17:03, Karol Herbst wrote: > > > You don't get why I try to say. We have to actually find out when to > > apply this workaround, not to create some silly whitelist/blacklist. > > It's the last option, we never want to actually use. > > > > Well if you do not say, who can understand!? :) > Besides, you can mock with "silly" whitelist/blacklist", however there is nothing wrong with the method as such, it is used practically everywhere. > > > And even if we would have to create such lists, who tells us, that if > > affects every GPU with your device id? Usually quirks are applied > > depending on the sub-vendor-id and sub-device-id if actually required. > > > > In the end we need something like this: If byte X in table Y is set in > > the vbios or if bits A-B in reg Z in the MMIO space are set to > > whatever, we have to apply that workaround. > > > > In the end we should also wait until Ben replies, because he might > > know the exact reasons why this workaround was actually needed. > > > > If you eager to leave it broken even more than three months that have already been passed since the original commit ... > > > We might have a GPU with the same chipset like yours and we might be > > able to verify the issue > > > > Ah, I see. > You do not have confidence in my test results, good to know.Testing on another GPU with the same chipset does not mean he does not trust your results. For example, my laptop (which also has an NVAC) has been triggering the no-signal message on external monitors way before Ben’s patch landed, but only for some adapters. I haven’t tried Ben’s patch yet, nor yours, but I will certainly do it, and see what effect each of them has. Regards, Pierre> > Oh! Carol > > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161019/013ff7d7/attachment.sig>
On 10/20/2016 03:58 AM, Pierre Moreau wrote:> Hello, > > On 07:37 pm - Oct 19 2016, poma wrote: >> On 19.10.2016 17:03, Karol Herbst wrote: >> >>> You don't get why I try to say. We have to actually find out when to >>> apply this workaround, not to create some silly whitelist/blacklist. >>> It's the last option, we never want to actually use. >>> >> >> Well if you do not say, who can understand!? :) >> Besides, you can mock with "silly" whitelist/blacklist", however there is nothing wrong with the method as such, it is used practically everywhere. >> >>> And even if we would have to create such lists, who tells us, that if >>> affects every GPU with your device id? Usually quirks are applied >>> depending on the sub-vendor-id and sub-device-id if actually required. >>> >>> In the end we need something like this: If byte X in table Y is set in >>> the vbios or if bits A-B in reg Z in the MMIO space are set to >>> whatever, we have to apply that workaround. >>> >>> In the end we should also wait until Ben replies, because he might >>> know the exact reasons why this workaround was actually needed.I'd like to see a mmiotrace of the NVIDIA binary driver on a system where this WAR breaks things. I applied it to all the GPUs that NVIDIA told me required it. Ben.>>> >> >> If you eager to leave it broken even more than three months that have already been passed since the original commit ... >> >>> We might have a GPU with the same chipset like yours and we might be >>> able to verify the issue >>> >> >> Ah, I see. >> You do not have confidence in my test results, good to know. > > Testing on another GPU with the same chipset does not mean he does not trust > your results. For example, my laptop (which also has an NVAC) has been > triggering the no-signal message on external monitors way before Ben’s patch > landed, but only for some adapters. I haven’t tried Ben’s patch yet, nor yours, > but I will certainly do it, and see what effect each of them has. > > Regards, > Pierre > >> >> Oh! Carol >> >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau >> >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161020/9767ad62/attachment.sig>
On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:> For example, my laptop (which also has an NVAC) has been triggering the > no-signal message on external monitors way before Ben???s patch landed, > but only for some adapters. I haven???t tried Ben???s patch yet, nor > yours, but I will certainly do it, and see what effect each of them has.The external DP port on your MBP5,3 is switchable between GPUs and the apple-gmux driver switches it in unison with the panel. Thus the NVAC cannot drive external displays when gmux is switched to the MCP79. (You probably were aware of this, just wanted to mention it in case you weren't.) (In theory we could change vga_switcheroo and apple-gmux to support switching the panel and the external port separately rather than in unison if there is demand. It's only supported on MBPs introduced from 2008 to 2010 though, the 2011+ models can only drive external ports with the discrete GPU.) Best regards, Lukas