[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x6wi5xnihnbpqsujjfjfw3ft6njncruta5l3xa44pds5oxmdkw@mmvv4bciy65s>
Date: Wed, 17 Jan 2024 10:26:35 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Jessica Zhang <quic_jesszhan@...cinc.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>,
Sam Ravnborg <sam@...nborg.org>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, quic_abhinavk@...cinc.com, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH RFC 0/4] Support for Simulated Panels
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.
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?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists