linux-kernel - Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

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]

Message-ID: <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com>
Date:   Tue, 10 Jan 2017 12:26:53 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        "Jose Abreu" <Jose.Abreu@...opsys.com>
CC:     <dri-devel@...ts.freedesktop.org>,
        Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville,

On 10-01-2017 11:16, Ville Syrjälä wrote:
> On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote:
>>

[snip]

>> The pixel clock rate is half of the TMDS character rate in 4:2:0
>> (in 24 bit), but for example in deep color 48 bit it will be the
>> same rate. There is also a reduction to half of htotal, hactive,
>> hblank, hfront, hsync and hback but I don't think it's a good
>> solution to guide us from there.
> I was asking if we can look at a specific modeline and whether we
> can tell from that if we would need to output it as 4:2:0.

Hmm, according to HDMI 2.0 spec there are no 4:2:0 only modes and
the only way to figure out if the mode is 4:2:0 only (or able) is
to parse the VCB and VBD blocks from EDID. The clock is half rate
but this is the source that has to figure it out. The mode is
still passed in a regular way (By VIC, by timing, ...).

>
>> Why does it feel wrong to you
>> expanding the uapi?
> Because it requires changing every single userspace kms client. And
> it's not something userspace should have to worry about.

I agree but, as Daniel said [1], we could make these new HDMI 2.0
features optional and only pass them to userspace if client asked
for them. What do you think?

[1]
https://lists.freedesktop.org/archives/dri-devel/2017-January/128683.html

>
>> I think its important to say that the chosen colorspace can
>> improve performance in systems: for example, as I said, 4:2:0
>> 24-bit uses half the rate that RGB 24-bit uses so we have less
>> trafic in the bus. I am recently working with a FPGA connected
>> trough pcie and I can definitely say that this is true. But, as
>> expected, less traffic means less quality in final image so its
>> not a matter of letting kernel decide, I think its a matter of
>> user choosing between performance vs. quality.
> Image quality control for userspace is a much bigger topic. And
> something we have no real precedent for at the moment (apart from 
> user choosing a different fb pixel format).
>
> The performance arument is very hardware dependent, and not really
> all that relevant IMO. If the user wants the big mode they either
> get it or not depending on whether the system can deliver.
>

Ok. But note that there is no nice way to figure this out. For
example, for a graphics card it all depends (apart from the
graphics HW) on the PCIe bus. If the bus is not free for enough
data rate then user can reach bottlenecks and not output at best
performance. If we gave user the ability to switch from, for
example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated.
Unless of course we always prefer YCbCr 4:2:0, when possible. I
did this internally for bridge driver dw-hdmi. We always prefer
YCbCr over RGB when they are available. It is user transparent as
the controller does the necessary color space conversion, though,
not ideal in my opinion.

Best regards,
Jose Miguel Abreu