public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Cc: rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com,
	hamohammed.sa@gmail.com, daniel@ffwll.ch, airlied@linux.ie,
	contact@emersion.fr, leandro.ribeiro@collabora.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	lkcamp@lists.libreplanetbr.org
Subject: Re: [PATCH 0/6] Refactor the vkms to accept new formats
Date: Mon, 18 Oct 2021 10:53:33 +0300	[thread overview]
Message-ID: <20211018105333.5f1bf9fe@eldfell> (raw)
In-Reply-To: <20211005201637.58563-1-igormtorrente@gmail.com>

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

On Tue,  5 Oct 2021 17:16:31 -0300
Igor Matheus Andrade Torrente <igormtorrente@gmail.com> wrote:

> XRGB to ARGB behavior
> =================
> During the development, I decided to always fill the alpha channel of
> the output pixel whenever the conversion from a format without an alpha
> channel to ARGB16161616 is necessary. Therefore, I ignore the value
> received from the XRGB and overwrite the value with 0xFFFF.
> 
> My question is, is this behavior acceptable?

Hi,

that is the expected behaviour. X channel values must never affect
anything on screen, hence they must never affect other channels'
values. You are free to completely ignore X channel values, and if your
output buffer has X channel, then you are free to write (or not write,
unless for security reasons) whatever into it.


Thanks,
pq

> 
> [1] https://lists.freedesktop.org/archives/igt-dev/2021-October/036125.html
> 
> Igor Matheus Andrade Torrente (6):
>   drm: vkms: Replace the deprecated drm_mode_config_init
>   drm: vkms: Alloc the compose frame using vzalloc
>   drm: vkms: Replace hardcoded value of `vkms_composer.map` to
>     DRM_FORMAT_MAX_PLANES
>   drm: vkms: Add fb information to `vkms_writeback_job`
>   drm: vkms: Prepare `vkms_wb_encoder_atomic_check` to accept multiple
>     formats
>   drm: vkms: Refactor the plane composer to accept new formats
> 
>  drivers/gpu/drm/vkms/vkms_composer.c  | 275 ++++++++++++++------------
>  drivers/gpu/drm/vkms/vkms_drv.c       |   5 +-
>  drivers/gpu/drm/vkms/vkms_drv.h       |  12 +-
>  drivers/gpu/drm/vkms/vkms_formats.h   | 125 ++++++++++++
>  drivers/gpu/drm/vkms/vkms_writeback.c |  27 ++-
>  5 files changed, 304 insertions(+), 140 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
> 


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

  parent reply	other threads:[~2021-10-18  7:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 20:16 [PATCH 0/6] Refactor the vkms to accept new formats Igor Matheus Andrade Torrente
2021-10-05 20:16 ` [PATCH 1/6] drm: vkms: Replace the deprecated drm_mode_config_init Igor Matheus Andrade Torrente
2021-10-18 10:02   ` Thomas Zimmermann
2021-10-18 18:21     ` Igor Matheus Andrade Torrente
2021-10-05 20:16 ` [PATCH 2/6] drm: vkms: Alloc the compose frame using vzalloc Igor Matheus Andrade Torrente
2021-10-05 20:16 ` [PATCH 3/6] drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES Igor Matheus Andrade Torrente
2021-10-18 10:04   ` Thomas Zimmermann
2021-10-05 20:16 ` [PATCH 4/6] drm: vkms: Add fb information to `vkms_writeback_job` Igor Matheus Andrade Torrente
2021-10-18 10:10   ` Thomas Zimmermann
2021-10-05 20:16 ` [PATCH 5/6] drm: vkms: Prepare `vkms_wb_encoder_atomic_check` to accept multiple formats Igor Matheus Andrade Torrente
2021-10-18 10:14   ` Thomas Zimmermann
2021-10-18 17:41     ` Igor Matheus Andrade Torrente
2021-10-18 18:06       ` Thomas Zimmermann
2021-10-18 19:32         ` Igor Matheus Andrade Torrente
2021-10-19  7:17           ` Thomas Zimmermann
2021-10-19 19:12             ` Igor Matheus Andrade Torrente
2021-10-05 20:16 ` [PATCH 6/6] drm: vkms: Refactor the plane composer to accept new formats Igor Matheus Andrade Torrente
2021-10-05 22:20   ` kernel test robot
2021-10-05 23:18   ` kernel test robot
2021-10-05 23:36   ` kernel test robot
2021-10-18  8:30   ` Pekka Paalanen
2021-10-18 19:26     ` Igor Matheus Andrade Torrente
2021-10-19  8:05       ` Pekka Paalanen
2021-10-19 21:10         ` Igor Matheus Andrade Torrente
2021-10-20  8:25           ` Pekka Paalanen
2021-10-18  7:53 ` Pekka Paalanen [this message]
2021-10-18 18:05   ` [PATCH 0/6] Refactor the vkms " Igor Matheus Andrade Torrente

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=20211018105333.5f1bf9fe@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=airlied@linux.ie \
    --cc=contact@emersion.fr \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=igormtorrente@gmail.com \
    --cc=leandro.ribeiro@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcamp@lists.libreplanetbr.org \
    --cc=melissa.srw@gmail.com \
    --cc=rodrigosiqueiramelo@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