me. Gentleman, I think we have a suspect...
--
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/20141028/b5ee59ba/attachment.html>
ng 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/20141028/071f9b89/attachment.html>
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
wrote:
> On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
>> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
>> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
> [...]
>> >> Hm, if you do this can you pls also update drm_pa
HW state or something completly different.
--
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/20141028/5fe07e5a/attachment.html>
flags
r600g: Drop references to destroyed blend state
--
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/20141028/f33dd
From: Michel Dänzer
We want to allocate small BOs strictly from the bottom up, just as large
BOs are allocated strictly from the top down.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers
From: Michel Dänzer
For placing a BO strictly from the bottom up, i.e. in the lowest hole which
can hold it.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 5 +
include/drm/ttm/ttm_placement.h | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff
From: Michel Dänzer
DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:
* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
difference whether the BO is p
From: Michel Dänzer
If the BO should be placed at the top of the area, we should start looking
for holes from the top.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_
From: Michel Dänzer
I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
AFAICT it does.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
From: Michel Dänzer
It was adding a second placement for the second 256MB segment of VRAM,
which is not a good idea for several reasons:
* It fills up the first 256MB segment (which is also typically the CPU
accessible part) of VRAM first, even for BOs which could go into the
second 256MB s
sp=sharing
--
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/20141028/49e1226a/attachment.html>
On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>> Hi Daniel and Sean,
>>
>> Thanks for the comments!
>>
>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
So don't ask w
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/06e9499e/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/3a6ec20b/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/063f0881/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/c03481de/attachment-0001.html>
d properly.
The anti-aliasing visual effect is killing performance.
--
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/2014
On Tue, 28 Oct 2014, Johan Hovold wrote:
> Hi,
>
> I have had some problems with crashes involving suspend-to-disk after
> updating to v3.16.
>
> Below is a log with 3.16.6 from a failed suspend attempt after which I
> get a NULL deref in ext4 code.
>
> A couple of weeks ago I got something simil
because of the registers, so I kept that limitation in the
driver. That means no revision bump is necessary.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/727754b0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141028/deae2d1e/attachment.html>
> Is this possible and if not, why not?
Long story short on modern hardware the VGA console is just an emulation
working on top of the real hardware. When the driver wants to talk to
the real hardware it must simply disable the VGA emulation first.
But to me all points why you don't like the fbc
ers,
> >> Emil
> >>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/59aeb816/attachment.html>
> @@ -5156,3 +5158,100 @@ struct drm_property
> *drm_mode_create_rotation_property(struct drm_device *dev,
>supported_rotations);
> }
> EXPORT_SYMBOL(drm_mode_create_rotation_property);
> +
> +/**
> + * DOC: Tile group
> + *
> + * Tile groups are used
On Tue, Oct 28, 2014 at 2:42 PM, Javier Martinez Canillas
wrote:
> Hello Ajay,
>
> On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart
> wrote:
>>>
>>> Right. It would be great if you guys come to agreement ASAP!
>>
>> I don't think we'll agree any time soon, so I believe it's up to you to
>> dec
eel free to ask for
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/attachments/20141028/3e13020a/attachment.html>
The Baseline_ELD_Len field does not include ELD Header Block size.
>From High Definition Audio Specification, Revision 1.0a:
The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple of 4 bytes, and its size is defined
in the header block
In the interest of reducing magic numbers and having to cross check with
the specs all the time.
Signed-off-by: Jani Nikula
---
include/drm/drm_edid.h | 102 +
1 file changed, 102 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelgaas at google.com]
> Sent: Tuesday, October 28, 2014 11:48 AM
> To: Michael Shell
> Cc: linux-kernel at vger.kernel.org; David Airlie; DRI mailing list; Deucher,
> Alexander; Koenig, Christian
> Subject: Re: Standard VGA console with D
ss on anything but DT. I
don't think we should strive for that, even if only DT-enabled platforms
currently use them.
Thierry
-- 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/attachments/20141028/66fd1f77/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=83461
--- Comment #14 from Christian König ---
Created attachment 155721
--> https://bugzilla.kernel.org/attachment.cgi?id=155721&action=edit
Add more debugging output.
Please apply the attached patch and provide new dmesg created with
drm.debug=0xE
usually asking for docs ;-)
FWIW, there's some kerneldoc in include/drm/drm_panel.h but I guess I
could write up something more complete and integrate it into DocBook.
Thierry
-- 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/attachments/20141028/cea53b8f/attachment.sig>
7;s similar =), but like
I said, I don't really understand what you think is wrong with it.
> It doesn't help that we have drm_of.[hc] around but not all the of
> code is in there. Adding Russell too.
DRM panel and DRM bridge aren't just OF helpers. They can be used with
whatever type of device you want.
Thierry
-- 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/attachments/20141028/c55c18b0/attachment.sig>
>
> The last patch instantiates the HDMI encoder in the Koelsch board DT file and
> connects it to the DU output.
>
> The patch series depends on Koelsch DU DT enablement (scheduled for merge in
> v3.19-rc1). Dave, I'd like to get this merged in v3.19-rc1, how would you like
> to proceed ? Could it
eping a struct device *, like having
access to the proper device and its name. Also you get access to the
device_node * via dev->of_node anyway. I don't see any advantage in
switching to just a struct device_node *, only disadvantages.
Thierry
-- 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/attachments/20141028/4208db32/attachment.sig>
Hi,
I have had some problems with crashes involving suspend-to-disk after
updating to v3.16.
Below is a log with 3.16.6 from a failed suspend attempt after which I
get a NULL deref in ext4 code.
A couple of weeks ago I got something similar, with backtraces from
ext4 (ext4_alloc_inode) and NUL
On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>>> Hi Daniel and Sean,
>>>
>>> Thanks for the comments!
>>>
>>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
On Mon, Oct 2
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
> wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they
work as well?
Hi Michel,
That patch works for me also.
Thanks again.
--
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/20
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
> wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>> So don't ask why but I accidentally ended up in a branch looking at this
>> patch and didn't like it. So very quick&grumpy review.
>>
>> Firs
On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Merge it into the plane update_plane() callback and make other
> users use the update_plane() functions instead.
>
> The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> so we fold
Hello,
i have an issue with Skype lately (i compile mesa, kernel, drm, xserver
from git periodically and i use a A8-6500 with its IGP with r600g and
glamor).
It crashes the x server if i use bi directional video call. It seems to
work in one-way video.
The x server restarts, but skype continues
On 10/27/14 06:13, Tomi Valkeinen wrote:
> On 27/10/14 13:59, Jani Nikula wrote:
>
>>> While doing 'depends on' instead of 'select' is an "easy" fix for this,
>>> I do dislike it quite a bit. It's a major pain to go around the kernel
>>> config, trying to find all the dependencies that a particula
Hello,
I find a drmOpen failed issue in our system as below description:
platform: ivy-bridge
OS: Ubuntu12.04 LTS
kernel: 3.13.0-32-generic
libdrm: libdrm-2.4.46
root at tchen37-ivb:/home/tchen37/ws/lib3app/utests# ./test_osd
DRM_IOCTL_I915_GEM_APERTURE failed:
On Tue, 28 Oct 2014 18:35:02 +0900
Michel Dänzer wrote:
> From: Michel Dänzer
>
> I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
> AFAICT it does.
>
> Signed-off-by: Michel Dänzer
This series is
Reviewed-by: Lauri Kasanen
- Lauri
On 27.10.2014 23:14, Joe Perches wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Use the already #defined values instead of hardcoding.
>
> Signed-off-by: Joe Perches
On Tue, Oct 28, 2014 at 06:35:04PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
> against the idea of TTM_PL_FLAG_TOPDOWN:
>
> * The smallest hole may be in the overall bottom of the area
> * If the hole isn't
Hi Ville,
2014-10-24 Ville Syrjälä :
> On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Merge it into the plane update_plane() callback and make other
> > users use the update_plane() functions instead.
> >
> > The fb != crtc->cursor->fb was
On Mon, Oct 27, 2014 at 12:44 PM, Bjorn Helgaas wrote:
> On Sun, Oct 26, 2014 at 11:31 AM, Alex Deucher
> wrote:
>> On Mon, Oct 13, 2014 at 12:11 PM, Bjorn Helgaas
>> wrote:
>>> [+cc Alex, Christian, dri-devel]
>>>
>>> On Sat, Oct 11, 2014 at 1:37 PM, Shawn Starr
>>> wrote:
On September
Am 28.10.2014 um 10:28 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> It was adding a second placement for the second 256MB segment of VRAM,
> which is not a good idea for several reasons:
>
> * It fills up the first 256MB segment (which is also typically the CPU
>accessible part) of VRAM
From: Dave Airlie
This passes the guest preferences for a where to place the
outputs through to userspace. Userspace would need to be updated
to take note of this information, X server and GNOME.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 28
From: Dave Airlie
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
Signed-off-by: Da
There was some discussion on spice irc channel somewhere last week
about how best to take note of the x/y offsets that were suggested
by the hosts into the guests, so that the guest can configured
the monitors in the same layout as they are on the host side.
I think initially the kernel needs to j
converted
to WX
--
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/20141028/a5897ebc/attachment.html>
dstindex
45?
--
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/20141028/c8db0ff6/attachment-0001.html>
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
> Hi Daniel and Sean,
>
> Thanks for the comments!
>
> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>>> So don't ask why but I accidentally ended up in a branch looking at this
>>> p
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/c86d781d/attachment.html>
On Tue, Oct 28, 2014 at 10:19 AM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
>> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
Hi Daniel and Sean,
Thanks for the comments!
On T
[+cc Alex Williamson, Rajat]
On Tue, Oct 28, 2014 at 9:45 AM, Alex Deucher wrote:
> On Mon, Oct 27, 2014 at 12:44 PM, Bjorn Helgaas
> wrote:
>> On Sun, Oct 26, 2014 at 11:31 AM, Alex Deucher
>> wrote:
>>> On Mon, Oct 13, 2014 at 12:11 PM, Bjorn Helgaas
>>> wrote:
[+cc Alex, Christian,
uffersWait" prevents
tearing, but presumably at the cost of one (additional) frame of delay. That
mechanism is not available with glamor.
--
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/20141028/d43144a4/attachment.html>
Hello Ajay,
On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart
wrote:
>>
>> Right. It would be great if you guys come to agreement ASAP!
>
> I don't think we'll agree any time soon, so I believe it's up to you to decide
> which option is best based on all arguments that have been presented.
>
Di
On Mo, 2014-10-27 at 22:09 +, Zachary Reizner wrote:
> ajax,
> What do you mean by a pci revision id bump? Do you want it in qemu or
> the kernel? Why is a revision bump needed when none of the behavior of
> the cirrus device has changed?
revision bump would be needed when adding a new interfa
ng 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/20141028/32d43d30/attachment.html>
On Mon, Oct 27, 2014 at 10:14 AM, Joe Perches wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Use the already #defined values instead of hardcoding.
>
> Signed-off-by
It's been in Linus tree for a few days now .
c572aaf46f71f63ae5914d4e194a955e0ba1b519
Dave.
On 27 October 2014 23:35, Marc-André Lureau
wrote:
> ping
>
> On Thu, Oct 16, 2014 at 11:39 AM, Marc-André Lureau
> wrote:
>>
>> Limit primary to qemu vgamem size, to avoid reaching
>> qemu guest bug
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #8 from Michel Dänzer ---
(In reply to Alan from comment #7)
> Reproducable case seems to be using firefox to review/edit an object you've
> uploaded to Shapeways. Another one is to load a fairly curved shape into
> OpenScad and hit F
[+cc David, Alex, Christian, dri-devel]
On Tue, Oct 28, 2014 at 12:32 AM, Michael Shell
wrote:
>
>
> Greetings,
>
> Well, I want to be able to have my cake and eat it too. I want to be able to
> have the standard VGA/"hardware" classic console (not the framebuffer) but
> I still want the /dev/
On Tue, Oct 28, 2014 at 8:13 AM, Laszlo Kertesz
wrote:
> Hello,
> i have an issue with Skype lately (i compile mesa, kernel, drm, xserver from
> git periodically and i use a A8-6500 with its IGP with r600g and glamor).
> It crashes the x server if i use bi directional video call. It seems to work
quot;git bisect good", and recompile.
Continue to do so until no revisions are left to be tested
--
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/20141028/23f715e3/attachment.html>
have no effect once the driver is initialized. None of the changes
between rc1 and rc2 seem like obvious candidates.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freede
hing for me, I doubt it is fixed.
rc2 crashed for you? After 24 hours I am still stable.
--
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/
https://bugzilla.kernel.org/show_bug.cgi?id=86891
--- Comment #6 from Michael Mair-Keimberger ---
(In reply to Dieter Nützel from comment #5)
> Can you please test with one of kernel git | 3.18-rc2 | drm-next together
> with
> git revert 59bc1d8?
I've tried it with kernel git 3.18rc2 with a pul
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/b2284f67/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/32b70806/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/99f3f2bd/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/b5979822/attachment.html>
b and thanks.
If you need this,
Tested-by: Nick Sarnie
Thanks again.
--
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/20
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/28ecbe7b/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/2d565f1e/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/87d5725e/attachment.html>
rom the terminal still produces image
corruptions for me with 10.3.2.
--
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/20141028/
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/4251cd0c/attachment.html>
ng 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/20141028/e42ff2a4/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/3baa7dd4/attachment.html>
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/20141028/6434c482/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/904f1c1e/attachment.html>
.
--
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/20141028/73bcbd16/attachment.html>
PIPE_USAGE_STREAM buffers
[hamish at Griffindor mesa]$
--
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/20141028/27385151/attachment-0001.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/acd2581f/attachment.html>
(at least three, but
the more the better) times before running git bisect 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/20141028/55b38fb3/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/1158b1ca/attachment.html>
92 matches
Mail list logo
