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

[Maxime Ripard]

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

Attachment: signature.asc
Description: PGP signature