Pancake

The patch might work but that doesn't mean it was effective. Try downloading the NvFBC sample and running that. Or this untested bit of code might be sufficient for testing...

560.X and 565.X still do not work.

I applied this patch to my kernel fork and while it did fix the limitation issue, it also slashed my speeds. Prior to patching I was able to get ~2100...

I can't believe this dumb workaround actually works ```diff diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c index da3231c9a..406974c31 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c @@ -148,12 +148,23 @@ mt7996_eeprom_check_or_use_default(struct mt7996_dev *dev, bool use_default) goto...

> Isn't it like [openwrt/mt76#968](https://github.com/openwrt/mt76/pull/968)? are ranges correct? +4 for 5G and +8 for 6G? and 2G? That sounds correct.. In my case `iw phy` returns all the way up...

Can't you apply the patch manually?

After a bit of headscratching in direct messages with @charles-lunarg we've found a good chunk of information and I will summarize it here. I will be using the terms "application",...

@PatTheMav Thanks for your explanation! So essentially what I'm doing is converting to and from twice, where I could be skipping any conversion entirely. I'll dig through my code again...

Let me try to document this here. The assumption I was making is that when the compositor provides a 10-bit texture, it would not be gamma-encoded sRGB. That was incorrect....

I hope that won't cause too many merge conflicts, but I think that is a good idea for now as I'm going to be busy these next few days.