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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyu0qn81.fsf@intel.com>
Date: Wed, 17 Jan 2024 12:16:14 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Maxime Ripard <mripard@...nel.org>, Jessica Zhang
 <quic_jesszhan@...cinc.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>, Thomas Zimmermann
 <tzimmermann@...e.de>, Sam Ravnborg <sam@...nborg.org>,
 quic_abhinavk@...cinc.com, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>, David
 Airlie <airlied@...il.com>
Subject: Re: [PATCH RFC 0/4] Support for Simulated Panels

On Wed, 17 Jan 2024, Maxime Ripard <mripard@...nel.org> wrote:
> Hi,
>
> On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
>> This series introduces a simulated MIPI DSI panel.
>> 
>> Currently, the only way to validate DSI connectors is with a physical
>> panel. Since obtaining physical panels for all possible DSI configurations
>> is logistically infeasible, introduce a way for DSI drivers to simulate a
>> panel.
>> 
>> This will be helpful in catching DSI misconfiguration bugs and catching
>> performance issues for high FPS panels that might not be easily
>> obtainable.
>> 
>> For now, the simulated panel driver only supports setting customized
>> modes via the panel_simlation.mode modparam. Eventually, we would like
>> to add more customizations (such as configuring DSC, dual DSI, etc.).
>
> I think that it's more complicated than it needs to be.

Both too complicated and not complicated enough! :p

> Why do we need to support (and switch to) both the actual and
> "simulated" panel?
>
> Wouldn't it be simpler if we had a vkms-like panel that we could either
> configure from DT or from debugfs that would just be registered the
> usual way and would be the only panel we register?

I get the idea of trying to test DSI code without panels, and looking at
the goals above, I think your vkms suggestion is going to fall short of
those goals.

However, my gut feeling is that creating a simulated panel to catch DSI
misconfiguration etc. is going to be insanely complicated, and this
series doesn't even scratch the surface.

I guess my questions are, what's the scope here really, are those goals
realistic, does more code already exist beyond this skeleton?

BR,
Jani.



-- 
Jani Nikula, Intel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ