https://bugs.freedesktop.org/show_bug.cgi?id=39953
Simon Strandman changed:
What|Removed |Added
CC||simon.strand...@gmail.com
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=41445
Summary: XBMC problem with playing the videos i915_dri.so
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #1 from Wojtek 2011-10-04 04:41:10 PDT ---
Created an attachment (id=51922)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51922)
Debian version
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #2 from Wojtek 2011-10-04 04:41:44 PDT ---
Created an attachment (id=51923)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51923)
Dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #3 from Wojtek 2011-10-04 04:42:11 PDT ---
Created an attachment (id=51924)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51924)
Lsmod
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #4 from Wojtek 2011-10-04 04:42:40 PDT ---
Created an attachment (id=51925)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51925)
Lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #5 from Wojtek 2011-10-04 04:42:57 PDT ---
Created an attachment (id=51926)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51926)
Uname
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #6 from Wojtek 2011-10-04 04:43:17 PDT ---
Created an attachment (id=51927)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51927)
Glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You a
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #7 from Wojtek 2011-10-04 04:43:38 PDT ---
Created an attachment (id=51928)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51928)
Glxheads
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #8 from Wojtek 2011-10-04 04:43:57 PDT ---
Created an attachment (id=51929)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51929)
Glxgears
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #9 from Wojtek 2011-10-04 04:44:22 PDT ---
Created an attachment (id=51930)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51930)
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #10 from Wojtek 2011-10-04 04:44:51 PDT ---
Created an attachment (id=51931)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51931)
Xbmc_crashlog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
On 08/07/2011 10:39 PM, Marek Olšák wrote:
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or writt
> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stol
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #5 from Alex Deucher 2011-10-04 06:43:32 PDT ---
Can you attach the output of xrandr --verbose? Note that Full aspect scaling
is not implemented for pre-avivo asics, so make sure you are not using that.
Center and Full do work howev
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
>
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors a
On Tue, Oct 4, 2011 at 9:42 AM, James Simmons wrote:
>
>> > Thats fine as long as you don't want to do acceleration or object
>> > migration between GTT
>> > and VRAM type memory. Now I expect when you give out this advice you
>>
>> Yes but the VIA doesn't if I recall correctly have any 'VRAM type
On Tue, Oct 4, 2011 at 9:45 AM, James Simmons wrote:
>
>> > Second question I have is how are monochrome cursor images
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> As far as I know, the
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if
From: Alex Deucher
Most asics just use the hw default value which requires
no explicit programming. For those that need a different
value, the vbios will program it properly. As such,
there's no need to program these registers explicitly
in the driver. Changing these registers requires a reloa
> >> > Thats fine as long as you don't want to do acceleration or object
> >> > migration between GTT
> >> > and VRAM type memory. Now I expect when you give out this advice you
> >>
> >> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> >> It's all effectively in the GA
> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
> >> the front buffer. The problem was the buffer offset for the second
> >> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> >> wrong, so does anyone have a idea?
> >
> > I gave up trying to understand TTM (they don't make
> From: Dave Airlie
>
> For the simple KMS driver case we need some more info about argb cursor
> limits and a preferred depth and if shadowed framebuffer access is preferred.
>
> I've only added this for intel/radeon which support the dumb ioctls so far.
>
> I really don't want to expose a tr
> >> Without code to look at we all can start guessing :) my guess is either
> >> you are not using the proper offset field or you are allocating from
> >> different memory pool.
> >
> > http://cgit.freedesktop.org/~jsimmons/drm-openchrome
> >
>
> >From quick glimpse ttm_bo_allocate in via/init_t
From: Alex Deucher
Most asics just use the hw default value which requires
no explicit programming. For those that need a different
value, the vbios will program it properly. As such,
there's no need to program these registers explicitly
in the driver. Changing MC_SHARED_CHREMAP requires a rel
On Die, 2011-10-04 at 10:46 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Most asics just use the hw default value which requires
> no explicit programming. For those that need a different
> value, the vbios will program it properly. As such,
> there's no need to program these r
From: Alex Deucher
The HPD pin is not reliable for detecting whether a monitor
is connected or not. Skip HPD and just use DDC or load
detection.
Fixes phantom VGA connected bugs.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_connectors.c | 21 ++---
https://bugs.freedesktop.org/show_bug.cgi?id=39897
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi Linus,
all radeon fixes, one nasty startup crash and/or memory corruption on one
family of radeon hd6450s resulted in a patch to stop setting a bunch of
regs in the drivers and let the BIOS set them correctly, displayport
regression fix, and some off-by-one in the cursor code around the cor
On 10/04/2011 01:07 AM, Alan Cox wrote:
Thats fine as long as you don't want to do acceleration or object
migration between GTT
and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effective
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and so
On 10/03/2011 09:14 PM, Alan Cox wrote:
the front buffer. The problem was the buffer offset for the second
allocation was the same as the VQ buffer. I'm stump to what I'm doing
wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and
On Tue, Oct 4, 2011 at 12:58 PM, Linus Torvalds
wrote:
> On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie wrote:
>>
>> all radeon fixes, one nasty startup crash and/or memory corruption on one
>> family of radeon hd6450s resulted in a patch to stop setting a bunch of
>> regs in the drivers and let the
On Die, 2011-10-04 at 12:23 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> The HPD pin is not reliable for detecting whether a monitor
> is connected or not. Skip HPD and just use DDC or load
> detection.
>
> Fixes phantom VGA connected bugs.
>
> Signed-off-by: Alex Deucher
Ju
https://bugs.freedesktop.org/show_bug.cgi?id=41445
Ian Romanick changed:
What|Removed |Added
Product|DRI |Mesa
Version|unspecified
A series of updates to
*) Deal with new device features like screen objects.
*) Handle query buffer object pinning correctly.
*) Make hardware surfaces swappable.
v2:
Rebased on Dave's freedesktop.org "linux" repo.
Incorporating Konrad's feedback in patches 05 and 06 and as an
additional cleanup p
Used by the vmwgfx driver.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b824d9b..6e96c85 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/svga3d_reg.h | 259 +++--
drivers/gpu/drm/vmwgfx/svga_escape.h |2 +-
drivers/gpu/drm/vmwgfx/svga_overlay.h | 22 ++--
drivers/gpu/drm/vmwgf
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1a4
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index c14eb76..
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
i
This will make it easier to execute commands operating on user-space
resources but generated by the kernel.
JB: Added tracking if the sw_context was called from the kernel or userspace.
Signed-off-by: Thomas Hellstrom
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Jakob Bornecrantz
---
drivers
From: Jakob Bornecrantz
In preperation for screen objects, still leaves the delayed workqueue
for surface updates in place.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 144 ++-
1 files changed, 90
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 77 +--
1 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/dr
From: Jakob Bornecrantz
More preparation for Screen Object support.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 238 +++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 31 -
drivers/gpu/drm/vmwgfx/vmwgfx_
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/Makefile |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 33
drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 292 +++
drivers/gpu/drm/v
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/Makefile |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 34 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 165 +-
d
On lower versions, the way we mix 2D and 3D may be too slow.
Signed-off-by: Thomas Hellstrom
Signed-off-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/dr
From: Jakob Bornecrantz
Since 3D requires HWv8 and screen objects is always available on those
hosts we only need the screen objects path for surfaces.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
drivers/gpu/drm/vmwgfx/v
From: Jakob Bornecrantz
When we hae screen objects we are allowed to place the overlay source
in the GMR area, do this as this will save precious VRAM.
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 134 +--
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 172 +
drivers/gpu/drm/vmwg
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_e
Add / fix some function comments.
Don't move out an fbdev framebuffer when unused. Just unpin.
Only have a single function that computes a SVGAGuestPtr from the buffer's
current placement, and make it more versatile by accepting a
struct ttm_buffer_object
Signed-off-by: Thomas Hellstrom
Reviewed-
The execbuf utils may call reference on NULL fence objects.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/
Previously, query results could be placed in any buffer object, but since
we didn't allow pinned buffer objects, query results could be written when
that buffer was evicted, corrupting data in other buffers.
Now, require that buffers holding query results are no more than two pages
large, and allo
Use a list for resources referenced during command submission, instead of
an array.
As long as we don't implement parallell command submission this works fine
and simplifies things a bit.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 56 --
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |2 +
2 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/
Make surfaces swappable. Make sure we honor the maximum amount of surface
memory the device accepts. This is done by potentially reading back surface
contents not used by the current command submission and storing it
locally in buffer objects.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bo
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgf
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index ee564f0..8cce73e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
++
As suggested by Konrad Rzeszutek Wilk
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drive
> There is a fully functional unichrome DRM on top of TTM, that together with
> the 3D driver in mesa's openchrome branch worked like a charm (even
> outperformed Intel's i965 with identical CPU at the time).
> Problem was that it was not backwards compatible with via's old drm.
>
> It should ser
From: Alex Deucher
If there are error flags in the aux status, retry the transaction.
This makes aux much more reliable, especially on llano systems.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_dp.c | 12 +---
1 files changed, 9 insertions(+)
https://bugs.freedesktop.org/show_bug.cgi?id=41467
Summary: No display with switcheroo
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #1 from Michael Lothian 2011-10-04 16:46:27
PDT ---
Created an attachment (id=51985)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51985)
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #2 from Michael Lothian 2011-10-04 16:47:03
PDT ---
Created an attachment (id=51986)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51986)
xorg.log.0 Intel
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #3 from Michael Lothian 2011-10-04 16:47:35
PDT ---
Created an attachment (id=51987)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51987)
xorg.log.0 Radeon
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #4 from Michael Lothian 2011-10-04 16:49:18
PDT ---
I should probably mention that I'm running git master from Linus' tree last
updated 6 hours ago with your fixes (I've tried with and without those fixes)
Unfortunately as this is a
https://bugs.freedesktop.org/show_bug.cgi?id=41467
Alex Deucher changed:
What|Removed |Added
Attachment #51985|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #5 from Alex Deucher 2011-10-04 17:01:26 PDT ---
You have a muxless laptop which means the discrete card is not connected to any
displays. You won't be able to use the discrete card until the xserver gets
the ability to decouple rend
https://bugs.freedesktop.org/show_bug.cgi?id=41467
--- Comment #6 from Michael Lothian 2011-10-04 18:33:20
PDT ---
How do I use the Intel graphics as default?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom wrote:
> Bah, I totally missed this patch and thus never reviewed it :( Probably on
> vacation.
>
> There are a couple of things I'd like to point out.
>
> 1) The bo subsystem may never assume that fence objects are ordered, so that
> when we unref
Hello Chris Wilson.
git : git://anongit.freedesktop.org/git/mesa/drm
branch : master
I found some memory leaks in xf86drmMode.c.
When we call drmModeGetResources(), fbs, crtcs, connectors and encoders
are newly allocated. But, drmModeFreeResources() doesn't free them.
drmModeFreeProperty() al
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Brad Campbell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 10/05/2011 04:08 AM, Marek Olšák wrote:
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom wrote:
Bah, I totally missed this patch and thus never reviewed it :( Probably on
vacation.
There are a couple of things I'd like to point out.
1) The bo subsystem may never assume that fence objec
Hi, Dave.
> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Monday, October 03, 2011 7:17 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com
> Subject: Re: [RESEND] An inquiry about DRM Driver for Sam
Hi, Konrad Rzeszutek Wilk.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Tuesday, October 04, 2011 12:46 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.co
> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages pre
Hi,
I've been finding that kmemleak reports that i915 is leaking gem
buffers (although it takes about 20 minutes before the supposed leaks
occur). The leaks normally occur in batches of 13 and seem to require
chrome to be running looking at a page like google.com while a
gnome-terminal is also pr
https://bugs.freedesktop.org/show_bug.cgi?id=39953
Simon Strandman changed:
What|Removed |Added
CC||simon.strandman at gmail.com
--- Comme
This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
only FIMD yet but we will add HDMI support also in the future.
this patch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: 88ef4e3f4f616462b78a7838eb3ffc3818d30f6
https://bugs.freedesktop.org/show_bug.cgi?id=41445
Summary: XBMC problem with playing the videos i915_dri.so
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #1 from Wojtek 2011-10-04 04:41:10 PDT ---
Created an attachment (id=51922)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51922)
Debian version
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #2 from Wojtek 2011-10-04 04:41:44 PDT ---
Created an attachment (id=51923)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51923)
Dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #3 from Wojtek 2011-10-04 04:42:11 PDT ---
Created an attachment (id=51924)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51924)
Lsmod
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #4 from Wojtek 2011-10-04 04:42:40 PDT ---
Created an attachment (id=51925)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51925)
Lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #5 from Wojtek 2011-10-04 04:42:57 PDT ---
Created an attachment (id=51926)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51926)
Uname
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #6 from Wojtek 2011-10-04 04:43:17 PDT ---
Created an attachment (id=51927)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51927)
Glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You a
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #7 from Wojtek 2011-10-04 04:43:38 PDT ---
Created an attachment (id=51928)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51928)
Glxheads
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #8 from Wojtek 2011-10-04 04:43:57 PDT ---
Created an attachment (id=51929)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51929)
Glxgears
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #9 from Wojtek 2011-10-04 04:44:22 PDT ---
Created an attachment (id=51930)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51930)
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=41445
--- Comment #10 from Wojtek 2011-10-04 04:44:51 PDT ---
Created an attachment (id=51931)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51931)
Xbmc_crashlog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
On 08/07/2011 10:39 PM, Marek Ol??k wrote:
> Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
> However, sometimes it would be more useful to be able to query whether
> a buffer is busy and being either read or written, and wait until it's stopped
> being either read or
> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stol
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #5 from Alex Deucher 2011-10-04 06:43:32 PDT
---
Can you attach the output of xrandr --verbose? Note that Full aspect scaling
is not implemented for pre-avivo asics, so make sure you are not using that.
Center and Full do work howe
> > ? ? ? ?Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
>
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors a
On Tue, Oct 4, 2011 at 9:42 AM, James Simmons wrote:
>
>> > Thats fine as long as you don't want to do acceleration or object
>> > migration between GTT
>> > and VRAM type memory. Now I expect when you give out this advice you
>>
>> Yes but the VIA doesn't if I recall correctly have any 'VRAM type
On Tue, Oct 4, 2011 at 9:45 AM, James Simmons wrote:
>
>> > ? ? ? ?Second question I have is how are monochrome cursor images
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> As far as I know, the
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if
1 - 100 of 154 matches
Mail list logo