On Friday 26 December 2008, Alex Deucher wrote:
>On Tue, Dec 23, 2008 at 11:57 PM, Shunichi Fuji wrote:
>> Begin forwarded message:
>>
>> Date: Tue, 23 Dec 2008 22:29:38 -0500
>> From: Gene Heskett
>> To: Shunichi Fuji
>> Subject: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate
>>
>>
On Tue, Dec 23, 2008 at 11:57 PM, Shunichi Fuji wrote:
>
>
> Begin forwarded message:
>
> Date: Tue, 23 Dec 2008 22:29:38 -0500
> From: Gene Heskett
> To: Shunichi Fuji
> Subject: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate
>
>
> On Tuesday 23 December 2008, Shunichi Fuji wrote:
>
On 27 December 2008 00:47:19 Shunichi Fuji wrote:
> >Option "DontZap" "boolean"
> > This disallows the use of the Ctrl+Alt+Backspace sequence.
> > That sequence is normally used to terminate the Xorg server. When this
> > option is enabled (as per default), that key sequenc
On Sat, 27 Dec 2008 07:47:19 +0900
Shunichi Fuji wrote:
> commit 8c560422b44e012053612754430d2b87dc44ed59 changed the default behavior.
oops, that is man pages change.
around 9d135ac10a7374c7ccda705f1eeb02cc53076c34 is it.
___
xorg mailing list
xorg@li
>Option "DontZap" "boolean"
> This disallows the use of the Ctrl+Alt+Backspace sequence. That
> sequence is normally used to terminate the Xorg server. When
> this option is enabled (as per default), that key sequence has
> no speci
On Fri, 2008-12-26 at 22:29 +0100, Magnus Hörlin wrote:
> glxinfo:
> name of display: :0.0
> display: :0 screen: 0
> direct rendering: Yes
> server glx vendor string: SGI
> server glx version string: 1.2
> server glx extensions:
> GLX_ARB_multisample, GLX_EXT_import_context,
> GLX_EXT_textur
Hi,
I recently upgraded to latest X11 stack from gentoo x11 overlay (just want to
test gem+dri2 :)), and it seems that ctrl+alt+backspace doesn't kill X
anymore. Is it bug or planned behavior?
Regards
Vasily
signature.asc
Description: This is a digitally signed message part.
_
Hi. I've built X from git several times since this summer but never
managed to get "OpenGL renderer string" to anything but "Software
Rasterizer" on my Intel G45 board. This time it's with 2.6.28 but it
doesn't seem to help. What should I look for? It works with standard
ubuntu 8.10 but I need
'Twas brillig, and Colin Guthrie at 15/12/08 00:19 did gyre and gimble:
> Just trying a new kernel 2.6.28rc and without changing anything else my
> DRI/GLX performance seems to have suffered badly. I'm running compiz on
> a i945GM.
>
> Is there anything specific that needs to be changed (e.g. in
On Fri, 2008-12-26 at 17:48 +0100, Clemens Eisserer wrote:
> > Could be. Shame the new optimised implementation of the private lookup
> > had to be reverted on the 1.5 branch.
> Its not shame, its just that ABI changes don't fit in minor releases.
>
> > I'm running 1.5.99, and it would appear that
On Fri, 2008-12-26 at 17:48 +0100, Clemens Eisserer wrote:
> > Could be. Shame the new optimised implementation of the private lookup
> > had to be reverted on the 1.5 branch.
> Its not shame, its just that ABI changes don't fit in minor releases.
>
> > I'm running 1.5.99, and it would appear that
> Could be. Shame the new optimised implementation of the private lookup
> had to be reverted on the 1.5 branch.
Its not shame, its just that ABI changes don't fit in minor releases.
> I'm running 1.5.99, and it would appear that the patch is applied. It is
> a shame dixLookupPrivate is consuming
On Wed, Dec 24, 2008 at 1:28 PM, Alex Villacís Lasso
wrote:
> This is probably a very basic question, but it is important for me to know:
>
> If I do an ordinary (non-accelerated) memcpy of a frame from system
> memory to a buffer in AGP memory (allocated via DRI), is it any faster
> than a (non-
On Fri, 2008-12-26 at 16:53 +0100, Erik Andrén wrote:
> 2008/12/26 Peter Clifton :
> > Hi guys,
> >
> > I've been profiling some speed differences rendering pixel aligned
> > (should be fast-path) cairo drawing, and happened across the fact that
> > for my redraw test (which is running flat out), 1
On Thu, Dec 25, 2008 at 2:33 AM, Ma, Ling wrote:
> hi Alex,
> Because the flag exist in EDID, but some laptop can't provide EDID, how can
> we know whether it support continuous frequency or not ?
>
Hi,
Most laptop panels have a fixed resolution so generally the driver
will always run the pan
2008/12/26 Peter Clifton :
> Hi guys,
>
> I've been profiling some speed differences rendering pixel aligned
> (should be fast-path) cairo drawing, and happened across the fact that
> for my redraw test (which is running flat out), 13% of my total system
> time is spent in dixLookupPrivate.
>
> Is
Hi guys,
I've been profiling some speed differences rendering pixel aligned
(should be fast-path) cairo drawing, and happened across the fact that
for my redraw test (which is running flat out), 13% of my total system
time is spent in dixLookupPrivate.
Is there anything which can be done to avoid
'Twas brillig, and Peter Hutterer at 26/12/08 00:25 did gyre and gimble:
> On Wed, Dec 24, 2008 at 11:41:10AM +, Colin Guthrie wrote:
>>> Just built the 1.6 branch + recent mesa snapshot and other such stuff.
>>>
>>> It seems to be stable enough just now, but one thing that's been
>>> affected
I have the same issue. Vanilla 2.6.28 kernel, Xorg stack from gentoo x11
overlay, gma950.
Sometimes it occurs even without suspend - few switches X->console->X are
enought.
Regards
Vasily
On 23 December 2008 06:56:07 Peter Clifton wrote:
> If it's a known issue, fine, well and good.. otherwise
Here we print all detailed timing of EDID and CEA or other extension.
---
hw/xfree86/ddc/print_edid.c | 252 +++
1 files changed, 136 insertions(+), 116 deletions(-)
diff --git a/hw/xfree86/ddc/print_edid.c b/hw/xfree86/ddc/print_edid.c
index 7b6e298..3df
handle detailed timing in xf86Configure.c
---
hw/xfree86/common/xf86Configure.c | 57
1 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/hw/xfree86/common/xf86Configure.c
b/hw/xfree86/common/xf86Configure.c
index b803b49..822b020 100644
---
handle detailed timing operation,e.g. set up Monitor from detailed timing
block
from EDID and cea ext
---
hw/xfree86/modes/xf86Crtc.c | 128 ---
1 files changed, 83 insertions(+), 45 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/
handled detailed timing operation .e.g extract detailed timing modes from EDID
and cea ext,
then insert mode list.
---
hw/xfree86/ddc/xf86DDC.h | 44 ++
hw/xfree86/modes/xf86EdidModes.c | 278 --
2 files changed, 189 insertions(+), 133 deletio
create unified interface for detail timing operation.
---
hw/xfree86/ddc/interpret_edid.c | 64 +++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index 0438449..2002cd5 100
Sorry, please use it to replace "[PATCH 2/7]implement detailed timing unified
interface in interpret_edid.c" sent early.
In this file handle detailed timing operation in interpret_edid.c
---
hw/xfree86/ddc/interpret_edid.c | 242 ++-
1 files changed, 138 in
create unified interface for detail timing operation.
---
hw/xfree86/ddc/interpret_edid.c | 64 +++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index 0438449..2002cd5 10064
defined corresponding structure and MACRO for detailed timing operation
---
hw/xfree86/ddc/edid.h | 76 +
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h
index 31bc7c1..bb5616f 100644
Hi FengGuan,
Thanks for your feedback, based on which I have updated the patchs.
[PATCH 1/7] Includes some new structures and defined MACRO in edid.h.
[PATCH 2/7] implement detailed timing unified interface in interpret_edid.c
[PATCH 3/7] implement detailed timing operation in interpret_edid.
28 matches
Mail list logo
