http://bugzilla.kernel.org/show_bug.cgi?id=12634
--- Comment #16 from [email protected] 2009-02-14 23:33 ---
I recently grabbed 2.6.29-rc3-zen1, and while I was able to get X to start, the
initial KDE-3.5.x splash screen is all messed up.
After that, I may or may not be able to
http://bugs.freedesktop.org/show_bug.cgi?id=20038
--- Comment #13 from Guy Lunardi 2009-02-14 22:53:08 PST
---
(In reply to comment #12)
> How to enable windows preview plug-in? Anyone knows that?
The easiest way to do this is to use the "ccsm" application provided on SLED by
the compizconf
http://bugzilla.kernel.org/show_bug.cgi?id=12634
[email protected] changed:
What|Removed |Added
CC||[email protected]
--- C
http://bugzilla.kernel.org/show_bug.cgi?id=12613
--- Comment #5 from [email protected] 2009-02-14 14:31 ---
References : http://lkml.org/lkml/2009/2/8/203
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You ar
>From b4c40cb00c44e65dd2a722f99e88260e0746bc22 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen
Date: Sat, 14 Feb 2009 22:22:39 +0200
Subject: [PATCH] drm_compat: remove kmap_atomic_prot_pfn()
This function is unused, and yet creates build problems: the symbol
init_mm is not exported by the latest -
>
> This will need to be revisited with KMS as i think we should not allow
> userspace to play with surface. Maybe we could setup surface on BO
> mapping and disable them on bo unmapping (we would to register some
> callback on vmclose).
Under KMS we can either enable swappers fulltime or just us
On Sat, 2009-02-14 at 02:04 -0800, David Miller wrote:
> From: Michel Dänzer
> Date: Sat, 14 Feb 2009 10:59:59 +0100
>
> > On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
> > > This allocates a physical surface for the PCI GART table, this way no
> > > matter what other surface configurati
On Lunes 09 Febrero 2009 09:30:57 Dave Airlie escribió:
> Hi Linus,
>
> Please pull the 'drm-fixes' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> drm-fixes
A commit from this merge is causing an error in my machine:
commit ab657db12d7020629f26f30d287558a8d0e
On Viernes 13 Febrero 2009 20:04:03 Jesse Barnes escribió:
> Does this prevent the message? We map it WC in GEM but not in
> i915_initialize...
Yes, the message has disappeared.
--
Open Source Business Conference (OSBC)
On 13.02.2009 05:49, Dave Airlie wrote:
>>> Compressed textures also seem to be broken, since they'll raise a FPE:
>>> Program received signal SIGFPE, Arithmetic exception.
>>> [Switching to Thread -1480239424 (LWP 11180)]
>>> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
>>> t
From: Michel Dänzer
Date: Sat, 14 Feb 2009 10:59:59 +0100
> On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
> > This allocates a physical surface for the PCI GART table, this way no
> > matter what other surface configurations exist the GART table will
> > always be seen by the hardware pr
On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
> This allocates a physical surface for the PCI GART table, this way no
> matter what other surface configurations exist the GART table will
> always be seen by the hardware properly.
BTW, I don't think the swapping settings affect GPU access
From: David Miller
Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST)
> From: Benjamin Herrenschmidt
> Date: Sat, 14 Feb 2009 20:07:54 +1100
>
> > We can do that by registering a surface from the kernel to cover the
> > GART I suppose, and clean things a bit so that when using the DRI, X
> > doesn't t
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.
We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV. On
From: Benjamin Herrenschmidt
Date: Sat, 14 Feb 2009 20:07:54 +1100
> > I did some research, and it does appear that the GART does read the
> > PTEs from the VRAM using the Host Data Path. This means the surface
> > control byte swapping settings are applied.
> >
> > So for depths of 16 and 24,
> The only think I can think to do is use a surface instead of the
> aperture swappers
> and make the surface cover all the VRAM except the GART table which is
> at the end.
Why not use a surface to cover the GART ? At least this would ensure a
known swapper setting for it.
> That's interesting
> So I've narrowed down the final problems I'm having. It's the surface
> swapping settings indeed.
>
> Running Xorg at depth 8, the CP can execute indirect buffers just
> fine, no code changes necessary.
>
> However, the CP hangs on indirect execution for depth 16 and 24. But
> these depths w
From: Dave Airlie
Date: Sat, 14 Feb 2009 17:42:02 +1000
> On Sat, Feb 14, 2009 at 4:09 PM, David Miller wrote:
> > 1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead
> > of the constant 4096 to determine how many GART entries there
> > are. The PCI GART entries map 4096 byte
18 matches
Mail list logo
