On 2/2/2024 2:15 AM, Maxime Ripard wrote:
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.
Hi Maxime and Daniel,
For our current sim panel requirements, we can go with implementing the
configfs first then add ebpf if requirements get more complex.
Thanks,
Jessica Zhang
Maxime
