r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/0aea9044/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #5 from Jan Outhuis ---
Disabling dpm gets me through the bootprocess. I have a text console on
tty1-6, but still no graphic screen on tty7 (or 8). The relevant logs
show no particular warnings or errors that could give a clue.
On Thu
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/01e4a5c9/attachment.html>
|--- |FIXED
--- Comment #8 from Vova ---
Fixed on 3.13 kernel
--
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/20140
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/5abb34bf/attachment.html>
Hi
On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar wrote:
>
> * David Herrmann wrote:
>
>> >> +#ifdef CONFIG_X86_SYSFB
>> >> +# include
>> >> +#endif
>> >
>> > I guess a single space is sufficient?
>> >
>> > Better yet, I'd include sysfb.h unconditionally:
>>
>> Unconditionally won't work as only
te cause lockups.
--
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/20140123/3cb88bed/attachment.html>
On Wed, Jan 22, 2014 at 12:32 AM, Laurent Pinchart
wrote:
> Add DT bindings for the R-Car DU with support for core resources
> (memory, IRQ and clocks). Output configuration must still be passed
> through platform data using OF_DEV_AUXDATA.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../devicet
Ping?
On Tue, Jan 7, 2014 at 9:03 PM, Erik Faye-Lund wrote:
> When patching gathers, we don't need to check against
> gathers with lower indices than the current one, as
> they are guaranteed to already have been handled.
>
> Signed-off-by: Erik Faye-Lund
> ---
>
> Here's a trivial optimization
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/28c3a757/attachment.html>
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/20140123/55f5fb35/attachment-0001.html>
* David Herrmann wrote:
> >> +#ifdef CONFIG_X86_SYSFB
> >> +# include
> >> +#endif
> >
> > I guess a single space is sufficient?
> >
> > Better yet, I'd include sysfb.h unconditionally:
>
> Unconditionally won't work as only x86 has this header. [...]
Well, in non-x86 code an #ifdef x86 look
Hi
On Thu, Jan 23, 2014 at 5:51 PM, Ingo Molnar wrote:
>
> Just a couple of small nits:
>
> * David Herrmann wrote:
>
>> --- a/arch/x86/kernel/sysfb.c
>> +++ b/arch/x86/kernel/sysfb.c
>> @@ -33,11 +33,76 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #
On 01/23/2014 05:27 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
>> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>>> On Mon, 20 Jan 2014, Liu Ying wrote:
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the bac
Just a couple of small nits:
* David Herrmann wrote:
> --- a/arch/x86/kernel/sysfb.c
> +++ b/arch/x86/kernel/sysfb.c
> @@ -33,11 +33,76 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
>
> +static DEFINE_MUTEX(sysfb_lock);
> +static st
Jean-Francois Moine wrote on Sun [2014-Jan-19 19:58:40
+0100]:
> This patch uses always the adjusted video mode instead of a mix of
> original and adjusted mode.
>
> Signed-off-by: Jean-Francois Moine
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 66
> +++
>
On 01/23/2014 01:44 PM, Jingoo Han wrote:
> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>> On Mon, 20 Jan 2014, Liu Ying wrote:
>>> We don't have to turn backlight on/off everytime a blanking
>>> or unblanking event comes because the backlight status may
>>> have already been what w
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #3 from Jan Outhuis ---
Yes. I don't exactly understand what these 'video components' stand for,
but I have an Intel CPU and an AMD/ATI video-card. So I thought DRI -
Intel would be the better choice after all.
On Thu, 2014-01-23 at
Hi Dave,
The following changes since commit 81239c6f7972d4909a6862d08ed1d2943983ffd4:
drm/tegra: fix compile w/ CONFIG_DYNAMIC_DEBUG (2013-12-20 15:56:33 +0100)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.14-rc1-20140123
for you to
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/e2ed90b9/attachment.html>
On Thu, Jan 23, 2014 at 01:53:15PM +0100, David Herrmann wrote:
> Lets make sure some basic expressions are always true:
> bpp != NULL
> width != NULL
> height != NULL
> stride = bpp * width < 2^32
> size = stride * height < 2^32
> PAGE_ALIGN(size) < 2^32
>
> At least the udl driver do
ri-devel/attachments/20140123/ea7e7d4b/attachment.html>
> drm/radeon: fix tiling and command stream checking on evergreen v3
Closing.
--
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/attac
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Damien Lespiau changed:
What|Removed |Added
CC||damien.lespiau at intel.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/0db0810d/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/20140123/bcaf43bb/attachment.html>
||CAYMAN
--
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/20140123/8d2b14d1/attachment.html>
We used to protect X86_SYSFB by depending on FB_SIMPLE so users don't
accidentally end up without a kernel console. Now that DRM_SIMPLEDRM also
provides a simple-framebuffer driver, we can whitelist this driver, too.
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 +++
drivers/gpu/drm/simpledrm/Makefile | 1 +
drivers/gpu/drm/simpledrm/simpledrm.c | 13 ++-
driv
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create dumb-buffers which can be blit into the real
framebuffer similar to UDL. No access to the real framebuffer i
Once we allow DRM drivers for system-framebuffers, we need to evict such
devices *before* probing the real driver. A simple call to sysfb_claim()
does this and remove_conflicting_framebuffers() implicitly calls this.
However, it causes the sysfb device to be unloaded and thus locks
drm_global_mutex
We already call remove_conflicting_framebuffers() on PCI BAR0 during
pci-probe, no need to do that again during device loading.
This avoids calling into remove_conflicting_framebuffers() from within DRM
->load() callback, which might deadlock, once we make this call remove
DRM-backed sysfb-devices
We supported many different firmware-fbs in linux for a long time. On x86,
we tried to unify the different types into platform-devices so their
lifetime and drivers can be more easily controlled. This patch moves the
x86-specific sysfb_*() helpers into drivers/video/sysfb.c so other
architectures c
To get a generic remove_conflicting_framebuffers() for
firmware-framebuffers, we need to store the apertures in the platform-data
of each framebuffer. So make x86-sysfb do that for simple-framebuffer
devices.
Unfortunately, "struct apertures_struct" contains a VLA so we cannot
easily embed it. Thu
If x86-sysfb platform-devices are removed from a system, we should
properly unload vesafb. Otherwise, we end up releasing the parent while
our vesa framebuffer is still running. This currently works just fine, but
will cause problems on handover to real hw. So add the ->remove() callback
and unregi
If x86-sysfb platform-devices are removed from a system, we should
properly unload efifb. Otherwise, we end up releasing the parent while our
efi framebuffer is still running. This currently works just fine, but will
cause problems on handover to real hw. So add the ->remove() callback and
unregist
With CONFIG_X86_SYSFB=y, probing real hw-drivers may result in
resource-conflicts and drivers will refuse to load. A call to
request_mem_region() will fail, if the region overlaps with the mem-region
used by simplefb. The common desktop DRM drivers (intel, nouveau, radeon)
are not affected as they
Turns out, people do not read help-texts of new config-options and enable
them nonetheless. So several reports came in with X86_SYSFB=y and
FB_SIMPLE=n, which in almost all situations prevents firmware-fbs from
being probed.
X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers into
Hi
Another round of SimpleDRM patches. I somehow lost track of the last ones and as
this is a major rewrite, I'll just start at v1 again.
Some comments up-front:
- @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I
included them in this series as the other patches depen
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/e9152e3a/attachment.html>
Hi
On Thu, Jan 23, 2014 at 2:55 PM, Ville Syrj?l?
wrote:
> On Thu, Jan 23, 2014 at 01:53:15PM +0100, David Herrmann wrote:
>> Lets make sure some basic expressions are always true:
>> bpp != NULL
>> width != NULL
>> height != NULL
>> stride = bpp * width < 2^32
>> size = stride * height
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/d287b015/attachment-0001.html>
Hi,
In si_populate_smc_acpi_state function, the acpi (emergency) state is a patched
version of the initial state. Then 'ACIndex = 0' for the acpi state (i.e.
setting it to SISLANDS_MCREGISTERTABLE_INITIAL_SLOT) seems misleading, since
ACIndex is already set to 0 (SISLANDS_MCREGISTERTABLE_INITIAL_S
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/f83c26d3/attachment.html>
- This is _not_ a generic interface to create gem objects, but just an
interface to make early boot services (like boot splash) with a
generic KMS userspace driver possible. Hence it's better to move
the documentation for this from the GEM section to the KMS section,
next to the creation of
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-Implement-drmCheckModesettingSupported-for-FreeB.patch
Type: text/x-diff
Size: 2501 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/001a9
On Thu, Jan 23, 2014 at 01:56:51PM +0100, Laurent Pinchart wrote:
> > > >
> > > > Drivers must first validate the requested frame buffer
> > > > parameters passed
> > > > @@ -1052,6 +998,71 @@ int max_width, max_height;
> > > > drm_framebuffer_unregister_private.
>
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Jan Outhuis changed:
What|Removed |Added
CC||intel-gfx-bugs at lists.freede
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Bug ID: 69301
Summary: no screen on update from 3.12.0
Product: Drivers
Version: 2.5
Kernel Version: 3.13.0
Hardware: x86-64
OS: Linux
Tree: Mainline
On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
> On Mon, 20 Jan 2014, Liu Ying wrote:
> > We don't have to turn backlight on/off everytime a blanking
> > or unblanking event comes because the backlight status may
> > have already been what we want. Another thought is that one
> > backl
Hi Daniel,
Thank you for the patch.
On Thursday 23 January 2014 13:48:17 Daniel Vetter wrote:
> - This is _not_ a generic interface to create gem objects, but just an
> interface to make early boot services (like boot splash) with a
> generic KMS userspace driver possible. Hence it's better t
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 6 +++---
drivers/gpu/drm/radeon/radeon_trace.h | 21 -
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 0e9143b..a8f9b46 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
From: Christian K?nig
Otherwise we allocate a new VMID on nearly every submit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_gart.c | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/d7743f3d/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/3108a7d5/attachment.html>
Hi Daniel,
On Thursday 23 January 2014 13:47:31 Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 12:21:42PM +0100, Laurent Pinchart wrote:
> > On Thursday 23 January 2014 09:52:26 Daniel Vetter wrote:
> > > - This is _not_ a generic interface to create gem objects, but just an
> > > interface to m
vel/attachments/20140123/901f7115/attachment.html>
Lets make sure some basic expressions are always true:
bpp != NULL
width != NULL
height != NULL
stride = bpp * width < 2^32
size = stride * height < 2^32
PAGE_ALIGN(size) < 2^32
At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never hap
|Drivers/Gallium/r600
--
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/20140123/5c4fcf1a/attachment.html>
Hi
On Tue, Jan 21, 2014 at 10:41 AM, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 08:26:25PM +0100, David Herrmann wrote:
>> Instead of rounding down to the next lower page-boundary, round up.
>> dma-buf guarantees that we can map buffers in multiples of a page, so if
>> an exporter does not pa
On Thu, Jan 23, 2014 at 10:05:19AM +, Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 11:00:28AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 10:42:02AM +0100, David Herrmann wrote:
> > > If there's ever hardware that truly supports sub-device hotplugging,
> > > we can supp
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Use DIV_ROUND_UP() to avoid the problem entirely and make the core more
readable.
Reviewed-by: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/u
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Reviewed-by: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/u
- This is _not_ a generic interface to create gem objects, but just an
interface to make early boot services (like boot splash) with a
generic KMS userspace driver possible. Hence it's better to move
the documentation for this from the GEM section to the KMS section,
next to the creation of
On Thu, Jan 23, 2014 at 12:21:42PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Thursday 23 January 2014 09:52:26 Daniel Vetter wrote:
> > - This is _not_ a generic interface to create gem objects, but just an
> > interface to make early boot services (like bo
On Mon, 28 Oct 2013, Stefan Demharter wrote:
> Hi all,
>
> i've got a system with a muxed intel+ati card and had a problem with
> hibernation:
> Vgaswitcheroo didn't restore the states of the graphics cards and the state
> of the mux after resume.
>
> I have solved the issue with the attached pa
Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. Th
With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.
Cc: Dave Airlie
Cc: Be
DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
in
Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. Th
On Wed, Jan 22, 2014 at 5:21 PM, Olof Johansson wrote:
> On Wed, Jan 22, 2014 at 2:06 AM, Daniel Vetter
> wrote:
>> Hi Stephen,
>>
>> On Wed, Jan 22, 2014 at 4:04 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the drm-intel tree got a conflict in
>>> drivers/gpu
On Thu, Jan 23, 2014 at 8:24 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Otherwise we allocate a new VMID on nearly every submit.
I wonder if this fix would allow us to fix up this:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=466476dfdcafbb4286ffa232a3a79
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/7e8737c6/attachment-0001.html>
vel/attachments/20140123/d33fa041/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/4e2ecf28/attachment.html>
Hi Magnus,
On Thursday 23 January 2014 18:52:29 Magnus Damm wrote:
> On Wed, Jan 22, 2014 at 12:32 AM, Laurent Pinchart wrote:
> > Add DT bindings for the R-Car DU with support for core resources
> > (memory, IRQ and clocks). Output configuration must still be passed
> > through platform data usin
Hi David,
On Thursday 23 January 2014 10:14:35 David Herrmann wrote:
> On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter wrote:
> > - This is _not_ a generic interface to create gem objects, but just an
> > interface to make early boot services (like boot splash) with a
> > generic KMS userspace
vel/attachments/20140123/b76b9ed0/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/3579df85/attachment.html>
Hi Daniel,
Thank you for the patch.
On Thursday 23 January 2014 09:52:26 Daniel Vetter wrote:
> - This is _not_ a generic interface to create gem objects, but just an
> interface to make early boot services (like boot splash) with a
> generic KMS userspace driver possible. Hence it's better t
|font with compiz|font with compiz with SB
--
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/20140123/9a4ce
vel/attachments/20140123/5bf2b5bc/attachment.html>
ow and there is no audio.
So is this fixed then?
--
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/20140123/a5ec93c4/attachment.html>
Am 23.01.2014 04:20, schrieb Ben Widawsky:
> On Wed, Jan 22, 2014 at 11:11:10AM +0100, Christian K?nig wrote:
>> Am 21.01.2014 21:33, schrieb Ben Widawsky:
>>> The debugfs helper duplicates the functionality used by Armada, so let's
>>> just use that.
>>>
>>> WARNING: only compile tested
>>>
>>> Cc
vel/attachments/20140123/73e3c8c5/attachment-0001.html>
dri-devel/attachments/20140123/ffdc2d29/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/74fcc2b5/attachment.html>
Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value. Also
add some detailed debug info when acpi_evaluate_object() failed.
Reviewed-by: Jani Nikula
Acked-by: Bjorn Helgaas
Signed-off-by: Yijing Wang
---
v4->v5: Add some
vel/attachments/20140123/fe066432/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/82518532/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/ccfaa5ff/attachment.html>
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value. Also
> add some detailed debug info when acpi_evaluate_object() failed.
>
> Reviewed-by: Jani Nikula
> Acked-by:
dri-devel/attachments/20140123/4c0d028a/attachment.html>
archives/dri-devel/attachments/20140123/322125ac/attachment-0001.html>
dri-devel/attachments/20140123/c60ed80b/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/5f16dd27/attachment.html>
|Drivers/DRI/Radeon
--
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/20140123/91c697a1/attachment.html>
1 - 100 of 147 matches
Mail list logo
