ore and after the lid close should help narrow
this down quickly, so please include those too.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
Stay on top of everything new and different, both inside and
arou
ig the 2D driver will try to use a tiled buffer but the kernel
won't set it up properly and you'll just get corruption.
--
Jesse Barnes, Intel Open Source Technology Center
--
Stay on top of everything new
On Tue, 21 Apr 2009 19:48:39 -0700
Eric Anholt wrote:
> On Tue, 2009-04-14 at 15:22 -0700, Jesse Barnes wrote:
> > Add a new page flipping ioctl to the i915 driver, using KMS
> > functionality.
> >
> > Internally, the new flip ioctl will use the mode_set_base func
&chan->adapter, chan);
Ah yeah, that probably explains some misdetection I've seen too, looks
good.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
--
Stay on top of everything n
eople (at least not that I've heard); I certainly have a hard
time reproducing it.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 69aa0ab..c41cba4 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_ir
On Wed, 29 Apr 2009 15:09:33 -0700
Jesse Barnes wrote:
> I'm still working through mutlihead issues on the kernel side; the
> flip waits should wait for *both* vblank events before completing the
> flip. But other than that, I'm pretty happy with things.
This increment
On Thu, 30 Apr 2009 08:08:36 +0200
Michel Dänzer wrote:
> On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote:
> > On Wed, 29 Apr 2009 15:09:33 -0700
> > Jesse Barnes wrote:
> > > I'm still working through mutlihead issues on the kernel side; the
> > > fl
On Thu, 30 Apr 2009 11:36:55 +0300
Ville Syrjälä wrote:
> On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote:
> > On Wed, 29 Apr 2009 15:09:33 -0700
> > Jesse Barnes wrote:
> > > I'm still working through mutlihead issues on the kernel side; the
> >
On Thu, 30 Apr 2009 17:48:08 +0200
Michel Dänzer wrote:
> On Thu, 2009-04-30 at 08:39 -0700, Jesse Barnes wrote:
> > On Thu, 30 Apr 2009 08:08:36 +0200
> > Michel Dänzer wrote:
> >
> > > On Wed, 2009-04-29 at 18:02 -0700, Jesse Barnes wrote:
> > &g
simplest way to fix the issue, so
Acked-by: Jesse Barnes
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'
If you
> combine that with supporting interval (should be useful when queueuing
> up several frames using 3:2 pulldown sequence) then there seems to be
> a need for something more than just a single number.
Ok. I'd better add wha
On Wed, 01 Apr 2009 12:29:04 -0700
Eric Anholt wrote:
> On Fri, 2009-03-27 at 22:01 -0700, Arjan van de Ven wrote:
> > On Fri, 27 Mar 2009 16:08:18 -0700
> > Jesse Barnes wrote:
> > > >
> > > > return ret;
> > >
> > > I defi
libdrm & xf86-video-intel for this.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index ea11207..414a60a 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -353,10 +353,13 @@ drmModeEncoderPtr drmModeGetEncoder(in
This patch adds a "get current" info function for apps to use, probably
mostly at startup time when they just want to see what outputs are
available vs. detecting current status & mode lists. Can help speed up
startup quite a bit in some configurations.
Signed-off-by: Jesse Barn
hich one is better, it's just that D3D
> behaves the way it behaves and Wine needs GLX_SGI_swap_control to
> properly support it. So there are braindead apps out there that need
> it :-)
Ok, thanks a lot for the explanation, it definitely helps. I guess we
have to support several m
On Fri, 1 May 2009 14:13:16 +0300
Ville Syrjälä wrote:
> On Thu, Apr 30, 2009 at 02:39:57PM -0700, Jesse Barnes wrote:
> > On Fri, 1 May 2009 00:25:54 +0300
> > Ville Syrjälä wrote:
> > > > The completion won't happen until at least 'interval' fra
On Wed, 29 Apr 2009 18:02:59 -0700
Jesse Barnes wrote:
> On Wed, 29 Apr 2009 15:09:33 -0700
> Jesse Barnes wrote:
> > I'm still working through mutlihead issues on the kernel side; the
> > flip waits should wait for *both* vblank events before completing
> > the fl
On Sat, 2 May 2009 00:02:16 +0100
Jakob Bornecrantz wrote:
> On Fri, May 1, 2009 at 10:19 PM, Jesse Barnes
> wrote:
> > On Wed, 29 Apr 2009 18:02:59 -0700
> > Jesse Barnes wrote:
> >
> >> On Wed, 29 Apr 2009 15:09:33 -0700
> >> Jesse Barnes wrote:
On Fri, 1 May 2009 14:19:29 -0700
Jesse Barnes wrote:
> On Wed, 29 Apr 2009 18:02:59 -0700
> Jesse Barnes wrote:
>
> > On Wed, 29 Apr 2009 15:09:33 -0700
> > Jesse Barnes wrote:
> > > I'm still working through mutlihead issues on the kernel side; the
>
On Mon, 6 Apr 2009 10:39:17 -0700
Jesse Barnes wrote:
> On Mon, 6 Apr 2009 13:29:53 -0400
> Jarod Wilson wrote:
>
> > On Monday 06 April 2009 12:52:16 Jesse Barnes wrote:
> > > On Mon, 6 Apr 2009 10:11:25 -0400
> > > Jarod Wilson wrote:
> > >
>
On Mon, 04 May 2009 14:45:07 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jesse Barnes wrote:
> > Ok, this set addresses all the shortcomings of the last set, and
> > things seem quite solid, aside from output detection on my test
>
On Mon, 04 May 2009 19:14:29 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jesse Barnes wrote:
> > On Mon, 04 May 2009 14:45:07 -0700
> > Ian Romanick wrote:
> >
> >> There's a problem in dri2SwapBuffers. If a ne
On Sat, 02 May 2009 11:32:02 -0500
Robert Noland wrote:
> On Fri, 2009-02-06 at 10:22 -0800, Jesse Barnes wrote:
> > As discussed in the long thread about vblank related timeouts, it
> > turns out GM45 has different frame count registers than previous
> > chips. This patch
On Tue, 05 May 2009 11:24:29 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
> > On Tue, May 5, 2009 at 12:20 PM, Jesse Barnes
> > wrote:
> >> On Mon, 04 May 2009 19:14:29 -0700
> >> Ian Roman
On Tue, 05 May 2009 13:50:57 -0500
Robert Noland wrote:
> On Tue, 2009-05-05 at 10:44 -0700, Jesse Barnes wrote:
> > On Sat, 02 May 2009 11:32:02 -0500
> > Robert Noland wrote:
> >
> > > On Fri, 2009-02-06 at 10:22 -0800, Jesse Barnes wrote:
> > > > As
Here's a compiz patch to assume the presence of a sane glXSwapBuffer
implementation (i.e. one that uses page flips synchronized to vblank).
It adds --no-wait and --always-swap options, which, if used with the
swapbuffers patchset, will make compiz use the page flipping path for
tear-free drawing.
On Fri, 08 May 2009 10:27:49 +0100
Barry Scott wrote:
> Jesse Barnes wrote:
>
> Why are you comparing booleans to TRUE and worse then negating the
> result?
>
> if( !noWait )
>
> Is clearer.
>
> - waitForVideoSync (s);
> +
On Fri, 08 May 2009 10:27:49 +0100
Barry Scott wrote:
> Jesse Barnes wrote:
>
> Why are you comparing booleans to TRUE and worse then negating the
> result?
>
> if( !noWait )
>
> Is clearer.
>
> - waitForVideoSync (s);
> +
*offset)
> +{
I like the event stuff too; I can imagine it being useful for other
GL features as well, like vblank waits.
--
Jesse Barnes, Intel Open Source Technology Center
--
The NEW KODAK i700 Series Scanners deliver
linus
Jesse Barnes (1):
drm/i915: automatically select FRAMEBUFFER_CONSOLE if !EMBEDDED
drivers/gpu/drm/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Just one fix so far for a common complaint. I think Ben has an
important fix on the way soon too, but I haven't r
advance,
Ah yeah you should probably send this to
intel-...@lists.freedesktop.org and cc e...@anholt.net so he can apply
it. Patch looks fine.
--
Jesse Barnes, Intel Open Source Technology Center
--
The NEW KODAK i700 Ser
g on updates to the dri2-swapbuffers
branches to get it working with userspace.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simpli
7;s an update that makes the set_base async using a new
work_struct. I'll push the libdrm changes into the kms-pageflip branch
now too.
The set_base thing is really ugly; apparently on x86 there's a set_base
macro in the global namespace now, gross. Hopefully that will be fixed
before t
On Fri, 15 May 2009 12:16:14 -0700
Jesse Barnes wrote:
> On Thu, 14 May 2009 23:04:51 -0400
> Kristian Høgsberg wrote:
>
> > From: Kristian Høgsberg
> >
> > This patch adds a vblank synced pageflip ioctl for to the
> > modesetting family of ioctls. The
ffset & (~(resource_size_t)PAGE_MASK)) ||
> (map->size & (~PAGE_MASK))) { drm_free(map, sizeof(*map),
> DRM_MEM_MAPS); return -EINVAL;
Applied to my for-linus branch, thanks Ben.
--
Jesse Barnes, Intel Open Source Technology Center
--
code = func(dev, kdata, file_priv);
>
> - if ((retcode == 0) && (cmd & IOC_OUT)) {
> + if (cmd & IOC_OUT) {
> if (copy_to_user((void __user *)arg, kdata,
>_IOC_SIZE(cmd)) != 0)
>
changed, 9 insertions(+), 1 deletions(-)
--
Jesse Barnes, Intel Open Source Technology Center
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & br
>
> if (alwaysSwap == TRUE)
> damageScreen (s);
>
> at src/screen.c:1455 in the original file, or just after the whole "if
> (s->slowAnimations)" block.
>
> Good luck getting this patch in. Compiz has needed something like this
> for a while.
>
&
On Fri, 15 May 2009 19:21:40 +1000
Dave Airlie wrote:
> > Now all the DRM debug info will be printed if the boot option of
> > "drm.debug=1" is added. Sometimes it is inconvenient. We will get
> > too much unrelated info.
> >
> > This will separate several DRM debug levels and the debug level can
On Sun, 31 May 2009 09:27:54 +0800
yakui_zhao wrote:
> On Wed, 2009-05-27 at 23:28 +0800, Jesse Barnes wrote:
> > On Fri, 15 May 2009 19:21:40 +1000
> > Dave Airlie wrote:
> >
> > > > Now all the DRM debug info will be printed if the boot option of
> > &
GMx-IF"),
> + },
> + },
>
> { } /* terminating entry */
> };
>
Looks fine to me, Eric? Patches to the i915 driver should generally go
to intel-...@lists.freedesktop.org so we don't miss them. Thanks.
Acked-by: Jesse Barnes
-
On Fri, 29 May 2009 19:58:36 +0530
Jaswinder Singh Rajput wrote:
> Hi Andrew,
>
> On Fri, 2009-05-29 at 09:34 -0400, Jarod Wilson wrote:
> > On Friday 29 May 2009 02:16:35 Jaswinder Singh Rajput wrote:
> > > I am not sure where this patch should go.
> > >
> > > So I am also mailing to Andrew an
On Mon, 01 Jun 2009 09:11:41 -0700
Joe Perches wrote:
> On Mon, 2009-06-01 at 11:54 -0400, Jarod Wilson wrote:
> > On Monday 01 June 2009 07:01:26 Jesse Barnes wrote:
> > > Patches to the i915 driver should generally go
> > > to intel-...@lists.freedesktop.org so
o me. I think Dave will have to make the
call.
Acked-by: Jesse Barnes
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution
On Tue, 09 Jun 2009 15:16:53 -0700
Eric Anholt wrote:
> On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote:
> > On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote:
> > > On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote:
> > > > It is useful to get the register snapshot.
> > > > Add a debug
Seems ok to me, but I'd have to audit the mode list handling to be sure
it's ok; there may be other bugs lurking...
Dave?
Jesse
On Mon, 8 Jun 2009 20:18:09 +0800
"Ma, Ling" wrote:
> Any comments ?
>
> Thanks
> Ma Ling
>
> >-Original Message-
> >From: intel-gfx-boun...@lists.freedesk
On Wed, 10 Jun 2009 09:06:47 +0800
yakui_zhao wrote:
> On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote:
> > On Tue, 09 Jun 2009 15:16:53 -0700
> > Eric Anholt wrote:
> >
> > > On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote:
> > > > On F
On Wed, 10 Jun 2009 14:08:44 +0800
yakui_zhao wrote:
> On Wed, 2009-06-10 at 06:45 +0800, Eric Anholt wrote:
> > On Mon, 2009-05-11 at 10:52 +0800, yakui_zhao wrote:
> > > Hi, All
> > >
> > > This is the patch set to add the CVT/GTF algorithm in
> > > kernel space. They are based on the CVT/GT
m); no need for big changes
there.
I don't really care about static or dynamic modes for the standard
stuff. We already have the static tables in place; there's not much
reason to remove them. CVT/GTF is mainly needed to properly generate
mode lists when we parse the EDID I th
Not sure where this check came from, but it's wrong according to a bug
report I can't find right now. We need to parse the detailed blocks no
matter what, or lots of monitors won't be given a good set of default
modes.
Adam, can you check & ack this?
Thanks,
Jesse
Signed-o
On Tue, 23 Jun 2009 11:58:44 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
> > I think it could work, but ideally we'd keep the kernel fbcon object
> > pinned, and keep printing into it even while some other gfx app is
>
h buffers (something like this would
also be handy for dual head debugging; one head running your desktop
and the other a debug console printing all the messages). That's
slightly more invasive surgery though... I should have a c
dly a way around a second machine for
> graphics driver development anyway.
Oh I know, most operating systems have reasonable debugging facilities,
and have had for a long time. Linux is the one lagging here.
I agree it probably won't be that helpful for low level gfx debugging,
but I
On Tue, 23 Jun 2009 12:26:15 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote:
>
> > Yeah I don't think we should try to change the mode, unless we
> > really have to for whatever reason. fbcon should generally be able
> >
On Tue, 23 Jun 2009 08:39:44 -0700
Jesse Barnes wrote:
> On Tue, 23 Jun 2009 09:48:00 +0200
> Michel Dänzer wrote:
> > On a side note, I did precisely that about ten years ago on my
> > Amiga. :) Granted, that was using two separate framebuffer devices
> > (X glint drive
T_HSYNC_POSITIVE |
> DRM_EDID_PT_VSYNC_POSITIVE;
> + pt->misc |=
> (DRM_EDID_DETAILED_MISC_DIGITAL_HSYNC_POSITIVE |
> +
> DRM_EDID_DETAILED_MISC_DIGITAL_VSYNC_POSITIVE); }
Looks ok, but according to wikipedia hsync+ is 1<<1 an
On Thu, 25 Jun 2009 17:57:47 -0700
Keith Packard wrote:
> On Thu, 2009-06-25 at 16:50 -0700, Jesse Barnes wrote:
>
> > Is this mixing up the pixel block definition of sync vs the basic
> > block definition (which has all the composite, green etc bits)?
>
> The VESA spec
...)
DRM_DEBUG_KMS(prefix, fmt, args...)
DRM_DEBUG_MODE(prefix, fmt, args...)
but that should probably be done as a separate patch.
Reviewed-by: Jesse Barnes
--
Jesse
Just a DRM_MASTER flag is sufficient here, though maybe this call is
totally deprecated anyway (xf86-video-intel still calls it though).
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b39d7bf..d0a70bd 100644
--- a/drivers/gpu/drm/drm_drv.c
ble attached CRT devices,
> but i'm not sure if this really sufficient in all cases.
>
> Shouldn't the i915 driver use the information provided by the VBT
> ("crt_ddc_gmbus_pin" field in the "bdb_general_definitions" block) to
> figure out which I2C
actor. None of the drivers implement that today, but if someone wants
to do it, I think it could be done with the addition of a single new
type and a new property to describe the scaling factor in the X and Y
directions.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_crtc.c b/
m according to
our discussion on IRC, though I've left out potential new additions for
a new scaling property with an integer (or two) for the scaling
factor. None of the drivers implement that today, but if someone wants
to do it, I think it could be done with the addition of a single new
t
be, then yes, it's not ideal. There
was some debate on the IRC channel about what it meant...
If it's a monitor thing, how is it different from "none" or "center"?
Is there some way of telling the monitor to scale or not?
--
aw 64 bit divide in the i915 driver. Fix
> up this raw divide.
>
> Signed-off-by: Andy Whitcroft
I think building with newer GCCs will prevent this error, but the fix
looks fine.
Acked-by: Jesse Barnes
--
Jesse Barnes
On Wed, 1 Jul 2009 12:22:17 -0400
Alex Deucher wrote:
> On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher
> wrote:
> > On Wed, Jul 1, 2009 at 12:11 PM, Jesse
> > Barnes wrote:
> >> On Wed, 1 Jul 2009 11:23:50 +0200
> >> Maarten Maathuis wrote:
> >>
>
On Tue, 30 Jun 2009 23:43:19 -0700
Eric Anholt wrote:
> On Mon, 2009-06-29 at 16:52 -0700, Jesse Barnes wrote:
> > Just a DRM_MASTER flag is sufficient here, though maybe this call is
> > totally deprecated anyway (xf86-video-intel still calls it though).
> >
> >
On Wed, 1 Jul 2009 12:22:17 -0400
Alex Deucher wrote:
> On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher
> wrote:
> > On Wed, Jul 1, 2009 at 12:11 PM, Jesse
> > Barnes wrote:
> >> On Wed, 1 Jul 2009 11:23:50 +0200
> >> Maarten Maathuis wrote:
> >>
>
Userspace can (and does) flood the kernel log with vblank related error
messages. Since we already return a reasonable errno, we can just make
this into a DRM_DEBUG instead.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b4a3dbc..f85aaf2
On Wed, 8 Jul 2009 11:50:38 -0700
Keith Packard wrote:
> KMS mode does not call I830AccelMethodInit as that does a ton of
> random device initialization, but that means that the NoAccel and DRI
> options were ignored. Split out the option parsing from
> I830AccelMethodInit and have both KMS and
On Thu, 9 Jul 2009 11:37:30 -0400
Alex Deucher wrote:
> On Thu, Jul 9, 2009 at 11:15 AM, Keith Packard
> wrote:
> > On Wed, 2009-07-08 at 20:28 +0100, Julien Cristau wrote:
> >
> >> DRI2 init can fail for various reasons, and it's easier to test if
> >> you don't have to hack the driver. No part
_pixel_timing *)dvo_timing);
> >
> > dev_priv->lfp_lvds_vbt_mode = panel_fixed_mode;
> >
> >@@ -152,7 +125,7 @@ parse_sdvo_panel_data(struct
> >drm_i915_private *dev_priv,
> >
bd19219d930bbb9a5a22758c8f5bec
> > References :
> > http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > http://lkml.org/lkml/2009/4/27/317 Handled-By : Jesse Barnes
> > Patch:
> > http://patchwork.kernel.org/patch/20197/
>
> St
> sr_entries; 1884}
>
>
> which according to git it seems to be code from this commit:
>
> commit 7662c8bd6545c12ac7b2b39e4554c3ba34789c50
> Author: Shaohua Li
>
> drm/i915: add FIFO watermark support
Yep, my bug. Should be fixed in Eric's drm-intel-ne
On Wed, 29 Jul 2009 23:06:14 +0200
"Rafael J. Wysocki" wrote:
> On Tuesday 28 July 2009, Andrew Morton wrote:
> > (cc jbarnes)
> >
> > On Sun, 26 Jul 2009 00:50:38 +0200
> > Roel Kluin wrote:
> >
> > > dev_priv->saveSWF1 is a 16 element array, but this reads up to
> > > index 22
> > >
> > > S
27;d like to do with a full
device (e.g. runtime power management or some sort of per-connector
suspend/resume).
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting -
On Tue, 11 Aug 2009 16:17:46 -0700
Jesse Barnes wrote:
> On Tue, 11 Aug 2009 15:52:06 +1000
> Dave Airlie wrote:
>
> > From: Tiago Vignatti
> >
> > Background:
> > Graphic devices are accessed through ranges in I/O or memory space.
> > While most
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Tue, 11 Aug 2009 11:23:09 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Hi!
> >>
> >> I'm wondering why we are using a struct device as a s
ti
> Signed-off-by: Dave Airlie
Ok, applied this to my linux-next branch, but I'd like to get Ben's
s-o-b before pushing it to Linus.
Ben?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
Le
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Tue, 11 Aug 2009 20:29:39 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Jesse Barnes wrote:
> >>
> >>> On Tue,
On Wed, 12 Aug 2009 10:35:16 +0300
"Vignatti Tiago (Nokia-D/Helsinki)" wrote:
> On Wed, Aug 12, 2009 at 01:21:03AM +0200, Jesse Barnes wrote:
> > Oh yeah, and we should get the documentation merged too. I can
> > handle that or you can send it to Randy. Tiago?
>
On Wed, 12 Aug 2009 00:24:37 -0700
"Vignatti Tiago (Nokia-D/Helsinki)" wrote:
> On Wed, Aug 12, 2009 at 08:48:08AM +0200, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote:
> >
> > > Ok, applied this to my l
On Wed, 12 Aug 2009 16:24:58 -0700
Greg KH wrote:
> On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
> > On Wed, 12 Aug 2009 08:21:24 +0200
> > Thomas Hellström wrote:
> >
> > > Jesse Barnes wrote:
> > > > On Tue, 11 Aug 2009 20:2
goes here.
> + */
> +
> +};
> +
Unusual indentation here (I think the usual is
struct foo bar {
.baz = xyz,
};
> +
> /* Display the version of drm_core. This doesn't work right in
> current design */ static ssize_t version_show(struct class *dev, char
>
{
> newmode = drm_mode_detailed(dev, edid,
> timing, quirks);
Yeah I've sent this before too, but I think it got missed. Dave can
you make sure something like this gets applied (if it hasn't been
already, I didn't check current sources)?
Thanks,
--
Je
ks are aware of those. There is no per device-type suspend /
> resume. Only new-style PM.
>
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
--
Le
token provided by user space in the ioctl.
> >
> > Based on work and suggestions from
> > Jesse Barnes ,
> > Jakob Bornecrantz ,
> > Chris Wilson
> >
> > Signed-off-by: Kristian Høgsberg
> > Signed-off-by: Jesse Barnes
> > ---
>
On Tue, 18 Aug 2009 09:32:50 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Mon, 17 Aug 2009 22:22:34 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Kristian Høgsberg wrote:
> >>
> >>> This patch adds a vblank syn
he drm fd to
> >>> their main loop and handle other tasks while waiting for the flip
> >>> to happen. The event includes the time of the flip, the frame
> >>> counter and a 64 bit opaque token provided by user space in the
> >>> ioctl.
> >&
knows what we
> > (don't)
> > + * support
> > + */
> > + if (flip_data->flags & (~DRM_MODE_PAGE_FLIP_FLAGS_MASK)) {
> > + DRM_DEBUG("bad page flip flags\n");
> > + return
On Tue, 18 Aug 2009 09:17:23 -0700
Jesse Barnes wrote:
> > >> Exactly what in the generic modesetting code is protected by the
> > >> struct mutex here?
> > >>
> > >
> > > I'm a little fuzzy on the details, this part of the patch wa
y lock confusion (struct_mutex vs
mode_config). Or would you like something substantial changed with
these bits before they land?
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the
nf or elsewhere?
With DRI2 we don't currently have a way to do this, but we're working
on adding one (along with some other sync
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handl
gt; include/linux/vgaarb.h | 49
> + 2 files changed, 32
> insertions(+), 28 deletions(-)
Applied to my linux-next branch, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
-
up.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus o
On Sun, 16 Aug 2009 18:09:36 +0300
Tiago Vignatti wrote:
> On Wed, Aug 12, 2009 at 06:02:14PM +0200, Jesse Barnes wrote:
> > On Wed, 12 Aug 2009 10:35:16 +0300
> > "Vignatti Tiago (Nokia-D/Helsinki)"
> > wrote:
> > > Okay, I can handle this documentation
5&w=4
>
> This entry is being used for tracking a regression from 2.6.30.
> Please don't close it until the problem is fixed in the mainline.
Fixed by this patch?
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
ind
On Mon, 03 Aug 2009 08:30:57 +0200
"David Müller (ELSOFT AG)" wrote:
> Hello
>
> Any news regarding this issue?
I don't see the patch anymore, but if the VBT pin info is correct we
should probably be using it more broadly.
--
Jesse Barnes, Intel Open
can
probably assume its correct unless the general definitions block has a
size that doesn't match our structure size.
Wanna respin it with that change (just remove the IS_85X change and add
a return below the crtc_ddc_bus = -1 if the structure size doesn't match
the block size).
Thanks,
heuristics. We've recently
added some to catch non-existent LVDS displays, but currently don't
have any for VGA. Using the current configuration as a guide is a
reasonable addition...
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 28 Aug 2009 11:36:22 +0200
"David Müller (ELSOFT AG)" wrote:
> Jesse Barnes wrote:
> > Wanna respin it with that change (just remove the IS_85X change and
> > add a return below the crtc_ddc_bus = -1 if the structure size
> > doesn't match the block
401 - 500 of 741 matches
Mail list logo