On 4/15/21 8:59 AM, Matthew Auld wrote:
> Add a note about the two-step process.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc:
On 09/27/2017 10:07 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick <i...@freedesktop.org> wrote:
>> On 09/27/2017 04:55 PM, Rob Clark wrote:
>>> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick <i...@freedesktop.org> wrote:
>>>> O
On 09/27/2017 04:55 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick <i...@freedesktop.org> wrote:
>> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>>> Hi all,
>>>
>>> First again big thanks to Stéphane and Jennifer for organizing a g
On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> Hi all,
>
> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
>
> Like last year we'd like to hear feedback on how this year's XDC went,
> both the good (and what you'd like to see more of) and the not so
> good. Talk
er_private;
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
Presumably cases like this one could be 'const struct
drm_crtc_helper_funcs *const' but meh.
This patch is
Reviewed-by: Ian Romanick
...who hasn't had a patch in the Matrox driver in almost a decade.
> u8 tmp;
>
> if (mdev->type == G200_WB)
>
Based on light reading, patches 1, 5, 6, 7, 8, 10, and 11 are
Reviewed-by: Ian Romanick
I sent a comment on patch 9. I'll try to look at the others in the next
few days... assuming nobody beats me to it.
I'm also going to send some similar Mesa patches that I'll CC you on.
On 03/05/2015 08
On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> Time to switch over all the IS_GENX() macros to the new device object.
> Nothing more than a mechanical search & replace here.
Hmm... why not just do the comparisons directly? The macros seem
superfluous.
> Signed-off-by: Damien Lespiau
> ---
>
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
>
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> intel/intel
This patch is
Reviewed-by: Ian Romanick
On 02/09/2015 03:28 PM, Jan Vesely wrote:
> v2: Remove unrelated change in main()
>
> This is more consistent with the rest, and avoids potential undefined
> behavior (signed overflow) ind drmRandom()
>
> Signed-
This patch is
Reviewed-by: Ian Romanick
On 02/09/2015 01:39 PM, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
> tests/vbltest/vbltest.c | 3 ++-
> xf86drm.c | 4 ++--
> xf86drmMode.c | 2 +-
> 3 files changed, 5 insertions(+), 4 deletions(
On 02/09/2015 01:39 PM, Jan Vesely wrote:
> This is more consistent with the rest, and avoids potential undefined
> behavior (signed overflow) in drmRandom()
>
> Signed-off-by: Jan Vesely
> ---
> xf86drmRandom.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff
On 01/19/2015 06:29 AM, Chris Wilson wrote:
> Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
> when the current back buffer was defined. As this may require ddx
> support, only set the value if enabled by the ddx and report the new
> semantics via a DRI2GetParam request.
>
s-buffer-age parameter.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Ian Romanick
> ---
> configure.ac | 2 +-
> dri2proto.h | 2 ++
> dri2proto.txt | 11 ---
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/confi
On 01/20/2015 12:35 PM, Ian Romanick wrote:
> On 01/19/2015 03:00 AM, Chris Wilson wrote:
>> + DRI2Buffer *buffers;
>> +
>> + for (i = 0; i < priv->bufferCount; i++)
>> + attachments[i] = priv->buffers[i].attachment;
>> +
>>
On 01/19/2015 03:00 AM, Chris Wilson wrote:
> Since the introduction of DRI2GetBuffersWithFormat, the old
> DRI2GetBuffers interface would always recreate all buffers all the time
> as it was no longer agnostic to the format value being set by the DDXes.
> This causes an issue with clients
On 01/19/2015 03:00 AM, Chris Wilson wrote:
> Within the DRI2GetBuffers return packet there is a 4-byte field that is
> currently unused by any driver, i.e. flags. With the co-operation of a
> suitably modified X server, we can pass the last SBC on which the buffer
> was defined (i.e. the last
On 01/19/2015 03:00 AM, Chris Wilson wrote:
> As the SBC from the reply from SwapBuffers is not used immediately and
> can be easily determined by counting the new of SwapBuffers requests
> made by the client, we can defer the synchronisation point to the
> pending GetBuffers round trip. (We force
On 01/19/2015 03:00 AM, Chris Wilson wrote:
> Available since the inclusion of dri2proto 1.4 is a DRI2 request to
> query and set certain parameters about the X/DDX configuration. This
> implements the getter request.
>
> Signed-off-by: Chris Wilson
This patch is
Reviewed-b
On 04/07/2014 12:56 PM, Daniel Vetter wrote:
> On Mon, Apr 7, 2014 at 5:19 PM, Ian Romanick wrote:
>> On 04/05/2014 02:44 AM, Daniel Vetter wrote:
>>> ttm_bo_unref unconditionally calls kref_put on it's argument, so the
>>> thing can't be NULL without already ca
^^
Now
> overflow. But I guess the real risk is gcc spotting this and going
> bananas. Fix this by simply using unsigned in to force all computations
> to use the well-defined unsigned behaviour.
Seems reasonable... it also seems impossible (ha!) to break anything.
Reviewed-by: Ian Roman
was not
> flagged.
>
> Signed-off-by: Daniel Vetter
Same as MGA change.
Reviewed-by: Ian Romanick
> ---
> drivers/gpu/drm/bochs/bochs_mm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_m
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The outer if already checks for data != 0, so it can't really be
> 0. Hence remove it.
>
> Now I don't have specs or anything for this beast, so I have no
> idea whether this was actually intended or whether the logic
> should be different. At least
as MGA change.
Reviewed-by: Ian Romanick
> ---
> drivers/gpu/drm/ast/ast_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index 38941a656312..01bf9e730acf 100644
> --- a/drivers/gpu/drm/ast/ast_
as MGA change.
Reviewed-by: Ian Romanick
> ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index b119f66fed92..99c1983f99d2 100644
> --
till be NULL.
> Spotted by coverity.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Ian Romanick
> ---
> drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
> b/drivers/gpu/drm/mgag
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> ttm_bo_unref unconditionally calls kref_put on it's argument, so the
> thing can't be NULL without already causing Oopses.
Doesn't this mean the NULL check is in the wrong place (rather than the
NULL check should be removed)?
> Spotted by coverity.
Reviewed-by: Ian Romanick
On 01/12/2014 10:34 AM, Keith Packard wrote:
> the drmServerInfo member, debug_print, takes a printf format string
> and varargs list. Tell the compiler about it.
>
> Signed-off-by: Keith Packard
> ---
> xf86drm.h | 8 +++-
> 1 file change
On 12/13/2013 05:25 PM, Keith Packard wrote:
> These are duplicates from gl.h; I'm not sure which file they belong in, but
> you don't get to have them in both places.
If you're doing something that involves defining GL_GLEXT_PROTOTYPES,
you're doing it wrong.
Also, unless you're sending kernel
From: Ian Romanick <ian.d.roman...@intel.com>
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick
Reported-by: Zhenyu Wang
Cc: Damien Lespiau
Cc: Daniel Vetter
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2013 06:43 PM, Keith Packard wrote:
> Emil Velikov writes:
>
>> On 18/11/13 01:08, Keith Packard wrote:
>>> libudev doesn't have a stable API/ABI, and if the application
>>> wants to use one version, we'd best not load another into
>>>
):
Revert "intel: Add support for GPU reset status query ioctl"
Ian Romanick (3):
intel: Add support for GPU reset status query ioctl
intel: Add support for GPU reset status query ioctl
libdrm: bump to 2.4.48
Keith Packard (1):
Add DRM_MODE_PAGE_FLIP_ASYNC defin
From: Ian Romanick <ian.d.roman...@intel.com>
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kerne
From: Ian Romanick <ian.d.roman...@intel.com>
Previously GCC was squaking about:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized':
intel_bufmgr_gem.c:1325:20: warning: unused variable 'bo_gem'
[-Wunused-variable]
Wrapping with VG(); replaced that w
From: Ian Romanick <ian.d.roman...@intel.com>
The drm_intel_context structure is, wisely, opaque. However, libdrm
users may want to know the hardware context ID associated with the
structure.
Signed-off-by: Ian Romanick
Cc: Ben Widawsky
---
intel/intel_bufmgr.h | 1 +
On 11/09/2013 12:11 AM, Dave Airlie wrote:
>>> How does this interact with the rule that kernel interfaces require an
>>> open source userspace? Is "here are the mesa/libdrm patches that use
>>> it" sufficient to get the kernel interface merged?
>>
>> That's my understanding: open source userspace
On 10/31/2013 04:13 PM, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
>
> Signed-off-by: Keith Packard
One nit below. With that changed,
Reviewed-by: Ian Romanick
> ---
> src/mes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/2013 02:35 PM, Keith Packard wrote:
> Kristian H?gsberg writes:
>
>> I sent a reply to the sourceforge addresses in the original
>> emails, but I didn't see it show up in the archives. Trying
>> again with the freedesktop addresses.
>
>
From: Ian Romanick <ian.d.roman...@intel.com>
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute
From: Ian Romanick <ian.d.roman...@intel.com>
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
Signed-off-by: Ian Romanick
Cc: Mika Kuoppa
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> It's only used in drm_platform.c.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_platform.c | 7 +++
> include/drm/drmP.h | 3 ---
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_platform.c | 7 +++
include/drm/drmP.h | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git
e, I had a look especially at the defined macros (defines).
>
> Signed-off-by: Sedat Dilek
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick ---
> include/drm/i915_drm.h | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> di
at the defined macros (defines).
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff
On 02/14/2013 12:29 PM, Sedat Dilek wrote:
> On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote:
>> On 02/14/2013 01:10 PM, Sedat Dilek wrote:
>>>
>>> Hi,
>>>
>>> noticed when polishing up my build-scripts fot libdrm | mesa |
>>> xf86-video-intel (last one requires gl.h).
>>>
>>> /*
>>>* Mesa
On 02/14/2013 12:29 PM, Sedat Dilek wrote:
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul bri...@vmware.com wrote:
On 02/14/2013 01:10 PM, Sedat Dilek wrote:
Hi,
noticed when polishing up my build-scripts fot libdrm | mesa |
xf86-video-intel (last one requires gl.h).
/*
* Mesa 3-D graphics
On 09/11/2012 09:40 AM, Sedat Dilek wrote:
> Hi,
>
> I can't see it in [1], forgotten?
Mesa 9.0 hasn't been released yet, so of course there isn't a release tag.
> Regards,
> - Sedat -
>
> [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags
On 09/11/2012 09:40 AM, Sedat Dilek wrote:
Hi,
I can't see it in [1], forgotten?
Mesa 9.0 hasn't been released yet, so of course there isn't a release tag.
Regards,
- Sedat -
[1] http://cgit.freedesktop.org/mesa/mesa/refs/tags
___
dri-devel
On 06/11/2012 03:02 AM, Michel D?nzer wrote:
> On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote:
>> Hi,
>>
>> I'm currently trying to make use of OML_sync_control extension to schedule
>> presentation of video frames in xbmc.
>>
>> I've run into somewhat of a snag. It seem the spec doesn't
On 06/11/2012 03:02 AM, Michel Dänzer wrote:
On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote:
Hi,
I'm currently trying to make use of OML_sync_control extension to schedule
presentation of video frames in xbmc.
I've run into somewhat of a snag. It seem the spec doesn't specify what
time
On 05/17/2012 12:09 AM, Dan Carpenter wrote:
> drm_core_ioremap() initializes ->handle. We already know
> "dev->agp_buffer_map" is a valid pointer.
>
> Signed-off-by: Dan Carpenter
I'm surprised that has never been hit.
Reviewed-by: Ian Romanick
>
> d
On 05/17/2012 12:09 AM, Dan Carpenter wrote:
drm_core_ioremap() initializes -handle. We already know
dev-agp_buffer_map is a valid pointer.
Signed-off-by: Dan Carpenterdan.carpen...@oracle.com
I'm surprised that has never been hit.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
diff
pport can be added to Mesa if we
> really want 64 bit values, but that means checking the drawable sbc and
> adding whenver sbc hits 0.
3/4, 4/4, 5/6, and 6/6:
Reviewed-by: Ian Romanick
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> We only spec a 32 bit swap count, so drop the high sbc field.
>
> Signed-off-by: Jesse Barnes
Is there any way we could do this and NOT break building older versions
of Mesa? I'd like to be able to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 02:08 PM, Jesse Barnes wrote:
> On Tue, 3 May 2011 14:02:31 -0700
> Jesse Barnes wrote:
>
>> On Tue, 03 May 2011 13:54:38 -0700
>> Keith Packard wrote:
>>
>>> On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes >> virtuousgeek.org>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 02:08 PM, Jesse Barnes wrote:
On Tue, 3 May 2011 14:02:31 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 03 May 2011 13:54:38 -0700
Keith Packard kei...@keithp.com wrote:
On Tue, 3 May 2011 12:21:24 -0700, Jesse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
We only spec a 32 bit swap count, so drop the high sbc field.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Is there any way we could do this and NOT break building older versions
of Mesa? I'd
to Mesa if we
really want 64 bit values, but that means checking the drawable sbc and
adding whenver sbc hits 0.
3/4, 4/4, 5/6, and 6/6:
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
> and fix fallout.
>
> Signed-off-by: Joe Perches
Aside from the comment below about intel_bios.c,
Reviewed-by:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Reduce drm text size ~1% by using drm_err and
> printf extension %pV to emit error messages.
>
> Remove unused macro DRM_MEM_ERROR.
>
> $ size drivers/gpu/drm/built-in.o*
>text data bss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
Reduce drm text size ~1% by using drm_err and
printf extension %pV to emit error messages.
Remove unused macro DRM_MEM_ERROR.
$ size drivers/gpu/drm/built-in.o*
text data bss dec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches j...@perches.com
Aside from the comment below about intel_bios.c,
Reviewed-by: Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2011 08:40 AM, Gross, Andy wrote:
> There has been some discussion on the linaro-dev list about having a
> memory management meeting at the ELC. See links below:
What is "the ELC"?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2011 08:40 AM, Gross, Andy wrote:
There has been some discussion on the linaro-dev list about having a
memory management meeting at the ELC. See links below:
What is the ELC?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luc Verhaegen wrote:
> Since redhat is then not working with qualcomm, why is this then your
> responsibility?
I find that sentiment surprising from somebody who has actually met Dave. :/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10
65 matches
Mail list logo
