Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On Mon, 2012-09-24 at 15:31 -0400, Robert Heller wrote: If hostname is longer than 33 characers, the server can't locate/open the config file. I'm guessing someone is using a fixed size buffer (#1 nono!) that is not big enough. Yes, some of use use long and meaningful domain and host names... The hostname buffer is a fixed length anyway, see man gethostname. But that you're seeing truncation to 33 bytes is certainly a server bug, I think the MAXHOSTNAMELEN code in hw/xfree86/parser/scan.c should just be talking about HOST_NAME_MAX like the gethostname man page suggests. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Mon, 24 Sep 2012 16:07:26 -0400 Adam Jackson a...@redhat.com wrote: On Mon, 2012-09-24 at 15:31 -0400, Robert Heller wrote: If hostname is longer than 33 characers, the server can't locate/open the config file. I'm guessing someone is using a fixed size buffer (#1 nono!) that is not big enough. Yes, some of use use long and meaningful domain and host names... The hostname buffer is a fixed length anyway, see man gethostname. But that you're seeing truncation to 33 bytes is certainly a server bug, I think the MAXHOSTNAMELEN code in hw/xfree86/parser/scan.c should just be talking about HOST_NAME_MAX like the gethostname man page suggests. Right. HOST_NAME_MAX == 64 on my machine, and allowing for 'xorg.conf.' yields 74 +1 for the NUL byte. The buffer *ought* to be at lease 75 bytes. It *appearently* is only 44 bytes long or something like that, - ajax Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlBgvX4ACgkQW4otUKDs0NNOcgCguvsHTJQwCZS8y8qt3PfIjZzR UDMAnRmGfiy+CwWMOJy+jvb/HHgZ/fcK =muxj -END PGP SIGNATURE- -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Installing proto pc files in /usr/share/pkgconfig?
On Sep 23, 2012 9:59 PM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: On 2012-09-23 12:35, Matt Turner wrote: The proto packages install their pc files in $(libdir)/pkgconfig, but this leads to files being installed in /usr/lib32 or /usr/lib64 when there's nothing ABI specific about them. Would it be reasonable to install them to $(prefix)/share/pkgconfig instead? Absolutely NOT. If you do this, then they will be picked up when cross-compiling, adding e.g. -I/usr/include to CFLAGS, which will then cause the build-system's headers to be used instead of the cross-host's. Where the pc file is installed has nothing to do with what flags are returned. This is only an issue if people don't put $datadir/pkgconfig in their path. That used to happen frequently, but now there are lots of arch-independent packages who put their pc files there. The likelihood this breaks now is pretty low. Can you explain how this affects cross-compiling? Dan ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/7] dix: Repack ClientRec
On Sat, 2012-09-22 at 09:07 +0200, Keith Packard wrote:
Adam Jackson a...@redhat.com writes:
Pick smaller types where possible, including bitfielding some Bools and
small enums, then shuffle the result to be hole-free. 192 - 128 bytes
on LP64, 144 - 96 bytes on ILP32.
One thing that would make this easier to check for 'optimal' packing
would be to simply start with the largest sized objects and work down to
the smallest ones. Otherwise, I'm sitting here counting bits. Or would
that be less efficient at run time?
That's true, as far as it goes, but I find it less tedious to just ask
what the answer is:
hate:~/xserver% pahole -C _Client hw/vfb/Xvfb
struct _Client {
pointerrequestBuffer;/* 0 8 */
pointerosPrivate;/* 8 8 */
Mask clientAsMask; /*16 4 */
short int index;/*20 2 */
unsigned char majorOp; /*22 1 */
unsigned char minorOp; /*23 1 */
intswapped:1;/*24:31 4 */
intlocal:1; /*24:30 4 */
intbig_requests:1; /*24:29 4 */
intclientGone:1; /*24:28 4 */
intcloseDownMode:2; /*24:26 4 */
intclientState:2;/*24:24 4 */
/* Bitfield combined with next fields */
char smart_priority; /*25 1 */
short int noClientException;/*26 2 */
intpriority; /*28 4 */
ReplySwapPtr pSwapReplyFunc; /*32 8 */
XIDerrorValue; /*40 4 */
intsequence; /*44 4 */
intignoreCount; /*48 4 */
intnumSaved; /*52 4 */
SaveSetElt * saveSet; /*56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
int ()(ClientPtr) * * requestVector;/*64 8 */
CARD32 req_len; /*72 4 */
unsigned int replyBytesRemaining; /*76 4 */
PrivateRec * devPrivates; /*80 8 */
short unsigned int xkbClientFlags; /*88 2 */
short unsigned int mapNotifyMask;/*90 2 */
short unsigned int newKeyboardNotifyMask; /*92 2 */
short unsigned int vMajor; /*94 2 */
short unsigned int vMinor; /*96 2 */
KeyCodeminKC;/*98 1 */
KeyCodemaxKC;/*99 1 */
intsmart_start_tick; /* 100 4 */
intsmart_stop_tick; /* 104 4 */
intsmart_check_tick; /* 108 4 */
DeviceIntPtr clientPtr;/* 112 8 */
ClientIdPtrclientIds;/* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
/* size: 128, cachelines: 2, members: 37 */
};
Not the best-documented set of tools in the world, but very handy.
As far as efficiency, I suspect cacheline fill cost would dominate over
the cost of computing offsets. So if you really wanted to ricer tune
this, try a multi-client benchmark with the server under cachegrind,
figure out the histogram of field access, put the most-frequently used
member as the first element so its address constant-folds with that of
the struct itself, and then try to cram as many frequently-accessed
fields into the first cacheline as you can.
Having done that I'm not sure you'd see a statistically significant win
even in x11perf -noop.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Installing proto pc files in /usr/share/pkgconfig?
On Mon, 2012-09-24 at 07:15 -0700, Dan Nicholson wrote: On Sep 23, 2012 9:59 PM, Yaakov (Cygwin/X) wrote: On 2012-09-23 12:35, Matt Turner wrote: The proto packages install their pc files in $(libdir)/pkgconfig, but this leads to files being installed in /usr/lib32 or /usr/lib64 when there's nothing ABI specific about them. Would it be reasonable to install them to $(prefix)/share/pkgconfig instead? Absolutely NOT. If you do this, then they will be picked up when cross-compiling, adding e.g. -I/usr/include to CFLAGS, which will then cause the build-system's headers to be used instead of the cross-host's. Can you explain how this affects cross-compiling? Unlike /usr/lib/pkgconfig, /usr/share/pkgconfig is meant to be used even when cross-compiling. If you put the *proto.pc in the latter, then cross-compile anything which requires *proto, pkg-config will use the native proto and do one of two things: 1) if PKG_CONFIG_SYSTEM_INCLUDE_DIR is unset, no -I flag will be printed (since by default pkg-config doesn't print -I/-L flags to default search dirs), in which case the cross-compiler will not find the headers (since /usr/include isn't in a cross-compiler's default include search path); 2) or, if PKG_CONFIG_SYSTEM_INCLUDE_DIR is correctly set for cross-compiling, -I/usr/include will be added to CFLAGS, causing anything else in /usr/include (e.g. the build-system's native system headers) to be picked up BEFORE the cross-host's. There is also the matter of xproto and xtrans not being truly cross-platform (e.g. NARROWPROTO and FUNCPROTO in Xfuncproto.h), so each platform anyway needs their own copy. Yaakov Cygwin/X ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/7] dix: Repack ClientRec
Adam Jackson a...@redhat.com writes: That's true, as far as it goes, but I find it less tedious to just ask what the answer is: Right, I'd actually forgotten that you were just using pahole for this. -- keith.pack...@intel.com pgpCUezemdfU7.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Installing proto pc files in /usr/share/pkgconfig?
On 12-09-23 01:35 PM, Matt Turner wrote: Hi Gaetan, The proto packages install their pc files in $(libdir)/pkgconfig, but this leads to files being installed in /usr/lib32 or /usr/lib64 when there's nothing ABI specific about them. Would it be reasonable to install them to $(prefix)/share/pkgconfig instead? Thanks, Matt This has been debated a few times on the list. I think there would be a bigger consensus in favour of it today, but some sticky points would remain. Here is a random excerpt I got from the list: Furthermore, X11/Xfuncproto.h and X11/Xpoll.h (from xproto) and xtrans.pc have system-dependent substitutions, so they cannot be used for cross-compiling. Given the modular nature of the X packaging, and the wide variety of OS/architecture, a per package approach rather than an all or nothing approach might obtain a consensus. Any current issue would not go away by virtue of an eventually single protocol package. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/7] xfree86: Bump video ABI to 14
On 09/20/2012 01:56 PM, Adam Jackson wrote:
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/common/xf86Module.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
index 83f9790..fd90aac 100644
--- a/hw/xfree86/common/xf86Module.h
+++ b/hw/xfree86/common/xf86Module.h
@@ -80,7 +80,7 @@ typedef enum {
* mask is 0x.
*/
#define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4)
-#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(13, 0)
+#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(14, 0)
#define ABI_XINPUT_VERSIONSET_ABI_VERSION(18, 0)
#define ABI_EXTENSION_VERSION SET_ABI_VERSION(7, 0)
#define ABI_FONT_VERSION SET_ABI_VERSION(0, 6)
Given the rest of these changes,
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[XDC 2012] Google+ photo sharing
Hey guys As discussed by a few of us, I have created an event on Google+ which provides an easy way to share all the photos clicked at XDC/Nuremberg by each of us. It is a public event so you can straight away click yes on attended and start adding your photos. Event link: https://plus.google.com/u/0/events/c7so9gpjqa4qg28nuvcufvdq0eo Please let me know if there is any problem or if you feel something is not appropriate. It was great to meet you guys! :D -- Thanks Supreet ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest 0/4] Test speedup patches
Found a bit of time to investigate why the tests are so slow and it turns out the slow testing was caused by unecessary sleeps in the test framework. Patches 1 and 3 get the average test time for very basic tests from ~1500ms down to around 145ms. The other two are auxiliary patches. A bit more time can be shaved off with -noreset, but that currently has to be set by the client, any caller that uses WaitForConnection() will cause a server reset. Not ideal, but I'm too jetlagged to have found a nice solution to this yet. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest 1/4] process: reduce wait time for process termination
Re-try with a constant 10 us until the timeout is reached instead of a
timeout-dependent wait time.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/process.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/process.cpp b/src/process.cpp
index 1a1739a..284ecbd 100644
--- a/src/process.cpp
+++ b/src/process.cpp
@@ -127,14 +127,14 @@ void xorg::testing::Process::Start(const std::string
program, ...) {
}
bool xorg::testing::Process::WaitForExit(unsigned int timeout) {
- for (int i = 0; i 10; i++) {
+ for (int i = 0; i timeout * 100; i++) {
int status;
int pid = waitpid(Pid(), status, WNOHANG);
if (pid == Pid())
return true;
- usleep(timeout * 100);
+ usleep(10);
}
return false;
--
1.7.11.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest 2/4] process: return if waitpid() fails
If the Process is forked after Start(), the child to be terminated isn't
actually the child and we hang forever. Thus, treat ECHILD as success, after
all if the child isn't there it can be seen as terminated.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/process.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/process.cpp b/src/process.cpp
index 284ecbd..57ee35e 100644
--- a/src/process.cpp
+++ b/src/process.cpp
@@ -133,6 +133,8 @@ bool xorg::testing::Process::WaitForExit(unsigned int
timeout) {
if (pid == Pid())
return true;
+else if (pid == -1)
+ return errno == ECHILD;
usleep(10);
}
--
1.7.11.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest 3/4] xserver: don't sleep for a second, 100us is enough
But loop more often. On my machine the average wait time for the server to
start up appears to be ~600 us. Play it safe, usleep for 100us only and then
try again.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/xserver.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/xserver.cpp b/src/xserver.cpp
index d371421..28f2eca 100644
--- a/src/xserver.cpp
+++ b/src/xserver.cpp
@@ -222,7 +222,7 @@ bool xorg::testing::XServer::WaitForDevice(::Display
*display, const std::string
}
void xorg::testing::XServer::WaitForConnections(void) {
- for (int i = 0; i 10; ++i) {
+ for (int i = 0; i 100; ++i) {
Display *test_display = XOpenDisplay(GetDisplayString().c_str());
if (test_display) {
@@ -243,7 +243,7 @@ void xorg::testing::XServer::WaitForConnections(void) {
message += for any errors;
throw std::runtime_error(message);
} else if (pid == 0) {
- sleep(1); /* Give the X server some time to start */
+ usleep(100);
} else if (pid == -1) {
throw std::runtime_error(Could not get status of X server process);
} else {
--
1.7.11.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest 4/4] process: fix compiler warning
../src/process.cpp: In member function ‘bool
xorg::testing::Process::WaitForExit(unsigned int)’:
../src/process.cpp:130:33: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/process.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/process.cpp b/src/process.cpp
index 57ee35e..4deea14 100644
--- a/src/process.cpp
+++ b/src/process.cpp
@@ -127,7 +127,7 @@ void xorg::testing::Process::Start(const std::string
program, ...) {
}
bool xorg::testing::Process::WaitForExit(unsigned int timeout) {
- for (int i = 0; i timeout * 100; i++) {
+ for (unsigned int i = 0; i timeout * 100; i++) {
int status;
int pid = waitpid(Pid(), status, WNOHANG);
--
1.7.11.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Bug#597692: kde-full: Strange mouse cursor behaviour. - Reproducable
On Son, 2012-09-23 at 12:00 +0100, Ben Whyall wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-5 Followup-For: Bug #597692 Dear Maintainer, Hi I have in the last week or so been seeing this problem and the resolution has been to reboot the machine. Any suggestions. Can you try a newer kernel, one based on upstream version 3.5.1 or at least 3.2.25 or newer? Those versions have a fix that might help. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #14 from Alex Deucher ag...@yahoo.com --- (In reply to comment #12) Hi Alex, I recently obtained emachines C6207 desktop PC by accident. Interestingly, I noticed that the mainboard inside has ATI Technologies Radeon Xpress 200 (RS480 + SB400). The mainboard inside is MSI R480M (MS-7145). When I tested the ACPI S3 State resume with the original BIOS (AMI BIOS that shows emachines 'e' logo during POST. The BIOS version displayed is Version 1.05.) of the mainboard, to my surprise, ACPI S3 State resume worked correctly. However, if I flashed MSI R480M mainboard with the BIOS image from MSI (R480M BIOS Version 1.50, Award BIOS), the mainboard will not resume from ACPI S3 State. Note that RS480 is 130nm process version of Radeon Xpress 200 and RS482 is 110nm process shrink version of the same chip with supposedly exact same functionality. I used flashrom (http://www.flashrom.org) to go from AMI to Award. I kept the original BIOS image of the mainboard so I can go back to the original image for testing purposes. Sounds like it may be a bios bug. Does the change I suggested help? -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #13 from Alex Deucher ag...@yahoo.com --- (In reply to comment #11) (In reply to comment #10) try making the following change to radeon_combios_asic_init() in radeon_combios.c in the kernel. Remove the following code: /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) combios_parse_pll_table(dev, table); and see if that helps. I am not saying that I cannot do this, but I am not a Linux kernel developer, so I am not sure how I can make the change, and recompile the kernel. I do have Windows device driver development experience, but I have never done software development with Linux. Keeping that in mind, can you provide me with detailed instructions on how to make the edits and recompile the kernel? 1. download the kernel source. 2. edit drivers/gpu/drm/radeon/radeon_combios.c in the kernel source tree and remove the code in question. 3. build the kernel: make make modules (as root) make modules_install (as root) make install 4. reboot and pick the new kernel in the grub menu -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon/radeon_platform_probe: fix Zaphod mode breakage
Using radeon_platform_probe function breaks the Zaphod mode because it attempts to call xf86AddEntityToScreen multiple times, but nobody calls xf86SetEntityShared prior to that. Consequently, calls for all but first device instance fail. Prior to introduction of platform bus, the logic was that the Probe function would make the entity sharable, which would cause Xserver to later make it shared prior to adding it to screen. With the platform bus loading, add to screen happens in the probe function so we have to make it shared there. Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com --- src/radeon_probe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/radeon_probe.c b/src/radeon_probe.c index b1471af..fef5d81 100644 --- a/src/radeon_probe.c +++ b/src/radeon_probe.c @@ -278,6 +278,7 @@ radeon_platform_probe(DriverPtr pDriver, scr_flags = XF86_ALLOCATE_GPU_SCREEN; pScrn = xf86AllocateScreen(pDriver, scr_flags); +xf86SetEntityShared(entity_num); xf86AddEntityToScreen(pScrn, entity_num); if (!radeon_kernel_mode_enabled(pScrn, dev-pdev)) -- 1.7.12 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 55296] New: [KMS] Extremely low performance of XDrawImageString
https://bugs.freedesktop.org/show_bug.cgi?id=55296 Priority: medium Bug ID: 55296 Assignee: xorg-driver-ati@lists.x.org Summary: [KMS] Extremely low performance of XDrawImageString QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mihail.zen...@gmail.com Hardware: x86 (IA32) Status: NEW Version: unspecified Component: Driver/Radeon Product: xorg Created attachment 67652 -- https://bugs.freedesktop.org/attachment.cgi?id=67652action=edit test.c I have performance problem in simple terminal apps like st (st.suckless.org) that render text without xft. With NoAccel 1 or RenderAccel 0 problem gone. I write simple test and have result: 1. default x.org configuration: 2000 ms 2. with RenderAccel 0: 70-170 ms 3. with NoAccel 1: 18-30 ms I also run gtkperf -ac1000 and see many test faster with RenderAccel 0. Default x.org configuration: GtkEntry - time: 0,22 GtkComboBox - time: 14,89 GtkComboBoxEntry - time: 17,33 GtkSpinButton - time: 0,39 GtkProgressBar - time: 0,42 GtkToggleButton - time: 0,36 GtkCheckButton - time: 0,34 GtkRadioButton - time: 1,90 GtkTextView - Add text - time: 12,98 GtkTextView - Scroll - time: 2,31 GtkDrawingArea - Lines - time: 15,77 GtkDrawingArea - Circles - time: 9,08 GtkDrawingArea - Text - time: 4,74 GtkDrawingArea - Pixbufs - time: 1,84 --- Total time: 82,59 With RenderAccel 0: GtkEntry - time: 0,22 GtkComboBox - time: 10,63 GtkComboBoxEntry - time: 11,35 GtkSpinButton - time: 0,31 GtkProgressBar - time: 0,31 GtkToggleButton - time: 0,34 GtkCheckButton - time: 0,34 GtkRadioButton - time: 0,82 GtkTextView - Add text - time: 13,21 GtkTextView - Scroll - time: 2,51 GtkDrawingArea - Lines - time: 28,74 GtkDrawingArea - Circles - time: 9,25 GtkDrawingArea - Text - time: 8,58 GtkDrawingArea - Pixbufs - time: 2,16 --- Total time: 88,78 HD6770, kernel-3.5, xorg-server-1.12.4, libdrm-2.4.39, xf86-video-ati-6.14.6 -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
