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:
 <TY4PR01MB14432AF536089C12B8D201BBA9838A@TY4PR01MB14432.jpnprd01.prod.outlook.com>
Date: Wed, 27 Aug 2025 23:36:27 +0800
From: Shengyu Qu <wiagn233@...look.com>
To: Daniel Stone <daniel@...ishbar.org>, Maxime Ripard <mripard@...nel.org>
Cc: wiagn233@...look.com, Marius Vlad <marius.vlad@...labora.com>,
 alexander.deucher@....com, christian.koenig@....com, airlied@...il.com,
 simona@...ll.ch, harry.wentland@....com, sunpeng.li@....com,
 siqueira@...lia.com, maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
 contact@...aelrc.com, lijo.lazar@....com, jesse.zhang@....com,
 tim.huang@....com, dark_sylinc@...oo.com.ar, mario.limonciello@....com,
 alex.hung@....com, aurabindo.pillai@....com, sunil.khatri@....com,
 chiahsuan.chung@....com, mwen@...lia.com, Roman.Li@....com,
 Wayne.Lin@....com, dominik.kaszewski@....com, alvin.lee2@....com,
 Aric.Cyr@....com, Austin.Zheng@....com, Sung.Lee@....com,
 PeiChen.Huang@....com, dillon.varone@....com, Richard.Chiang@....com,
 ryanseto@....com, linux@...blig.org, haoping.liu@....com,
 Relja.Vojvodic@....com, Yihan.Zhu@....com, Samson.Tam@....com,
 amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, wayland-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 0/2] Add "pixel_encoding" to switch between RGB & YUV
 color modes

Hi,

Sounds OK to me too.

Cheers,
Shengyu

在 2025/8/27 19:36, Daniel Stone 写道:
> Hey,
> 
> On Wed, 27 Aug 2025 at 12:21, Maxime Ripard <mripard@...nel.org> wrote:
>> On Wed, Aug 27, 2025 at 11:39:25AM +0100, Daniel Stone wrote:
>>> There are other reasons to have uAPI though ...
>>>
>>> One is because you really care about the colour properties, and you'd
>>> rather have better fidelity than anything else, even if it means some
>>> modes are unusable.
>>>
>>> Another is for situations which static quirks can't handle. If you
>>> want to keep headroom on the link (either to free up bandwidth for
>>> other uses), or you accidentally bought a super-long cable so have a
>>> flaky link, you might well want to force it to use lower fidelity so
>>> you can negotiate a lower link rate.
>>>
>>> I'm all for just dtrt automatically, but there are definitely reasons
>>> to expose it to userspace regardless.
>>
>> Oh, yeah, definitely.
>>
>> But bringing the big guns and the requirements we have for those to
>> address the point initially discussed by the gitlab issues seems like
>> biting off more than they can chew.
>>
>> Even more so since whatever uapi we come up with would still depend on
>> the EDIDs, and they would still be broken for these monitors.
> 
> Sounds like we're agreeing with each other then.
> 
> Shengyu's 'I want these broken panels to work' usecase is probably
> best served with an EDID quirk, yeah.
> 
> The reason Marius is working on it is the reasons I said above though
> - some for uses where we'd rather clearly fail out and push an error
> to userspace than continue with visually-degraded output, and some for
> uses where people have bought a too-long cable (or bought a too-short
> one which is now at tension through a 180° bend) so we want to force
> the lowest link rate possible, without dropping to a ridiculously low
> resolution.
> 
> So I don't think these are in tension, and Marius should proceed with
> his work (complete with the proper userspace to back it up), and
> Shengyu should proceed with new in-kernel quirks, which will be
> effective when the properties are set to auto, but hard overridden by
> userspace if it decides otherwise.
> 
> How does that sound?
> 
> Cheers,
> Daniel


Download attachment "OpenPGP_0xE3520CC91929C8E7.asc" of type "application/pgp-keys" (6869 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ