Re: WM_CLASS purpose?
For example, let's suppose I have a window manager somebox that has taskbar, dock, menus for starting applications/switching workspaces and configuration dialogs. What should be res_name/res_class for each of them? An X client should have a single name and class. You shouldn't use different values for different windows within a single client (however, it's possible for a single process to contain multiple clients by calling XtOpenApplication() multiple times; each client has a separate X connection and XtAppContext). So, if _you_ write a window manager somebox what values would you use for res_name and res_class in the above example? ___ 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: Dell D520 and strange X coordinates
On Sun, Oct 14, 2012 at 02:59:27PM +0200, Thomas L?bking wrote: On Mittwoch, 10. Oktober 2012 22:17:47 CEST, Michael George wrote: I have Fedora 17 installed on a Dell Latitude D520. I can boot it into runlevel 5 just fine as a laptop and I can run the default KDE window manager. I like to use CTWM, so I use the Custom option. It all works fine. When I put it into the docking station, I have two video outputs, one VGA and one DVI. If I boot into the default desktop, they both work as expected. However, if I start into the Custom desktop, my ctwm desktop comes up fine, but it seems that there are 1024 pixels of width off to the left of the left screen that isn't visible. Thomas, thank you for your response. I have been busy at work and this is a side-endeavor, so I haven't had a chance to look at the system until today. What's the output of xrandr -q? This is the output of xrandr -q with ctwm running: - Screen 0: minimum 320 x 200, current 3584 x 1024, maximum 4096 x 4096 LVDS1 connected (normal left inverted right x axis y axis) 1024x768 60.0 + 800x60060.3 56.2 640x48059.9 VGA1 connected 1280x1024+1024+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1280x800 74.9 59.8 1152x864 75.0 1280x768 74.9 59.9 1024x768 75.1 70.1 60.0 1024x576 60.0 800x60072.2 75.0 60.3 56.2 848x48060.0 640x48072.8 75.0 60.0 720x40070.1 DVI1 connected 1280x1024+2304+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1280x800 74.9 59.9 1152x864 75.0 1280x768 74.9 60.0 1024x768 75.1 70.1 60.0 1024x576 60.0 800x60072.2 75.0 60.3 56.2 848x48060.0 640x48072.8 75.0 60.0 720x40070.1 TV1 unknown connection (normal left inverted right x axis y axis) 848x48059.9 + 640x48059.9 + 1024x768 59.9 800x60059.9 - I think it's the LVDS1 screen that is the problem. The output looks very similar with KDE running, but it must somehow ignore that first screen. I do not notice the TV1 output being a problem. CTWM seems err... matured (aka old) - it can pot. not cope with xrandr driven multiscreen setups. CTWM just works with X11, so the config issue is in X11. I am using CTWM with no problems under gentoo and have been for years. Can you move the pointer out of the visible area and to you have a dead area on the right (ie. is the desktop just shifted to the left?) No, to look at the screen it looks normal, but all the stuff that is placed at coordinates in the first 1024 pixels to the left is not visible. Thank you again for your assistance! -- -Michael Rident stolidi verba Latina. -Ovid ___ 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: Dell D520 and strange X coordinates
On 10/30/12 8:36 AM, Michael George wrote: On Sun, Oct 14, 2012 at 02:59:27PM +0200, Thomas L?bking wrote: What's the output of xrandr -q? This is the output of xrandr -q with ctwm running: - Screen 0: minimum 320 x 200, current 3584 x 1024, maximum 4096 x 4096 LVDS1 connected (normal left inverted right x axis y axis) 1024x768 60.0 + 800x60060.3 56.2 640x48059.9 VGA1 connected 1280x1024+1024+0 (normal left inverted right x axis y axis) 376mm x 301mm See, this here is saying 1280x1024 box, horizontal offset 1024, vertical offset 0. How are you configuring this display? Are you just letting xserver decide how to place things, or is there something in your session explicitly configuring RANDR? If the latter, whatever it is, it's broken. - ajax ___ 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: Resolution problem with AMD Radeon 5450/6350 and Dell U3011
2012/10/31 Alex Deucher alexdeuc...@gmail.com: On Tue, Oct 30, 2012 at 6:35 AM, Johan Mazel johan.ma...@gmail.com wrote: Hi I am trying to use a Dell U3011 (30 inches IPS screen) on a Dell Optiplex 990 with an AMD HD 5450/6350. I am using Debian Testing and Ubuntu 12.10 with Xorg's ATI driver. The respective xserver-xorg-video-radeon package versions for these two OSes are: 1:6.14.4-5 and 1.6.99.99~git20120913.8637f772-0ubuntu1. Theoretically, the HD5450 is able to display the screen's native resolution (2560x1600) according to http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-3000/hd-3400/Pages/ati-radeon-hd-3400-specifications.aspx provided that a dual-link DVI cable is used, which is the case. Unfortunately, the biggest available resolution is 1600x1200 on Debian Testing and 1920x1200 for Ubuntu 12.10. I think there is a discrepancy between what Xorg probes through the graphic card as the biggest resolution available (1600x1200, starting line 438 in Xorg.0.log_debian_xorg) and what is actually announced by the monitor (2560x1600, eg.: line 587 (and further) in Xorg.0.log_debian_xorg). This discrepancy is also present in Ubuntu's Xorg log files. I am guessing that Ubuntu uses a slightly newer version of the driver and therefore handle slightly better the resolution. However, I have no idea regarding the cause of this discrepancy. While the chip is cable of dual link, dual link is only available if the oem wired up a dual link DVI connector on your card. If the oem used a single link DVI connector, you will be limited to single link DVI. I suspect that is what's happening. Alex Are you sure that this would explain both problems (I mean with Debian and Ubuntu) ? One hypothesis might be that the package used by Ubuntu 12.10 fixes the software problem present in Debian's package version while the hardware problems remains... Johan ___ 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: Resolution problem with AMD Radeon 5450/6350 and Dell U3011
I finally found some documentation : http://i.dell.com/sites/content/shared-content/data-sheets/en/Documents/optiplex-990-tech-guidebook-final-1-4.pdf. In a short word, for this particular Dell model, Optiplex 990, HD6350 is stuck at 1920x1200. I need to upgrade to HD6450 if I want 2560x1600. This is also the case for Optiplex 960 with an AMD HD 3450 (cf https://www.dell.com/downloads/global/products/optix/en/desktop-optiplex-960-technical-guidebook-en.pdf). This means that the guys building graphic card for Dell are particularly careless/cheap. :/ I'll check the xrandr trick. I already tried something similar: generating a modeline through cvt/gft, add it and use xrandr to use it. However, the image was completely messed up. Johan 2012/10/31 Thomas Lübking thomas.luebk...@gmail.com: On Dienstag, 30. Oktober 2012 16:14:32 CEST, Johan Mazel wrote: 2012/10/31 Alex Deucher alexdeuc...@gmail.com: On Tue, Oct 30, 2012 at 6:35 AM, Johan Mazel Theoretically, the HD5450 is able to display the screen's native resolution (2560x1600) according to http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-3000/hd-3400/Pages/ati-radeon-hd-3400-specifications.aspx provided that a dual-link DVI cable is used, which is the case. Unfortunately, the biggest available resolution is 1600x1200 on Debian Testing and 1920x1200 for Ubuntu 12.10. While the chip is cable of dual link, dual link is only available if the oem wired up a dual link DVI connector on your card. If the oem used a single link DVI connector, you will be limited to single link DVI. I suspect that is what's happening. Alex Are you sure that this would explain both problems (I mean with Debian and Ubuntu) ? One hypothesis might be that the package used by Ubuntu 12.10 fixes the software problem present in Debian's package version while the hardware problems remains... Single link is limited to 1600x1200 unless the entire chain supports reduced blanking, what bumps the limit to 1920x1200 (both at 60Hz) Support for latter is probably not correctly detected on the Debian system. You can use xrandr --newmode and --addmode and see what happens if you try to forcefully select 2560×1600 (but i'd add a sleep 10; xrandr -s 1920x1200 because the screen will likely turn off - or the DVI link burns ;-) Also ensure the cable to actually support DL and is not broken (test on other system) Notice that DVI-D does *not* mean Dual-Link, but Digital. You need the pins in the center: http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/DVI_Connector_Types.svg/1000px-DVI_Connector_Types.svg.png Cheers, Thomas ___ 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: Resolution problem with AMD Radeon 5450/6350 and Dell U3011
Does the HD 5450 have a VGA output? Does the U3011 have VGA input? If yes to both, can you try that way and get 2560x1600? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ 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: Resolution problem with AMD Radeon 5450/6350 and Dell U3011
On Dienstag, 30. Oktober 2012 16:14:32 CEST, Johan Mazel wrote: 2012/10/31 Alex Deucher alexdeuc...@gmail.com: On Tue, Oct 30, 2012 at 6:35 AM, Johan Mazel Theoretically, the HD5450 is able to display the screen's native resolution (2560x1600) according to http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-3000/hd-3400/Pages/ati-radeon-hd-3400-specifications.aspx provided that a dual-link DVI cable is used, which is the case. Unfortunately, the biggest available resolution is 1600x1200 on Debian Testing and 1920x1200 for Ubuntu 12.10. While the chip is cable of dual link, dual link is only available if the oem wired up a dual link DVI connector on your card. If the oem used a single link DVI connector, you will be limited to single link DVI. I suspect that is what's happening. Alex Are you sure that this would explain both problems (I mean with Debian and Ubuntu) ? One hypothesis might be that the package used by Ubuntu 12.10 fixes the software problem present in Debian's package version while the hardware problems remains... Single link is limited to 1600x1200 unless the entire chain supports reduced blanking, what bumps the limit to 1920x1200 (both at 60Hz) Support for latter is probably not correctly detected on the Debian system. You can use xrandr --newmode and --addmode and see what happens if you try to forcefully select 2560×1600 (but i'd add a sleep 10; xrandr -s 1920x1200 because the screen will likely turn off - or the DVI link burns ;-) Also ensure the cable to actually support DL and is not broken (test on other system) Notice that DVI-D does *not* mean Dual-Link, but Digital. You need the pins in the center: http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/DVI_Connector_Types.svg/1000px-DVI_Connector_Types.svg.png Cheers, Thomas ___ 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
Hide or change mouse pointer in Linux/X11 when pointer is actively grabbed by others
0 down vote favorite I failed to hide or change mouse pointer when mouse pointer is actively grabbed by some other client. I have tried XChangeActivePointerGrab and XDefineCursor. Main question is: During XDnD (Drag and Drop), when the mouse pointer enters my window, I cannot hide it. I am going to use that in Synergy: When user is dragging something to another display (on some other computer) mouse pointer on the first one should be hidden. -- View this message in context: http://old.nabble.com/Hide-or-change-mouse-pointer-in-Linux-X11-when-pointer-is-actively-grabbed-by-others-tp34620320p34620320.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. ___ 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
[PATCH] os: Add libnettle as a choice of SHA1 implementation
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
libnettle is smaller than libgcrypt, currently being released more
frequently, and has replaced the latter in gnutls-3.x (which is used
by TigerVNC, so they can avoid pulling in two crypto libraries
simultaneously).
Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
---
configure.ac| 14 +-
include/dix-config.h.in |3 +++
os/xsha1.c | 30 ++
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index e686614..758c4b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1360,7 +1360,7 @@ CORE_INCS='-I$(top_srcdir)/include
-I$(top_builddir)/include'
# SHA1 hashing
AC_ARG_WITH([sha1],
-
[AS_HELP_STRING([--with-sha1=libc|libmd|libgcrypt|libcrypto|libsha1|CommonCrypto|CryptoAPI],
+
[AS_HELP_STRING([--with-sha1=libc|libmd|libnettle|libgcrypt|libcrypto|libsha1|CommonCrypto|CryptoAPI],
[choose SHA1 implementation])])
AC_CHECK_FUNC([SHA1Init], [HAVE_SHA1_IN_LIBC=yes])
if test x$with_sha1 = x test x$HAVE_SHA1_IN_LIBC = xyes; then
@@ -1423,6 +1423,18 @@ if test x$with_sha1 = xlibsha1; then
[Use libsha1 for SHA1])
SHA1_LIBS=-lsha1
fi
+AC_CHECK_LIB([nettle], [nettle_sha1_init], [HAVE_LIBNETTLE=yes])
+if test x$with_sha1 = x test x$HAVE_LIBNETTLE = xyes; then
+ with_sha1=libnettle
+fi
+if test x$with_sha1 = xlibnettle test x$HAVE_LIBNETTLE != xyes; then
+ AC_MSG_ERROR([libnettle requested but not found])
+fi
+if test x$with_sha1 = xlibnettle; then
+ AC_DEFINE([HAVE_SHA1_IN_LIBNETTLE], [1],
+ [Use libnettle SHA1 functions])
+ SHA1_LIBS=-lnettle
+fi
AC_CHECK_LIB([gcrypt], [gcry_md_open], [HAVE_LIBGCRYPT=yes])
if test x$with_sha1 = x test x$HAVE_LIBGCRYPT = xyes; then
with_sha1=libgcrypt
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 578f249..b270a32 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -157,6 +157,9 @@
/* Define to use libgcrypt SHA1 functions */
#undef HAVE_SHA1_IN_LIBGCRYPT
+/* Define to use libnettle SHA1 functions */
+#undef HAVE_SHA1_IN_LIBNETTLE
+
/* Define to use libsha1 for SHA1 */
#undef HAVE_SHA1_IN_LIBSHA1
diff --git a/os/xsha1.c b/os/xsha1.c
index fa66c7a..24c0aa2 100644
--- a/os/xsha1.c
+++ b/os/xsha1.c
@@ -116,6 +116,36 @@ x_sha1_final(void *ctx, unsigned char result[20])
return 1;
}
+#elif defined(HAVE_SHA1_IN_LIBNETTLE) /* Use libnettle for SHA1 */
+
+#include nettle/sha.h
+
+void *
+x_sha1_init(void)
+{
+struct sha1_ctx *ctx = malloc(sizeof(*ctx));
+
+if (!ctx)
+return NULL;
+sha1_init(ctx);
+return ctx;
+}
+
+int
+x_sha1_update(void *ctx, void *data, int size)
+{
+sha1_update(ctx, size, data);
+return 1;
+}
+
+int
+x_sha1_final(void *ctx, unsigned char result[20])
+{
+sha1_digest(ctx, 20, result);
+free(ctx);
+return 1;
+}
+
#elif defined(HAVE_SHA1_IN_LIBGCRYPT) /* Use libgcrypt for SHA1 */
#include gcrypt.h
--
1.7.9
___
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
[PULL] input fixes 30.10.2012
Thomas pointed out that the fix for 55738 may cause another bug, but I suspect it merely uncovers that other bug. So the patch is included here nonetheless. The following changes since commit 53830281b4da096f9c13107d73ec9c76ff1d14cc: Merge remote-tracking branch 'sandmann/for-keithp' (2012-10-26 18:04:34 -0700) are available in the git repository at: git://people.freedesktop.org/~whot/xserver for-keith for you to fetch changes up to d511a3016a79c50cb38e7504d4831a9ae128e422: Add missing labels for multitouch valuators (2012-10-30 15:11:10 +1000) Benjamin Tissoires (1): Add missing labels for multitouch valuators Carlos Garnacho (1): Sync TouchListener memory allocation with population in TouchSetupListeners() Peter Hutterer (5): xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP Xi: set xChangeDeviceControlReply.status to Success by default Xi: don't deliver TouchEnd to a client waiting for TouchBegin (#55738) dix: fix zaphod screen scrossing (#54654) xfree86: remove unused variable sigstate Xi/chgdctl.c | 3 ++- Xi/exevents.c | 5 + Xi/xiproperty.c| 3 +++ dix/getevents.c| 5 +++-- dix/touch.c| 4 ++-- hw/xfree86/common/xf86Events.c | 2 +- include/xserver-properties.h | 3 +++ xkb/xkbAccessX.c | 2 +- 8 files changed, 20 insertions(+), 7 deletions(-) pgpO2OEAmmzrA.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: [PATCH proto/x11proto] Adjust windows.h wrapping to work with MinGW-w64 headers as well
Hi, http://lists.x.org/archives/xorg-devel/2012-October/034096.html works for me (MinGW 32-bit) for both Xwinsock.h and Xwindows.h Reviewed-by: Colin Harrison colin.harrison at virgin.net Thanks, Colin Harrison ___ 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 app/xdpyinfo] Include Xwindows.h on WIN32 to avoid type clashes
On 29/10/2012 13:57, walter harms wrote: Am 29.10.2012 14:38, schrieb Jon TURNEY: Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- xdpyinfo.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xdpyinfo.c b/xdpyinfo.c index dcca0ad..2482156 100644 --- a/xdpyinfo.c +++ b/xdpyinfo.c @@ -78,6 +78,10 @@ in this Software without prior written authorization from The Open Group. #endif +#ifdef WIN32 +#include X11/Xwindows.h +#endif + would it hurt to include that with other architecture also ? re, wh I'm not sure I understand the question. X11/Xwindows.h is a wrapper for windows.h, the Windows-specific header file which declares the Windows API, which avoids conflicts between that header and X headers. It doesn't make much sense to try to include it on other platforms. In this specific case, including XWindows.h first avoids conflicting type definitions between windows.h (which is otherwise included unwrapped by xcb.h) and Xproto.h CC xdpyinfo.o In file included from /jhbuild/install-mingw/include/X11/Xproto.h:72:0, from /jhbuild/checkout/xorg/app/xdpyinfo/xdpyinfo.c:89: /jhbuild/install-mingw/include/X11/Xmd.h:122:14: error: conflicting types for ‘INT32’ /usr/i686-pc-mingw32/sys-root/mingw/include/basetsd.h:54:13: note: previous declaration of ‘INT32’ was here /jhbuild/install-mingw/include/X11/Xmd.h:145:15: error: conflicting types for ‘BOOL’ /usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:234:17: note: previous declaration of ‘BOOL’ was here ___ 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 libxkbcommon 2/2] build: Require xorg macros 1.16
On Fri, Oct 26, 2012 at 12:51:56AM +0100, Damien Lespiau wrote: From: Damien Lespiau damien.lesp...@intel.com For XORG_TESTSET_CFLAG and XORG_MEMORY_CHECK_FLAGS. Thanks, I will take both patches through my tree so they won't get lost. Ran Signed-off-by: Damien Lespiau damien.lesp...@intel.com Cc: Daniel Stone dan...@fooishbar.org --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index eda593c..ebefbd9 100644 --- a/configure.ac +++ b/configure.ac @@ -41,7 +41,7 @@ LT_INIT # Require xorg-macros minimum of 1.8 for AM_SILENT_RULES m4_ifndef([XORG_MACROS_VERSION], [m4_fatal([must install xorg-macros 1.8 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.8) +XORG_MACROS_VERSION(1.16) XORG_DEFAULT_OPTIONS XORG_MEMORY_CHECK_FLAGS XORG_ENABLE_DOCS -- 1.7.7.5 ___ 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: [PULL 1.13] A few small fixes
Jon, Ack'd. Matt On 10/16/2012 08:27 AM, Jon TURNEY wrote: On 11/10/2012 17:37, Keith Packard wrote: Jon TURNEY writes: Jon TURNEY (4): Correct description of -displayfd option in man page. hw/xwin: Only add GLX extension once. Fix compilation of Xorg DDX without XF86VIDMODE Fix 'make distcheck' for hw/xwin Merged. 4b7f003..a69429a master - master Make sure you let Matt know which of these you'd like to see in a 1.13 stable update. The following changes since commit f0bad69edd57facd6cffde8cb0863d1a735e2492: Version bumped to 1.13 (2012-09-05 14:45:08 -0700) are available in the git repository at: git://people.freedesktop.org/~jturney/xserver server-1.13-branch for you to fetch changes up to 0456d56092e7617131c77b50a7e7f501e6d9d275: Fix 'make distcheck' for hw/xwin (2012-10-16 15:14:55 +0100) Jon TURNEY (4): Correct description of -displayfd option in man page. hw/xwin: Only add GLX extension once. Fix compilation of Xorg DDX without XF86VIDMODE Fix 'make distcheck' for hw/xwin hw/xfree86/common/Makefile.am |3 ++- hw/xwin/InitOutput.c |5 +++-- hw/xwin/Makefile.am |3 +++ hw/xwin/glx/Makefile.am |3 ++- man/Xserver.man |2 +- 5 files changed, 11 insertions(+), 5 deletions(-) ___ 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: MinGW build fixes for various applications
On Mon, 2012-10-29 at 13:38 +, Jon TURNEY wrote: MinGW build fixes for some applications which are relatively simple to fix. xauth: Jon TURNEY (1): Include Xwinsock.h rather than sys/socket.h on WIN32 xdpyinfo: Jon TURNEY (1): Include Xwindows.h on WIN32 to avoid type clashes xkbcomp: Ryan Pavlik (1): Include Xwindows.h rather than windows.h xmodmap: Jon TURNEY (1): Include X11/Xwindows.h on WIN32 xrdb: Jon TURNEY (1): Fix build with WIN32 defined, but PATHETICCPP not defined xset: Jon TURNEY (1): Remove unneeded include of windows.h on WIN32 For the series: Reviewed-by: Yaakov Selkowitz yselkow...@users.sourceforge.net ___ 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 34486] Poor xterm/exa perf with ColorTiling on.
https://bugs.freedesktop.org/show_bug.cgi?id=34486 --- Comment #8 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #7) On the downside is seems like the TrueType fonts don't look as nice as the bitmap fonts for small font sizes. You should be able to use the same bitmap fonts with the right fontconfig setup. -- 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 56458] slow rendering in urxvt
https://bugs.freedesktop.org/show_bug.cgi?id=56458 --- Comment #5 from Michel Dänzer mic...@daenzer.net --- The profile isn't very useful without callgraphs; it's hard to deduce which code paths are the hottest. That said, the fact that disabling tiling helps indicates it may indeed be (related to) bug 34486. Make sure you're configuring urxvt to use fontconfig/freetype for font rendering, not X11 core fonts. -- 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 56503] Chrome causes crash of Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=56503 --- Comment #5 from Michel Dänzer mic...@daenzer.net --- The log file doesn't show an actual X server crash. Please describe the symptoms a bit more. -- 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 56458] slow rendering in urxvt
https://bugs.freedesktop.org/show_bug.cgi?id=56458 --- Comment #7 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #6) but can't disable antialiasing You have to choose a bitmap font for that (and make sure bitmap fonts are enabled in the fontconfig configuration). -- 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 56458] slow rendering in urxvt
https://bugs.freedesktop.org/show_bug.cgi?id=56458 --- Comment #8 from JS js314...@gmail.com --- editing files in /etc/fonts disabled antialiasing -- 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 56503] Chrome causes crash of Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=56503 --- Comment #6 from JS js314...@gmail.com --- got some core dump #0 x86_fallback_frame_state (fs=0xbfd057e0, context=optimized out) at ./md-unwind-support.h:131 #1 uw_frame_state_for (context=context@entry=0xbfd05760, fs=fs@entry=0xbfd057e0) at ../../../libgcc/unwind-dw2.c:1187 #2 0xb71909ea in _Unwind_Backtrace (trace=0xb733fbe0 backtrace_helper, trace_argument=0xbfd058dc) at ../../../libgcc/unwind.inc:290 #3 0xb733fce5 in __GI___backtrace (array=array@entry=0xbfd05950, size=size@entry=64) at ../sysdeps/i386/backtrace.c:127 #4 0x081bc9c9 in xorg_backtrace () at backtrace.c:50 #5 0x081c0636 in OsSigHandler (sip=0xbfd05a9c, signo=11, unused=optimized out) at osinit.c:128 #6 OsSigHandler (signo=11, sip=0xbfd05a9c, unused=0xbfd05b1c) at osinit.c:107 #7 signal handler called #8 x86_fallback_frame_state (fs=0xbfd05f00, context=optimized out) at ./md-unwind-support.h:131 #9 uw_frame_state_for (context=context@entry=0xbfd05e80, fs=fs@entry=0xbfd05f00) at ../../../libgcc/unwind-dw2.c:1187 #10 0xb71909ea in _Unwind_Backtrace (trace=0xb733fbe0 backtrace_helper, trace_argument=0xbfd05ffc) at ../../../libgcc/unwind.inc:290 #11 0xb733fce5 in __GI___backtrace (array=array@entry=0xbfd06070, size=size@entry=64) at ../sysdeps/i386/backtrace.c:127 #12 0x081bc9c9 in xorg_backtrace () at backtrace.c:50 #13 0x0819b29b in mieqEnqueue (pDev=pDev@entry=0x8652be0, e=e@entry=0xb7140948) at mieq.c:281 #14 0x08090725 in queueEventList (device=0x8652be0, device@entry=0x2, events=optimized out, nevents=2) at getevents.c:1002 #15 0x08092958 in QueuePointerEvents (device=0x2, device@entry=0x8652be0, type=type@entry=6, buttons=buttons@entry=0, flags=10, mask=mask@entry=0x86539e8) at getevents.c:1262 #16 0x080ca9bb in xf86PostMotionEventM (mask=0x86539e8, is_absolute=0, device=0x8652be0) at xf86Xinput.c:1161 #17 xf86PostMotionEventM (device=0x8652be0, is_absolute=is_absolute@entry=0, mask=0x86539e8) at xf86Xinput.c:1146 #18 0xb5d71e3d in EvdevPostRelativeMotionEvents (pInfo=pInfo@entry=0x862f470, num_v=0, num_v@entry=1, first_v=0, first_v@entry=1, v=v@entry=0xbfd062f0) at evdev.c:898 #19 0xb5d73546 in EvdevProcessSyncEvent (pInfo=0x862f470, ev=optimized out) at evdev.c:1010 #20 EvdevProcessEvent (ev=0xbfd06390, pInfo=0x862f470) at evdev.c:1052 #21 EvdevReadInput (pInfo=0x862f470) at evdev.c:1131 #22 0x080b9eb1 in xf86SigioReadInput (fd=16, closure=0x862f470) at xf86Events.c:312 #23 0x080dfe25 in xf86SIGIO (sig=29) at ../shared/sigio.c:108 #24 signal handler called #25 __memcpy_ia32 () at ../sysdeps/i386/i686/memcpy.S:75 #26 0x006aa400 in ?? () #27 0xb6d4e0ad in memcpy (__len=7680, __src=0xb22fe400, __dest=0xb2b72408) at /usr/include/bits/string3.h:52 #28 RADEONCopySwap (dst=dst@entry=0xb2b72408 , src=0xb22fe400 Address 0xb22fe400 out of bounds, size=size@entry=7680, swap=swap@entry=0) at radeon_accel.c:994 #29 0xb6dc0974 in RADEONDownloadFromScreenCS (pSrc=pSrc@entry=0x87ab4a8, x=0, y=y@entry=0, w=7680, h=optimized out, dst=0xb2b72408 , dst_pitch=7680) at radeon_exa_funcs.c:665 #30 0xb6cf53a2 in exaCopyDirty (migrate=migrate@entry=0xbfd06c90, pValidDst=0x87ab508, pValidSrc=0x87ab514, transfer=transfer@entry=0xb6dc0820 RADEONDownloadFromScreenCS, fallback_index=fallback_index@entry=1, sync=sync@entry=0xb6cf3f90 exaWaitSync) at exa_migration_classic.c:220 #31 0xb6cf5770 in exaCopyDirtyToSys (migrate=migrate@entry=0xbfd06c90) at exa_migration_classic.c:285 #32 0xb6cf7ac7 in exaPrepareAccessReg_mixed (pPixmap=0x87ab4a8, index=0, pReg=0xbfd06d64) at exa_migration_mixed.c:254 #33 0xb6d01eb6 in ExaPrepareCompositeReg (height=1154, width=12, yDst=0, xDst=1908, yMask=0, xMask=1908, ySrc=24, xSrc=1908, pDst=0x880e2c8, pMask=0x0, pSrc=0x87c7a68, op=1 '\001', pScreen=0x8484560) at exa_unaccel.c:577 #34 ExaCheckComposite (op=op@entry=1 '\001', pSrc=pSrc@entry=0x87c7a68, pMask=pMask@entry=0x0, pDst=pDst@entry=0x880e2c8, xSrc=xSrc@entry=1908, ySrc=ySrc@entry=24, xMask=xMask@entry=1908, yMask=yMask@entry=0, xDst=1908, yDst=0, width=width@entry=12, height=height@entry=1154) at exa_unaccel.c:600 #35 0xb6cfe6ae in exaComposite (op=1 '\001', pSrc=0x87c7a68, pMask=0x0, pDst=0x880e2c8, xSrc=optimized out, ySrc=optimized out, xMask=1908, yMask=0, xDst=optimized out, yDst=optimized out, width=12, height=1154) at exa_render.c:1039 #36 0x08145772 in damageComposite (op=1 '\001', pSrc=0x87c7a68, pMask=0x0, pDst=0x880e2c8, xSrc=1908, ySrc=24, xMask=1908, yMask=0, xDst=1908, yDst=0, width=12, height=1154) at damage.c:562 #37 0x08139b99 in CompositePicture (op=optimized out, pSrc=0x87c7a68, pMask=pMask@entry=0x0, pDst=0x880e2c8, xSrc=1908, ySrc=24, xMask=1908, yMask=0, xDst=1908, yDst=0, width=12, height=1154) at picture.c:1578 #38 0x0813e34d in ProcRenderComposite (client=0x87abf00) at render.c:707 #39 0x0813a25e in ProcRenderDispatch (client=0x87abf00) at render.c:1988 #40 0x0807b5d5 in Dispatch () at dispatch.c:428 #41 0x08069165 in main (argc=8, argv=0xbfd07174, envp=0xbfd07198) at main.c:288
[Bug 56503] Chrome causes crash of Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=56503 --- Comment #7 from JS js314...@gmail.com --- another backtrace, it is crashing every 5 minutes #0 x86_fallback_frame_state (fs=0xbfb810d0, context=optimized out) at ./md-unwind-support.h:131 #1 uw_frame_state_for (context=context@entry=0xbfb81050, fs=fs@entry=0xbfb810d0) at ../../../libgcc/unwind-dw2.c:1187 #2 0xb72329ea in _Unwind_Backtrace (trace=0xb73e1be0 backtrace_helper, trace_argument=0xbfb811cc) at ../../../libgcc/unwind.inc:290 #3 0xb73e1ce5 in __GI___backtrace (array=array@entry=0xbfb81240, size=size@entry=64) at ../sysdeps/i386/backtrace.c:127 #4 0x081bc9c9 in xorg_backtrace () at backtrace.c:50 #5 0x081c0636 in OsSigHandler (sip=0xbfb8138c, signo=11, unused=optimized out) at osinit.c:128 #6 OsSigHandler (signo=11, sip=0xbfb8138c, unused=0xbfb8140c) at osinit.c:107 #7 signal handler called #8 x86_fallback_frame_state (fs=0xbfb817f0, context=optimized out) at ./md-unwind-support.h:131 #9 uw_frame_state_for (context=context@entry=0xbfb81770, fs=fs@entry=0xbfb817f0) at ../../../libgcc/unwind-dw2.c:1187 #10 0xb72329ea in _Unwind_Backtrace (trace=0xb73e1be0 backtrace_helper, trace_argument=0xbfb818ec) at ../../../libgcc/unwind.inc:290 #11 0xb73e1ce5 in __GI___backtrace (array=array@entry=0xbfb81960, size=size@entry=64) at ../sysdeps/i386/backtrace.c:127 #12 0x081bc9c9 in xorg_backtrace () at backtrace.c:50 #13 0x0819b29b in mieqEnqueue (pDev=pDev@entry=0x8d10bd0, e=e@entry=0xb71e2948) at mieq.c:281 #14 0x08090725 in queueEventList (device=0x8d10bd0, device@entry=0x2, events=optimized out, nevents=2) at getevents.c:1002 #15 0x08092958 in QueuePointerEvents (device=0x2, device@entry=0x8d10bd0, type=type@entry=6, buttons=buttons@entry=0, flags=10, mask=mask@entry=0x8d119d8) at getevents.c:1262 #16 0x080ca9bb in xf86PostMotionEventM (mask=0x8d119d8, is_absolute=0, device=0x8d10bd0) at xf86Xinput.c:1161 #17 xf86PostMotionEventM (device=0x8d10bd0, is_absolute=is_absolute@entry=0, mask=0x8d119d8) at xf86Xinput.c:1146 #18 0xb5e13e3d in EvdevPostRelativeMotionEvents (pInfo=pInfo@entry=0x8ced460, num_v=0, num_v@entry=1, first_v=0, first_v@entry=1, v=v@entry=0xbfb81be0) at evdev.c:898 #19 0xb5e15546 in EvdevProcessSyncEvent (pInfo=0x8ced460, ev=optimized out) at evdev.c:1010 #20 EvdevProcessEvent (ev=0xbfb81c80, pInfo=0x8ced460) at evdev.c:1052 #21 EvdevReadInput (pInfo=0x8ced460) at evdev.c:1131 #22 0x080b9eb1 in xf86SigioReadInput (fd=16, closure=0x8ced460) at xf86Events.c:312 #23 0x080dfe25 in xf86SIGIO (sig=29) at ../shared/sigio.c:108 #24 signal handler called #25 __memcpy_ia32 () at ../sysdeps/i386/i686/memcpy.S:75 #26 0x003d8600 in ?? () #27 0xb6df00ad in memcpy (__len=7680, __src=0xb2099600, __dest=0xb2963608) at /usr/include/bits/string3.h:52 #28 RADEONCopySwap (dst=dst@entry=0xb2963608 , src=0xb2099600 Address 0xb2099600 out of bounds, size=size@entry=7680, swap=swap@entry=0) at radeon_accel.c:994 #29 0xb6e62974 in RADEONDownloadFromScreenCS (pSrc=pSrc@entry=0x8e788f8, x=0, y=y@entry=0, w=7680, h=optimized out, dst=0xb2963608 , dst_pitch=7680) at radeon_exa_funcs.c:665 #30 0xb6d973a2 in exaCopyDirty (migrate=migrate@entry=0xbfb82580, pValidDst=0x8e78958, pValidSrc=0x8e78964, transfer=transfer@entry=0xb6e62820 RADEONDownloadFromScreenCS, fallback_index=fallback_index@entry=1, sync=sync@entry=0xb6d95f90 exaWaitSync) at exa_migration_classic.c:220 #31 0xb6d97770 in exaCopyDirtyToSys (migrate=migrate@entry=0xbfb82580) at exa_migration_classic.c:285 #32 0xb6d99ac7 in exaPrepareAccessReg_mixed (pPixmap=0x8e788f8, index=0, pReg=0x0) at exa_migration_mixed.c:254 #33 0xb6da3eb6 in ExaPrepareCompositeReg (height=9, width=7, yDst=10, xDst=38, yMask=0, xMask=976, ySrc=10, xSrc=37, pDst=0x8e7ae48, pMask=0x8d37728, pSrc=0x8e78bf0, op=3 '\003', pScreen=0x8b42560) at exa_unaccel.c:577 #34 ExaCheckComposite (op=op@entry=3 '\003', pSrc=pSrc@entry=0x8e78bf0, pMask=pMask@entry=0x8d37728, pDst=pDst@entry=0x8e7ae48, xSrc=37, ySrc=10, xMask=976, yMask=0, xDst=38, yDst=10, width=7, height=9) at exa_unaccel.c:600 #35 0xb6da0234 in exaCompositeRects (op=optimized out, op@entry=3 '\003', pSrc=pSrc@entry=0x8e78bf0, pMask=0x8d37728, pDst=pDst@entry=0x8e7ae48, nrect=37, rects=0xbfb8278c) at exa_render.c:604 #36 0xb6d9e37a in exaGlyphsToDst (buffer=0xbfb82788, pDst=0x8e7ae48, pSrc=0x8e78bf0) at exa_glyphs.c:623 #37 exaGlyphs (op=3 '\003', pSrc=0x8e78bf0, pDst=0x8e7ae48, maskFormat=0x0, xSrc=36, ySrc=19, nlist=optimized out, list=0xbfb83d3c, glyphs=0xbfb840e4) at exa_glyphs.c:824 #38 0x081459e4 in damageGlyphs (op=3 '\003', pSrc=0x8e78bf0, pDst=0x8e7ae48, maskFormat=0x0, xSrc=36, ySrc=19, nlist=1, list=0xbfb83d30, glyphs=0xbfb84030) at damage.c:628 #39 0x08133b1e in CompositeGlyphs (op=3 '\003', pSrc=0x8e78bf0, pDst=0x8e7ae48, maskFormat=0x0, xSrc=36, ySrc=19, nlist=nlist@entry=1, lists=lists@entry=0xbfb83d30, glyphs=glyphs@entry=0xbfb84030) at glyph.c:560 #40 0x0813e859 in ProcRenderCompositeGlyphs (client=0x8e16480) at render.c:1389 #41 0x0813a25e in
