On 01/18/2016 04:20 PM, Ilia Mirkin wrote: > On Mon, Jan 18, 2016 at 1:15 AM, Alexandre Courbot <[email protected]> wrote: >> On Mon, Jan 18, 2016 at 3:11 PM, Ilia Mirkin <[email protected]> wrote: >>> All the video decoding firmware was *pretty* standard... I suspect >>> ~everyone used my extraction script and it's sitting in >>> /lib/firmware/nouveau for everyone who uses VDPAU. There are packages >>> in several distributions which grab the nvidia blob, my script, and >>> run the extraction on the end user's computer to avoid licensing >>> complications. Please support the existing locations. >> >> Ok, so there *are* some end-users (not developers) relying on these >> external firmwares? >> >> In that case probably the best thing to do is to not use these new >> functions for video - at least for chips that do not require signed >> firmware. All I'd like to do is reduce the number of occurences of the >> "build path - load firmware" logic. > > Yep. And FWIW there were users of pgraph firmware loading with the old > paths too :( For some users, the blob pgraph fw is stable while > nouveau one isn't. But hopefully not that many, I think VDPAU has a > lot more. VDPAU is currently supported through Kepler. I don't think it's worth supporting the soon-to-be-old gr ucode paths going forward. Our implementation of using the binary driver gr firmware is pretty broken anyway (outside of Tegra), and works by accident mostly. I suspect most (if not all) of the issues with our ucode have been ironed out now too, no?
There's probably a legitimate case for keeping support for the video paths, especially since we don't know if/when/what-form nvidia will distrubute them in. Ben. > > -ilia >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
