Re: Problems with xf86-input-synaptics 1.5.99.901
On 03/21/2012 02:55 PM, Ilya Ilembitov wrote: Hi, all. I have HP Envy 13 which uses a single button design of Synaptics Clickpad. Using Arch Linux I have updated to xf86-input-synaptics 1.5.99.901 which is supposed to bring proper support for my touchpad. What works: -drag and drop -two-finger scrolling -tap to click, double tap to click for right button What doesn't work: -right click -button areas recognize movements, so the cursor jumps a lot during drag and drop What can I do to fix the issues? ___ 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: dgbale...@0x01b.net Firstly, try upgrading to 1.5.99.902. Also check out: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/conf/50-synaptics.conf ___ 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
[ANNOUNCE] xcb-proto 1.7.1
Hey, xcb-proto 1.7.1 is out. Not a big deal though. Changes: Alex Plotnick (1): Rename the ExprType parent attribute to parents. Arnaud Fontaine (3): Add ge and xf86vidmode protocol descriptions. Remove now unnecessary files as everything is implemented in xcbgen. Add autogen.sh to EXTRA_DIST. Julien Danjou (1): Release xcb-proto 1.7.1 Download: http://xcb.freedesktop.org/dist/xcb-proto-1.7.1.tar.bz2 http://xcb.freedesktop.org/dist/xcb-proto-1.7.1.tar.gz md5sum: 948fec39dd42f3694edd5d9689735ec4 xcb-proto-1.7.1.tar.bz2 146725fa167cd3d66ecf404870608875 xcb-proto-1.7.1.tar.gz sha1sum: 82a568559235fc6e26d0a38911c5ea18f8e8455c xcb-proto-1.7.1.tar.bz2 4c7d56da2669943b981eb5e739e5c89787140720 xcb-proto-1.7.1.tar.gz -- Julien pgpN6H0xJhoYm.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-ast 0.93.10
Aspeed Tech driver update for compatibility with Xorg 1.12 ABI Adam Jackson (4): Adapt to domain changes in videoabi 12 Check ABI major not encoded ABI Make failure to XAA non-fatal Fix for new vgaHW ABI Alan Coopersmith (1): xf86-video-ast 0.93.10 git tag: xf86-video-ast-0.93.10 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ast-0.93.10.tar.bz2 MD5: de0bf8e0c8ab67be42c14f07ca427271 SHA1: 40e8acd04ccf670b196be74a2c806d064f7b68db SHA256: c9d466fef391bdf960f79b82f1f776a1c1ab870e93475c3d1b3d028531fac4e0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ast-0.93.10.tar.gz MD5: 31d280faeab4a51ebb36b59d36764955 SHA1: 66550e154909d1944fe304ca25c3ff1c679dfc10 SHA256: 7503e5cebb71d9113611d61a4228a02934b2a951d2242cdfd784e611cfa0ca27 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpTDpEtGGqEf.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-mach64 6.9.1
Driver release for compatibility with Xorg 1.12 ABI. Adam Jackson (1): Fall back to shadowfb if XAA is unavailable Alan Coopersmith (1): xf86-video-mach64 6.9.1 Jeremy Huddleston (2): Use unsigned long rather than deprecated IOADDRESS Use pci_device_map_legacy rather than xf86MapDomainMemory git tag: xf86-video-mach64-6.9.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.1.tar.bz2 MD5: 8484c18f08e77564a56ccbf226694038 SHA1: 7129cf61a1c70d923a370fea66686d7a13be8fe8 SHA256: 9f6ad49f07c8785a64caac6f4aaf58fc7746a24b718491d047c45bc1ee9e834e http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.1.tar.gz MD5: a4d71b32f161338beb05720bc5a33ce1 SHA1: 963ca3af991862b5a29182623bfe5f5dcd5bbe8a SHA256: ceef5cefeabc8fa52babba0484b2389a210abaee5d9533899a9347656b478874 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpCe4nzOAXhu.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-neomagic 1.2.6
Driver release for compatibility with Xorg 1.12 ABI Adam Jackson (2): Fall back to shadowfb when XAA is unavailable Fix for new vgahw ABI Alan Coopersmith (1): xf86-video-neomagic 1.2.6 Gaetan Nadon (10): config: upgrade to util-macros 1.8 for additional man page support config: update AC_PREREQ statement to 2.60 config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_HEADER_STDC config: remove unrequired AC_SUBST([XORG_CFLAGS]) config: complete AC_INIT m4 quoting config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace deprecated AC_HELP_STRING with AS_HELP_STRING config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES config: add comments for main statements Jeremy Huddleston (2): Use malloc/calloc/realloc/free directly Include stdlib.h for abs() Jesse Adkins (1): Purge cvs tags. git tag: xf86-video-neomagic-1.2.6 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-neomagic-1.2.6.tar.bz2 MD5: e5f25c01492d96ddd0171454a8e6bd39 SHA1: 35ac1d62357fa2ddc37473b24335db441bc70f4d SHA256: b19ed2a33e8d9a3e2bfc1ae3e8ff49031b7d34dec786e4a5e060e68e48649888 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-neomagic-1.2.6.tar.gz MD5: 52af77505c4ab5eb5a1f8938253697d6 SHA1: 336ed37592cf71def5942c4765c0c987fa1343c2 SHA256: 2374f64655aa179b6a0a58a6255abacd995863d75c5a3dee215df136ad5c6cf9 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpE1VkjzoOh1.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-savage 2.3.4
Driver release for compatibility with Xorg server 1.12 ABI. Adam Jackson (3): Don't include xf86Priv.h Fall back to shadowfb if XAA is unavailable Fix for new vgahw ABI Alan Coopersmith (2): Add savage_pciids.h to src/Makefile.am to fix distcheck xf86-video-savage 2.3.4 Andrew Turner (1): Merge almost identical code in SAVAGEInitVisualConfigs Peter Hutterer (1): Untangle XF86DRI from the driver-specific DRI define Tormod Volden (2): Do not use the deprecated xf86PciInfo.h from xserver Avoid leading underscores in #include guards git tag: xf86-video-savage-2.3.4 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-savage-2.3.4.tar.bz2 MD5: 664c7d9c93049ebe96af262ec448451f SHA1: e2eb14a6d7dc6a031e22a243afab0181ed9d568d SHA256: 3a666a66339686ad4dd85b0665cc300e8a7fc6d38b49a9e8e8d48f393627be49 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-savage-2.3.4.tar.gz MD5: 9aede30cc328d26ebc1208940d39b172 SHA1: a0b5d02378f665ba8552f16edc504d0428690312 SHA256: 4e43dc40bd4dd957f79819d5ae6db7b7bb899d2747a64c265b35023266784f13 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpWLxHAaCo3I.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-siliconmotion 1.7.6
Driver release for compatibility with Xorg 1.12 ABI. Adam Jackson (4): Adapt to missing PIOOffset in videoabi 12 Check ABI major not encoded ABI Make failure to XAA non-fatal Fix for new vgaHW ABI Alan Coopersmith (1): xf86-video-siliconmotion 1.7.6 Matt Turner (2): Don't check for randrproto or renderproto Add component=Driver/siliconmotion to Bugzilla link git tag: xf86-video-siliconmotion-1.7.6 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-siliconmotion-1.7.6.tar.bz2 MD5: b5acd392d799e2bb67ea702a83feb4a0 SHA1: b26f149dd7cfc7bb5d18658701b52cd00ffd964d SHA256: a59f1bd21499351b3703c4b77ec007d1299ccb888434d19fabbbeee0a7a14d07 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-siliconmotion-1.7.6.tar.gz MD5: b71859e15fc62563d346c7bccc0ef82e SHA1: 8c0095c9e585d0abde4fcb99aa3e96663f8ae9d5 SHA256: 0982d5694be4d380ae891f6ebb325f4864374a7bd5aa9f6486c8236364506a43 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpHllYT4hhvn.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-sis 0.10.4
Driver release for compatibility with Xorg 1.12 ABI. Adam Jackson (1): Fall back to shadowfb if XAA is unavailable Alan Coopersmith (2): Convert sis.man from XORG_RAWCPP to using sed like other drivers xf86-video-sis 0.10.4 Fernando Carrijo (1): Purge macros NEED_EVENTS and NEED_REPLIES Gaetan Nadon (10): config: update AC_PREREQ statement to 2.60 config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_HEADER_STDC config: remove unrequired AC_SUBST([XORG_CFLAGS]) config: remove unrequired AC_SUBST([DRI_CFLAGS]) config: complete AC_INIT m4 quoting config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace deprecated AC_HELP_STRING with AS_HELP_STRING config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES config: add comments for main statements Jeremy Huddleston (9): Fix build failures with recent server changes to swapl and swaps Use malloc/calloc/realloc/free directly Use unsigned long rather than deprecated IOADDRESS Build fix for ABI Version 12 Silence warnings by using newer xf86dgaproto pciTag was removed from xorg-server, so provide it in-driver until this is updated to use libpciaccess Convert use of LookupWindow to dixLookupWindow Use pci_device_map_legacy rather than xf86MapDomainMemory on newer servers Build fix for older servers (error: conflicting types for 'pciTag') Jesse Adkins (1): Purge cvs tags. Johannes Obermayr (1): Fix build with XInput version 12. Matt Turner (1): Fix wrong-sized swaps Peter Hutterer (3): Use miPointerSetPosition, not miPointerAbsoluteCursor Untangle XF86DRI from the driver-specific DRI define Undo typos from last commit git tag: xf86-video-sis-0.10.4 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-sis-0.10.4.tar.bz2 MD5: e1dda5365ad28ef3165fd0ed25952d9c SHA1: e17fabf160939cef3128f4b10f70fd5f9b0e6442 SHA256: 4e841080ea524f37d887ef4ee50df5b9f7f5b417abddc9eb8ddad19128c0b10d http://xorg.freedesktop.org/archive/individual/driver/xf86-video-sis-0.10.4.tar.gz MD5: 8ebedfd3bdb587874c29ed024dc0ab0d SHA1: 31b3a805a24fd264d45647ece6eb5ea93605d540 SHA256: 5dc15c47e061484266a785d4d4344dd40358a45a927a4621bfefcd2639aab9d0 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgp2AiERziIqo.pgp Description: PGP signature ___ 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
[ANNOUNCE] xf86-video-trident 1.3.5
Driver release for compatibility with Xorg 1.12 ABI Adam Jackson (2): Fall back to shadowfb if XAA is unavailable Fix for new vgaHW ABI Alan Coopersmith (1): xf86-video-trident 1.3.5 Gaetan Nadon (10): config: upgrade to util-macros 1.8 for additional man page support config: update AC_PREREQ statement to 2.60 config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_HEADER_STDC config: remove unrequired AC_SUBST([XORG_CFLAGS]) config: complete AC_INIT m4 quoting config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace deprecated AC_HELP_STRING with AS_HELP_STRING config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES config: add comments for main statements Jeremy Huddleston (5): Use unsigned long rather than deprecated IOADDRESS Build fix for ABI Version 12 Use uint32_t instead of deprecated PCITAG Disable PC98 code on newer servers Dead code removal Jesse Adkins (1): Purge cvs tags. Trevor Woerner (2): Convert x+m/calloc/free to m/calloc/free. Update xf86dgastr.h include. git tag: xf86-video-trident-1.3.5 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-trident-1.3.5.tar.bz2 MD5: 5ca073f0ca52b83e51def3115e6cae4a SHA1: d4ef8112eeabb7a7e31e287172425e3540bb34fd SHA256: 4bb3d091ab7788e1883d6d9e7e0c7ecbf9f57e5ef03d94a5082c2870dbbfc50b http://xorg.freedesktop.org/archive/individual/driver/xf86-video-trident-1.3.5.tar.gz MD5: 713e75c84c68cc553275b3ecef9db884 SHA1: c1b250b43945e5dfb81864b6d80e341907404b6c SHA256: 88e4c92e02cf8a6c91c7691720fe9cfec25feca96857389fb8cbc59ebddc38a1 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpdAWqkCc9CA.pgp Description: PGP signature ___ 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: [RFC] server-private and public header separation
On Thu, Mar 22, 2012 at 10:48:53PM -0700, Chase Douglas wrote:
On 03/22/2012 09:25 PM, Peter Hutterer wrote:
This is just a quickfire patch to show the principle, it has not been tested
much. Plus, it's more of an idea right now, not sure if I'll find the time
to do it.
Right now, we export virtually everything including the gory bits of every
struct. Which causes us to break the ABI whenever we so much as look at a
struct (see the per-device-idlecounters for example).
This patch introduces a new define __XSERVER__ that we can use in the sdk
headers. Obviously the real integration will be a tad harder as there are
other headers that are installed outside of include/. But the gist is that
anything between ifdef __XSERVER__ disappears on install, (in)effectively
hiding it.
It's going to be painful defining what goes in and what doesn't, but maybe,
just maybe, it'll be useful in the long term.
Is that something we want?
---
include/Makefile.am |8
include/dix-config.h.in |3 +++
include/inputstr.h | 27 +++
3 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/include/Makefile.am b/include/Makefile.am
index 972f403..3e183db 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -71,3 +71,11 @@ EXTRA_DIST = \
eventconvert.h eventstr.h inpututils.h \
protocol-versions.h \
xsha1.h
+
+
+unifdef_headers: $(sdk_HEADERS)
+ for file in $(sdk_HEADERS); do \
+ (cd $(DESTDIR)$(sdkdir) unifdef -U__XSERVER__ -o $$file.tmp
$$file; mv $$file.tmp $$file) \
+ done
+
+install-data-hook: unifdef_headers
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 3fb6413..9b362c6 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -3,6 +3,9 @@
#ifndef _DIX_CONFIG_H_
#define _DIX_CONFIG_H_
+/* XServer-internal */
+#define __XSERVER__ 1
+
/* Support BigRequests extension */
#undef BIGREQS
diff --git a/include/inputstr.h b/include/inputstr.h
index 5a38924..a4f549c 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -529,19 +529,8 @@ typedef struct _SpriteInfoRec {
typedef struct _DeviceIntRec {
DeviceRec public;
DeviceIntPtr next;
-Bool startup; /* true if needs to be turned on at
- server initialization time */
-DeviceProc deviceProc; /* proc(DevicePtr, DEVICE_xx). It is
- used to initialize, turn on, or
- turn off the device */
-Bool inited;/* TRUE if INIT returns Success */
-Bool enabled; /* TRUE if ON returns Success */
-Bool coreEvents;/* TRUE if device also sends core */
-GrabInfoRec deviceGrab; /* grab on the device */
-int type; /* MASTER_POINTER, MASTER_KEYBOARD, SLAVE
*/
-Atom xinput_type;
-char *name;
int id;
+char *name;
KeyClassPtr key;
ValuatorClassPtr valuator;
TouchClassPtr touch;
@@ -554,6 +543,19 @@ typedef struct _DeviceIntRec {
StringFeedbackPtr stringfeed;
BellFeedbackPtr bell;
LedFeedbackPtr leds;
+
+#ifdef __XSERVER__
+Bool startup; /* true if needs to be turned on at
+ server initialization time */
+DeviceProc deviceProc; /* proc(DevicePtr, DEVICE_xx). It is
+ used to initialize, turn on, or
+ turn off the device */
+Bool inited;/* TRUE if INIT returns Success */
+Bool enabled; /* TRUE if ON returns Success */
+Bool coreEvents;/* TRUE if device also sends core */
+GrabInfoRec deviceGrab; /* grab on the device */
+int type; /* MASTER_POINTER, MASTER_KEYBOARD, SLAVE
*/
+Atom xinput_type;
struct _XkbInterest *xkb_interest;
char *config_info; /* used by the hotplug layer */
ClassesPtr unused_classes; /* for master devices */
@@ -593,6 +595,7 @@ typedef struct _DeviceIntRec {
int xtest_master_id;
struct _SyncCounter *idle_counter;
+#endif
} DeviceIntRec;
typedef struct {
This implementation would make the struct size look different between
the server and the client. I think that would likely end up causing some
bad memory corruption bugs sometime down the line.
I would suggest using the pimpl idiom, where you have a public struct
with a pointer to a private data struct. The pointer is still public,
but the data hidden behind the pointer isn't. The private structure
definition could be provided in a struct within the __XSERVER__
conditional macros so it's filtered out at install time.
I do think this is valuable. The
C99 inline keyword
These two patches replace all custom inline keywords with a plain `inline`, while still maintaining backwards compatibility through a autoconf macro. ___ 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 1/2] Standartize on C99 inline
The current code uses a mix of inline, __inline, __inline__ and _X_INLINE.
Settle on C99 inline, but add AC_C_INLINE to configure.ac to take care
of old compilers. Also remove reference to _X_INLINE in doc/c-extensions.
Signed-off-by: Tomas Carnecky tomas.carne...@gmail.com
---
Xext/security.c |2 +-
configure.ac|1 +
dix/region.c|4 ++--
dix/resource.c |2 +-
dix/selection.c |2 +-
doc/c-extensions|2 --
exa/exa_classic.c |2 +-
exa/exa_driver.c|2 +-
exa/exa_mixed.c |2 +-
exa/exa_priv.h |2 +-
hw/xfree86/modes/xf86Crtc.h |6 +++---
mi/miarc.c |4 ++--
mi/mifpoly.h|2 +-
13 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/Xext/security.c b/Xext/security.c
index 3699510..45dd950 100644
--- a/Xext/security.c
+++ b/Xext/security.c
@@ -146,7 +146,7 @@ SecurityLabelInitial(void)
/*
* Looks up a request name
*/
-static _X_INLINE const char *
+static inline const char *
SecurityLookupRequestName(ClientPtr client)
{
return LookupRequestName(client-majorOp, client-minorOp);
diff --git a/configure.ac b/configure.ac
index 65d29f2..bf77b91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -136,6 +136,7 @@ AC_CHECK_HEADERS([fcntl.h stdlib.h string.h unistd.h
dlfcn.h stropts.h fnmatch.h
dnl Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST
+AC_C_INLINE
AC_C_BIGENDIAN([ENDIAN=X_BIG_ENDIAN], [ENDIAN=X_LITTLE_ENDIAN])
AC_CHECK_SIZEOF([unsigned long])
diff --git a/dix/region.c b/dix/region.c
index 737d2a8..4a0d847 100644
--- a/dix/region.c
+++ b/dix/region.c
@@ -383,7 +383,7 @@ RegionRectAlloc(RegionPtr pRgn, int n)
*
*---
*/
-_X_INLINE static int
+static inline int
RegionCoalesce(RegionPtr pReg, /* Region to coalesce*/
int prevStart, /* Index of start of previous band */
int curStart)
@@ -468,7 +468,7 @@ RegionCoalesce(RegionPtr pReg, /* Region to coalesce
*/
*---
*/
-_X_INLINE static Bool
+static inline Bool
RegionAppendNonO(RegionPtr pReg, BoxPtr r, BoxPtr rEnd, int y1, int y2)
{
BoxPtr pNextRect;
diff --git a/dix/resource.c b/dix/resource.c
index 89d0776..b728e34 100644
--- a/dix/resource.c
+++ b/dix/resource.c
@@ -232,7 +232,7 @@ static const struct ResourceType predefTypes[] = {
CallbackListPtr ResourceStateCallback;
-static _X_INLINE void
+static inline void
CallResourceStateCallback(ResourceState state, ResourceRec * res)
{
if (ResourceStateCallback) {
diff --git a/dix/selection.c b/dix/selection.c
index dfdcfdc..3e3a0b4 100644
--- a/dix/selection.c
+++ b/dix/selection.c
@@ -101,7 +101,7 @@ InitSelections(void)
CurrentSelections = NULL;
}
-static _X_INLINE void
+static inline void
CallSelectionCallback(Selection * pSel, ClientPtr client,
SelectionCallbackKind kind)
{
diff --git a/doc/c-extensions b/doc/c-extensions
index eb33e27..a7b0f29 100644
--- a/doc/c-extensions
+++ b/doc/c-extensions
@@ -21,8 +21,6 @@ extensions, although the results may not be optimal.
table.
* _X_INTERNAL: like _X_HIDDEN, but attempt to ensure that this function
is never called from another module.
-* _X_INLINE: inline this functon if possible (generally obeyed unless
- disabling optimisations).
* _X_DEPRECATED: warn on use of this function.
Mandatory extensions:
diff --git a/exa/exa_classic.c b/exa/exa_classic.c
index 1fa534b..485ab89 100644
--- a/exa/exa_classic.c
+++ b/exa/exa_classic.c
@@ -33,7 +33,7 @@
/* This file holds the classic exa specific implementation. */
-static _X_INLINE void *
+static inline void *
ExaGetPixmapAddress(PixmapPtr p)
{
ExaPixmapPriv(p);
diff --git a/exa/exa_driver.c b/exa/exa_driver.c
index d467ca9..e83e0d0 100644
--- a/exa/exa_driver.c
+++ b/exa/exa_driver.c
@@ -33,7 +33,7 @@
/* This file holds the driver allocated pixmaps specific implementation. */
-static _X_INLINE void *
+static inline void *
ExaGetPixmapAddress(PixmapPtr p)
{
ExaPixmapPriv(p);
diff --git a/exa/exa_mixed.c b/exa/exa_mixed.c
index 0681731..3904f8f 100644
--- a/exa/exa_mixed.c
+++ b/exa/exa_mixed.c
@@ -34,7 +34,7 @@
/* This file holds the driver allocated pixmaps + better initial placement
code.
*/
-static _X_INLINE void *
+static inline void *
ExaGetPixmapAddress(PixmapPtr p)
{
ExaPixmapPriv(p);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index bde78c3..ce37a0f 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -458,7 +458,7 @@ ExaCheckAddTraps(PicturePtr pPicture,
/* exa_accel.c */
-static _X_INLINE Bool
+static inline Bool
exaGCReadsDestination(DrawablePtr pDrawable, unsigned long
[PATCH 2/2] Convert remaining code to use C99 inline
But keep compatibility defines for __inline and __inline__ in case some
drivers still use those (hw/xfree86/common/compiler.h).
Signed-off-by: Tomas Carnecky tomas.carne...@gmail.com
---
hw/xfree86/common/compiler.h | 289 --
hw/xfree86/x86emu/sys.c | 24 ++--
hw/xquartz/xpr/x-hash.h |8 +-
3 files changed, 153 insertions(+), 168 deletions(-)
diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index 0abdfb6..bb59d2a 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -75,25 +75,10 @@
#include pixman.h /* for uint*_t types */
-/* Allow drivers to use the GCC-supported __inline__ and/or __inline. */
-#ifndef __inline__
-#if defined(__GNUC__)
-/* gcc has __inline__ */
-#elif defined(__HIGHC__)
-#define __inline__ _Inline
-#else
-#define __inline__ /**/
-#endif
-#endif /* __inline__ */
-#ifndef __inline
-#if defined(__GNUC__)
-/* gcc has __inline */
-#elif defined(__HIGHC__)
-#define __inline _Inline
-#else
-#define __inline /**/
-#endif
-#endif /* __inline */
+/* FIXME: Remove once all drivers and other external modules are ported */
+#define __inline inline
+#define __inline__ inline
+
/* Support gcc's __FUNCTION__ for people using other compilers */
#if !defined(__GNUC__) !defined(__FUNCTION__)
#define __FUNCTION__ __func__ /* C99 */
@@ -239,7 +224,7 @@ struct __una_u16 {
/* Elemental unaligned loads */
-static __inline__ uint64_t
+static inline uint64_t
ldq_u(uint64_t * p)
{
const struct __una_u64 *ptr = (const struct __una_u64 *) p;
@@ -247,7 +232,7 @@ ldq_u(uint64_t * p)
return ptr-x;
}
-static __inline__ uint32_t
+static inline uint32_t
ldl_u(uint32_t * p)
{
const struct __una_u32 *ptr = (const struct __una_u32 *) p;
@@ -255,7 +240,7 @@ ldl_u(uint32_t * p)
return ptr-x;
}
-static __inline__ uint16_t
+static inline uint16_t
ldw_u(uint16_t * p)
{
const struct __una_u16 *ptr = (const struct __una_u16 *) p;
@@ -265,7 +250,7 @@ ldw_u(uint16_t * p)
/* Elemental unaligned stores */
-static __inline__ void
+static inline void
stq_u(uint64_t val, uint64_t * p)
{
struct __una_u64 *ptr = (struct __una_u64 *) p;
@@ -273,7 +258,7 @@ stq_u(uint64_t val, uint64_t * p)
ptr-x = val;
}
-static __inline__ void
+static inline void
stl_u(uint32_t val, uint32_t * p)
{
struct __una_u32 *ptr = (struct __una_u32 *) p;
@@ -281,7 +266,7 @@ stl_u(uint32_t val, uint32_t * p)
ptr-x = val;
}
-static __inline__ void
+static inline void
stw_u(uint16_t val, uint16_t * p)
{
struct __una_u16 *ptr = (struct __una_u16 *) p;
@@ -292,7 +277,7 @@ stw_u(uint16_t val, uint16_t * p)
#include string.h /* needed for memmove */
-static __inline__ uint64_t
+static inline uint64_t
ldq_u(uint64_t * p)
{
uint64_t ret;
@@ -301,7 +286,7 @@ ldq_u(uint64_t * p)
return ret;
}
-static __inline__ uint32_t
+static inline uint32_t
ldl_u(uint32_t * p)
{
uint32_t ret;
@@ -310,7 +295,7 @@ ldl_u(uint32_t * p)
return ret;
}
-static __inline__ uint16_t
+static inline uint16_t
ldw_u(uint16_t * p)
{
uint16_t ret;
@@ -319,7 +304,7 @@ ldw_u(uint16_t * p)
return ret;
}
-static __inline__ void
+static inline void
stq_u(uint64_t val, uint64_t * p)
{
uint64_t tmp = val;
@@ -327,7 +312,7 @@ stq_u(uint64_t val, uint64_t * p)
memmove(p, tmp, sizeof(*p));
}
-static __inline__ void
+static inline void
stl_u(uint32_t val, uint32_t * p)
{
uint32_t tmp = val;
@@ -335,7 +320,7 @@ stl_u(uint32_t val, uint32_t * p)
memmove(p, tmp, sizeof(*p));
}
-static __inline__ void
+static inline void
stw_u(uint16_t val, uint16_t * p)
{
uint16_t tmp = val;
@@ -362,37 +347,37 @@ extern _X_EXPORT unsigned int _inb(unsigned long port);
extern _X_EXPORT unsigned int _inw(unsigned long port);
extern _X_EXPORT unsigned int _inl(unsigned long port);
-static __inline__ void
+static inline void
outb(unsigned long port, unsigned char val)
{
_outb(val, port);
}
-static __inline__ void
+static inline void
outw(unsigned long port, unsigned short val)
{
_outw(val, port);
}
-static __inline__ void
+static inline void
outl(unsigned long port, unsigned int val)
{
_outl(val, port);
}
-static __inline__ unsigned int
+static inline unsigned int
inb(unsigned long port)
{
return _inb(port);
}
-static __inline__ unsigned int
+static inline unsigned int
inw(unsigned long port)
{
return _inw(port);
}
-static __inline__ unsigned int
+static inline unsigned int
inl(unsigned long port)
{
return _inl(port);
@@ -425,25 +410,25 @@ extern _X_EXPORT unsigned int inl(unsigned int port);
#include inttypes.h
-static __inline__ void
+static inline void
outb(unsigned short port, unsigned char val)
{
__asm__ __volatile__(outb %0,%1::a(val), d(port));
}
-static __inline__ void
+static inline
Re: [PATCH synaptics] conf: the bcm5974 doesn't have Apple in the product name
#part sign=pgpmime On Fri, 23 Mar 2012 15:49:39 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: But it's still a single-button device from the known fruit manufacturer. This definitely helps with my machine -- it gets rid of a frequently annoying habit where the driver generated button 3 events after a click-drag operation. -- keith.pack...@intel.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
Re: [RFC] server-private and public header separation
#part sign=pgpmime On Fri, 23 Mar 2012 14:25:44 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Is that something we want? Should we should be splitting the files apart instead? -- keith.pack...@intel.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
Re: Stable branch reformatting issues
On Mon, Mar 19, 2012 at 06:58:59PM -0700, Chase Douglas wrote: I think that's a bit overkill. If we are going to reformat the 1.11 and earlier branches, then we might as well leave it at that and let the downstreams worry about it. Or, actually have someone maintain a pre-formatted branch. However, adding another level of stable branches (and releases?) that differ from the main stable branches could get very confusing. Fwiw, once Ubuntu 12.04 is out, it's probably unlikely we'd be doing much beyond security fixes for earlier xservers, so the odd patch needing a reformat is not going to be a big deal. If it helps upstream to reformat their stable series, we can cope with deformatting on our end. Granted, this issue will apply for Precise's 1.11 xserver, which I do hope we can continue to pull fixes into more actively. However I suspect most of the changes we'll see will be on the input side, which is 1.12. (I'm presuming we'll reformat the input patches we're carrying to match upstream?) Bryce ___ 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: [RFC] server-private and public header separation
On 23/03/12 16:37 , Keith Packard wrote: #part sign=pgpmime On Fri, 23 Mar 2012 14:25:44 +1000, Peter Huttererpeter.hutte...@who-t.net wrote: Is that something we want? Should we should be splitting the files apart instead? Good point, but that would only get us half-way. We currently export things like the GrabRec as well, just because they are in the same header. These could be moved into a private header. For other structs like the DeviceIntRec, we want only parts to be exposed to the driver so we either need the private structs, opaque structs + API or conditional compilation. 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
indent quirks
Is there a way we can tweak indent to not mess up blocks like this:
} known_numeric_keys[] = {
-{65, XK_period, XK_KP_Decimal},
-{67, XK_asterisk, XK_KP_Multiply},
-{69, XK_plus, XK_KP_Add},
-{75, XK_slash, XK_KP_Divide},
-{76, 0x0103, XK_KP_Enter},
-{78, XK_minus, XK_KP_Subtract},
-{81, XK_equal, XK_KP_Equal},
-{82, XK_0, XK_KP_0},
-{83, XK_1, XK_KP_1},
-{84, XK_2, XK_KP_2},
-{85, XK_3, XK_KP_3},
-{86, XK_4, XK_KP_4},
-{87, XK_5, XK_KP_5},
-{88, XK_6, XK_KP_6},
-{89, XK_7, XK_KP_7},
-{91, XK_8, XK_KP_8},
-{92, XK_9, XK_KP_9},
-};
+{
+65, XK_period, XK_KP_Decimal}, {
+67, XK_asterisk, XK_KP_Multiply}, {
+69, XK_plus, XK_KP_Add}, {
+75, XK_slash, XK_KP_Divide}, {
+76, 0x0103, XK_KP_Enter}, {
+78, XK_minus, XK_KP_Subtract}, {
+81, XK_equal, XK_KP_Equal}, {
+82, XK_0, XK_KP_0}, {
___
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: [RFC] server-private and public header separation
On 3/22/12, Chase Douglas chase.doug...@canonical.com wrote: On 03/22/2012 09:25 PM, Peter Hutterer wrote: This patch introduces a new define __XSERVER__ that we can use in the sdk headers. Obviously the real integration will be a tad harder as there are other headers that are installed outside of include/. But the gist is that anything between ifdef __XSERVER__ disappears on install, (in)effectively hiding it. This implementation would make the struct size look different between the server and the client. I think that would likely end up causing some bad memory corruption bugs sometime down the line. These aren't protocol-visible structs, so clients aren't affected. Unless you meant drivers? Clearly any struct that drivers allocate directly, or that drivers do pointer math on such as array indexing, can't get this treatment. Those are the only bad cases though, I think? Jamey ___ 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: [RFC] server-private and public header separation
On 03/23/2012 07:14 AM, Jamey Sharp wrote: On 3/22/12, Chase Douglas chase.doug...@canonical.com wrote: On 03/22/2012 09:25 PM, Peter Hutterer wrote: This patch introduces a new define __XSERVER__ that we can use in the sdk headers. Obviously the real integration will be a tad harder as there are other headers that are installed outside of include/. But the gist is that anything between ifdef __XSERVER__ disappears on install, (in)effectively hiding it. This implementation would make the struct size look different between the server and the client. I think that would likely end up causing some bad memory corruption bugs sometime down the line. These aren't protocol-visible structs, so clients aren't affected. Unless you meant drivers? Clearly any struct that drivers allocate directly, or that drivers do pointer math on such as array indexing, can't get this treatment. Those are the only bad cases though, I think? I did mean drivers, not clients. Sorry! If you apply this to some structs but not others based on a rule like: if the driver allocates the struct directly, then don't, you'll likely screw up at some point. That rule alone isn't enough though. If any structures are in arrays, like input valuator classes for example, they must have the correct size in the public ABI too. -- Chase ___ 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: [RFC] server-private and public header separation
On 03/22/2012 11:07 PM, Peter Hutterer wrote:
On Thu, Mar 22, 2012 at 10:48:53PM -0700, Chase Douglas wrote:
On 03/22/2012 09:25 PM, Peter Hutterer wrote:
This is just a quickfire patch to show the principle, it has not been tested
much. Plus, it's more of an idea right now, not sure if I'll find the time
to do it.
Right now, we export virtually everything including the gory bits of every
struct. Which causes us to break the ABI whenever we so much as look at a
struct (see the per-device-idlecounters for example).
This patch introduces a new define __XSERVER__ that we can use in the sdk
headers. Obviously the real integration will be a tad harder as there are
other headers that are installed outside of include/. But the gist is that
anything between ifdef __XSERVER__ disappears on install, (in)effectively
hiding it.
It's going to be painful defining what goes in and what doesn't, but maybe,
just maybe, it'll be useful in the long term.
Is that something we want?
---
include/Makefile.am |8
include/dix-config.h.in |3 +++
include/inputstr.h | 27 +++
3 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/include/Makefile.am b/include/Makefile.am
index 972f403..3e183db 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -71,3 +71,11 @@ EXTRA_DIST = \
eventconvert.h eventstr.h inpututils.h \
protocol-versions.h \
xsha1.h
+
+
+unifdef_headers: $(sdk_HEADERS)
+ for file in $(sdk_HEADERS); do \
+ (cd $(DESTDIR)$(sdkdir) unifdef -U__XSERVER__ -o $$file.tmp
$$file; mv $$file.tmp $$file) \
+ done
+
+install-data-hook: unifdef_headers
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 3fb6413..9b362c6 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -3,6 +3,9 @@
#ifndef _DIX_CONFIG_H_
#define _DIX_CONFIG_H_
+/* XServer-internal */
+#define __XSERVER__ 1
+
/* Support BigRequests extension */
#undef BIGREQS
diff --git a/include/inputstr.h b/include/inputstr.h
index 5a38924..a4f549c 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -529,19 +529,8 @@ typedef struct _SpriteInfoRec {
typedef struct _DeviceIntRec {
DeviceRec public;
DeviceIntPtr next;
-Bool startup; /* true if needs to be turned on at
- server initialization time */
-DeviceProc deviceProc; /* proc(DevicePtr, DEVICE_xx). It is
- used to initialize, turn on, or
- turn off the device */
-Bool inited;/* TRUE if INIT returns Success */
-Bool enabled; /* TRUE if ON returns Success */
-Bool coreEvents;/* TRUE if device also sends core */
-GrabInfoRec deviceGrab; /* grab on the device */
-int type; /* MASTER_POINTER, MASTER_KEYBOARD, SLAVE
*/
-Atom xinput_type;
-char *name;
int id;
+char *name;
KeyClassPtr key;
ValuatorClassPtr valuator;
TouchClassPtr touch;
@@ -554,6 +543,19 @@ typedef struct _DeviceIntRec {
StringFeedbackPtr stringfeed;
BellFeedbackPtr bell;
LedFeedbackPtr leds;
+
+#ifdef __XSERVER__
+Bool startup; /* true if needs to be turned on at
+ server initialization time */
+DeviceProc deviceProc; /* proc(DevicePtr, DEVICE_xx). It is
+ used to initialize, turn on, or
+ turn off the device */
+Bool inited;/* TRUE if INIT returns Success */
+Bool enabled; /* TRUE if ON returns Success */
+Bool coreEvents;/* TRUE if device also sends core */
+GrabInfoRec deviceGrab; /* grab on the device */
+int type; /* MASTER_POINTER, MASTER_KEYBOARD, SLAVE
*/
+Atom xinput_type;
struct _XkbInterest *xkb_interest;
char *config_info; /* used by the hotplug layer */
ClassesPtr unused_classes; /* for master devices */
@@ -593,6 +595,7 @@ typedef struct _DeviceIntRec {
int xtest_master_id;
struct _SyncCounter *idle_counter;
+#endif
} DeviceIntRec;
typedef struct {
This implementation would make the struct size look different between
the server and the client. I think that would likely end up causing some
bad memory corruption bugs sometime down the line.
I would suggest using the pimpl idiom, where you have a public struct
with a pointer to a private data struct. The pointer is still public,
but the data hidden behind the pointer isn't. The private structure
definition could be provided in a struct within the __XSERVER__
conditional macros so it's filtered out at install time.
I do think this is valuable. The scope of the ABI today is *huge*
because we don't hide anything.
Re: indent quirks
Twas brillig at 02:44:41 23.03.2012 UTC-07 when jerem...@apple.com did gyre and gimble: JH Is there a way we can tweak indent to not mess up blocks like this: I had to resort to post-processing script recently, exactly for this issue. -- pgpzeQ4QCCPnj.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: indent quirks
Hi, On 23 March 2012 15:13, Mikhail Gusarov dotted...@dottedmag.net wrote: Twas brillig at 02:44:41 23.03.2012 UTC-07 when jerem...@apple.com did gyre and gimble: JH Is there a way we can tweak indent to not mess up blocks like this: I had to resort to post-processing script recently, exactly for this issue. Same. I fiddled around and read the manpage inside out but couldn't find a way to make it not screw up initialisers like that, so had to do the rest with manual cleanup. Cheers, Daniel ___ 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: [RFC] server-private and public header separation
#part sign=pgpmime On Fri, 23 Mar 2012 18:30:30 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Good point, but that would only get us half-way. We currently export things like the GrabRec as well, just because they are in the same header. These could be moved into a private header. For other structs like the DeviceIntRec, we want only parts to be exposed to the driver so we either need the private structs, opaque structs + API or conditional compilation. So we need a DeviceIntIntRec that includes DeviceIntRec? Or should we move a bunch of the stuff that is currently in DeviceIntRec over to DeviceRec? Neither of those options sounds like much fun at all, the former would preserve existing API compatibility, albeit with a comedic naming effect (DeviceIntNoSeriouslyNotPublicRec...) -- keith.pack...@intel.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
Re: indent quirks
#part sign=pgpmime On Fri, 23 Mar 2012 15:45:42 +, Daniel Stone dan...@fooishbar.org wrote: Hi, On 23 March 2012 15:13, Mikhail Gusarov dotted...@dottedmag.net wrote: Twas brillig at 02:44:41 23.03.2012 UTC-07 when jerem...@apple.com did gyre and gimble: JH Is there a way we can tweak indent to not mess up blocks like this: I had to resort to post-processing script recently, exactly for this issue. Same. I fiddled around and read the manpage inside out but couldn't find a way to make it not screw up initialisers like that, so had to do the rest with manual cleanup. Yeah, if you come up with a script that fixes things, we can apply that. Alternatively, just post cleanup patches and we'll merge them in and hope that we don't impact cross-version patches too much. Fixing 20 years of format neglect isn't going to be completely pain-free... -- keith.pack...@intel.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
Re: indent quirks
Keith Packard kei...@keithp.com writes: Yeah, if you come up with a script that fixes things, we can apply that. Alternatively, just post cleanup patches and we'll merge them in and hope that we don't impact cross-version patches too much. Fixing 20 years of format neglect isn't going to be completely pain-free... FWIW, when I fixed up formatting in pixman, this program: http://uncrustify.sourceforge.net/ worked significantly better than indent. Soren ___ 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: C99 inline keyword
On 03/22/12 02:50 AM, Tomas Carnecky wrote: These two patches replace all custom inline keywords with a plain `inline`, while still maintaining backwards compatibility through a autoconf macro. For both patches: Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com And I'm in favor of the concept in general, but before anyone goes off to do this to all our other modules, I do think we need to stick to use of _X_INLINE in headers exposed to clients. For any internal headers, server-side headers, or direct use in .c files, using just plain inline requiring AC_C_INLINE is great, but we know there's a ton of existing X clients which aren't built with autoconf or C99 compilers, and we don't want to break them. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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 xf86-input-synaptics 1/2] Count number of multitouch touches for multitouch finger count
The evdev protocol only goes up to three touches for non-multitouch
devices. If you perform a four touch tap, the finger count will only go
up to three touches if you roll your fingers, or will always be 0 if all
four touches land at the same time.
This change ensures the correct finger count is reported.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
I test build with HAVE_MULTITOUCH undefined to be sure it didn't break
anything.
src/eventcomm.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/eventcomm.c b/src/eventcomm.c
index 3721c91..b485377 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -72,6 +72,7 @@ struct eventcomm_proto_data
int axis_map[MT_ABS_SIZE];
int cur_slot;
ValuatorMask **last_mt_vals;
+int num_touches;
#endif
};
@@ -565,6 +566,7 @@ EventProcessTouchEvent(InputInfoPtr pInfo, struct
SynapticsHwState *hw,
if (ev-value = 0)
{
hw-slot_state[slot_index] = SLOTSTATE_OPEN;
+proto_data-num_touches++;
if (slot_index = 0)
valuator_mask_copy(hw-mt_mask[slot_index],
@@ -574,7 +576,10 @@ EventProcessTouchEvent(InputInfoPtr pInfo, struct
SynapticsHwState *hw,
Attempted to copy values from out-of-range
slot, touch events may be incorrect.\n);
} else
+{
hw-slot_state[slot_index] = SLOTSTATE_CLOSE;
+proto_data-num_touches--;
+}
} else
{
int map = proto_data-axis_map[ev-code - ABS_MT_TOUCH_MAJOR];
@@ -607,10 +612,17 @@ EventProcessTouchEvent(InputInfoPtr pInfo, struct
SynapticsHwState *hw,
* @param comm Assembled information from previous events.
* @return The number of fingers currently set.
*/
-static int count_fingers(const struct CommData *comm)
+static int count_fingers(InputInfoPtr pInfo, const struct CommData *comm)
{
+SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
+struct eventcomm_proto_data *proto_data = priv-proto_data;
int fingers = 0;
+#ifdef HAVE_MULTITOUCH
+if (priv-has_touch)
+return proto_data-num_touches;
+#endif
+
if (comm-oneFinger)
fingers = 1;
else if (comm-twoFingers)
@@ -653,7 +665,7 @@ EventReadHwState(InputInfoPtr pInfo,
case EV_SYN:
switch (ev.code) {
case SYN_REPORT:
- hw-numFingers = count_fingers(comm);
+ hw-numFingers = count_fingers(pInfo, comm);
hw-millis = 1000 * ev.time.tv_sec + ev.time.tv_usec / 1000;
SynapticsCopyHwState(hwRet, hw);
return TRUE;
--
1.7.9.1
___
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 xf86-input-synaptics 2/2] Do not perform a tap action when more than three touches
Though this looks like a behavior change, it really isn't since the
maximum tap_max_fingers that was previously possible was already handled.
The only real change is that if a tap is recognized but the
tap_max_fingers is zero, a tap will no longer be emitted. This shouldn't
happen in the real world.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
In Unity we have a four tap gesture to show/hide the dash. Without this
fix, the dash will often appear and disappear because Unity got the four
tap gesture and then synaptics sends a button click.
src/synaptics.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/synaptics.c b/src/synaptics.c
index f07fd13..99b5085 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -1798,7 +1798,6 @@ SelectTapButton(SynapticsPrivate *priv, edge_type edge)
switch (priv-tap_max_fingers) {
case 1:
-default:
switch (edge) {
case RIGHT_TOP_EDGE:
DBG(7, right top edge\n);
@@ -1830,6 +1829,9 @@ SelectTapButton(SynapticsPrivate *priv, edge_type edge)
DBG(7, three finger tap\n);
tap = F3_TAP;
break;
+default:
+priv-tap_button = 0;
+return;
}
priv-tap_button = priv-synpara.tap_action[tap];
--
1.7.9.1
___
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: indent quirks
On Fri, 2012-03-23 at 18:05 +0100, Søren Sandmann wrote: Keith Packard kei...@keithp.com writes: Yeah, if you come up with a script that fixes things, we can apply that. Alternatively, just post cleanup patches and we'll merge them in and hope that we don't impact cross-version patches too much. Fixing 20 years of format neglect isn't going to be completely pain-free... FWIW, when I fixed up formatting in pixman, this program: http://uncrustify.sourceforge.net/ worked significantly better than indent. Good tip I will try that ! it is packaged for Debian , Fedora ... I just had to do: yum install uncrustify.x86_64 Thanks, -- Sérgio M. B. ___ 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 gccmakedep] Add parsing of GCC option '-std='.
Especially useful when forcing language standards. Correct error when using experimental code in GCC (-std=c++0x or -std=gnu++0x.) Signed-off-by: Anderson Luiz da Silva anderson.si...@autotrac.com.br --- gccmakedep.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gccmakedep.in b/gccmakedep.in index 860d102..0c11306 100644 --- a/gccmakedep.in +++ b/gccmakedep.in @@ -31,7 +31,7 @@ while [ $# != 0 ]; do endmarker= else case $1 in - -D*|-I*|-U*) + -D*|-I*|-U*|-std=*) # arg may contain single quotes qarg=`echo $1 | sed s/'/'''/g` args=$args '$qarg' -- 1.7.1 Esta mensagem e qualquer anexo a ela são documentos confidenciais e direcionados exclusivamente ao(s) destinatário(s). Qualquer uso, desvio, sonegação, supressão, revelação ou divulgação não autorizada é proibida e sujeita às sanções e/ou reparações legais por ato ilícito (Código Penal, Artigos 151 e 152). Caso não seja um dos destinatários expressamente indicados, por favor entre em contato com o remetente, respondendo este e-mail e destrua quaisquer cópias da mensagem original. Qualquer opinião, crítica ou análise descrita nesta mensagem é de responsabilidade única do remetente, a menos quando estiver explicitamente expresso que seja da empresa remetente. This message and any attachment are confidential information for the sole use of the intended recipients. Any unauthorized use, deviation, withholdment, suppression, disclosure or distribution is prohibited and is subjected to legal sanctions and/or compensations per illicit act (Penal Code, articles 151 and 152). If you are not one of the intended recipients, please contact the sender by reply e-mail and destroy any copy of the original message. Any view, comment or analysis expressed in this message is sole responsibility from the sender, except when it’s specifically expressed that it’s the view, comment or analysis of the company. ___ 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] Added an xorg configuration file snippet to disable grabbing of virtual test devices. Signed-off-by: Thomas Voß tvoss@tvoss-ThinkPad-X121e.(none)
On 03/23/2012 11:50 AM, Julien Cristau wrote: On Thu, Mar 22, 2012 at 14:59:19 -0400, thomas.v...@canonical.com wrote: From: Thomas Voß tvoss@tvoss-ThinkPad-X121e.(none) --- data/Makefile.am |2 +- data/X11/xorg.conf.d/99-virtual-test-devices.conf |4 2 files changed, 5 insertions(+), 1 deletions(-) create mode 100644 data/X11/xorg.conf.d/99-virtual-test-devices.conf care to explain why this is needed in the commit message? I'm going to commit this, so I'll add the message when I do. The issue is when you are running a dummy server and instantiating uinput virtual trackpad devices, you have contention between the dummy server and the real server running your desktop. Usually, the desktop X server wins and grabs the evdev event node. The test dummy server then fails to open the event node and your tests fail. I have been resorting to VT switching to run trackpad tests :). -- Chase ___ 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: [RFC] server-private and public header separation
One lower-impact compromise would be to simply rename private fields of the structs to something obviously wrong when compiling without __XSERVER__. Easy-ish patches to get right, and preserves ABI compatibility. If you generate the secret names with a macro, you can change them regularly to ensure no one is building against them :-). Bart On Fri, Mar 23, 2012 at 9:23 AM, Keith Packard kei...@keithp.com wrote: #part sign=pgpmime On Fri, 23 Mar 2012 18:30:30 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Good point, but that would only get us half-way. We currently export things like the GrabRec as well, just because they are in the same header. These could be moved into a private header. For other structs like the DeviceIntRec, we want only parts to be exposed to the driver so we either need the private structs, opaque structs + API or conditional compilation. So we need a DeviceIntIntRec that includes DeviceIntRec? Or should we move a bunch of the stuff that is currently in DeviceIntRec over to DeviceRec? Neither of those options sounds like much fun at all, the former would preserve existing API compatibility, albeit with a comedic naming effect (DeviceIntNoSeriouslyNotPublicRec...) -- keith.pack...@intel.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 ___ 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: XQuartz tablet mouse events are at the wrong location and other Xinput headaches
On Mar 21, 2012, at 00:23, Jeremy Huddleston wrote:
On Mar 20, 2012, at 8:07 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
On Sat, Mar 17, 2012 at 12:49:53AM -0700, Jeremy Huddleston wrote:
Here are some examples. The first is just valuator_mask_get_double(..., #)
for the valuators of the event we enqueue with QueuePointerEvents(pDev,
ev_type, ev_button, POINTER_ABSOLUTE, valuators). The second is from the
corresponding event sent to 'xinput test pointer'.
Valuators: {32777.67,0.00,0.00,22526.687460,0.00}
motion a[0]=16398 a[1]=0 a[2]=0 a[3]=22526 a[4]=0
Valuators: {32777.67,65510.186667,0.00,-23552.718772,-12288.375011}
motion a[0]=16398 a[1]=65510 a[2]=0 a[3]=-23552 a[4]=-12288
Valuators: {65526.27,21.33,0.00,39935.218726,3070.093692}
motion a[0]=65521 a[1]=21 a[2]=0 a[3]=39935 a[4]=3070
Valuators: {65526.27,65471.36,0.00,61439.874996,-21504.656270}
motion a[0]=65521 a[1]=65471 a[2]=0 a[3]=61439 a[4]=-21504
I just tried this with a uinput test device that submits exactly the same
values and has the same button/axes as the darwinTablet (had to set
BTN_STYLUS to avoid evdev treating it as touchpad but that does not
affect any coordinate handling in the server).
The coordinates are identical, so I'm a bit confused where the scaling comes
from. I noticed that the debug output displays pointer_x, pointer_y, but not
the valuators[] values you actually submit to the dix.
The copy/pasted text above actually *are* the valuators sent to the dix. The
debug printing does include pointer_x and pointer_y, but I omitted those in
the information above. From darwinEvents.c[1], you can see the Valuators
above match what we're sending to QueuePointerEvents:
DEBUG_LOG(Pointer (%lf, %lf), Valuators: {%lf,%lf,%lf,%lf,%lf}\n,
pointer_x, pointer_y,
valuator_mask_get_double(pmask, 0),
valuator_mask_get_double(pmask, 1),
valuator_mask_get_double(pmask, 2),
valuator_mask_get_double(pmask, 3),
valuator_mask_get_double(pmask, 4));
}
1:
http://cgit.freedesktop.org/~jeremyhu/xserver/tree/hw/xquartz/darwinEvents.c?h=server-1.13-appleid=5adf599c893e68a3057a6c4af507e4275dc6fca5
I traced it a bit further today, and the correct value for the valuator is
landing on the input queue and is set right in FP3232 in the xi event. In the
case below, I'm trying to send 32768. eventToRawEvent() gives us something
that looks right, but 16636 is still coming out the other end (xinput test
pen).
(gdb) bt
#0 eventToRawEvent (ev=0x106bc5248, xi=0x106bc50f8) at eventconvert.c:763
#1 0x00010017bb03 in EventToXI2 (ev=0x106bc5248, xi=0x106bc50f8) at
eventconvert.c:287
#2 0x00010016ffb3 in DeliverRawEvent (ev=0x106bc5248, device=0x103384e50)
at events.c:2299
#3 0x0001000df42a in ProcessOtherEvent (ev=0x106bc5248,
device=0x103384e50) at exevents.c:1738
#4 0x000100120a72 in ProcessPointerEvent (ev=0x106bc5248,
mouse=0x103384e50) at xkbAccessX.c:726
#5 0x0001001bf7d7 in mieqProcessDeviceEvent (dev=0x10303ca40,
event=0x1002fbc30, screen=0x100c17cf0) at mieq.c:549
#6 0x0001001bfaaa in mieqProcessInputEvents () at mieq.c:609
#7 0x000100017314 in ProcessInputEvents () at darwinEvents.c:386
#8 0x00010015d3ea in Dispatch () at dispatch.c:362
#9 0x00010003d532 in dix_main (argc=8, argv=0x7fff5fbff710,
envp=0x7fff5fbff670) at main.c:287
#10 0x00010001c9c0 in server_thread (arg=0x100c12a60) at quartzStartup.c:63
#11 0x7fff940d58bf in _pthread_start (self=0x106bc6000, kport=21511,
fun=0x10001c980 server_thread, funarg=0x100c12a60, stacksize=20,
pflags=67108864) at pthread.c:897
#12 0x7fff940d8b75 in thread_start () at thread_start.s:34
(gdb) print *ev
$36 = {
header = 255 '?',
type = ET_RawMotion,
length = 624,
time = 1103041104,
deviceid = 2,
sourceid = 8,
detail = {
button = 0,
key = 0
},
valuators = {
mask = \037\000\000\000,
data = {32768, 0, 0, 25598.781212805567, -16384.500015259255, 0 repeats 31
times},
data_raw = {32768, 0, 0, 25598.781212805567, -16384.500015259255, 0
repeats 31 times}
},
flags = 0
}
...
785 for (i = 0; i sizeof(ev-valuators.mask) * 8; i++)
(gdb) n
787 if (BitIsOn(ev-valuators.mask, i))
(gdb) n
789 SetBit(ptr, i);
(gdb) n
790 *axisval = double_to_fp3232(ev-valuators.data[i]);
(gdb) print ev-valuators.data[i]
$39 = 32768
(gdb) n
791 *axisval_raw = double_to_fp3232(ev-valuators.data_raw[i]);
(gdb) n
792 axisval++;
(gdb) print *axisval
$40 = {
integral = 32768,
frac = 0
}
(gdb) print *axisval_raw
$41 = {
integral = 32768,
frac = 0
}
...
Breakpoint 5, eventToRawEvent (ev=0x106bc5248, xi=0x106bc50f8) at
eventconvert.c:797
797 return Success;
(gdb) print *(FP3232*)(ptr + raw-valuators_len * 4)
$43 = {
integral = 32768,
frac = 0
}
I'd
Re: [PATCH] xrandr: move transform limit checking after scaling
Ping? On 03/20/2012 04:54 PM, Pierre-Loup A. Griffais wrote: Wasted a good chunk of time on that one. ___ 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: indent quirks
Yeah, our new indent policy butchers ObjC, unfortunately. On Mar 23, 2012, at 11:34, Sérgio Basto wrote: On Fri, 2012-03-23 at 18:05 +0100, Søren Sandmann wrote: Keith Packard kei...@keithp.com writes: Yeah, if you come up with a script that fixes things, we can apply that. Alternatively, just post cleanup patches and we'll merge them in and hope that we don't impact cross-version patches too much. Fixing 20 years of format neglect isn't going to be completely pain-free... FWIW, when I fixed up formatting in pixman, this program: http://uncrustify.sourceforge.net/ worked significantly better than indent. Good tip I will try that ! it is packaged for Debian , Fedora ... I just had to do: yum install uncrustify.x86_64 Thanks, -- Sérgio M. B. ___ 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 ___ 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] XQuartz changes which have been pending, rebased against indent
The following changes since commit a7eac500e652f30deffd9dc5e623fab701077738: Merge branch 'per-device-sync-counters' into for-keith (2012-03-22 13:13:07 +1000) are available in the git repository at: git://people.freedesktop.org/~jeremyhu/xserver master for you to fetch changes up to 3e65135fe7b0976703e4f0b512ff842bb80a08b2: XQuartz: Detect FatalErrors on startup to prevent tight crash loops (2012-03-23 19:04:45 -0700) Jeremy Huddleston (6): XQuartz: Move our logs into an X11 subdirectory XQuartz: Xi: darwinPointer is now Relative XQuartz: Use doubles for input valuators XQuartz: Add a defaults option to disable the RENDER extension os: Pass the FatalError message to OsVendorFatalError XQuartz: Detect FatalErrors on startup to prevent tight crash loops hw/dmx/dmxinit.c |2 +- hw/dmx/dmxlog.c|3 - hw/kdrive/src/kdrive.c |2 +- hw/vfb/InitOutput.c|2 +- hw/xfree86/common/xf86Init.c |2 +- hw/xnest/Init.c|2 +- hw/xquartz/X11Application.h|4 + hw/xquartz/X11Application.m| 49 + .../Resources/English.lproj/Localizable.strings| Bin 4410 - 5454 bytes hw/xquartz/darwin.c| 22 ++-- hw/xquartz/darwinEvents.c | 115 +--- hw/xquartz/darwinEvents.h | 16 +-- hw/xwin/winerror.c |2 +- include/os.h |2 +- os/log.c | 18 +-- test/ddxstubs.c|2 +- 16 files changed, 146 insertions(+), 97 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: [PATCH] xrandr: move transform limit checking after scaling
#part sign=pgpmime
On Tue, 20 Mar 2012 16:54:52 -0700, Pierre-Loup A. Griffais
pgriff...@nvidia.com wrote:
Wasted a good chunk of time on that one.
From f1a65814f119cb83d16e15093e81946f3adcde61 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Tue, 20 Mar 2012 16:46:22 -0700
Subject: [PATCH] xrandr: move transform limit checking after scaling
This would trigger for legit scaled matrices, resulting in the wrong
extents getting computed.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
xrandr.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 35dff3e..622f6a9 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -432,14 +432,15 @@ transform_point (XTransform *transform, double *xp,
double *yp)
v = 0;
for (i = 0; i 3; i++)
v += (XFixedToDouble (transform-matrix[j][i]) * vector[i]);
- if (v 32767 || v -32767)
- return False;
result[j] = v;
}
if (!result[2])
return False;
-for (j = 0; j 2; j++)
+for (j = 0; j 2; j++) {
vector[j] = result[j] / result[2];
+if (vector[j] 32767 || vector[j] -32767)
+return False;
+}
Yeah, that looks right - transform from homogeneous back to pixel
coordinates before doing the range check.
Reviewed-by: Keith Packard kei...@keithp.com
(sorry I didn't see this on Tuesday, thanks for the ping!)
--
keith.pack...@intel.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
[Bug 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #10 from Michel Dänzer mic...@daenzer.net 2012-03-23 01:23:00 PDT --- Has anyone tried if this happens with the upstream 6.14.3 release, or possibly even older releases? If it doesn't, can someone bisect? I haven't seen this on any of my machines. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #11 from Ernst Sjöstrand ern...@gmail.com 2012-03-23 01:39:08 PDT --- So if I start a bisect it's xorg-driver-ati I should test? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #12 from Michel Dänzer mic...@daenzer.net 2012-03-23 02:19:38 PDT --- (In reply to comment #11) So if I start a bisect it's xorg-driver-ati I should test? Whichever of that or xserver / kernel you can find a good snapshot for. But the X driver seems most likely at this point. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #13 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de 2012-03-23 02:30:46 PDT --- Created attachment 58906 -- https://bugs.freedesktop.org/attachment.cgi?id=58906 another screenshot -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #14 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de 2012-03-23 02:31:10 PDT --- Created attachment 58907 -- https://bugs.freedesktop.org/attachment.cgi?id=58907 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #15 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de 2012-03-23 02:31:30 PDT --- Created attachment 58908 -- https://bugs.freedesktop.org/attachment.cgi?id=58908 Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de changed: What|Removed |Added CC||tk...@fachschaft.imn.htwk-l ||eipzig.de --- Comment #16 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de 2012-03-23 02:32:42 PDT --- Hi, attached some additional resources because i have those artifacts too. I am using latest 3.3.0 kernel, latest Oneiric + xorg-edgers ppa too (git versions). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #17 from piroxil...@gmail.com 2012-03-23 05:31:38 PDT --- It's not ounly in Gnome, but also both KDE, Xfce4, so the name of the topic is wrong. As I wrote in deleted duplication (47573) last stable version of driver works correctly. Also I need to mention that bug not always present, it something like time intervals when it always present and time when it absent at all. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #18 from Alex Deucher ag...@yahoo.com 2012-03-23 06:28:48 PDT --- For those using mesa from git or a 3.3 kernel, these might be 2D tiling related. See bug 47765. To check, use mesa 8.0 or older and make sure to remove the ColorTiling2D option from your config if you are using it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #19 from Alex Deucher ag...@yahoo.com 2012-03-23 07:34:54 PDT --- (In reply to comment #18) For those using mesa from git or a 3.3 kernel, these might be 2D tiling related. See bug 47765. To check, use mesa 8.0 or older and make sure to remove the ColorTiling2D option from your config if you are using it. BTW, this is only relevant for the r6xx+ asics, not older asics. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #20 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de 2012-03-23 08:48:12 PDT --- I am using a ATI RV516 [Radeon X1300/X1550 Series] - so the cause must be something else and it does happen with stock oneiric version and edgers driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47776] New: Choppy video playback
https://bugs.freedesktop.org/show_bug.cgi?id=47776 Bug #: 47776 Summary: Choppy video playback Classification: Unclassified Product: xorg Version: 7.6 (2010.12) Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/Radeon AssignedTo: xorg-driver-ati@lists.x.org ReportedBy: pumb...@gmail.com QAContact: xorg-t...@lists.x.org Choppy video playback with GNOME Shell, Unity, Gnome-fallback with compiz, but not with Unity 2D and Gnome-fallback without compiz on two machines (1. Laptop with ATI Radeon X200M, 2. Desktop system with ATI Radeon HD6450). Media players doesn't report dropped frames, CPU usage is well below 100%. Tested with a 720p x264 video at about ~6000kbps. See https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/961124. Tried Fedora 16 and the problem is the same. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #21 from Ernst Sjöstrand ern...@gmail.com 2012-03-23 13:01:54 PDT --- Actually I can reproduce this with Precise vanilla right now, only with Precise + edgers. Also if I have Precise + edgers and downgrade only libcairo I can't reproduce it... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #22 from Ernst Sjöstrand ern...@gmail.com 2012-03-23 13:44:05 PDT --- Sorry, meant: Actually I CAN'T reproduce this with Precise vanilla right now, only with Precise + edgers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
