http://bugs.freedesktop.org/show_bug.cgi?id=21536
--- Comment #13 from Jeremy Uchitel 2009-12-30 18:49:44
PST ---
Ok, I've had a couple of days to play with things... definitely not there yet.
I still have weirdness when I end an X-session and try to start a new one.
Sometimes it works, an
On Wed, Dec 30, 2009 at 9:21 PM, Jack wrote:
> On 2009.12.24 04:12, Xavier wrote:
>>
>> On Thu, Dec 24, 2009 at 12:29 AM, Jack wrote:
>>>
>>> I'm using nouveau xf86-video-nouveau 0.0.10_git20091101-1 and nouveau-drm
>>> 0.0.15_20091120-1 under Arch Linux with xorg-server 1.7.3.901-1. My video
>>
On Wed, Dec 30, 2009 at 9:10 PM, Erik Auerswald
wrote:
>
> No, it would omit them. Thus for open mailing lists no reply-to header
> should be used. At least some ML software can be configured to remove
> duplicates (i.e. don't send message to recipients in CC). Of course the
> MUA's "reply all" fu
On Wed, Dec 30, 2009 at 10:36:41PM +0100, Maarten Maathuis wrote:
> From: Marcin Slusarz
>
> ---
> src/gallium/drivers/nouveau/nouveau_push.h | 93 -
> src/gallium/drivers/nv04/nv04_context.c| 44 ++-
> src/gallium/drivers/nv04/nv04_context.h|4 -
> src/gallium/drivers/nv04/n
The prerequisite patch (which kills nouveau_push) got stuck in queue
because of it's size.
This patch is here for discussion, and it needs testing on nv30/nv40
for miscalculated so sizes.
On Wed, Dec 30, 2009 at 10:36 PM, Maarten Maathuis wrote:
> - The previous solution was hacky and didn't do
Same patch from before, without the debatable unmap change.
On Wed, Dec 30, 2009 at 10:36 PM, Maarten Maathuis wrote:
> - This avoids problematic "reloc'ed while mapped" messages and
> some associated corruption as well.
>
> Signed-off-by: Maarten Maathuis
> ---
> src/gallium/drivers/nouveau/no
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour should match what libdrm_nouveau does closely.
- There appears to be a minor performance loss, probably due to having multiple
memcpy's instead of one.
- The solution remains statically sized, but when debuggin
- This avoids problematic "reloc'ed while mapped" messages and
some associated corruption as well.
Signed-off-by: Maarten Maathuis
---
src/gallium/drivers/nouveau/nouveau_screen.c | 21 +
src/gallium/drivers/nouveau/nouveau_screen.h |3 +++
src/gallium/drivers/nouve
On 2009.12.24 04:12, Xavier wrote:
> On Thu, Dec 24, 2009 at 12:29 AM, Jack
> wrote:
>> I'm using nouveau xf86-video-nouveau 0.0.10_git20091101-1 and
>> nouveau-drm 0.0.15_20091120-1 under Arch Linux with xorg-server
>> 1.7.3.901-1. My video card is recognized as "nVidia Corporation
>> NV
Hi,
Marcin Slusarz wrote:
> On Wed, Dec 30, 2009 at 08:00:57PM +0100, Xavier wrote:
>
>> Afaik the absence of that header is the reason that the reply button
>> in mail clients or in gmail answers to the sender rather than to the
>> mailing list.
>> Does anyone know why that header is not inclu
On Wed, Dec 30, 2009 at 08:35:32PM +0100, Marcin Slusarz wrote:
> ps: i'll remove the piece you fixed differently and resend my patch soon
here we go: (2nd patch applies cleanly, so I won't resend it)
---
>From 201601b66386d6fc8e28b863eac405f91edee5ed Mon Sep 17 00:00:00 2001
From: Marcin Slusarz
On 2009.12.30 14:00, Xavier wrote:
> Afaik the absence of that header is the reason that the reply button
> in mail clients or in gmail answers to the sender rather than to the
> mailing list.
> Does anyone know why that header is not included ?
> I consider it a must have for any mailing list,
On Wed, Dec 30, 2009 at 08:00:57PM +0100, Xavier wrote:
> Afaik the absence of that header is the reason that the reply button
> in mail clients or in gmail answers to the sender rather than to the
> mailing list.
> Does anyone know why that header is not included ?
> I consider it a must have for
On Wed, Dec 30, 2009 at 06:52:40PM +0100, Christoph Bumiller wrote:
> On 12/30/2009 06:37 PM, Christoph Bumiller wrote:
> > On 12/29/2009 06:06 PM, Marcin Slusarz wrote:
> >> On Mon, Dec 28, 2009 at 06:55:23PM +0100, Maarten Maathuis wrote:
> >>> On Mon, Dec 28, 2009 at 6:37 PM, Marcin Slusarz
> >>
It seems that the current miptree layout is incorrect because the size
of all the levels of each cube map face must be 64-byte aligned.
This patch fixes piglit cubemap and fbo-cubemap which were broken.
This makes sense since otherwise all the levels would no longer be
64-byte aligned, which the GP
Afaik the absence of that header is the reason that the reply button
in mail clients or in gmail answers to the sender rather than to the
mailing list.
Does anyone know why that header is not included ?
I consider it a must have for any mailing list, without reply-to it's
quite impractical.
Or is e
On 12/30/2009 06:37 PM, Christoph Bumiller wrote:
> On 12/29/2009 06:06 PM, Marcin Slusarz wrote:
>> On Mon, Dec 28, 2009 at 06:55:23PM +0100, Maarten Maathuis wrote:
>>> On Mon, Dec 28, 2009 at 6:37 PM, Marcin Slusarz
>>> wrote:
---
src/nv50_exa.c | 155
On 12/29/2009 06:06 PM, Marcin Slusarz wrote:
> On Mon, Dec 28, 2009 at 06:55:23PM +0100, Maarten Maathuis wrote:
>> On Mon, Dec 28, 2009 at 6:37 PM, Marcin Slusarz
>> wrote:
>>>
>>> ---
>>> src/nv50_exa.c | 155
>>>
>>> 1 files changed,
On some systems, putting vertex and index buffers in VRAM instead of
GART memory eliminates massive graphics corruption which is otherwise
present, due to unclear causes.
This patch adds an environment variable that does that, along with
helpful messages, prompting the user the report his configur
This patch adds support for two-sided vertex color to NV20, NV30 and NV40.
When set, the COLOR0/1 fs inputs on back faces will be wired to vs outputs
BCOLOR0/1.
This makes OpenGL two sided lighting work, which can be tested with
progs/demos/projtex.
This is already supported on NV50 and seems to
http://bugs.freedesktop.org/show_bug.cgi?id=25824
--- Comment #5 from Pekka Paalanen 2009-12-30 04:15:52 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > Case 2 you should be able to achieve with the "video" kernel command line
> > parameter, forcing the small mode on the big
http://bugs.freedesktop.org/show_bug.cgi?id=25824
--- Comment #4 from Achim Schaefer 2009-12-30 02:26:29
PST ---
(In reply to comment #3)
> Case 2 you should be able to achieve with the "video" kernel command line
> parameter, forcing the small mode on the big monitor. I hope it is document
http://bugs.freedesktop.org/show_bug.cgi?id=25824
--- Comment #3 from Pekka Paalanen 2009-12-30 02:17:05 PST ---
Achim, this is more of a user preference to choose one over the other:
1. use the best mode on each output
2. use the largest common mode on all outputs
Case 1 is what X does, an
http://bugs.freedesktop.org/show_bug.cgi?id=25824
--- Comment #2 from Achim Schaefer 2009-12-30 00:09:10
PST ---
I know handling of this situation is not very easy.
But the current situation is
Would it be possible to use in both screens the lower resolution, so in my case
in both 1024x76
24 matches
Mail list logo
