no on-board GPU).
A quick search seems to indicate that an i815E variant also existed.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
On Mon, Dec 27, 2010 at 12:58:10AM +0100, Mario Kleiner wrote:
2. There are gpu's firing spurious vblank irq's as soon as you enable
irq's
You're sure this isn't simply a matter of the driver forgetting to ack
the irq just before enabling it?
--
Ville Syrjälä
syrj...@sci.fi
http
at DirectFB and OpenWF Display APIs might be helpful.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
that) to be
drawn in the UI layer.
That's a good reason to aim for an OpenWF Display type of API where you
can commit the whole device state atomically.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel
+};
Please don't use enums for bit operations.
Now I'm curious. Why not?
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum
On Fri, Nov 11, 2011 at 09:01:46AM -0800, Jesse Barnes wrote:
On Fri, 11 Nov 2011 18:04:05 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Help drivers a little by guaranteeing that crtc_x+crtc_w and
crtc_y+crtc_h don't overflow
On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
On Fri, 11 Nov 2011 18:04:04 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the source coordinates stay within the buffer.
Signed-off-by: Ville Syrjälä ville.syrj
fourccs when we know most of them won't match
the official list. AFAICS a simple running number would do
just as well as the format identifier.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
set_plane.flags:
#define DRM_MODE_PRESENT_TOP_FIELD 0x1
#define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
On Mon, 14 Nov 2011 23:24:55 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
+struct drm_mode_fb_cmd2 {
+ __u32 fb_id;
+ __u32 width, height
ahead more with the GETPLANE ioctl
structure, or we could add a PLANE_CAPS ioctl later to expose
additional details about the hardware.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
On Mon, Nov 14, 2011 at 01:22:10PM -0800, Jesse Barnes wrote:
On Mon, 14 Nov 2011 23:16:44 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
+#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) 8
On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
On Tue, 15 Nov 2011 14:57:02 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
I'm fine with fourccs as long as the defines are named and documented
in way that avoids guesswork.
So what I'm thinking is something like
we even define formats for both the YUV vs. YVU
variant. Seeing as we now have independent handles and offsets for
each plane, we can make do with just one format definition.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel
, whereas otherwise you'd possibly need to look at multiple
bits of information inside the structure.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 16, 2011 at 01:23:01PM -0800, Jesse Barnes wrote:
On Wed, 16 Nov 2011 23:19:38 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
Oh and one extra detail just occured to me regarding the three plane
formats. Should we even define formats for both the YUV vs. YVU
variant
:4:4 is supported by the overlays in most ATI chips IIRC,
so adding both packed and planar 4:4:4 formats would likely make
sense.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
is needed when you eg.
mmap() some buffer?
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Nov 17, 2011 at 03:00:17PM +0100, Michel Dänzer wrote:
On Don, 2011-11-17 at 15:06 +0200, Ville Syrjälä wrote:
On Thu, Nov 17, 2011 at 08:52:05AM +0100, Michel Dänzer wrote:
On Mit, 2011-11-16 at 20:42 +0200, ville.syrj...@linux.intel.com wrote:
Name the formats
On Thu, Nov 17, 2011 at 09:05:54AM -0800, Jesse Barnes wrote:
On Thu, 17 Nov 2011 18:05:14 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Swapping the handle/offset indexes is enough to support such formats.
Signed-off-by: Ville Syrjälä
G1 B1 A0 R0 B0 G0
So every second pixel has B and G swapped around. That would be some
interesting hardware to use :D
It's possible the TRM I had lying around was an old one though and the
issue is fixed in later revisions.
--
Ville Syrjälä
Intel OTC
On Tue, Dec 20, 2011 at 05:58:41PM -0600, Rob Clark wrote:
On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
+static const struct format formats[] = {
+ /* 16bpp [A]RGB
made it in:
Message-Id: 1324405614-18547-1-git-send-email-ville.syrj...@linux.intel.com
Message-Id: 1324405614-18547-2-git-send-email-ville.syrj...@linux.intel.com
Message-Id: 1324405614-18547-3-git-send-email-ville.syrj...@linux.intel.com
Would be nice if you could scoop them up.
--
Ville Syrjälä
On Thu, Feb 02, 2012 at 02:55:22PM -0500, Jerome Glisse wrote:
On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
Hi,
I plan to do a libdrm release on friday because ddx/mesa work i have
been doing depends
reading segment 0 (which your
code doesn't do).
To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split
into two flags (one for addr, other for data).
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
.
As there will be a new API anyway, it might be a good time to make that
change.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
);
}
I just stumbled on this same thing when looking at some internal patch.
Looks good, except you should also check that 'd' is less than 127.
I do wonder how may other unchecked buffer accesses there are in the
EDID code...
--
Ville Syrjälä
Intel OTC
On Thu, Mar 01, 2012 at 01:53:01PM +0200, Ville Syrjälä wrote:
On Sun, Nov 13, 2011 at 02:04:54AM +0100, Christian Schmidt wrote:
The current logic misunderstands the spec about CEA 18byte descriptors.
First, the spec doesn't state detailed timing descriptors but 18 byte
descriptors, so any
A quick hack to verify that the fix works as intended...
Do not apply.
---
drivers/i2c/algos/i2c-algo-bit.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index d25112e..3f547b5 100644
---
is still low after the
timeout has been reached, before deciding to return -ETIMEDOUT.
Signed-off-by: Ville Syrjälä syrj...@sci.fi
---
I can easily reproduce these spurious timeouts on my HP-compaq nc6000
laptop with the radeon kms driver. It's enough to have a -j2 kernel
build running, and simultaneosly
On Thu, Mar 15, 2012 at 03:32:40PM +0100, Jean Delvare wrote:
Hi Ville,
On Wed, 14 Mar 2012 10:32:52 +0200, Ville Syrjälä wrote:
When the system is under heavy load, there can be a significant delay
between the getscl() and time_after() calls inside sclhi(). That delay
may cause
handling in the goto version is equally broken. I'll respin
the patch on top of the goto version, and I'll check the other idr
usage under drm as well...
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
it is
recommended
+ that exporters limit the flags passed to dma_buf_fd to only O_CLOEXEC.
Difficult to parse. Needs more punctuation.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
)
static bool ...
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
and modeset more
dynamic. It would also solve the atomic modset, even with device
specific properties and future features.
Great minds think alike ;) Exactly what I've suggested a few times
before. Unfortunately I haven't had the time to do any prototyping
yet.
--
Ville Syrjälä
Intel OTC
)
+ goto out;
+
+ for_each_sg(sg-sgl, iter, nr_pages, i)
+ sg_set_page(iter, pages[i], PAGE_SIZE, 0);
+
+ return sg;
+out:
+ kfree(sg);
+ return NULL;
+}
+EXPORT_SYMBOL(drm_prime_pages_to_sg);
--
Ville Syrjälä
Intel OTC
?
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
think it should improve cache behavior.
You could also render a large batch of glyphs with just a single
glDrawElements()/glDrawArrays() call. Looks like the current code
does a glDrawArrays() for each glyph.
--
Ville Syrjälä
Intel OTC
___
dri-devel
;
+};
+
+struct drm_render_node_remove {
+ __u32 node_minor_id;
+};
+
#endif
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
work.
The name render node is confusing. It makes me think there's no
modesetting stuff involved.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
part of the ABI, so exposing half finished version of the
struct in the headers, only to later change it, seems like a bad idea.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Cr (1) and Cb (2) planes */
+/* 3 non contiguous plane YCbCr */
+#define DRM_FORMAT_YUV420M fourcc_code('Y', 'M', '1', '2') /* 2x2
subsampled Cb (1) and Cr (2) planes */a
NAK. DRM_FORMAT_YUV420 handles this.
--
Ville Syrjälä
Intel OTC
___
dri
a little less revolutionary.
In any case, the current mess just doesn't allow any kind of truly
generic user space code to be written.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
, and the CRTC
area size, you could do away with all mode selection policy, and
panel fitter and border properties, and you would end up with a more
powerful API.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
?
On 2012년 03월 30일 19:12, Ville Syrjälä wrote:
On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
Multi buffer plane pixel formats are added as like kernel header.
Signed-off-by: Seung-Woo Kimsw0312@samsung.com
---
include/drm/drm_fourcc.h |7 +++
1 files changed
drm_framebuffer;
+struct drm_property;
Unrelated change?
+struct drm_object_properties;
#define DRM_MODE_OBJECT_CRTC 0x
@@ -50,6 +52,13 @@ struct drm_framebuffer;
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel
( drm_ioctls )
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
would perhaps just stick more details about the transformations into
drm_crtc, but we will anyway require a better mode setting API. So
perhaps this is an OK intermediate solution.
ret = -ENOSPC;
goto out;
}
--
Ville Syrjälä
syrj...@sci.fi
On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
For drivers that can support rotated scanout, the extra parameter
On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrjälä wrote:
On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
On Tue, Apr 03, 2012 at 04:02:54PM -0500, Rob Clark wrote:
On Mon, Apr 2, 2012 at 1:39 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrjälä wrote:
On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
On Sat, Mar 31, 2012 at 4
On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
Multi buffer plane pixel formats are added as like kernel header.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
include/drm/drm_fourcc.h |7
need to allow the addfb2.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution
On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
Am 05.04.2012 20:35, schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
These functions return the chroma subsampling factors for the specified
pixel format.
Hmm not really related
in the getresources reply. So when queried via a render node,
some form of remapping must be performed.
Also the name render node is still very confusing. How about just
callling it a partition or something. Or maybe someone could suggest
a more self explanatory name for this stuff.
--
Ville Syrjälä
Intel
On Fri, Apr 13, 2012 at 04:42:04AM +0200, Roland Scheidegger wrote:
Am 12.04.2012 14:23, schrieb Ville Syrjälä:
On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
Am 05.04.2012 20:35, schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
is a property approach, and I'd like to get
rid of some of the other limitations in the current API at the same
time.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
with the blocking approach or not.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote:
On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
Also, I'm toying around with ideas to split up the big modeset lock such
that operations that only touch the crtc (like pageflip, plane changes and
cursor changes
On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
On Thu, Apr 5, 2012 at 7:35 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
There will be a need for this function in drm_crtc.c later. This
avoids making drm_crtc.c depend
On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie airl...@gmail.com wrote:
On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
On Thu, Apr 5
of it, but I ran out of steam before I got
that far. I suppose I should try to get off my ass and do something
useful with that code.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
On Thu, 24 May 2012 21:08:58 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Take fb-offset[0] into account when calculating the linear and tile x/y
offsets.
For non-tiled
On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
UINT_MAX.
Signed-off
or not.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
', '2') /*
non-subsampled Cb:Cr plane */
If you want these to reach the driver you need to add them to
format_check().
Also you should update drm_format_num_planes() and
drm_format_plane_cpp() appropriately.
--
Ville Syrjälä
Intel OTC
___
dri-devel
On Wed, May 30, 2012 at 03:20:09PM +0200, Laurent Pinchart wrote:
Hi Ville,
Thank you for the review.
On Wednesday 30 May 2012 16:09:25 Ville Syrjälä wrote:
On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch
to help with such
checks. I probably need to revisit that issue and try to make something
that'd work for tiled formats as well.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
the hardware scan it out as ARGB instead.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
the objects in the beginning) and starts
to modify the current state of the objects as new values are read in by
the ioctl handler. Anything not part of the atomic modeset is left
untouched.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel
of the rotation was also opposite to xrandr (cw in dss,
ccw in xrandr).
So FWIW, my vote goes to reflect if we want to match xrandr
semantics. Also I agree on the number of bits, six is better than
three since it allows you to describe the hw capabilities.
--
Ville Syrjälä
Intel OTC
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the the framebuffer stride is smaller than the maximum
accepted by any plane
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
On Thu, 24 May 2012 21:08:58 +0300
seem acceptable.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
. That way user space couldn't even try to use an unsupported
configuration. The downside is that user space would need to parse
those strings if it wants to do some automagic stacking order changes,
which means the string format would need some though.
--
Ville Syrjälä
Intel OTC
On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote:
Hello Ville Syrjälä,
On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote:
The current logic for probing ddc is limited to
2 blocks
On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote:
On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote:
Here are my earlier comments on Jean's patch:
http://lists.freedesktop.org/archives
sending the segment addr to not upset non-compliant ddc
+ * monitors.
+ */
Wrong indentation and comment style is wrong. I'm guessing this didn't go
through checkpatch.pl.
Otherwise looks OK to me.
--
Ville Syrjälä
Intel OTC
___
dri-devel
can
show it to anyone.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky b...@bwidawsk.net wrote:
On Sun, 9 Sep
On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
prototyping the atomic modesetting, but
that's certainly the way I would design the system.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
But I think we could still do this w/ one ioctl per crtc for
atomic-pageflip.
We
On Wed, Sep 12, 2012 at 02:40:56PM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote:
On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Wed, Sep 12, 2012 at 02:40:56PM -0500, Rob Clark wrote:
On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote:
On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote:
On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote:
On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
and pin/fence stuff,
so it's no surprise my code is a bit fscked up in those areas.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Fri, Sep 14, 2012 at 05:39:30PM +0200, Daniel Vetter wrote:
On Fri, Sep 14, 2012 at 5:30 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
intel_pipe_set_base() won't disable the pipe or change the size,
it'll just flip the primary plane. So that doesn't quite explain
why the call
On Fri, Sep 14, 2012 at 04:56:00PM +0100, Chris Wilson wrote:
On Fri, 14 Sep 2012 18:30:21 +0300, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Sep 14, 2012 at 03:27:05PM +0100, Chris Wilson wrote:
On Fri, 14 Sep 2012 17:21:30 +0300, Ville Syrjälä
ville.syrj
On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
On Fri, Sep 14, 2012 at 12:34:59PM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 12:02 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote:
On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote
useful error reporting. Perhaps there is no nice way to do it.
- Returning a list of retired FBs in the events
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
: unspecified properties revert to default
pageflip: unspecified properties preserve current value
Why on earth would you want to revert stuff to default? That's only
going to make the code more complex.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala
On Sat, Sep 15, 2012 at 11:07:02AM -0500, Rob Clark wrote:
On Sat, Sep 15, 2012 at 9:56 AM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Sep 14, 2012 at 09:12:35PM -0500, Rob Clark wrote:
On Thu, Sep 13, 2012 at 11:35 AM, Rob Clark rob.cl...@linaro.org wrote:
note that the test phase
1 - 100 of 3983 matches
Mail list logo
