a good example. They've been out there since
early Oct, have received review and testing, and should have been in
-next for many months now (in previous releases!).
What can we do to improve the process to get trees updated more
regularly and get fixes integrated faster?
Thanks,
--
Jesse Barn
not for virtualization; these bits are read by the AMT
engine for its built-in KVM functionality.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
big downside here is that we'll be very pessimistic about the link
bw requirements for say 16 or 8bpp modes.
I see you have another patch to address some of this, but I wonder if
we have enough info to calculate the bpp at prepare time so it's set
early on for use by both the crtc and enco
This prevents a race between module init and sysfs access (usually only
seen at module reload time, or if somehow your userspace starts fast
enough and pokes at /sys/class/drm while the drivers are still
initializing).
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_sysfs.c | 75
Many of us really want (and need) a way to set the whole display
configuration atomically, as well as test a global config.
In talking with Rob and Alex here at ELC a bit, I think this may be
enough:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 2a2acda..2864b02 100644
--- a/
On Wed, 15 Feb 2012 17:59:45 -0500
Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
> > +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > it for validity */
> > +
> > +struct drm_mode_set_config {
&g
On Thu, 16 Feb 2012 00:12:49 +0100
Daniel Vetter wrote:
> On Wed, Feb 15, 2012 at 05:59:45PM -0500, Adam Jackson wrote:
> > On 2/15/12 5:42 PM, Jesse Barnes wrote:
> >
> > >+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> >
On Thu, 16 Feb 2012 04:46:39 -0800 (PST)
Jakob Bornecrantz wrote:
> - Original Message -
> > Many of us really want (and need) a way to set the whole display
> > configuration atomically, as well as test a global config.
> >
> > In talking with Rob and Alex here at ELC a bit, I think thi
-
2 files changed, 37 insertions(+), 2 deletions(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
On Thu, 23 Feb 2012 23:57:06 -0200
Eugeni Dodonov wrote:
> As noticed by Torsten Kaiser, the operator precedence can play tricks with
> us here.
>
> CC: Dave Airlie
> CC: Jesse Barnes
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/intel_display.c |
ion to avoid divide by zero if
xpos<0
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
_
abled though, which should have the same effect as
the patch intended, though at the cost of higher power consumption.
Fix just sent to Dave anyway.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri
On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov wrote:
> On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:
>
> > On Thu, 23 Feb 2012 21:19:20 +0100
> > Torsten Kaiser wrote:
> >
> > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie wrote:
> > > &
On Mon, 27 Feb 2012 08:08:13 -0800
Jesse Barnes wrote:
> The following changes since commit
> 3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712:
>
> drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06
> +)
>
> are available in the git repository at:
>
cea_extension(edid);
Ah that's better. Do you have a TV that reports these feature bits?
If so, which model?
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
COLOR_FORMAT_RGB444;
> if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB444)
> info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
> if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB422)
> info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
&g
it may be better to just do the font rendering with the CPU anyway
(though cairo-gl is supposedly getting better), and leave the GL for
transition effects and such.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
D_NAME, "AT5NM10T-I"),
> > > },
> > > },
> > > + {
> > > + .callback = intel_no_lvds_dmi_callback,
> > > + .ident = "MSI Wind Box DC500",
> > > + .matches = {
> > > +
er interrupt, with chained secondary interrupt statuses.
> If IIR is 0, the interrupt wasn't raised by the GPU.
I've actually seen cases where one of the PIPE*STAT regs is stuck, and
even if IIR is 0 we still get interrupts... Jiri can you verify the
PIPE*STAT regs have bits set, maybe one
known issue with the DRM code, I thought Dave had a
fix queued a long time ago though... Dave?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesk
10 @@ static void intel_sdvo_mode_set(struct drm_encoder
> *encoder,
> !intel_sdvo_set_tv_format(intel_sdvo))
> return;
>
> + /* We have tried to get input timing in mode_fixup, and filled into
> + * adjusted_mode.
> + */
> +
On Tue, 10 Apr 2012 10:47:49 +0200
Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don
;input_dtd because it's not
> needed).
>
> Hopefully this clears things up a bit.
Yep, thanks. Hopefully you'll get your SDVO spec access soon...
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby wrote:
> On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > So port hotplug is always reporting that port C has a hotplug
> > interrupt though... If you write 0x3 back to it does the interrupt
> > stop?
>
> I'm not s
etting stuck (though it's possible this could be related to
pipelined fencing, if the fences are programmed to point at some funky
memory space).
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
_
On Wed, 11 Apr 2012 08:29:22 +0200
Michel Dänzer wrote:
> On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
> > On Tue, 10 Apr 2012 20:11:29 +0200
> > Jiri Slaby wrote:
> >
> > > On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > > > So port hot
re planes associated with a given pipe, along with
ancillary data that may be needed (sprite position, z order, gamma,
etc).
This could easily spiral out of control though, given how poorly the
existing KMS API expresses the variety of display controllers out
there; hopefully we can ke
tc didn't emit an
event, so I didn't add it to setplane (it would be of limited
usefulness anyway since we really want to flip primary + sprite at the
same time).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
the interim a wait would at least avoid the issues we are
> >> seeing. I will see how awful it looks.
> >
> > Just to confirm its the drm_sysfs_device_add that causes the race we care
> > about.
> >
> > it needs to happen after the driver is happy. Since it calls
> > device_register and that is what triggers udev magic to load the
> > userspace.
> >
> > If you have a userspace app banging on a static device node that might
> > need another set of fun fixes.
>
> Okay the sysfs add and the idr_replace are the things we need to delay.
Since you can still get at things with a static node, it seems like
locking is the real issue here? Is there no mutex we can take across
init to block any openers until we're done?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
s for you I guess it's ok to blacklist your
chipset until we poke some hw folks internally about this.
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
kind of problem... though hopefully we'll
be adding planar support back again sometime soon.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
requirement; the assumption was that
the display manager would do the right thing in any case (both mode
sets and plane sets are privileged ops). When doing a mode set, the
plane parameters will probably need to be changed anyway...
But keeping it on with some kind of sensible behavior makes the simpl
spin_lock_irqsave(&dev->event_lock, flags);
> > --
> > 1.7.3.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-
initely better than nothing.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
kfree(intel_plane);
> return -ENODEV;
> }
>
> @@ -699,4 +700,3 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe)
>
> return ret;
> }
Yeah, looks fine. I just fixed the same thing in a local tree (though
by using a goto since I
compat atomic setup, we'll need to read the
current state of any existing objects and pass them in to the driver...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
that work isn't ready yet either I've dropped the offending
> patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
kage introduced in
>
> commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
> Author: Daniel Vetter
> Date: Tue Dec 11 00:59:24 2012 +0100
>
> drm: refcounting for sprite framebuffers
>
> Reported-by: Jesse Barnes
> Cc: Jesse Barnes
> Cc: Rob Clark
> Sig
o this stuff seems to be a nop.
>
> And if these writes can get reordered somewhere, why not everything
> else too? I'm sure we have places where we write a bunch of registers,
> and the final write enables something which requires the earlier
> writes to have landed bef
fprintf(stderr, "clock_gettime failed: %s\n", strerror(ret));
> + fprintf(stderr, "clock_gettime failed: %s\n", strerror(errno));
> goto out;
> }
> timeout.tv_sec++;
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technolo
not attached to the direct structure reference; a couple of
inlines are just as easy to read. So no argument from me.
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
se I can do besides using a special kernel with the backed out
> commit ? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issu
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck wrote:
> On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
> > On Fri, 21 Jun 2013 23:58:08 -0700
> > Guenter Roeck wrote:
> >
> > > Hi all,
> > >
> > > after upgrading one
er than trying
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes wrote:
> On Tue, 16 Jul 2013 11:34:25 +0400
> Konstantin Khlebnikov wrote:
> > I've tested that patch and it really works for me. If you want change
> > something for other hardware or
> > extend range where forcew
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter wrote:
> On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote:
> > On Tue, 16 Jul 2013 10:06:54 -0700
> > Jesse Barnes wrote:
> >
> > > On Tue, 16 Jul 2013 11:34:25 +0400
> > > Konstantin Khlebnikov
://bugs.freedesktop.org/show_bug.cgi?id=54089
> References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
> Signed-off-by: Konstantin Khlebnikov
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Jesse Barnes
> ---
My hero!
So the later init change didn't work?
Eithe
(probably a "task hung" message?).
Does this happen reliably? Does a previous kernel work ok?
--
Jesse Barnes, Intel Open Source Technology Center
--
Create and publish websites with WebMatrix
Use the most popular FR
On Sat, 2 Apr 2011 09:24:10 +0900
Norbert Preining wrote:
> > Hm, ok so on resume we're checking GPU busyness, which is normal,
> > but end up hanging on the spinlock? Do you see what scrolls by
> > above the text you took a picture of (probably a "task hung"
> > message?).
>
> More than what I
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a ueve
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 54
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 10 ++
include/drm/drm_crtc.h |6
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson wrote:
> On 4/15/11 2:40 PM, Jesse Barnes wrote:
>
> > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
> > info->bpp = 0;
> > break;
> > }
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson wrote:
> On 4/15/11 2:22 PM, Jesse Barnes wrote:
> > EDID 1.4 digital monitors report the bit depth supported in the input
> > field. Add support for parsing this out and storing the info in the
> > display_info structu
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes wrote:
> On Fri, 15 Apr 2011 15:13:02 -0400
> Adam Jackson wrote:
> > info->color_formats = DRM_COLOR_FORMAT_RGB444;
> > if (edid->features & DRM_EDID_FEATURE_YCRCB444)
> > info->color
On Fri, 15 Apr 2011 15:36:22 -0400
Adam Jackson wrote:
> On 4/15/11 3:19 PM, Jesse Barnes wrote:
>
> > Or is there a CEA block extension that allows for more granularity?
>
> CEA has bits for the two YCbCr formats too, which we should also parse
> since there's plent
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 55
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c |6 ++
include/drm/drm_crtc.h |5
>
> unsigned long? its 2011.
That doesn't tell me much about what you'd prefer... I figured a
bitfield would be fairly extensible if new surface formats were added.
Maybe you're thinking it's not enough to support all the misc ones out
there though?
--
Jesse Ba
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie wrote:
> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c |6 ++
include/drm/drm_crtc.h |5
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie wrote:
> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444
next Wednesday.
Np, thanks. Just wanted to make sure you didn't want other changes.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
we have already,
but taking an overlay object instead of a CRTC.
Overlays 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
---
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> wrote:
>
> > Overlays 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 Mon, 25 Apr 2011 16:35:20 -0700
Stéphane Marchesin wrote:
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> >> wrote:
&
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes
> wrote:
>
> > Yes, that matches my understanding as well. I've deliberately made the
> > implementation flexible there though, under the assumption that
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher wrote:
> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> >> wrote
t of capture hardware would map very nicely onto GEM objects I
> suspect and if you want to merge live video into Wayland it seems a
> logical path ?
Thanks Alan, of course that's a good idea, I'll see about integrating
the two.
--
Jesse Barnes, Intel Open Source T
On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrjälä wrote:
> On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> > wrote:
> >
> > > Overlays are a bit like half-CRTCs. They have a location and fb,
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel over
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
proto version bump.
---
configure.ac |2 +-
glxproto.h | 13 +
2 fi
The swap complete event wasn't being handled fully; because XEvents are
only 32 bytes long, we were getting junk for the sbc_lo value. If the
server supports it, unpack the new structure, otherwise just return 0
for the sbc value instead of garbage.
---
configure.ac|4 ++--
src/glx/dr
XEvents are limited to 32 bytes, so use some creative stuffing to fit
all the bits we'd like to supply.
---
configure.ac |2 +-
dri2proto.h |9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5b78d6b..9505f56 100644
--- a/configur
I obviously failed to count the swap event structure size after adding
and removing fields a few times, and didn't even account for padding. The
end result is that clients today won't receive the sbc_lo field at all,
and so will likely stuff junk into that field on the client side (or
zero at best
Use the new swap event structure packing and send it to the client if
possible. This means tracking client version information when clients
connect. If they don't support the new packing, they'll get the old
bits and fill junk into their sbc values when they receive the event.
If they do support
se.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
e->event.sequence);
could be pulled out into a separate function for both to use.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
hanged, 16 insertions(+), 23 deletions(-)
>
Oh I see you already addressed my last comment. :)
I think Michel is right about the put; the event queue holds the ref
and the emit should drop it, so keeping them together seems good to me.
Other than that,
Reviewed-by: Jesse Barnes
same for the fir
-EINVAL in that case from drm_wait_vblank due to
drm_vblank_get failing (i.e. the driver enable_vblank hook should fail
if the corresponding crtc is off). At least that's how it's supposed
to work.
--
Jesse Barnes, Intel Open Source Technology Center
see other cases where the refcount was nonzero at
this point?
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
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes wrote:
> On Thu, 28 Apr 2011 18:09:58 +1000
> Christopher James Halse Rogers
> wrote:
> > Ok. This appears to be surprisingly difficult. Particularly, the
> > vblank code indexes crtcs based on the driver-private numbering,
On Thu, 28 Apr 2011 14:33:58 -0700
Eric Anholt wrote:
> On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes
> wrote:
> > The defintion of the swap complete event was wrong; XEvents are only 32
> > bytes long, and with padding the swap event was longer. So use some
> > cre
On Fri, 29 Apr 2011 09:20:31 +0200
Julien Cristau wrote:
> On Thu, Apr 28, 2011 at 13:27:22 -0700, Jesse Barnes wrote:
>
> > diff --git a/glx/glxdri2.c b/glx/glxdri2.c
> > index d979717..654b4ae 100644
> > --- a/glx/glxdri2.c
> > +++ b/glx/glxdri2.c
> > @@
On Thu, 28 Apr 2011 13:27:18 -0700
Jesse Barnes wrote:
> I obviously failed to count the swap event structure size after adding
> and removing fields a few times, and didn't even account for padding. The
> end result is that clients today won't receive the sbc_lo field at
On Sat, 30 Apr 2011 01:10:27 +0200
Mario Kleiner wrote:
>
> On Apr 29, 2011, at 11:37 PM, Jesse Barnes wrote:
>
> > On Thu, 28 Apr 2011 13:27:18 -0700
> > Jesse Barnes wrote:
> >
> >> I obviously failed to count the swap event structure size after
> &
Ended up moving over to generic events since the GLX type code is part
of the GLX namespace and larger than 8 bits.
Apparently no one had ever tried ChangeDrawableAttributes with indirect
clients, because simply going a glXSelectEvent causes a crash in that
case. So this patch set includes a fix
version and look for generic events in the event stream
with DRI2 in the extension field.
Signed-off-by: Jesse Barnes
---
configure.ac|2 +-
src/glx/dri2.c | 105 --
src/glx/dri2.h |3 +-
src/glx/dri2_glx.c | 31
The existing event is too large for an XEvent meaning that the swap
count is never sent to clients. Create a generic event instead for use
by new clients & servers.
Signed-off-by: Jesse Barnes
---
configure.ac |2 +-
glxproto.h | 18 ++
2 files changed, 19 insert
events for client compatibility.
Signed-off-by: Jesse Barnes
---
configure.ac|2 +-
src/glx/glxclient.h |2 +-
src/glx/glxext.c| 55 --
3 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
Pass the right drawable pointer as data to the swap complete function.
Signed-off-by: Jesse Barnes
---
glx/glxdri2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index d979717..93c5e5b 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
r the lifetime of the client.
Signed-off-by: Jesse Barnes
---
configure.ac |2 +-
glx/glxdri2.c | 20 +++
hw/xfree86/dri2/dri2.c| 57 -
hw/xfree86/dri2/dri2.h|6
hw/xfree86/dri2/dri2ext.c |
Send the new generic GLX swap event if supported by the client. This
means checking the client GLX version at swap complete time and
constructing a new generic swap completion event at swap complete time.
Signed-off-by: Jesse Barnes
---
configure.ac|2 +-
glx/glxdri2.c
The existing swap complete event is too large to fit in an XEvent, so
use a generic event instead. New servers and clients can use this
structure to fully pass the swap count along with the media stamp
counter, swap complete type, and timestamp.
Signed-off-by: Jesse Barnes
---
configure.ac
After sending the GLXChangeDrawableAttributes request, we also set a
local set of attributes on the DRI drawable. But in the indirect case
this array won't be present, so skip the setting in that case to avoid a
crash.
Signed-off-by: Jesse Barnes
---
src/glx/glx_pbuffer.c |3 +++
1
Ian reminded me that we changed the spec to fit within an XEvent, but we
never updated the code to match. This set of patches (much simpler than
the last) does just that. Wrapping support can be added to Mesa if we
really want 64 bit values, but that means checking the drawable sbc and
adding whe
Pass the right drawable pointer as data to the swap complete function.
Signed-off-by: Jesse Barnes
---
glx/glxdri2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index d979717..93c5e5b 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
Only send a 32 bit swap count out to the client.
Signed-off-by: Jesse Barnes
---
configure.ac |4 ++--
glx/glxdri2.c |5 ++---
hw/xfree86/dri2/dri2.c|2 +-
hw/xfree86/dri2/dri2.h|2 +-
hw/xfree86/dri2/dri2ext.c |5 ++---
5 files changed, 8
We only spec a 32 bit swap count, so drop the high sbc field.
Signed-off-by: Jesse Barnes
---
configure.ac |2 +-
glxproto.h |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index d88e6df..a3047e4 100644
--- a/configure.ac
+++ b
We only spec a 32 bit sbc count, so drop the high bits.
Signed-off-by: Jesse Barnes
---
configure.ac |2 +-
dri2proto.h |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5b78d6b..9505f56 100644
--- a/configure.ac
+++ b/configure.ac
201 - 300 of 905 matches
Mail list logo
