Is there any client program which can test what extension the server support?
Sorry for disturbing everyone. May someone tell me is there any client program that can test what extension the X server supports? I try X -extension XX command,it just shows the extensions that can be run-time disabled. However I am going to test another X server which runs in windows and seems have no support for CLI parameters. So is there some CLIENT program that can test what extension the X server supports? As far as I know,there is a request format in X protocol that can query what extension the X server supports(Request: QueryExtenion in wireshark). So if there is no compiled client program/package, is it hard to archieve the goal by coding ? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Is there any client program which can test what extension the server support?
On Thu, Nov 17, 2011 at 1:36 PM, Adam Q wrote: Sorry for disturbing everyone. May someone tell me is there any client program that can test what extension the X server supports? xdpyinfo Regards, Tormod ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Simple test
On Friday, February 25, 2011 02:47:47 pm Pat Kane did opine: Hi Gene, Could run these simple tests: ssh -Y -l gene shop xdpyinfo About 1000 lines of output, I didn't note any errors, how much of it do you need? Here is the first 150 or so lines: gene@shop:~$ xdpyinfo name of display:localhost:10.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10605000 X.Org version: 1.6.5 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x2e0003e, revert to PointerRoot number of extensions:31 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Multi-Buffering NV-CONTROL NV-GLX RANDR RECORD RENDER SECURITY SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-VidModeExtension XINERAMA XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1680x1050 pixels (431x272 millimeters) resolution:99x98 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x154 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0x7ac07f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskEnterWindowMask LeaveWindowMask PointerMotionMaskKeymapStateMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals:84 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x22 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits etc,etc if that works, then: ssh -Y -l gene shop xclock Opens a small, no second hand, colored analog clock, no errors reported on the background cli. ssh -Y -l gene shop xterm Works, opens an xterm window, no errors reported on the background cli. As usual, its small, and the font is quite small too. Thanks Pat. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) http://tinyurl.com/ddg5bz The most happy marriage I can imagine to myself would be the union of a deaf man to a blind woman. -- Samuel Taylor Coleridge ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)
Hi all. I've somehow broken 3D accel on my system. I'm not quite sure if it was me, my distro, if there is a regression, or if my hardware has issues. I did a fairly major system update ( Sabayon ) ... and rebuilt manually: 2.6.37 kernel with modesetting mesa from git libdrm from git latest radeon firmware Now I'm getting: [ 44.612719] [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) [ 44.612724] radeon :01:05.0: disabling GPU acceleration ... and obviously 3D accel is no longer working. I've also tried with a 2.6.36 kernel with modesetting, which was working previously ... it gives the same error now. Any ideas? Thanks for any help :) Dan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
ping (test: ignore)
Sorry for the noice. kind regards, Kai-Uwe ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Bounce test – please ignore
Hi, somebody on this list appears to forward their mail to a ticketing system which spams everybody who mails the list. Earlier attempts at working out who the responsible part is has failed, so I have modified mailman a little bit to prepend the recipient to the subject field. Hopefully this should allow us to work out who the responsible part is and unsubscribe that address. Sorry for the noise. Regards, -- Tollef Fog Heen, fd.o sitewrangler UNIX is user friendly, it's just picky about who its friends are ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Bounce test – please ignore
]] Tollef Fog Heen | Ok, I did a silly error in that patch to mailman, hopefully the second | try should work. Again, sorry for the noise. I just found the address and unsubscribed it, so you should no longer see mails from a ticketing system when you mail x...@. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] dri2: Fix order of operations issue in __glXdriSwapEvent test.
On Thu, 21 Jan 2010 10:31:04 -0800, Eric Anholt e...@anholt.net wrote: -if (!drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK) +if (!(drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK)) Reviewed-by: Keith Packard kei...@keithp.com I'll note that using 'drawable' as a name here is sub-optimal. Also the code in glxcmds.c that sets eventMask has an inaccurate comment, and also fails to validate the event mask to make sure it doesn't include bits which aren't allowed. -- keith.pack...@intel.com pgptA1WcY1uAu.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
test
test ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xrandr: Remove test against RANDR_MAJOR/RANDR_MINOR, already done by configure script
Le 04/11/2009 14:28, Yann Droneaud a écrit : xrandr.c uses structures defined inX11/extensions/Xrandr.h provided by 'libXrandr' package but tests structures availability through RANDR_MAJOR/RANDR_MINOR defined inX11/extensions/randr.h provided by 'randrproto' package. Sometimes they are not in sync so it's safer to rely on checks made by configure script through pkg-config. In my test case, XRRPanning structure is not defined in Xrandr.h, RANDR_MAJOR is 1 and RANDR_MINOR 2 but xrandr.c try to use it anyway. (for the record, XRRPanning was added in libXrandr-1.2.91). Pushed to master. Don't forget to sign-off your patches next time :) Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How to test contribute my kbd layout, in xkb, for Tamil?
: Hi all, I'm interested to contribute a keyboard map, in Unicode, for the Tamil language, called VUTAM Type_As_You_Write. Even though in the present encoding scheme of Unicode, for tamil, it requires an intelligent KBD driver, for the time being it could be restricted to the present capability of XKB. Once the encoding scheme is ratified to suit single code for a key, it could be modified to suit the then situation. I've made the above kbd layout for Tamil, called VUTAM. Is there a way to make xkb recognise it, so that it could be tested? (by copying it to some .xkb.symbols folder in my home folder, or something similar?). I'm awaiting a favourable response. Thanking You, V.Ramasami, From Aruppukottai, TamilNadu, India. : PS: (I) I've contributed to SCIM, usable via M17N bridge. I've also contributed to NHM writer, TakthiNT and KeytransU for windows OS. (II) I use Ubuntu 8.10. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to test contribute my kbd layout, in xkb, for Tamil?
veerasami wrote: I'm interested to contribute a keyboard map, in Unicode, for the Tamil language, called VUTAM Type_As_You_Write. X.Org no longer maintains keyboard maps, but relies on those provided by our sister project xkeyboard-config: http://www.freedesktop.org/wiki/Software/XKeyboardConfig Their process for contributing keyboard maps is described at: http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development I've made the above kbd layout for Tamil, called VUTAM. Is there a way to make xkb recognise it, so that it could be tested? (by copying it to some .xkb.symbols folder in my home folder, or something similar?). Can't you just add it to the /usr/share/X11/xkb files? (You'll need to use root to do so.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to test contribute my kbd layout, in xkb, for Tamil?
: Thank you Cooper, I've successfully copied the layout file to the symbols folder of xkb; but the layout is not recognised by xkb, even after a restart. Any other solution? VR. : PS: I'll try with wiki too. -Original Message- From: Alan Coopersmith alan.coopersm...@sun.com To: veerasami v.ramas...@gmail.com Cc: xorg xorg@lists.freedesktop.org Subject: Re: How to test contribute my kbd layout, in xkb, for Tamil? Date: Sat, 07 Nov 2009 08:35:58 -0800 veerasami wrote: I'm interested to contribute a keyboard map, in Unicode, for the Tamil language, called VUTAM Type_As_You_Write. X.Org no longer maintains keyboard maps, but relies on those provided by our sister project xkeyboard-config: http://www.freedesktop.org/wiki/Software/XKeyboardConfig Their process for contributing keyboard maps is described at: http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development I've made the above kbd layout for Tamil, called VUTAM. Is there a way to make xkb recognise it, so that it could be tested? (by copying it to some .xkb.symbols folder in my home folder, or something similar?). Can't you just add it to the /usr/share/X11/xkb files? (You'll need to use root to do so.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xrandr: Remove test against RANDR_MAJOR/RANDR_MINOR, already done by configure script
Le 04/11/2009 14:28, Yann Droneaud a écrit : xrandr.c uses structures defined inX11/extensions/Xrandr.h provided by 'libXrandr' package but tests structures availability through RANDR_MAJOR/RANDR_MINOR defined inX11/extensions/randr.h provided by 'randrproto' package. Sometimes they are not in sync so it's safer to rely on checks made by configure script through pkg-config. In my test case, XRRPanning structure is not defined in Xrandr.h, RANDR_MAJOR is 1 and RANDR_MINOR 2 but xrandr.c try to use it anyway. (for the record, XRRPanning was added in libXrandr-1.2.91). configure.ac deps on xrandr = 1.3. Reviewed-by: Rémi Cardona r...@gentoo.org I'll push it to master in a few days if no-one objects. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
My savage test machine is now dead - last resend of patches
Two weeks ago, my home computer with the integrated ProSavageDDR video
chipset died on me. After several attempts to diagnose the problem, it
seems that the mainboard itself is damaged. So I built myself a new
machine with an Intel i915 video chipset. Therefore I am no longer able
to develop or test patches for the savage driver. Attached are the last
two patches that were not yet committed to the git repository. I am
resending them because after all this time, the git commit access I
requested was still not granted (but is now useless).
--
perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From f4929b64da2ebc2adaabce7a5da716026449b9d9 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= a...@karlalex.palosanto.com
Date: Sat, 11 Apr 2009 19:12:31 -0500
Subject: [PATCH] Implement use of Mastered Image Transfer through AGP for
UploadToScreen EXA acceleration.
Under some conditions (documented in this patch), the UploadToScreen
implementation can make use of the AGP scratch buffer used for XVideo as a
convenient source for Mastered Image Transfer. The previous implementation is
still available as a fallback for when AGP acceleration is not possible. This
requires the AGP scratch buffer to be persistent, so the XVideo code is also
made aware of an existing DRM mapping for the scratch buffer.
---
man/savage.man |6 -
src/savage_exa.c | 67 ++-
src/savage_video.c | 11 ++--
3 files changed, 78 insertions(+), 6 deletions(-)
diff --git a/man/savage.man b/man/savage.man
index 822a233..a1cbb1e 100644
--- a/man/savage.man
+++ b/man/savage.man
@@ -180,7 +180,7 @@ and twister (use BCI for Xv); off for savage4 (do not use
the BCI for Xv).
Instructs the BCI Xv pixel formatter to use AGP memory as a scratch buffer.
Ordinarily the BCI formatter uses a an area in framebuffer memory to hold
YV12 planar data to be converted for display. This requires a somewhat
expensive
-upload of YV12 data to framebuffer memory. The \*qAGPforXv\*q causes the BCI
+upload of YV12 data to framebuffer memory. The \*qAGPforXv\*q option causes
the BCI
formatter to place the YV12 data in AGP memory instead, which can be uploaded
faster than the framebuffer. Use of this option cuts upload overhead by 25%
according to benchmarks. This option also smooths out most of the shearing
@@ -189,6 +189,10 @@ present when using BCI for pixel conversion. Currently
this option is
and is disabled by default. Video width restrictions that apply to
\*qBCIforXv\*q
also apply here. Only valid when \*qDRI\*q and \*qBCIforXv\*q are both active,
and only on AGP chipsets. Default: \*qoff\*q.
+.br
+If \*qAccelMethod\*q is set to \*qEXA\*q and \*qAGPforXv\*q is enabled, then
the
+driver will also attempt to reuse the AGP scratch buffer for UploadToScreen
+acceleration.
.TP
.BI Option \*qAGPMode\*q \*q integer \*q
Set AGP data transfer rate.
diff --git a/src/savage_exa.c b/src/savage_exa.c
index 538e000..08524f0 100644
--- a/src/savage_exa.c
+++ b/src/savage_exa.c
@@ -463,10 +463,73 @@ SavageUploadToScreen(PixmapPtr pDst, int x, int y, int w,
int h, char *src, int
BCI_GET_PTR;
int i, j, dwords, queue, Bpp;
unsigned int cmd;
-CARD32 * srcp;
+CARD32 * srcp;
+unsigned int dst_pitch;
+unsigned int dst_yoffset;
+int agp_possible;
+exaWaitSync(pDst-drawable.pScreen);
+
Bpp = pDst-drawable.bitsPerPixel / 8;
+/* Test for conditions for AGP Mastered Image Transfer (MIT). AGP memory
+ needs to be available, the XVideo AGP needs to be enabled, the
+ framebuffer destination must be a multiple of 32 bytes, and the source
+ pitch must span the entirety of the destination pitch. This last
+ condition allows the code to consider this upload as equivalent to a
+ plain memcpy() call. */
+dst_pitch = exaGetPixmapPitch(pDst);
+dst_yoffset = exaGetPixmapOffset(pDst) + y * dst_pitch;
+agp_possible =
+(!psav-IsPCI psav-drmFD 0 psav-DRIServerInfo != NULL
+psav-DRIServerInfo-agpXVideo.size 0
+x == 0 src_pitch == dst_pitch w * Bpp == dst_pitch
+(dst_yoffset 0x1f) == 0);
+
+if (agp_possible) {
+ SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
+if (pSAVAGEDRIServer-agpXVideo.map != NULL ||
+0 = drmMap( psav-drmFD,
+ pSAVAGEDRIServer-agpXVideo.handle,
+ pSAVAGEDRIServer-agpXVideo.size,
+ pSAVAGEDRIServer-agpXVideo.map)) {
+
+unsigned char * agpMap = pSAVAGEDRIServer-agpXVideo.map;
+unsigned int agpOffset = drmAgpBase(psav-drmFD) +
pSAVAGEDRIServer-agpXVideo.offset;
+unsigned int bytesTotal = dst_pitch * h;
+
+while (bytesTotal 0) {
+unsigned int bytesTransfer =
+(bytesTotal pSAVAGEDRIServer-agpXVideo.size
XORG_MACROS_VERSION test is filled with hate
I think these lines, when added to configure.ac don't do what they're intended to do: m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.2) I run autogen.sh in, for example, app/rendercheck as: CC=gcc ACLOCAL=aclocal -I /opt/xorg-master-x86_64/share/aclocal sh ./autogen.sh --prefix=/opt/xorg-master-x86_64 --libdir=/opt/xorg-master-x86_64/lib64 --disable-dmx --disable-xvfb --disable-xnest --disable-xwin --disable-xgl --disable-xglx --disable-xegl --disable-kdrive --disable-xprint --enable-glx --enable-glx-tls --enable-dri CFLAGS=-momit-leaf-frame-pointer -march=core2 The xorg-macros.m4 in /opt/xorg-master-x86_64/share/aclocal is version 1.2.1: [...@oscar rendercheck]$ grep 1.2. /opt/xorg-master-x86_64/share/aclocal/xorg-macros.m4 [XORG_MACROS_version=1.2.1 # Minimum version: 1.2.0 # Minimum version: 1.2.0 But I get the error message: checking if xorg-macros used to generate configure is at least 1.2... configure: error: configure built with too old of a version of xorg-macros.m4 - requires version 1.1.0 or newer My first question is WTF? My second question is do people who commit changes to the build system even test that their changes continue to build? About once a month I have to chase down a build failure caused by something stupid. It's really frustrating. signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XORG_MACROS_VERSION test is filled with hate
On Tue, Jan 20, 2009 at 11:28 AM, Ian Romanick i...@freedesktop.org wrote: I think these lines, when added to configure.ac don't do what they're intended to do: m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.2) One thing is that the AC_FATAL should probably be m4_fatal so that it bombs when aclocal runs, not when the user runs ./configure. But that's besides the point here. I run autogen.sh in, for example, app/rendercheck as: CC=gcc ACLOCAL=aclocal -I /opt/xorg-master-x86_64/share/aclocal sh ./autogen.sh --prefix=/opt/xorg-master-x86_64 --libdir=/opt/xorg-master-x86_64/lib64 --disable-dmx --disable-xvfb --disable-xnest --disable-xwin --disable-xgl --disable-xglx --disable-xegl --disable-kdrive --disable-xprint --enable-glx --enable-glx-tls --enable-dri CFLAGS=-momit-leaf-frame-pointer -march=core2 The xorg-macros.m4 in /opt/xorg-master-x86_64/share/aclocal is version 1.2.1: [...@oscar rendercheck]$ grep 1.2. /opt/xorg-master-x86_64/share/aclocal/xorg-macros.m4 [XORG_MACROS_version=1.2.1 # Minimum version: 1.2.0 # Minimum version: 1.2.0 But I get the error message: checking if xorg-macros used to generate configure is at least 1.2... configure: error: configure built with too old of a version of xorg-macros.m4 - requires version 1.1.0 or newer Are you running this from a clean checkout? It would seem that the version of XORG_MACROS_VERSION in aclocal.m4 (what actually gets into configure) is an older version. XORG_MACROS_VERSION seems to work for me. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XORG_MACROS_VERSION test is filled with hate
On Tue, 2009-01-20 at 11:28 -0800, Ian Romanick wrote: I run autogen.sh in, for example, app/rendercheck as: CC=gcc ACLOCAL=aclocal -I /opt/xorg-master-x86_64/share/aclocal sh ./autogen.sh --prefix=/opt/xorg-master-x86_64 --libdir=/opt/xorg-master-x86_64/lib64 --disable-dmx --disable-xvfb --disable-xnest --disable-xwin --disable-xgl --disable-xglx --disable-xegl --disable-kdrive --disable-xprint --enable-glx --enable-glx-tls --enable-dri CFLAGS=-momit-leaf-frame-pointer -march=core2 aclocal = fail. It seems that aclocal looks in the default places before the places specified by -I. The --acdir option makes it look in the specified place only. Really? Could we get an option that does the sensible thing of looking in the specified directory FIRST, then look in the default places? sigh... Still look for a suggestion of how to make the build work on a system with distro development packages installed. It seems like a logical thing to build one version of the X.org stack while a different version is installed. signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XORG_MACROS_VERSION test is filled with hate
On Tue, 2009-01-20 at 11:48 -0800, Dan Nicholson wrote: On Tue, Jan 20, 2009 at 11:37 AM, Ian Romanick i...@freedesktop.org wrote: On Tue, 2009-01-20 at 11:28 -0800, Ian Romanick wrote: I run autogen.sh in, for example, app/rendercheck as: CC=gcc ACLOCAL=aclocal -I /opt/xorg-master-x86_64/share/aclocal sh ./autogen.sh --prefix=/opt/xorg-master-x86_64 --libdir=/opt/xorg-master-x86_64/lib64 --disable-dmx --disable-xvfb --disable-xnest --disable-xwin --disable-xgl --disable-xglx --disable-xegl --disable-kdrive --disable-xprint --enable-glx --enable-glx-tls --enable-dri CFLAGS=-momit-leaf-frame-pointer -march=core2 aclocal = fail. It seems that aclocal looks in the default places before the places specified by -I. The --acdir option makes it look in the specified place only. Really? Could we get an option that does the sensible thing of looking in the specified directory FIRST, then look in the default places? sigh... Are you sure about that? I do X development all the time with ACLOCAL=aclocal -I/opt/gfx/share/aclocal, and it does the right thing. $ aclocal --verbose -I /opt/gfx/share/aclocal ... aclocal: found macro XORG_MACROS_VERSION in /opt/gfx/share/aclocal/xorg-macros.m4: 44 ... aclocal: ignoring macro XORG_MACROS_VERSION in /usr/share/aclocal/xorg-macros.m4: 43 Thank you for the tip. The problem was rendercheck's autogen.sh, and your suggestion helped me track this down. See commit 37eac61e71a313df9927ca2a41ef49bda92fd9c6 in app/rendercheck. signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to test GLX performance?
Alan James Caruana wrote: Hi, I am writing an X Server for the company I work for, and I have implemented the GLX extension. I know that it works because 'glxinfo' gives output, 'glxgears' works, and some sample GLX programs I downloaded also do work, but now I want to test for performance. What programs/methods exist to test the performance of the GLX ? Try the Phoronix Test Suite. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How to test GLX performance?
Hi, I am writing an X Server for the company I work for, and I have implemented the GLX extension. I know that it works because 'glxinfo' gives output, 'glxgears' works, and some sample GLX programs I downloaded also do work, but now I want to test for performance. What programs/methods exist to test the performance of the GLX ? Thanks Alan J. Caruana ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Thursday 27 November 2008, Peter Hutterer wrote: On Thu, Nov 27, 2008 at 11:49:58AM +, Magnus Kessler wrote: Tested-by: Magnus Kessler [EMAIL PROTECTED] That patch works fine for me. Thanks for fixing this. However, I see that the same unchecked access to p-key-xkbInfo exists in other functions in xkbEvents.c as well, notably XkbSendStateNotify and XkbSendControlsNotify (where it might be guarded by the xkb_interest field?), XkbSendMapNotify, XkbHandleBell and XkbSendActionMessage. It seems clear from the naming (kbd) of the DeviceIntPtr parameter in those cases that above functions are intended to be called only for regular keyboard devices? Is this guaranteed? IIRC, these functions were always called with the VCK so that wouldn't cause any problems. We can't easily do that anymore, so the bail out if it's not a keyboard is the best approach. I'll amend the patch to fix the other occurances, but it'll take me a few days. If you get to it on the weekend, I'll be happy to review. Cheers, Peter Looks like you beat me to it with with the patch in your latest patch-set for 1.6. Please apply to main as well. Cheers, Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Wednesday 26 November 2008, Peter Hutterer wrote:
On Wed, Nov 19, 2008 at 10:07:59PM +, Magnus Kessler wrote:
With the latest server and synaptics driver from git I can reliably
crash the server by starting
xinput test SynPS2/2 Synaptics Touchpad
and then clicking the any of the physical buttons or tapping the pad to
simulate a click.
How about this one?
From 87f5aa009d65e44f516bfc0168249ea29433b2b4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer [EMAIL PROTECTED]
Date: Wed, 26 Nov 2008 12:20:00 +1000
Subject: [PATCH] xkb: don't attempt to filter events for devices without
key classes.
Reported by Magnus Kessler.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
xkb/xkbEvents.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 151849c..02565a4 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -819,7 +819,8 @@ XkbSrvInfoPtr xkbi;
pXDev = inputInfo.keyboard;
}
-xkbi= pXDev-key-xkbInfo;
+xkbi= (pXDev-key) ? pXDev-key-xkbInfo : NULL;
+
if ( pClient-xkbClientFlags _XkbClientInitialized ) {
if ((xkbDebugFlags0x10)
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -841,6 +842,10 @@ XkbSrvInfoPtrxkbi;
(_XkbIsReleaseEvent(xE[0].u.u.type)) ) {
return False;
}
+
+if (!xkbi)
+return True;
+
if ((pXDev-deviceGrab.grab != NullGrab)
pXDev-deviceGrab.fromPassiveGrab
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -884,6 +889,9 @@ XkbSrvInfoPtr xkbi;
else {
register CARD8 type;
+if (!xkbi)
+return True;
+
for (i=0;inEvents;i++) {
type= xE[i].u.u.type;
if ((xkbDebugFlags0x4)
Tested-by: Magnus Kessler [EMAIL PROTECTED]
That patch works fine for me. Thanks for fixing this.
However, I see that the same unchecked access to p-key-xkbInfo exists in
other functions in xkbEvents.c as well, notably XkbSendStateNotify and
XkbSendControlsNotify (where it might be guarded by the xkb_interest
field?), XkbSendMapNotify, XkbHandleBell and XkbSendActionMessage.
It seems clear from the naming (kbd) of the DeviceIntPtr parameter in
those cases that above functions are intended to be called only for regular
keyboard devices? Is this guaranteed?
Cheers,
Magnus
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Thu, Nov 27, 2008 at 11:49:58AM +, Magnus Kessler wrote: Tested-by: Magnus Kessler [EMAIL PROTECTED] That patch works fine for me. Thanks for fixing this. However, I see that the same unchecked access to p-key-xkbInfo exists in other functions in xkbEvents.c as well, notably XkbSendStateNotify and XkbSendControlsNotify (where it might be guarded by the xkb_interest field?), XkbSendMapNotify, XkbHandleBell and XkbSendActionMessage. It seems clear from the naming (kbd) of the DeviceIntPtr parameter in those cases that above functions are intended to be called only for regular keyboard devices? Is this guaranteed? IIRC, these functions were always called with the VCK so that wouldn't cause any problems. We can't easily do that anymore, so the bail out if it's not a keyboard is the best approach. I'll amend the patch to fix the other occurances, but it'll take me a few days. If you get to it on the weekend, I'll be happy to review. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Wed, Nov 19, 2008 at 10:07:59PM +, Magnus Kessler wrote:
With the latest server and synaptics driver from git I can reliably crash
the server by starting
xinput test SynPS2/2 Synaptics Touchpad
and then clicking the any of the physical buttons or tapping the pad to
simulate a click.
How about this one?
From 87f5aa009d65e44f516bfc0168249ea29433b2b4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer [EMAIL PROTECTED]
Date: Wed, 26 Nov 2008 12:20:00 +1000
Subject: [PATCH] xkb: don't attempt to filter events for devices without key
classes.
Reported by Magnus Kessler.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
xkb/xkbEvents.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 151849c..02565a4 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -819,7 +819,8 @@ XkbSrvInfoPtr xkbi;
pXDev = inputInfo.keyboard;
}
-xkbi= pXDev-key-xkbInfo;
+xkbi= (pXDev-key) ? pXDev-key-xkbInfo : NULL;
+
if ( pClient-xkbClientFlags _XkbClientInitialized ) {
if ((xkbDebugFlags0x10)
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -841,6 +842,10 @@ XkbSrvInfoPtr xkbi;
(_XkbIsReleaseEvent(xE[0].u.u.type)) ) {
return False;
}
+
+if (!xkbi)
+return True;
+
if ((pXDev-deviceGrab.grab != NullGrab)
pXDev-deviceGrab.fromPassiveGrab
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -884,6 +889,9 @@ XkbSrvInfoPtr xkbi;
else {
register CARD8 type;
+if (!xkbi)
+return True;
+
for (i=0;inEvents;i++) {
type= xE[i].u.u.type;
if ((xkbDebugFlags0x4)
--
1.6.0.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xinput test crashes server when touchpad clicked
With the latest server and synaptics driver from git I can reliably crash
the server by starting
xinput test SynPS2/2 Synaptics Touchpad
and then clicking the any of the physical buttons or tapping the pad to
simulate a click.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f808f66b6f0 (LWP 22831)]
XkbFilterEvents (pClient=0x46d2e80, nEvents=1, xE=0x45b5580) at
xkbEvents.c:822
/usr/src/debug/x11-base/xorg-server-/xorg-
server-/xkb/xkbEvents.c:822:23919:beg:0x554d35
(gdb) backtrace
#0 XkbFilterEvents (pClient=0x46d2e80, nEvents=1, xE=0x45b5580) at
xkbEvents.c:822
#1 0x004505ad in WriteEventsToClient (pClient=0x46d2e80, count=1,
events=0x45b5580) at events.c:5938
#2 0x004546c5 in TryClientEvents (client=0x46d2e80, dev=value
optimized out, pEvents=0x45b5580, count=1, mask=2540292784,
filter=41155024, grab=0x0) at events.c:1985
#3 0x0045532c in DeliverEventsToWindow (pDev=0x2ac7d40,
pWin=0x27b42f0, pEvents=0x45b5580, count=1, filter=4, grab=0x0, mskidx=2) at
events.c:2122
#4 0x00456f25 in DeliverDeviceEvents (pWin=0x27b42f0, xE=0x45b5580,
grab=0x0, stopAt=0x0, dev=0x2ac7d40, count=1) at events.c:2420
#5 0x00537ecd in ProcessOtherEvent (xE=0x45b5580, device=0x2ac7d40,
count=1) at exevents.c:1126
#6 0x005603cd in ProcessKeyboardEvent (xE=0x45b5580,
keybd=0x2ac7d40, count=1) at xkbPrKeyEv.c:208
#7 0x004cd11c in mieqProcessInputEvents () at mieq.c:378
#8 0x00490669 in ProcessInputEvents () at xf86Events.c:174
#9 0x0044ae21 in Dispatch () at dispatch.c:363
#10 0x00430f3d in main (argc=9, argv=0x7fff9769d128, envp=value
optimized out) at main.c:384
The server dies because of a null pointer in
Bool
XkbFilterEvents(ClientPtr pClient,int nEvents,xEvent *xE)
{
int i, button_mask;
DeviceIntPtr pXDev = inputInfo.keyboard;
XkbSrvInfoPtr xkbi;
if (xE-u.u.type EXTENSION_EVENT_BASE)
{
pXDev = XIGetDevice(xE);
if (!pXDev)
pXDev = inputInfo.keyboard;
}
xkbi= pXDev-key-xkbInfo;
^
| key is NULL on crash
Why would a touchpad be treated as a keyboard here?
Regards,
Magnus Kessler
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [sugar] rendering test
On Tue, 2008-09-30 at 21:30 +0200, Bernie Innocenti wrote: Michel Dänzer wrote: On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. I was remembering the code. As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? ShmPutImage is still accelerated though (also, that commit is only in 1.5, not 1.4). What kind of cleanup do you have in mind? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [sugar] rendering test
On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. excessive migration of pixmaps to the framebuffer, and so on. Migration overhead is indeed often the cause of EXA performance issues. Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
