linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6470960a-dbe8-43ca-889a-b5a7cc934569@quicinc.com>
Date: Wed, 28 Feb 2024 13:49:34 -0800
From: Jessica Zhang <quic_jesszhan@...cinc.com>
To: Maxime Ripard <mripard@...nel.org>,
        Abhinav Kumar
	<quic_abhinavk@...cinc.com>,
        Jani Nikula <jani.nikula@...ux.intel.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: [PATCH RFC 0/4] Support for Simulated Panels



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