assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/014d4619/attachment-0001.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/01f66c61/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/58317468/attachment.html>
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
>
> > So in the meantime the attached patch should work, it just silently ignore
> > the caching attribute request on non x86 instead of pretending that things
> > are
On Wed, Sep 03, 2014 at 09:55:53PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > I've been tracking down some problems with the recent DRI on powerpc and
> > stumbled upon something that doesn't look right, and not nece
On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
>
> Now it's possible that I haven't fully unders
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/2d58510f/attachment.html>
On Wed, Sep 3, 2014 at 6:00 PM, Rob Clark wrote:
> so, I am not quite sure that would work.. (and maybe this is an extra
> thing to think about for atomic).
>
> The problem is that hw has no hw cursor. So cursor is implemented
> using plane. But thanks to retarded userspace that rapidly
> enabl
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140903/e6dc7f42/attachment.html>
avi infoframe is a 13 bytes array, do not read after this limite.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 284e541..90ee20a 100644
--- a/drivers/gpu
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/4d62d96b/attachment.html>
On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote:
> On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote:
> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> >> Currently modesetting is not done synchronously, but it queues work that
> >> is done later. In theory this is
This crash was already here before the conversion, but qxl never leaked
hard enough to hit this.
Signed-off-by: Maarten Lankhorst
---
The crash is probably only going to happen in extreme memory stress
when the system's already fucked, but hey still a bug. :-)
drivers/gpu/drm/qxl/qxl_release.c
This is how you implement a sieve in a driver. ;-)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 828d47e90dce..29ab
The locking of release_lock was stupid; it should have been be called with
fence_lock_irq if it was legitimately used. Unfortunately it never protected
anything except the fence implementation correctly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 --
drivers/gpu/d
From: Gustavo Padovan
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.
More work is expected on this to get a better split of the two
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by:
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning proc
From: Gustavo Padovan
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_drv.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915
From: Gustavo Padovan
This is the beginning of the work to prepare i915 for the upcoming
atomic modesetting API. Here we split the plane update fucntions in
the check and commit states.
v2: use struct intel_plane_state to keep states between check and
commit stages.
v3: take Ville's comments
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/b237836b/attachment.html>
close to
what is screwed up.
Starting over.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/c0c1a94b/attachment.html>
On Wed, Sep 03, 2014 at 02:55:09PM +0300, Tomi Valkeinen wrote:
> We already wait for all scheduled work to be done on the driver's unload
> function. However, I think we need to wait on preclose() also, so that
> when an application closes the drm file descriptor, we are sure that
> there's no lef
On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
> omap_crtc_flush() is used to wait for scheduled work to be done for the
> give crtc. However, it's not quite right at the moment.
>
> omap_crtc_flush() does wait for work that is ran via vsync irq to be
> done. However, work is also
On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> Currently modesetting is not done synchronously, but it queues work that
> is done later. In theory this is fine, but the driver doesn't handle it
> at properly. This means that if an application first does a full
> modeset, then imm
nymore. The patch does also affect the non-statistics/non-hud path, doesn't
it?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/atta
e/linux/fwcoredump.h
> @@ -0,0 +1,35 @@
> +#ifndef __FWCOREDUMP_H
> +#define __FWCOREDUMP_H
> +
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_FW_COREDUMP
> +void fw_coredumpv(struct device *dev, const void *data, size_t datalen,
> + gfp_t gfp);
> +
> +void fw_coredumpm(struct device *dev, struct module *owner,
> + const void *data, size_t datalen, gfp_t gfp,
> + ssize_t (*read)(char *buffer, loff_t offset, size_t
> count,
> + const void *data, size_t datalen),
> + void (*free)(const void *data));
> +#else
> +static inline void fw_coredumpv(struct device *dev, const void *data,
> + size_t datalen, gfp_t gfp)
> +{
> + vfree(data);
> +}
> +
> +static inline void
> +fw_coredumpm(struct device *dev, struct module *owner,
> +const void *data, size_t datalen, gfp_t gfp,
> +ssize_t (*read)(char *buffer, loff_t offset, size_t count,
> +const void *data, size_t datalen),
> +void (*free)(const void *data))
> +{
> + free(data);
> +}
> +#endif /* CONFIG_FW_COREDUMP */
> +
> +#endif /* __FWCOREDUMP_H */
> --
> 2.1.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/ac86d648/attachment-0001.html>
On Wed, Sep 03, 2014 at 10:38:20AM -0300, Gustavo Padovan wrote:
> From: Derek Foreman
>
> Really just for completeness - old init function ends up making the plane
> exactly the same way due to the way the enums are set up.
>
> Signed-off-by: Derek Foreman
> Signed-off-by: Gustavo Padovan
Qu
I just wanted to provide a note on this issue.
I saw lots of text getting garbled up all the time on the Radeon R7
240. It was certain letters that just got all messed up all the
time. When I minimized the window and maximized it again or entered the
tty and back again, it was gone.
Anyways, b
ly, so I tested and didn't gain anything
significant.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/2fb0403c/attachment.html>
commit as good.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/155402f7/attachment.html>
Hi Dave, here's a couple of display regression fixes for 3.17.
BR,
Jani.
The following changes since commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a:
drm/i915: Remove bogus __init annotation from DMI callbacks (2014-08-28
09:54:27 +0300)
are available in the git repository at:
git://anon
Hi Fabio,
Am Dienstag, den 02.09.2014, 10:31 -0300 schrieb Fabio Estevam:
> For debug purposes it is useful to know how far away the generated pixelclock
> is
> from the desired rate, so print the amount of error.
>
> After adding this patch and with debug enabled we have:
>
> imx-ipuv3 240
unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.
Add a comment to make this clear.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu
We already wait for all scheduled work to be done on the driver's unload
function. However, I think we need to wait on preclose() also, so that
when an application closes the drm file descriptor, we are sure that
there's no left around.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/o
omap_crtc_flush() is used to wait for scheduled work to be done for the
give crtc. However, it's not quite right at the moment.
omap_crtc_flush() does wait for work that is ran via vsync irq to be
done. However, work is also queued to the driver's priv->wq workqueue,
which is not handled by omap_c
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS
Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
i
Currently modesetting is not done synchronously, but it queues work that
is done later. In theory this is fine, but the driver doesn't handle it
at properly. This means that if an application first does a full
modeset, then immediately afterwards starts page flipping, the page
flipping will not wor
omap_crtc's apply_worker does:
omap_irq_register(dev, &omap_crtc->apply_irq);
dispc_mgr_go(channel);
This is supposed to enable the vsync irq, and set the GO bit. The vsync
handler will later check if the HW has cleared the GO bit and queue
apply work.
However, what may happen is
The DRM documentation says:
"If a page flip is already pending, the page_flip operation must return
-EBUSY."
Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
1 file changed, 1 insertion(+),
OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.
However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the
.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/736a97be/attachment-0001.sig>
PESTAT(pipe), 0x);
I915_WRITE(HWSTAM, 0x);
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attach
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/c6cc8169/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/99732755/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/f93c67b2/attachment.html>
ro"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.f
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/e46d425d/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/4863bedc/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/afdff33f/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/153e2573/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/b74a4f78/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/7e15ca13/attachment.html>
On Wed, Sep 03, 2014 at 10:38:17AM +0200, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> > On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > > From: Derek Foreman
> > >
> > > Really just for completeness - old init function ends up makin
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/762f302a/attachment.html>
g/archives/dri-devel/attachments/20140903/896cd89c/attachment-0001.html>
ves/dri-devel/attachments/20140903/7aaceb9d/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/b7df0f41/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/a7a469e0/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/70fc8f5b/attachment.html>
On Wed, Sep 3, 2014 at 11:21 AM, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote:
>> On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote:
>> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> >> Currently modesetting is not done synchronously, b
On Tue, Sep 02, 2014 at 04:23:47PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
>
> This commit splits int
achments/20140903/b773393c/attachment.html>
On Tue, Sep 02, 2014 at 04:23:46PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This new struct will be the storage of src and dst coordinates
> between the check and commit stages of a plane update.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_drv.h | 20
On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> From: Derek Foreman
>
> Really just for completeness - old init function ends up making the plane
> exactly the same way due to the way the enums are set up.
>
> Signed-off-by: Derek Foreman
Reviewed-by: Ville Syrj?l?
> ---
>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/ad81bd39/attachment-0001.html>
On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> Currently modesetting is not done synchronously, but it queues work that
>> is done later. In theory this is fine, but the driver doesn't handle it
>> at properly. This means
dri-devel/attachments/20140903/b9d665aa/attachment.html>
nts/20140903/9945a7de/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/50097269/attachment.html>
vertices+ia-primitives;vs-invocations+ps-invocations+hs-invocations+ds-invocations;VRAM-usage+GTT-usage"
R600_DEBUG=hyperz. Though, I assume GALLIUM_HUD="fps" could be enough.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/8515b7cc/attachment.html>
ngl:sw /path/to/some_video
I'm sorry but I can't reproduce it with Tahiti (HD7950).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
On 09/02/2014 09:55 PM, Andrzej Hajda wrote:
> Since file pointer is preserved in c_node passing it
> as argument in node functions is redundant.
>
> Signed-off-by: Andrzej Hajda
> ---
> v3:
> - file check moved to next patch
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
> 1
On Tue, Sep 02, 2014 at 05:03:35PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be non-2x horizontal timings and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel
From: Derek Foreman
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertion
On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > From: Derek Foreman
> >
> > Really just for completeness - old init function ends up making the plane
> > exactly the same way due to the way the enums are set up.
On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > From: Derek Foreman
> >
> > Really just for completeness - old init function ends up making the plane
> > exactly the same way due to the way the enums are set up.
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/6c8c0576/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/7fa90a2b/attachment.html>
no segfault, what that can be? Hmm...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/c6551c07/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/ad71a7ba/attachment.html>
ceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/94e1ea22/attachment.html>
esktop.org/archives/dri-devel/attachments/20140903/ab4db9ee/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/def440a1/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/dbab49c5/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140903/3206ce6f/attachment.html>
be the compositor
as the only one using the hardware driver.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/ce35948e/attachment.html>
vel/attachments/20140903/0f98d235/attachment.html>
eedesktop.org/archives/dri-devel/attachments/20140903/cacae5f4/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/295ae326/attachment.html>
achments/20140903/d5641c2f/attachment.html>
2014-09-02 14:51 GMT+02:00 Ezequiel Garcia :
> Dave,
>
> I'm resending this, hoping it can be pushed for v3.18. The patchset was
> ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
> through some crack?
>
> Just for reference, here goes the details about this series and wh
On 3 September 2014 03:08, Johannes Pointner
wrote:
[..]
>
> I tested the series with 3.16.1 (with additonal patches from Guido and
> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
> me without an issue. I tried it with and without the backlight
> addition in the dts file.
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/2b6dafe7/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/a8076369/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/040586fa/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/497bff20/attachment-0001.html>
1 - 100 of 111 matches
Mail list logo
