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] [day] [month] [year] [list]
Message-ID: <5d207be0-c8f0-7c68-91b2-d5ef873ca6cc@ideasonboard.com>
Date:   Mon, 29 May 2023 14:12:23 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Aradhya Bhatia <a-bhatia1@...com>, neil.armstrong@...aro.org,
        Jyri Sarha <jyri.sarha@....fi>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Robert Foss <rfoss@...nel.org>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Rahul T R <r-ravikumar@...com>,
        Swapnil Jakhade <sjakhade@...ence.com>,
        Boris Brezillon <boris.brezillon@...labora.com>,
        Francesco Dolcini <francesco@...cini.it>
Cc:     DRI Development List <dri-devel@...ts.freedesktop.org>,
        Linux Kernel List <linux-kernel@...r.kernel.org>,
        Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Devarsh Thakkar <devarsht@...com>,
        Jayesh Choudhary <j-choudhary@...com>
Subject: Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format
 negotiation

On 29/05/2023 08:37, Aradhya Bhatia wrote:
>> Btw, we seem to be missing get-output-fmt from the mdhp driver.
> Yes, we are.
> 
> With the drm_bridge_attach call added, the display-connector bridge will
> assign MEDIA_BUS_FMT_FIXED as the default output format. And most
> bridges support only their primary output bus format in their
> get-output-fmt hooks. I suppose it would be RGB121212_1X36 in mhdp8546's
> case.
> 
> Do we require this when there is no comprehensive way to determine if
> another bus format may be more suitable (depending on the hardware
> configurations)?

If I recall right, mhdp supports other formats than RGB121212_1X36 on 
the input side (different bit depths and also yuv). On the output side, 
even if the input is 12 bits per component, when connected to a normal 
monitor, the output bpc would be 8.

I'm not sure if any of that matters, as nobody (?) will use the output 
format of mhdp, as it just goes "outside" to the monitor, and it is the 
mhdp driver that negotiates a suitable output format with the monitor.

  Tomi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ