est but in 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
connector->base.id,
> drm_get_connector_name(connector),
> - old_status, connector->status);
> + connector_status_str(old_status),
> + connector_status_str(connector->status));
> if (old_status != connector->status)
> changed = true;
> }
Yeah, thanks.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
*/
> @@ -3041,6 +3024,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
> udelay(24);
>
> I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
> +
> + mutex_unlock(&dev_priv->dpio_lock);
> }
>
> /*
> @@ -4268,6 +4253,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> bool is_sdvo;
> u32 temp;
>
> + mutex_lock(&dev_priv->dpio_lock);
> +
> is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
>
> @@ -4351,6 +4338,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> temp |= (1 << 21);
> intel_dpio_write(dev_priv, DPIO_DATA_CHANNEL2, temp);
> }
> +
> + mutex_unlock(&dev_priv->dpio_lock);
> }
>
> static void i9xx_update_pll(struct drm_crtc *crtc,
Looks fine, I guess you could convert the wait_for_atomic_us to the
non-atomic variant now that you have a mutex. Either way:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 12 Dec 2012 23:00:34 +0100
Daniel Vetter wrote:
> On Wed, Dec 12, 2012 at 12:54:47PM -0800, Jesse Barnes wrote:
> > On Wed, 12 Dec 2012 14:06:44 +0100
> > Daniel Vetter wrote:
> >
> > > Spinning for up to 200 us with interrupts locked out is not good. So
&
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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
U
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
-- next part --
A non-text attachment was scrubbed..
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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov wrote:
> On Mon, Feb 27, 2012 at 13:09, Jesse Barnes virtuousgeek.org>wrote:
>
> > On Thu, 23 Feb 2012 21:19:20 +0100
> > Torsten Kaiser wrote:
> >
> > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airl
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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
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;
> -
Ok no problem. I think Keith just queued up the i915 bits, but I don't
think they've made their way to Dave yet.
Jesse
On Wed, 4 Jan 2012 22:55:31 -0600
Rob Clark wrote:
> note: looks like I need to rebase this patch after exynos drm driver
> was pulled to drm-next.. if there are some other co
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 Bar
?
Right, but not for virtualization; these bits are read by the AMT
engine for its built-in KVM functionality.
--
Jesse Barnes, Intel Open Source Technology Center
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 encoder
#endif /* __alpha__ */
>
> +#ifdef CONFIG_PCI
> return pci_domain_nr(dev->pdev->bus);
> +#else
> + return 0;
> +#endif
> }
>
> #if __OS_HAS_AGP
I think we fixed this, but I guess Linus hasn't pulled my tree yet...
--
Jesse Barnes, Intel Open Source Technology Center
code is causing problems.
>
> If driver is utilising invalidate events detection can't happen in server
> side.
We could print a warning in this case at the very least. Maybe if we
try to swap again with the same dri2 invalidate stamp we could print an
error. Kristian?
Jesse
--
Jesse Barnes, Intel Open Source Technology Center
(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 Barnes, Intel Open Source Technology Center
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
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 virtuousgeek.org> wrote:
>
> > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handlin
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 >> virtuousgeek
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > Yes, that matches my understanding as well. I've deliberately made the
> > implementation flexible there though, unde
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 >> virtuousgeek.org
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 Technology Center
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 > virtuousgeek.org> wrote:
> >
> > > Overlays are a bit like half-CRTCs. They have a lo
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
>base.link, &e->base.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
> 1 files changed, 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:
We should return -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
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 virtuousgeek.org> 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
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
r this...
> I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
> + if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
> + DRM_ERROR("timed out waiting for panel to power off status
> 0x%08x control 0x%08x\n",
> +
only think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
Packard
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 ++-
> drivers/gpu/drm/i915/intel_display.c | 60 ++---
> 2 files changed, 58 insertions(+), 15 deletions(-)
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard wrote:
> Just an extra parameter which isn't actually needed.
>
> Signed-off-by: Keith Packard
> ---
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 08 Aug 2011 11:42:56 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
> wrote:
>
> > Yep, looks fine. The only think we might want to sprinkle about are
> > checks for panel off so we can avoid visible corruption if we whack
> &g
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
> wrote:
>
> > ...to catch places like this where the wrong register gets used. :)
>
> Ouch! There are only two places we *should* have these loops, one when
>
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> wrote:
>
> > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > fitting we do need to do an actual power cycle when going from
> > non
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
> wrote:
> > On Mon, 08 Aug 2011 12:53:31 -0700
> > Keith Packard wrote:
> >
> > > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes > > virtuousge
NTROL;
Hah yeah that's a good one, thanks for the fix.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes
---
include/drm/Makefile.am |1 +
include/drm/drm.h| 13 -
include
On Tue, 6 Dec 2011 15:23:57 -0800
Jesse Barnes wrote:
> Add structs and functions necessary for the new plane and fb handling code,
> including a new header, drm_fourcc.h, that includes the surface formats
> supported by various DRM drivers.
>
> Signed-off-by: Jesse Barnes
Import the current kernel bits into libdrm for client code.
Signed-off-by: Jesse Barnes
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir
tian has a few patches outstanding for CEA mode handling.
Getting them in makes sense to me and this patch looks like it's
structured nicely at least (I haven't checked the CEA bits against the
specs though).
Any chance we can get them included for 3.3?
Thanks,
--
Jesse Barnes, Intel Open
ed out was that you don't
seem to be validating the zpos ioctl parameters for sanity. Not sure
if there's much to do, but it may be worth checking for a max zpos or
something...
--
Jesse Barnes, Intel Open Source Technology Center
hang?
>
> No, it doesn't have any effect.
Yeah I don't think we use that flag for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just t
On Tue, 01 Feb 2011 16:57:37 +
Chris Wilson wrote:
> On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes
> wrote:
> > The bisect is interesting, I'd have expected a failure when we
> > re-enabled rc6 on ILK or when we fixed up the ring buffer init.
>
> Yes,
rtly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what
does /sys/kernel/debug/dri/0/i915_drpc_info report?
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes wrote:
> On Wed, 09 Feb 2011 17:09:10 +
> Chris Wilson wrote:
>
> > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > gmail.com> wrote:
> > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote:
On Wed, 9 Feb 2011 09:53:26 -0800
Jesse Barnes wrote:
> On Wed, 9 Feb 2011 09:50:47 -0800
> Jesse Barnes wrote:
>
> > On Wed, 09 Feb 2011 17:09:10 +
> > Chris Wilson wrote:
> >
> > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > >
>
> > That should work its way upstream shortly.
>
> I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang
> when I start X, but it hangs when I resume from suspend to RAM.
Since intel_reg_read won't work, can you try this patch instead? Just
patch
On Fri, 11 Feb 2011 00:23:09 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
> > Since intel_reg_read won't work, can you try this patch instead? Just
> > patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
>
On Fri, 11 Feb 2011 08:28:37 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
> > Does this kernel have the problem patch included? Or is it reverted?
>
> That was without the patch reverted, now I've reverted it and
not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes
> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> &g
ich makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
to VT switching suggest that the problems
> related to disabling part A may actually have been related to handover
> to the console driver before KMS.
Yes, definitely possible. We didn't have all the assertion checks we
have now, so we may have just been masking other problems without
knowing it.
--
Jesse Barnes, Intel Open Source Technology Center
ery much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be better to start a library-ized
EDID codebase from the most complete one we have already, i.e. the DRM
EDID code.
Do you really think the differences between your code and the existing
DRM code are irreconcilable?
--
Jesse Barnes, Intel Open Source Technology Center
; Why can't the gpu be reset/restarted when this happens? When a nic card
> gets hung it is reinitialized
> and restarted why not the gpu?
Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again. We could be meaner about
things and SIGILL the app, but often it's an innocent bystander, and
the real problem is kernel object synchronization and/or the DRI driver
generating bad commands.
--
Jesse Barnes, Intel Open Source Technology Center
s regarding this
issue though, but it does seem a likely candidate.
--
Jesse Barnes, Intel Open Source Technology Center
ink we've been doing well with this on the Intel
side at least; we add feature flags every time we change something, and
make sure userspace is forward and backward compatible). This is more
work for us, but I think it benefits the user in the end. And it could
be worse, at least we're
ditionals to our FDI
training code to support newer chips, I've split it into separate
functions entirely, leaving the old one alone. If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only a
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
501 - 600 of 905 matches
Mail list logo
