From: "Christian König" <christian.koenig@amd.com>
To: Petri Latvala <petri.latvala@intel.com>
Cc: Anson Jacob <Anson.Jacob@amd.com>,
igt-dev@lists.freedesktop.org, Sean Paul <seanpaul@chromium.org>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>,
Mark Yacoub <markyacoub@google.com>
Subject: Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.
Date: Wed, 16 Jun 2021 10:07:18 +0200 [thread overview]
Message-ID: <8077ffe8-8ee5-1d58-1797-69848d11d27a@amd.com> (raw)
In-Reply-To: <YMmpbOtT+CMFxbzI@platvala-desk.ger.corp.intel.com>
Am 16.06.21 um 09:34 schrieb Petri Latvala:
> On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
>> The alternative would be to try to create a framebuffer, but don't take it
>> as a failure when that fails with the correct return code.
> This.
>
> If the importing can fail for documented reasons, we should just add
> code that checks that the error is the documented one and then
> igt_skip(), fail the test if it's something it shouldn't.
Good point, but I don't think that this behavior is well documented
anywhere.
I'm also pretty sure that most drivers don't correctly reject an
imported DMA-buf for scanout when the hardware can't do this. Resulting
in either just garbage on the screen or a lockup.
Exercising this in an unit tests is probably a good idea, but only after
auditing all drivers for correct behavior.
Regards,
Christian.
> As a general rule the tests goes to hardware specific subdirs if the
> interface tested is hardware-specific. This interface is not, just the
> behaviour.
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2021-06-16 8:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 16:41 [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers Mark Yacoub
2021-06-14 18:48 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2021-06-15 0:25 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2021-06-15 9:05 ` [igt-dev] [PATCH] " Petri Latvala
2021-06-15 14:46 ` Mark Yacoub
2021-06-15 14:51 ` Christian König
2021-06-15 13:12 ` Rodrigo Siqueira
2021-06-15 13:43 ` Christian König
2021-06-15 14:49 ` Mark Yacoub
2021-06-15 14:55 ` Christian König
2021-06-15 15:46 ` Mark Yacoub
2021-06-15 16:20 ` Christian König
2021-06-16 7:34 ` Petri Latvala
2021-06-16 8:07 ` Christian König [this message]
2021-06-16 8:46 ` Petri Latvala
2021-06-16 9:07 ` Christian König
2021-07-02 19:45 ` Daniel Vetter
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=8077ffe8-8ee5-1d58-1797-69848d11d27a@amd.com \
--to=christian.koenig@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Anson.Jacob@amd.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=markyacoub@google.com \
--cc=petri.latvala@intel.com \
--cc=seanpaul@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.