linux-kernel - Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Sep 2017 01:17:10 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        linux-tegra@...r.kernel.org
Subject: Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver

On 27.09.2017 00:35, Greg Kroah-Hartman wrote:
> On Tue, Sep 26, 2017 at 03:32:23PM +0300, Dmitry Osipenko wrote:
>> On 26.09.2017 09:54, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 26, 2017 at 01:15:41AM +0300, Dmitry Osipenko wrote:
>>>> This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's,
>>>> it is a result of reverse-engineering efforts. Driver has been tested on
>>>> Toshiba AC100 and Acer A500, it should work on any Tegra20 device.
>>>>
>>>> In userspace this driver is utilized by libvdpau-tegra [0] that implements
>>>> VDPAU interface, so any video player that supports VDPAU can provide
>>>> accelerated video decoding on Tegra20 on Linux.
>>>
>>> Why not use the v4l2 api instead?  Doesn't that provide the same needed
>>> user/kernel api here instead of creating yet-another-custom ioctl?
>>>
>>
>> 1) The HW doesn't generalize for the common API. Like for example, it isn't
>> capable of unpacking bitstream encoded with CABAC (Context-adaptive binary
>> arithmetic coding), so unpacking should be done in software and then VDE HW
>> isn't capable of decoding such a stream in a fully-automated manner, software
>> would have to feed engine with a chunks of macroblocks untill the whole frame is
>> decoded. That lameness is partially hidden in the BLOB's firmware, that firmware
>> actually is just a driver BTW.
>>
>> 2) We want to have decoding integrated with the presentation of the decoded
>> video frame. So having v4l interface for decoding would be just an extra
>> unnecessary shim, increasing CPU / memory resources usage and complexity of the
>> code.
>>
>> 3) The decoding and presentation are already implemented using VDPAU API and
>> proven to work decently in that way.
> 
> This sounds like something you should be talking over with the media
> driver developers, why are they not even cc:ed on this submission?
> 
> I need their ack on this new api before I can take this.
> 

Indeed, will cc media on V2.

-- 
Dmitry