On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > I'd like to amend my reviewed by and say the lock shouldn't be held
> > around the call to the drm helper function. It queue
viously I had only checked our internal driver
callbacks but missed that the lock was held across the helper too.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
viously I had only checked our internal driver
callbacks but missed that the lock was held across the helper too.
--
Jesse Barnes, Intel Open Source Technology Center
erence from other outputs
> connected to that pch port
>
> Signed-off-by: Keith Packard
> ---
Ah nice catch. I expect one day we'll have all the chipset and PCH
differences coded...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
erence from other outputs
> connected to that pch port
>
> Signed-off-by: Keith Packard
> ---
Ah nice catch. I expect one day we'll have all the chipset and PCH
differences coded...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
output_reg);
> }
>
> +static enum drm_connector_status
> +i915_dp_detect_common(struct intel_dp *intel_dp)
Maybe you can fix the prefix of this function while you're at it since
it's not i915 or even i9xx specific?
--
Jesse Barnes, Intel Open Source Technology Center
_
p->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
p->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Revie
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Revie
output_reg);
> }
>
> +static enum drm_connector_status
> +i915_dp_detect_common(struct intel_dp *intel_dp)
Maybe you can fix the prefix of this function while you're at it since
it's not i915 or even i9xx specific?
--
Jesse Barnes, Intel Open Source Technology Center
ust fire off a uevent and let userspace tell us what to do */
> drm_helper_hpd_irq_event(dev);
> }
yay, sounds like this will fix Andrew's problem and probably lots of
other random DP related failures.
Looks like the ->detect function is similarly protected at the call
site (though
ust fire off a uevent and let userspace tell us what to do */
> drm_helper_hpd_irq_event(dev);
> }
yay, sounds like this will fix Andrew's problem and probably lots of
other random DP related failures.
Looks like the ->detect function is similarly protected at the call
site (though
On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer wrote:
> Am 29.06.2011 00:06, schrieb Jesse Barnes:
> > On Wed, 29 Jun 2011 00:01:58 +0200
> > Olaf Freyer wrote:
> >
> >> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> >>> Ok interesting, did
On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer wrote:
> Am 29.06.2011 00:06, schrieb Jesse Barnes:
> > On Wed, 29 Jun 2011 00:01:58 +0200
> > Olaf Freyer wrote:
> >
> >> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> >>> Ok interesting, did
On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > /**
> > + * drm_plane_funcs - driver plane control functions
> > + * @update_plane: update the plane configuration
> > + */
> > +stru
On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > ?/**
> > + * drm_plane_funcs - driver plane control functions
> > + * @update_plane: update the plane configuration
> > + */
> > +stru
On Thu, 21 Jul 2011 19:15:24 +0900
Joonyoung Shim wrote:
> Hi,
>
> 2011/6/16 Jesse Barnes :
> > On Tue, 7 Jun 2011 13:07:38 -0700
> > Jesse Barnes wrote:
> >
> >> This patchset updates the previous one, incorporating the feedback I
> >> rec
On Thu, 21 Jul 2011 19:15:24 +0900
Joonyoung Shim wrote:
> Hi,
>
> 2011/6/16 Jesse Barnes :
> > On Tue, ?7 Jun 2011 13:07:38 -0700
> > Jesse Barnes wrote:
> >
> >> This patchset updates the previous one, incorporating the feedback I
> >> rec
On Thu, 21 Jul 2011 19:30:00 +0900
Joonyoung Shim wrote:
> Hi,
>
> simple questions :)
>
> 2011/6/21 Jesse Barnes :
> > Planes are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the c
On Thu, 21 Jul 2011 19:30:00 +0900
Joonyoung Shim wrote:
> Hi,
>
> simple questions :)
>
> 2011/6/21 Jesse Barnes :
> > Planes are a bit like half-CRTCs. ?They have a location and fb, but
> > don't drive outputs directly. ?Add support for handling them to the c
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang wrote:
> On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
> > On Mon, 20 Jun 2011 19:36:11 +0200
> > Wolfram Sang wrote:
> >
> > > Commit 6067aa (drm/i915: split clock gating init into per-chipset
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang wrote:
> On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
> > On Mon, 20 Jun 2011 19:36:11 +0200
> > Wolfram Sang wrote:
> >
> > > Commit 6067aa (drm/i915: split clock gating init into per-chipset
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert "dri2proto: make DRI2 swap event match GLX spec"
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/indivi
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert "dri2proto: make DRI2 swap event match GLX spec"
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/indivi
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer wrote:
> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> > On Tue, 28 Jun 2011 23:09:45 +0200
> > Olaf Freyer wrote:
> >>>>> I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> >>>>
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer wrote:
> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> > On Tue, 28 Jun 2011 23:09:45 +0200
> > Olaf Freyer wrote:
> >>>>> I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> >>>>
interesting, didn't realize X startup was so GPU intensive. :)
The patch you reverted will definitely cause the GPU to ramp up its
frequency much faster than before, but it sounds like on your system
you might also see it with the revert if you run something GPU
intensive like nexuiz.
The CPU
interesting, didn't realize X startup was so GPU intensive. :)
The patch you reverted will definitely cause the GPU to ramp up its
frequency much faster than before, but it sounds like on your system
you might also see it with the revert if you run something GPU
intensive like nexuiz.
The CPU
32becf6e51535d36b690f2a
> > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2
> >
> >
> >
> > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> > cause. Can you check if the appended revert of that commit makes
> > things disappe
32becf6e51535d36b690f2a
> > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2
> >
> >
> >
> > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> > cause. Can you check if the appended revert of that commit makes
> > things disappear?
> It seems like you guessed perfectly correct - reverting the commit makes
> those notifications go away at once.
>
Without this reverted you see messages? I missed the earlier stuff,
what message are you seeing?
--
Jesse Barnes, Intel Open Source Technology Center
doesn't log the drm debug.
> > Is there another parameter to append at the kernel to send via ethernet
> > also the debug?
>
> I don't know how to get the drm debug sent to ethernet; perhaps someone
> else does?
Use netconsole. Documentation/networki
e, but it doesn't log the drm debug.
> > Is there another parameter to append at the kernel to send via ethernet
> > also the debug?
>
> I don't know how to get the drm debug sent to ethernet; perhaps someone
> else does?
Use netconsole. Documentation/networking/netconsole.txt has all the
gory details.
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
>
On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
>
On Tue, 21 Jun 2011 10:55:39 +0200
Marcus Lorentzon wrote:
> On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
>
On Tue, 21 Jun 2011 10:55:39 +0200
Marcus Lorentzon wrote:
> On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
>
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 235 +++-
drivers/gpu/drm/drm_
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets upstream.
I'd be interested to see whether thes
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 235 +++-
drivers/gpu/drm/drm_
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets upstream.
I'd be interested to see whether thes
n -ENODEV in this case and propagate it to the upper
> layers.
>
> Signed-off-by: Wolfram Sang
> Cc: Jesse Barnes
> Cc: Chris Wilson
> ---
Looks good, thanks Wolfram.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
n -ENODEV in this case and propagate it to the upper
> layers.
>
> Signed-off-by: Wolfram Sang
> Cc: Jesse Barnes
> Cc: Chris Wilson
> ---
Looks good, thanks Wolfram.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
; > gating routine is required I'd rather just see the panic and add a new
> > routine at that time (i.e. what we normally do during bringup).
>
> How about BUG_ON(!ptr) in the init-routine for a bit more grace? And/or
> a warning
; > gating routine is required I'd rather just see the panic and add a new
> > routine at that time (i.e. what we normally do during bringup).
>
> How about BUG_ON(!ptr) in the init-routine for a bit more grace? And/or
> a warning in the else-block? It seems to happen to users...
Yeah, a BUG_ON would be fine.
--
Jesse Barnes, Intel Open Source Technology Center
(HAS_PCH_SPLIT(dev)) {
> ...
> } else
> dev_priv->display.update_wm = NULL;
> }
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we nor
(HAS_PCH_SPLIT(dev)) {
> ...
> } else
> dev_priv->display.update_wm = NULL;
> }
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we nor
check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a
check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes wrote:
> This patchset updates the previous one, incorporating the feedback I
> received:
> 1) uses the v4l fourcc codes to communicate pixel format
> 2) adds a new addfb ioctl that takes a format
> 3) adds working SNB supp
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes wrote:
> This patchset updates the previous one, incorporating the feedback I
> received:
> 1) uses the v4l fourcc codes to communicate pixel format
> 2) adds a new addfb ioctl that takes a format
> 3) adds working SNB supp
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> > On Tue, 7 Jun 2011 13:07:39 -0700
> > Jesse Barnes wrote:
> >
> >
> >> +/* Planes blend with or override other bits on the CRTC */
> >&g
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> > On Tue, 7 Jun 2011 13:07:39 -0700
> > Jesse Barnes wrote:
> >
> >
> >> +/* Planes blend with or override other bits on the CRTC */
> >&g
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> +
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> +
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> > wrote:
> >
> > > Can you keep drm-intel-next fairly up to date with respect to the
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > Can you keep drm-intel-next fairly up to date wi
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> wrote:
>
> > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
>
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> wrote:
>
> > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
>
ng on a new feature for the next window), and as a
downstream gfx developer I'd like to see this on the Intel side as
well, unless other developers have big objections...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ng on a new feature for the next window), and as a
downstream gfx developer I'd like to see this on the Intel side as
well, unless other developers have big objections...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
t altogether, or we preserve the idea of a
"primary" plane (whatever that means for a given platform) that's tied
to each CRTC, which each additional plane described in a separate
structure. Z order and blend restrictions will have to be communicated
separately I think...
Thanks,
--
t altogether, or we preserve the idea of a
"primary" plane (whatever that means for a given platform) that's tied
to each CRTC, which each additional plane described in a separate
structure. Z order and blend restrictions will have to be communicated
separately I think...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
be sure to submit it soon.
Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.
Thanks,
Jesse Barn
be sure to submit it soon.
Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.
Thanks,
Jesse Barnes
LPC2011 Planning Chair
On Wed, 4 May 2011 17:49:37 -0700
Jesse Barnes wrote:
> How about you look at git and see what happened last time?
>
> We added some dri2 proto requests, and people wanted to build with old
> versions w/o the new requests. So they added some ifdefs but didn't
> check all
On Wed, 4 May 2011 17:49:37 -0700
Jesse Barnes wrote:
> How about you look at git and see what happened last time?
>
> We added some dri2 proto requests, and people wanted to build with old
> versions w/o the new requests. So they added some ifdefs but didn't
> check all
On Thu, 05 May 2011 09:32:46 +1000
Dave Airlie wrote:
> On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
> > On Wed, 04 May 2011 15:17:31 -0700
> > Ian Romanick wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
On Thu, 05 May 2011 09:32:46 +1000
Dave Airlie wrote:
> On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
> > On Wed, 04 May 2011 15:17:31 -0700
> > Ian Romanick wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
On Wed, 4 May 2011 16:16:37 -0700
Jesse Barnes wrote:
> On Wed, 04 May 2011 15:17:31 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > > We only spec a 32
On Wed, 4 May 2011 16:16:37 -0700
Jesse Barnes wrote:
> On Wed, 04 May 2011 15:17:31 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > > We only spec a 32
On Wed, 04 May 2011 15:17:31 -0700
Ian Romanick wrote:
> -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
>
&g
On Wed, 04 May 2011 15:17:31 -0700
Ian Romanick wrote:
> -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
>
&g
On Tue, 03 May 2011 14:15:30 -0700
Keith Packard wrote:
> On Tue, 3 May 2011 14:08:58 -0700, Jesse Barnes
> wrote:
>
> > Fixed version below.
>
> Reviewed-by: Keith Packard
>
> (assuming that the GLX protocol specification gets updated to match :-)
Yeah, Ian is
On Tue, 03 May 2011 14:15:30 -0700
Keith Packard wrote:
> On Tue, 3 May 2011 14:08:58 -0700, Jesse Barnes
> wrote:
>
> > Fixed version below.
>
> Reviewed-by: Keith Packard
>
> (assuming that the GLX protocol specification gets updated to match :-)
Yeah, Ian is
Updated with explicit padding.
--
Jesse Barnes, Intel Open Source Technology Center
>From 0ca3778de195a82087d0f07415a1cf8fc94f5b0a Mon Sep 17 00:00:00 2001
From: Jesse Barnes
Date: Tue, 3 May 2011 12:14:58 -0700
Subject: [PATCH] dri2proto: make DRI2 swap event match GLX spec
We only spec a
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
> > wrote:
> >
> > > We only spec a 32 bit swap count, so drop the high sbc field.
>
Updated with explicit padding.
--
Jesse Barnes, Intel Open Source Technology Center
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> wrote:
> >
> > > We only spec a 32 bit swap count, so drop the hig
On Tue, 03 May 2011 13:54:38 -0700
Keith Packard wrote:
> On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes
> wrote:
>
> > We only spec a 32 bit swap count, so drop the high sbc field.
>
> You're missing the explicit 16-bit padding field after 'event_type'
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> wrote:
>
> > We only spec a 32 bit swap count, so drop the high sbc field.
>
> You're missing the explicit 16-bit padding field after '
501 - 600 of 905 matches
Mail list logo
