linux-kernel - Re: Re: [PATCH RFC 0/4] Support for Simulated Panels

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]

Date: Fri, 2 Feb 2024 11:15:33 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Jessica Zhang <quic_jesszhan@...cinc.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	Sam Ravnborg <sam@...nborg.org>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	David Airlie <airlied@...il.com>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	Rob Clark <robdclark@...il.com>, Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>
Subject: Re: Re: [PATCH RFC 0/4] Support for Simulated Panels

On Tue, Jan 30, 2024 at 09:53:13AM +0100, Daniel Vetter wrote:
> > > > > > 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?
> > > > > 
> > > > 
> > > > No, we need to have validate actual hardware pipeline with the simulated
> > > > panel. With vkms, actual display pipeline will not be validated. With
> > > > incorrect display pipeline misconfigurations arising from different panel
> > > > combinations, this can easily be caught with any existing IGT CRC testing.
> > > > In addition, all performance related bugs can also be easily caught by
> > > > simulating high resolution displays.
> > > 
> > > That's not what I meant. What I meant was that something like a
> > > user-configurable, generic, panel driver would be a good idea. Just like
> > > vkms (with the debugfs patches) is for a full blown KMS device.
> > > 
> > 
> > Let me respond for both this question and the one below from you/Jani.
> > 
> > Certainly having user-configurable information is a goal here. The end-goal
> > is to make everything there in the existing panels such as below like I
> > wrote:
> > 
> > 1) Display resolution with timings (drm_display_mode)
> > 2) Compression/non-compression
> > 3) Command mode/Video mode
> > 4) MIPI mode flags
> > 5) DCS commands for panel enable/disable and other panel sequences
> > 6) Power-up/Power-down sequence for the panel
> > 
> > But, we also have to see what all is feasible today from the DRM fwk
> > standpoint. There are some limitations about what is boot-time configurable
> > using bootparams and what is runtime configurable (across a modeset) using
> > debugfs.
> > 
> > 1) Today, everything part of struct mipi_dsi_device needs to be available at
> > boot time from what I can see as we need that while calling
> > mipi_dsi_attach(). So for that we went with boot-params.
> > 
> > 2) For the list of modes, we can move this to a debugfs like
> > "populate_modes" which the client using a sim panel can call before picking
> > a mode and triggering a commit.
> > 
> > But we need to have some default mode and configuration.
> 
> Uh, at the risk of sounding a bit like I'm just chasing the latest
> buzzwords, but this sounds like something that's screaming for ebpf.

I make a half-joke to Jani on IRC about it, but I was also being
half-serious. If the goal we want to have is to fully emulate any panel
variation, ebpf really looks like the best and most flexible way
forward.

Maxime

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