public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Sumera Priyadarsini <sylphrenadin@gmail.com>
Cc: melissa.srw@gmail.com, hamohammed.sa@gmail.com,
	rodrigosiqueiramelo@gmail.com, airlied@linux.ie,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH V4 0/2] Add virtual hardware module
Date: Wed, 7 Apr 2021 10:12:58 +0300	[thread overview]
Message-ID: <20210407101258.72261c5d@eldfell> (raw)
In-Reply-To: <cover.1617602076.git.sylphrenadin@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]

On Mon, 5 Apr 2021 11:41:50 +0530
Sumera Priyadarsini <sylphrenadin@gmail.com> wrote:

> This patchset adds support for emulating virtual hardware with VKMS.
> The virtual hardware mode can be enabled by using the following command
> while loading the module:
>         sudo modprobe vkms enable_virtual_hw=1

Hi,

every time I see this cover letter subject, I start wondering "what is
this virtual hardware module, yet another one?" and then I read the
cover letter and realise it is about adding an option to VKMS.

The next time you revise this series, could you perhaps clarify the
subject?

The idea of having a mode where VKMS behaves like a virtual hardware
driver is good, IMO. I do think "vblank-less mode" describes it better
though, because I would assume things like USB display drivers to work
like this too, and VKMS is already a virtual driver anyway.

To clarify, as a userspace programmer what I would expect "vblank-less
mode" to be is that the DRM driver completes pageflips and modesets at
arbitrary times, perhaps always immediately or perhaps with a variable
delay that depends on how much processing is needed for the update.
Also vblank events do not fire and vblank counters do not advance. Is
this correct?


Thanks,
pq

> 
> The first patch is prep work for adding virtual_hw mode and refactors
> the plane composition in vkms by adding a helper function vkms_composer_common()
> which can be used for both vblank mode and virtual mode.
> 
> The second patch adds virtual hardware support as a module option. It
> adds new atomic helper functions for the virtual mode
> and modifies the existing atomic helpers for usage by the vblank mode
> This gives us two sets of drm_crtc_helper_funcs struct for both modes,
> making the code flow cleaner and easier to debug.
> 
> This patchset has been tested with the igt tests- kms_writeback, kms_atomic,
> kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for
> subtests related to crc reads and skips tests that rely on vertical
> blanking. This patchset must be tested after incorporating the
> igt-tests patch: https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html
> 
> Sumera Priyadarsini (2):
>   drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode
>   drm/vkms: Add support for virtual hardware mode
> 
>  drivers/gpu/drm/vkms/vkms_composer.c | 88 +++++++++++++++++-----------
>  drivers/gpu/drm/vkms/vkms_crtc.c     | 51 +++++++++++-----
>  drivers/gpu/drm/vkms/vkms_drv.c      | 18 ++++--
>  drivers/gpu/drm/vkms/vkms_drv.h      |  4 ++
>  4 files changed, 109 insertions(+), 52 deletions(-)
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-04-07  7:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05  6:11 [PATCH V4 0/2] Add virtual hardware module Sumera Priyadarsini
2021-04-05  6:14 ` [PATCH V4 1/2] drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode Sumera Priyadarsini
2021-04-10 11:33   ` Melissa Wen
2021-04-05  6:15 ` [PATCH V4 2/2] drm/vkms: Add support for virtual hardware mode Sumera Priyadarsini
2021-04-10 11:59   ` Melissa Wen
2021-04-07  7:12 ` Pekka Paalanen [this message]
2021-04-10 12:21   ` [PATCH V4 0/2] Add virtual hardware module Melissa Wen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210407101258.72261c5d@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=melissa.srw@gmail.com \
    --cc=rodrigosiqueiramelo@gmail.com \
    --cc=sylphrenadin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox