From: Keith Packard <keithp@keithp.com>
To: "Kristian Høgsberg" <hoegsberg@gmail.com>
Cc: mesa3d-dev@lists.freedesktop.org,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
Date: Wed, 06 Nov 2013 11:29:47 -0800 [thread overview]
Message-ID: <86fvr9qqfo.fsf@miki.keithp.com> (raw)
In-Reply-To: <CAOeoa-eGDUzOagcX0WZBeZCA98NhHLjnBxcr_GZmAusV2oiGxA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]
Kristian Høgsberg <hoegsberg@gmail.com> writes:
> I'm OK with either approach. It does seem like cleaning up the DRI
> driver interface is orthogonal to enabling the __DRIimage based
> getBuffer callout though.
We should probably not merge what we don't want to maintain though;
let's decide over lunch. I don't think it matters very much to the
current code, it'll only bug us in small ways in the future.
> I think that's fine. I was going to say that if we expect the
> requested and the returned set of buffers to differ, we might as well
> just memset the struct and let non-NULL images indicate returned
> images. But in case of a driver with a newer interface that extends
> the struct (stereoscopic buffers), the loader can't memset the entire
> struct (it only knows the smaller, previous version), and the driver
> will think the non-NULL garbage fields are valid images. So the
> image_mask makes sense.
That's what I was thinking.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-11-06 19:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 2:23 [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05 2:23 ` [PATCH 1/8] drivers/dri/common: A few dri2 functions are not actually DRI2 specific Keith Packard
2013-11-05 2:23 ` [PATCH 2/8] dri/intel: Split out DRI2 buffer update code to separate function Keith Packard
2013-11-05 2:23 ` [PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd Keith Packard
2013-11-05 22:23 ` Kristian Høgsberg
2013-11-06 0:52 ` Keith Packard
2013-11-07 5:17 ` Christopher James Halse Rogers
2013-11-07 5:42 ` Keith Packard
2013-11-05 2:23 ` [PATCH 4/8] Define __DRI_IMAGE_FORMAT_SARGB8 Keith Packard
2013-11-05 2:23 ` [PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_* Keith Packard
2013-11-05 3:01 ` Jordan Justen
2013-11-05 4:11 ` Keith Packard
2013-11-05 22:53 ` Jordan Justen
2013-11-05 22:35 ` Kristian Høgsberg
2013-11-06 0:54 ` Keith Packard
2013-11-05 2:23 ` [PATCH 6/8] dri/i915, dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat Keith Packard
2013-11-05 22:37 ` [PATCH 6/8] dri/i915,dri/i965: " Kristian Høgsberg
2013-11-05 2:23 ` [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension Keith Packard
2013-11-05 20:05 ` Eric Anholt
2013-11-05 23:47 ` Keith Packard
2013-11-05 22:59 ` Kristian Høgsberg
2013-11-06 0:59 ` Keith Packard
2013-11-06 2:48 ` Kristian Høgsberg
2013-11-06 6:25 ` Kristian Høgsberg
2013-11-06 14:55 ` Keith Packard
2013-11-06 16:17 ` Kristian Høgsberg
2013-11-06 18:09 ` Keith Packard
2013-11-06 19:06 ` Kristian Høgsberg
2013-11-06 19:29 ` Keith Packard [this message]
2013-11-05 2:23 ` [PATCH 8/8] Add DRI3+Present loader Keith Packard
2013-11-05 23:10 ` Eric Anholt
2013-11-06 2:32 ` Keith Packard
2013-11-05 16:40 ` [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05 20:04 ` Eric Anholt
2013-11-05 22:09 ` Kristian Høgsberg
2013-11-05 23:54 ` Keith Packard
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=86fvr9qqfo.fsf@miki.keithp.com \
--to=keithp@keithp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@gmail.com \
--cc=mesa3d-dev@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox