Nouveau - Jan 2016 - [PATCH 0/5] nouveau: unified firmware loading functions

On Mon, Jan 18, 2016 at 3:11 PM, Ilia Mirkin <imirkin at alum.mit.edu>
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.

On Mon, Jan 18, 2016 at 1:15 AM, Alexandre Courbot <gnurou at gmail.com>
wrote:
> On Mon, Jan 18, 2016 at 3:11 PM, Ilia Mirkin <imirkin at
alum.mit.edu> 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.

  -ilia

On 01/18/2016 04:20 PM, Ilia Mirkin wrote:
> On Mon, Jan 18, 2016 at 1:15 AM, Alexandre Courbot <gnurou at
gmail.com> wrote:
>> On Mon, Jan 18, 2016 at 3:11 PM, Ilia Mirkin <imirkin at
alum.mit.edu> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20160118/1370ac17/attachment-0001.sig>