Re: XI2 pointer emulation in more detail
On Sat, Nov 17, 2012 at 10:39:29AM -0600, Daniel Drake wrote: Hi, Thanks for all the informative blog posts such as this one: http://who-t.blogspot.com/2011/12/multitouch-in-x-pointer-emulation.html I'm trying to get my head around pointer emulation and touch-pointer interaction in a bit more detail. Would appreciate any guidance or followup posts :) This is all with xserver-1.13.0 patched with: Sync TouchListener memory allocation with population in TouchSetupListeners() Xi: Don't check for TOUCH_END, it's never set Xi: don't deliver TouchEnd to a client waiting for TouchBegin (#55738) Xi: Set modifier mask on touch events Xi: Update the device after delivering the emulated pointer event(#56558) remove init_event Update the MD's position when a touch event is received Don't use GetTouchEvents when replaying events Don't use GetTouchEvents in EmitTouchEnd Simplify GetTouchEvents Following the blog post, writing a simple non-touch XI2 listening app, quickly touching and releasing the screen generates: motion, button press, button release. All have XIPointerEmulated set. Now, when I make the app listen for touch events, the sequence changes, to: Motion (with XIPointerEmulated), TouchBegin, TouchEnd. The fact I received a Motion event seems in conflict with what is written: if your client selects for both touch and pointer events on a window, you will never see the emulated pointer events. Is this a bug? Here is the test app: http://dev.laptop.org/~dsd/20121117/xitouch.c Right, what happens is simple: for pointer-emulating touches, we need to move the cursor. That requires sending motion events. This should probably be fixed, we need a filter on the first client selecting for TouchUpdate _or_ MotionNotify and then discard the event if it's the former (and pretend we delivered). right now, we don't have that filter. but tbh, your app should not get too confused by this, it is just a state-less motion event after all. I couldn't find a mention of the general idea of the event stream changing when touch events are/aren't listened to in XI2proto.txt - am I missing something? (If not, I'll send a patch, once my understanding is complete) I can't remember if we've written it down, but the consensus was that if you're listening to touch events, you don't get pointer emulated events. one reason is that you can't associate touch points and pointer emulated events easily, the other obviously that if you're already listening for touch events, why would you need the pointer events. My next area of doubt is how touchscreen interaction should interact with the mouse cursor. In GNOME (fallback), when I place the mouse cursor inside a window, and then touch the screen in another part of the same window, the touch is registered as expected but the mouse cursor stays put. This behaviour changes when I add a second window into the mix. If I place the mouse cursor in one window, then touch into another window, the mouse cursor jumps to the touch point. Is there a reason for this difference in behaviour? no, this sounds like a bug. pointer emulation behaviour should be that only the first emulating touchpoint changes the pointer position, with subsequent touches not emulating. and a touchpoint is only emulating if there is no other touch point on that device when it starts. I might need more details though, how are you placing the pointer? with a mouse? Cheers, Peter In Sugar, even when touching within the same window where the mouse pointer is, the mouse pointer always jumps. This doesn't feel like the right behaviour for the user. The difference from GNOME may be related to the fact that we have some grabs set up, and we listen for touches, for our touch gesture implementation. Furthermore, this pointer-jumping behaviour is giving us problems, both in Sugar and GNOME. For example, position a window's close button directly on top of another window with a hover-sensitive widget. Touch-press the close button on the on-top window. The on-top window gets closed, and the implicit move of the mouse cursor now triggers the hover-event on the widget in the window below. This results in a strange touchscreen user experience and a variety of problems: http://bugs.sugarlabs.org/ticket/4068 Any thoughts/comments much appreciated. Thanks Daniel ___ 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: X Server want not start
On Mon, 19 Nov 2012 02:41:56 + (UTC) Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: It seems that the pastebin links have expired. It is usually a better idea to use attachments instead of pastebins where possible. Yes that's right. Ok the files as attachments at this mail. In your case, ensure that xf86-video-ati was rebuilt against the new xorg-server, and that KMS is enabled in your kernel. A grep for RADEON in your kernel config should result in this: Kernel .config # # Graphics support # CONFIG_AGP=y # CONFIG_AGP_ALI is not set CONFIG_AGP_ATI=y # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_I810=m CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m CONFIG_DRM_VMWGFX=m CONFIG_STUB_POULSBO=y CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y CONFIG_FB_HECUBA=m CONFIG_FB_SVGALIB=m # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y If the kernel is configured correctly, cat /proc/fb should return 0 radeondrmfb. gentoo-desk linux # cat /proc/fb 0 ATI Radeon 4966 Regards and Thank you for help Silvio Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard Option BlankTime 0 Option StandbyTime 0 Option SuspendTime 0 Option OffTime 0 EndSection Section ServerFlags Option BlankTime 0 Option StandbyTime 0 Option SuspendTime 0 Option OffTime 0 EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/misc/ FontPath /usr/share/fonts/TTF/ FontPath /usr/share/fonts/OTF/ FontPath /usr/share/fonts/Type1/ FontPath /usr/share/fonts/100dpi/ FontPath /usr/share/fonts/75dpi/ FontPath /usr/share/fonts/arabeyes-fonts/ FontPath /usr/share/fonts/arphicfonts/ FontPath /usr/share/fonts/bitstream-cyberbit/ FontPath /usr/share/fonts/dejavu/ FontPath /usr/share/fonts/droid/ FontPath /usr/share/fonts/freefonts/ FontPath /usr/share/fonts/intlfonts/ FontPath /usr/share/fonts/ipamonafont/ FontPath /usr/share/fonts/encodings/ FontPath /usr/share/fonts/ja-ipafonts/ FontPath /usr/share/fonts/kacst-fonts/ FontPath /usr/share/fonts/sil-arabicfonts/ FontPath /usr/share/fonts/terminus/ FontPath /usr/share/fonts/urw-fonts/ FontPath /usr/share/fonts/truetype/ EndSection Section Module Load glx Load record Load dri2 Load dbe Load extmod Load dri EndSection Section Extensions Option Composite Enable EndSection Section InputDevice Identifier Keyboard0 Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout de,fr,ma Option XkbVariant nodeadkeys EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model EndSection Section Monitor Identifier Monitor1 VendorName Monitor Vendor ModelNameMonitor Model EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz, ### percent: f% ### [arg]: arg optional #Option NoAccel # [bool] #Option SWcursor # [bool] #Option Dac6Bit # [bool] #Option Dac8Bit # [bool] #Option BusType # [str] #Option CPPIOMode #
Re: X Server want not start
On Mon, 2012-11-19 at 12:10 +0100, Silvio Siefke wrote: On Mon, 19 Nov 2012 02:41:56 + (UTC) Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: If the kernel is configured correctly, cat /proc/fb should return 0 radeondrmfb. gentoo-desk linux # cat /proc/fb 0 ATI Radeon 4966 That looks like radeonfb, which conflicts with radeon KMS. You can disable it at runtime by passing video=radeonfb:off on the kernel command line, or at build time by disabling CONFIG_FB_RADEON. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ 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: X Server want not start
Hello, On Mon, 19 Nov 2012 12:20:58 +0100 Michel Dänzer mic...@daenzer.net wrote: That looks like radeonfb, which conflicts with radeon KMS. You can disable it at runtime by passing video=radeonfb:off on the kernel command line, or at build time by disabling CONFIG_FB_RADEON. Ok i built the kernel new. That need little time, is a older PC with single CPU :) . Thank you for help and Greetings Silvio ___ 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: X Server want not start
Hello, just to make Michal's comment clearer, as kms includes a fb implementation, you cannot use both. either select fb or kms. for more info please consult http://en.gentoo-wiki.com/wiki/Radeon Dagg. From: Silvio Siefke siefke_lis...@web.de To: xorg@lists.x.org Sent: Monday, November 19, 2012 2:13 PM Subject: Re: X Server want not start Hello, On Mon, 19 Nov 2012 12:20:58 +0100 Michel Dänzer mic...@daenzer.net wrote: That looks like radeonfb, which conflicts with radeon KMS. You can disable it at runtime by passing video=radeonfb:off on the kernel command line, or at build time by disabling CONFIG_FB_RADEON. Ok i built the kernel new. That need little time, is a older PC with single CPU :) . Thank you for help and Greetings Silvio ___ 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: stompdagg...@yahoo.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
[ANNOUNCE] xscope 1.4
xscope is a program to monitor the connections between the X11 window server and a client program. Compared to 1.4 RC1 version fixes some bugs in building the transport code when not using libxtrans and adds a -V option to report the version number: Alan Coopersmith (5): Rename sockaddr_un variable from sun to saun to avoid conflict with #define sun Don't include Xtrans files if xtrans is disabled When not using xtrans, check if -lsocket -lnsl are needed for Solaris/SVR4 Add -V option to print version and exit xscope 1.4 Compared to 1.3.1, this release adds these new features: - RANDR decoding updated from just 0.x protocol to handle 1.0 - 1.4 - Atoms recorded from InternAtom GetAtomName to use for display in other requests referencing the atoms - Property requests now also show these property types in a more natural format instead of as just lists of bytes: UTF8_STRING, atoms, cardinals, integers, and windows - new -I command line flag to enter interactive mode immediately at startup - experimental support for reading a previously recorded file. If you run xscope -r -v0 xscope.raw, then you can later run xscope -f xscope.raw to decode the data. git tag: xscope-1.4 http://xorg.freedesktop.org/archive/individual/app/xscope-1.4.tar.bz2 MD5: 4fb4086e29af1b5b6d07d4d1ccbda5ca SHA1: 20a727f8925626d03112c67d88bb57cd343309f1 SHA256: eb4adf06f274bdd5d87b30367cd137b485b650b5dc6dc5ae1104bd8afaf22b1f http://xorg.freedesktop.org/archive/individual/app/xscope-1.4.tar.gz MD5: 1d9a27e5fd86ef88cb9bb7778c73b3cf SHA1: 7d01f9fa099a109f054664ac14133601c3326696 SHA256: c3554ebe098646e9ff1a08fc509cdfe7587898426fac81b0603c378201702270 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpqoxJd6w80d.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
[PATCH] dix: FakeClientID for implicit passive grabs
Using client-clientAsMask as resource for implicit passive grabs causes resource conflict with client-allocated resources. Freeing the passive grab frees all resources with that ID, so arbitrary resources can get freed while still in use. This causes random crashes. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Keith reminded me that FakeClientID() will re-use IDs already freed, so the dance with special IDs isn't necessary. Hidden bonus: this was my first attempt of this patch anyway and I've had 3 days without a crash with this patch. dix/events.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dix/events.c b/dix/events.c index 39350bc..81e3e01 100644 --- a/dix/events.c +++ b/dix/events.c @@ -1983,7 +1983,7 @@ ActivateImplicitGrab(DeviceIntPtr dev, ClientPtr client, WindowPtr win, return FALSE; tempGrab-next = NULL; tempGrab-device = dev; -tempGrab-resource = client-clientAsMask; +tempGrab-resource = FakeClientID(client-index); tempGrab-window = win; tempGrab-ownerEvents = (deliveryMask OwnerGrabButtonMask) ? TRUE : FALSE; tempGrab-eventMask = deliveryMask; -- 1.7.11.7 ___ 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: mach64 broken with xserver 1.13 ?
On 18/11/12 12:00 PM, xorg-devel-requ...@lists.x.org wrote: I'm seeing the xf86-video-mach64 6.9.3 crashing with xserver 1.13 on OpenBSD, both on sparc64 and intel (x86_64) machines. here's some debugging information. Apparently something in devPrivate doesn't get initialized properly, but I'm not able to figure out what. Any suggestion ? I'd bet its a long standing exa bug somewhere or maybe a mach64 exa specific problem. Since on previous servers mach64 would default to XAA, but that got removed. Dave. This summer I suspected that such a bug would hit mach64 so I made this patch: https://bugs.freedesktop.org/show_bug.cgi?id=51137 I didn't push to get it accepted because I couldn't test it and I was having a hard enough time working on the patch I could test. signature.asc Description: OpenPGP digital 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: mach64 broken with xserver 1.13 ?
On Sun, Nov 18, 2012 at 11:25:26PM -0800, Connor Behan wrote: On 18/11/12 12:00 PM, xorg-devel-requ...@lists.x.org wrote: I'm seeing the xf86-video-mach64 6.9.3 crashing with xserver 1.13 on OpenBSD, both on sparc64 and intel (x86_64) machines. here's some debugging information. Apparently something in devPrivate doesn't get initialized properly, but I'm not able to figure out what. Any suggestion ? I'd bet its a long standing exa bug somewhere or maybe a mach64 exa specific problem. Since on previous servers mach64 would default to XAA, but that got removed. Dave. This summer I suspected that such a bug would hit mach64 so I made this patch: https://bugs.freedesktop.org/show_bug.cgi?id=51137 I didn't push to get it accepted because I couldn't test it and I was having a hard enough time working on the patch I could test. Thank you. I cannot be in front of the machine to confirm that stuff on screen is correct before wednesday, but at least I can start the Xorg from a remote login and confirm that it doesn't crash anymore. -- Matthieu Herrb ___ 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] dix: FakeClientID for implicit passive grabs
Hi, On 19 November 2012 17:22, Peter Hutterer peter.hutte...@who-t.net wrote: Using client-clientAsMask as resource for implicit passive grabs causes resource conflict with client-allocated resources. Freeing the passive grab frees all resources with that ID, so arbitrary resources can get freed while still in use. This causes random crashes. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Daniel Stone dan...@fooishbar.org 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: [PATCH 0/3] More extmod fallout
Daniel, Unfortunately, I couldn't really test DMX too much, as every single mouse click warps the pointer back to (0,0). Oh well. I have hacked around this in my personal copy of 1.13[0] by recording the last 'absolute' location from the previous enqueMotion, and passing that location with the ButtonPress/ButtonRelease events. I doubt this meets the requirements to be pushed upstream without tidying though... Ali [0]: https://github.com/alown/xorg-server/commit/e89bc9e54346028a571940c0f47161fbb6439d03 ___ 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
[REMINDER] LockMods can lock another group on key release #865
Dear developers, Saturday last week, I sent a four-part xkb-related patch to address issue #865. The patch has not been reviewed yet. Can someone have a look please? I also notice that no part of the patch went into patchwork, which I thought would happen automatically. Actually, nothing went to patchwork between 8 November and 14 November. Do I have to resend the patch? Regards, Andreas ___ 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: [REMINDER] LockMods can lock another group on key release #865
Hi Andreas, On 20 November 2012 06:06, Andreas Wettstein wettstein...@solnet.ch wrote: Saturday last week, I sent a four-part xkb-related patch to address issue #865. The patch has not been reviewed yet. Can someone have a look please? I've been hoping to review this but haven't had the time yet. I really really like the general approach though, and will definitely merge it at some stage. 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: [PATCH] libXt: util: don't link makestrs with target cflags
Hello, Anyone for this basic libXt patch? Thanks, Thomas On Fri, 16 Nov 2012 10:41:06 +0100, Thomas Petazzoni wrote: The line: AM_CFLAGS = $(XT_CFLAGS) in util/Makefile.am is wrong because it adds target cflags to the compilation of makestrs, which is built for the build machine, which leads to build failures when cross-compiling. We also remove the inclusion of X11/Xos.h from makestrs.c, because it was the only non-standard header being included (and therefore possibly requiring special cflags), but it was in reality not useful at all to build makestrs.c. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- util/Makefile.am |1 - util/makestrs.c |1 - 2 files changed, 2 deletions(-) diff --git a/util/Makefile.am b/util/Makefile.am index dedfa6b..cc6f3fc 100644 --- a/util/Makefile.am +++ b/util/Makefile.am @@ -10,7 +10,6 @@ EXTRA_DIST = \ StrDefs.ht \ string.list -AM_CFLAGS = $(XT_CFLAGS) makestrs_SOURCES = makestrs.c diff --git a/util/makestrs.c b/util/makestrs.c index a52866a..00c861f 100644 --- a/util/makestrs.c +++ b/util/makestrs.c @@ -27,7 +27,6 @@ in this Software without prior written authorization from The Open Group. /* Constructs string definitions */ #include stdio.h -#include X11/Xos.h #include stdlib.h #include unistd.h -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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: [PATCH 0/3] More extmod fallout
On Mon, Nov 19, 2012 at 04:00:57PM +1100, Daniel Stone wrote: Hi, These three patches fix some fallout from extmod; the first two are just cleanup, whereas the second two restore the DMX extensions which are pretty vital to it actually running. Reviewed-by: Peter Hutterer peter.hutte...@who-t.net for the series. Cheers, Peter Unfortunately, I couldn't really test DMX too much, as every single mouse click warps the pointer back to (0,0). Oh well. 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 ___ 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] dix: Save touchpoint last coordinates before transform. #49347
DDXTouchPointInfoRec.valuators used to store axis values after transform.
This resulted in Coordinate Transformation Matrix
being applied multiple times to the last coordinates,
in the case when only pressure changes in the last touch event.
Changed DDXTouchPointInfoRec.valuators to store values before transform.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=49347
Signed-off-by: Yuly Novikov ynovi...@chromium.org
---
dix/getevents.c| 22 +-
include/inputstr.h |2 +-
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index 2a686e8..b52efc5 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1940,32 +1940,28 @@ GetTouchEvents(InternalEvent *events, DeviceIntPtr dev,
uint32_t ddx_touchid,
default:
return 0;
}
-if (t-mode == XIDirectTouch !(flags TOUCH_CLIENT_ID)) {
-if (!valuator_mask_isset(mask, 0))
-valuator_mask_set_double(mask, 0,
- valuator_mask_get_double(touchpoint.ti-
- valuators, 0));
-if (!valuator_mask_isset(mask, 1))
-valuator_mask_set_double(mask, 1,
- valuator_mask_get_double(touchpoint.ti-
- valuators, 1));
-}
/* Get our screen event co-ordinates (root_x/root_y/event_x/event_y):
* these come from the touchpoint in Absolute mode, or the sprite in
* Relative. */
if (t-mode == XIDirectTouch) {
-transformAbsolute(dev, mask);
-
if (!(flags TOUCH_CLIENT_ID)) {
-for (i = 0; i valuator_mask_size(mask); i++) {
+for (i = 0; i max(valuator_mask_size(mask), 2); i++) {
double val;
if (valuator_mask_fetch_double(mask, i, val))
valuator_mask_set_double(touchpoint.ti-valuators, i, val);
+/* If the device doesn't post new X and Y axis values,
+ * use the last values posted.
+ */
+else if (i 2
+valuator_mask_fetch_double(touchpoint.ti-valuators, i,
+ val))
+valuator_mask_set_double(mask, i, val);
}
}
+transformAbsolute(dev, mask);
clipAbsolute(dev, mask);
}
else {
diff --git a/include/inputstr.h b/include/inputstr.h
index 5a38924..bb0a779 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -331,7 +331,7 @@ typedef struct _DDXTouchPointInfo {
uint32_t ddx_id;/* touch ID given by the DDX */
Bool emulate_pointer;
-ValuatorMask *valuators;/* last recorded axis values */
+ValuatorMask *valuators;/* last axis values as posted, pre-transform */
} DDXTouchPointInfoRec;
typedef struct _TouchClassRec {
--
1.7.7.3
___
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] dix: split xi2_mask_isset into a per-device function
For touch selection conflicts, we need to check not only if the mask is set
for the device, but if it is set for only that specific device (regardless
of XIAll*Devices)
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/inpututils.c | 30 +-
include/inpututils.h | 1 +
test/xi2/xi2.c | 6 ++
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index f01e9a7..eb9 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -1033,6 +1033,21 @@ xi2mask_free(XI2Mask **mask)
}
/**
+ * Test if the bit for event type is set for this device only.
+ *
+ * @return TRUE if the bit is set, FALSE otherwise
+ */
+Bool
+xi2mask_isset_for_device(XI2Mask *mask, const DeviceIntPtr dev, int event_type)
+{
+BUG_WARN(dev-id 0);
+BUG_WARN(dev-id = mask-nmasks);
+BUG_WARN(bits_to_bytes(event_type + 1) mask-mask_size);
+
+return BitIsOn(mask-masks[dev-id], event_type);
+}
+
+/**
* Test if the bit for event type is set for this device, or the
* XIAllDevices/XIAllMasterDevices (if applicable) is set.
*
@@ -1043,15 +1058,12 @@ xi2mask_isset(XI2Mask *mask, const DeviceIntPtr dev,
int event_type)
{
int set = 0;
-BUG_WARN(dev-id 0);
-BUG_WARN(dev-id = mask-nmasks);
-BUG_WARN(bits_to_bytes(event_type + 1) mask-mask_size);
-
-set = ! !BitIsOn(mask-masks[XIAllDevices], event_type);
-if (!set)
-set = ! !BitIsOn(mask-masks[dev-id], event_type);
-if (!set IsMaster(dev))
-set = ! !BitIsOn(mask-masks[XIAllMasterDevices], event_type);
+if (xi2mask_isset_for_device(mask, inputInfo.all_devices, event_type))
+set = 1;
+else if (xi2mask_isset_for_device(mask, dev, event_type))
+set = 1;
+else if (IsMaster(dev) xi2mask_isset_for_device(mask,
inputInfo.all_master_devices, event_type))
+set = 1;
return set;
}
diff --git a/include/inpututils.h b/include/inpututils.h
index cd9a4de..53c96ba 100644
--- a/include/inpututils.h
+++ b/include/inpututils.h
@@ -57,6 +57,7 @@ XI2Mask *xi2mask_new(void);
XI2Mask *xi2mask_new_with_size(size_t, size_t); /* don't use it */
void xi2mask_free(XI2Mask **mask);
Bool xi2mask_isset(XI2Mask *mask, const DeviceIntPtr dev, int event_type);
+Bool xi2mask_isset_for_device(XI2Mask *mask, const DeviceIntPtr dev, int
event_type);
void xi2mask_set(XI2Mask *mask, int deviceid, int event_type);
void xi2mask_zero(XI2Mask *mask, int deviceid);
void xi2mask_merge(XI2Mask *dest, const XI2Mask *source);
diff --git a/test/xi2/xi2.c b/test/xi2/xi2.c
index 6ee7052..1cdad1d 100644
--- a/test/xi2/xi2.c
+++ b/test/xi2/xi2.c
@@ -36,8 +36,14 @@ xi2mask_test(void)
XI2Mask *xi2mask = NULL, *mergemask = NULL;
unsigned char *mask;
DeviceIntRec dev;
+DeviceIntRec all_devices, all_master_devices;
int i;
+all_devices.id = XIAllDevices;
+inputInfo.all_devices = all_devices;
+all_master_devices.id = XIAllMasterDevices;
+inputInfo.all_master_devices = all_master_devices;
+
/* size = nmasks * 2 for the test cases below */
xi2mask = xi2mask_new_with_size(MAXDEVICES + 2, (MAXDEVICES + 2) * 2);
assert(xi2mask);
--
1.7.11.7
___
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 2/2] Xi: fix touch event selction conflicts (#57301)
There are limits on which client may select for touch events on a given
window, with restrictions being that no two clients can select on the same
device, but narrower selections are allowed, i.e. if one client has
XIAllDevices, a second client may still select for device X.
The current code had a dependency on which client selected first and which
device, resulting in inconsistencies when selecting for events. Fix that,
responding with the right errors regardless of who selected what first.
X.Org Bug 57301 http://bugs.freedesktop.org/show_bug.cgi?id=57301
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
I'm not 100% myself on what the right thing to do is for XIAllDevices and
XIAllMasterDevices. A client selecting for the former would (with this
patch) essentially get overridden by a client XIAllMasterDevices, with touch
events only going to the second one then.
If we would limit that to either XIAllDevices or XIAllMasterDevices, not
both, we'd definitely need to add this to the protocol.
Xi/xiselectev.c | 80 -
1 file changed, 56 insertions(+), 24 deletions(-)
diff --git a/Xi/xiselectev.c b/Xi/xiselectev.c
index ab1b624..45a996e 100644
--- a/Xi/xiselectev.c
+++ b/Xi/xiselectev.c
@@ -37,6 +37,57 @@
#include xiselectev.h
/**
+ * Ruleset:
+ * - if A has XIAllDevices, B may select on device X
+ * - If A has XIAllDevices, B may select on XIAllMasterDevices
+ * - If A has XIAllMasterDevices, B may select on device X
+ * - If A has XIAllMasterDevices, B may select on XIAllDevices
+ * - if A has device X, B may select on XIAllDevices/XIAllMasterDevices
+ */
+static int check_for_touch_selection_conflicts(ClientPtr B, WindowPtr win, int
deviceid)
+{
+OtherInputMasks *inputMasks = wOtherInputMasks(win);
+InputClients *A = NULL;
+
+if (inputMasks)
+A = inputMasks-inputClients;
+for (; A; A = A-next) {
+DeviceIntPtr tmp;
+
+if (CLIENT_ID(A-resource) == B-index)
+continue;
+
+if (deviceid == XIAllDevices)
+tmp = inputInfo.all_devices;
+else if (deviceid == XIAllMasterDevices)
+tmp = inputInfo.all_master_devices;
+else
+dixLookupDevice(tmp, deviceid, serverClient, DixReadAccess);
+if (!tmp)
+return BadImplementation; /* this shouldn't happen */
+
+/* A has XIAllDevices */
+if (xi2mask_isset_for_device(A-xi2mask, inputInfo.all_devices,
XI_TouchBegin)) {
+if (deviceid == XIAllDevices)
+return BadAccess;
+}
+
+/* A has XIAllMasterDevices */
+if (xi2mask_isset_for_device(A-xi2mask, inputInfo.all_master_devices,
XI_TouchBegin)) {
+if (deviceid == XIAllMasterDevices)
+return BadAccess;
+}
+
+/* A has this device */
+if (xi2mask_isset_for_device(A-xi2mask, tmp, XI_TouchBegin))
+return BadAccess;
+}
+
+return Success;
+}
+
+
+/**
* Check the given mask (in len bytes) for invalid mask bits.
* Invalid mask bits are any bits above XI2LastEvent.
*
@@ -169,30 +220,11 @@ ProcXISelectEvents(ClientPtr client)
* same devices, including master devices.
* XXX: This breaks if a device goes from floating to attached. */
if (BitIsOn(bits, XI_TouchBegin)) {
-OtherInputMasks *inputMasks = wOtherInputMasks(win);
-InputClients *iclient = NULL;
-
-if (inputMasks)
-iclient = inputMasks-inputClients;
-for (; iclient; iclient = iclient-next) {
-DeviceIntPtr tmp;
-
-if (CLIENT_ID(iclient-resource) == client-index)
-continue;
-
-if (evmask-deviceid == XIAllDevices)
-tmp = inputInfo.all_devices;
-else if (evmask-deviceid == XIAllMasterDevices)
-tmp = inputInfo.all_master_devices;
-else
-dixLookupDevice(tmp, evmask-deviceid, serverClient,
-DixReadAccess);
-if (!tmp)
-return BadImplementation; /* this shouldn't
happen */
-
-if (xi2mask_isset(iclient-xi2mask, tmp, XI_TouchBegin))
-return BadAccess;
-}
+rc = check_for_touch_selection_conflicts(client,
+ win,
+ evmask-deviceid);
+if (rc != Success)
+return rc;
}
}
--
1.7.11.7
___
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] dix: Save touchpoint last coordinates before transform. #49347
On Mon, Nov 19, 2012 at 09:04:57PM -0500, Yuly Novikov wrote:
DDXTouchPointInfoRec.valuators used to store axis values after transform.
This resulted in Coordinate Transformation Matrix
being applied multiple times to the last coordinates,
in the case when only pressure changes in the last touch event.
Changed DDXTouchPointInfoRec.valuators to store values before transform.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=49347
Signed-off-by: Yuly Novikov ynovi...@chromium.org
---
merged, thanks
Cheers,
Peter
dix/getevents.c| 22 +-
include/inputstr.h |2 +-
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index 2a686e8..b52efc5 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1940,32 +1940,28 @@ GetTouchEvents(InternalEvent *events, DeviceIntPtr
dev, uint32_t ddx_touchid,
default:
return 0;
}
-if (t-mode == XIDirectTouch !(flags TOUCH_CLIENT_ID)) {
-if (!valuator_mask_isset(mask, 0))
-valuator_mask_set_double(mask, 0,
- valuator_mask_get_double(touchpoint.ti-
- valuators, 0));
-if (!valuator_mask_isset(mask, 1))
-valuator_mask_set_double(mask, 1,
- valuator_mask_get_double(touchpoint.ti-
- valuators, 1));
-}
/* Get our screen event co-ordinates (root_x/root_y/event_x/event_y):
* these come from the touchpoint in Absolute mode, or the sprite in
* Relative. */
if (t-mode == XIDirectTouch) {
-transformAbsolute(dev, mask);
-
if (!(flags TOUCH_CLIENT_ID)) {
-for (i = 0; i valuator_mask_size(mask); i++) {
+for (i = 0; i max(valuator_mask_size(mask), 2); i++) {
double val;
if (valuator_mask_fetch_double(mask, i, val))
valuator_mask_set_double(touchpoint.ti-valuators, i,
val);
+/* If the device doesn't post new X and Y axis values,
+ * use the last values posted.
+ */
+else if (i 2
+valuator_mask_fetch_double(touchpoint.ti-valuators, i,
+ val))
+valuator_mask_set_double(mask, i, val);
}
}
+transformAbsolute(dev, mask);
clipAbsolute(dev, mask);
}
else {
diff --git a/include/inputstr.h b/include/inputstr.h
index 5a38924..bb0a779 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -331,7 +331,7 @@ typedef struct _DDXTouchPointInfo {
uint32_t ddx_id;/* touch ID given by the DDX */
Bool emulate_pointer;
-ValuatorMask *valuators;/* last recorded axis values */
+ValuatorMask *valuators;/* last axis values as posted, pre-transform
*/
} DDXTouchPointInfoRec;
typedef struct _TouchClassRec {
--
1.7.7.3
___
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: any more nominations for xserver 1.13.1 ?
Peter Hutterer peter.hutte...@who-t.net writes: As aaron said in the original thread, using the nt_list macros can leave the current list in-place but avoids open-coding it again. this would be the easiest quick-term fix, but still needs someone to do and test it... Yeah, if someone wants to try the nt_list version and make sure that works, I'd take that into master so we could at least have the bug fixed for 1.13.1 IMO a switch to a struct list shouldn't go into the stable branch anyway (at least not that quickly) I haven't checked, but wouldn't switching to xorg_list cause ABI problems? -- keith.pack...@intel.com pgpuqEVZRwCIN.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: suspend graphics card - ATI
Hello Alex and Mike, do we have the functionality for delete also? Sorry for the late come back! Thanks, -Bala S On Thu, Apr 5, 2012 at 7:32 AM, Balasubramanian S spar...@gmail.com wrote: Hello Alex and Mike, I will look into this and get back to you. Thank you for the prompt reply, -Bala S On Wed, Apr 4, 2012 at 6:31 PM, Alex Deucher alexdeuc...@gmail.comwrote: 2012/4/4 Balasubramanian S spar...@gmail.com: Hello Mike, I am looking for the implementation details. Could you please let m know where can I find them. My understanding on suspend is that all the ongoing I/O request needs to be stopped and new I/O request should not be processed. Correct me if I am wrong. Take a look at the kernel source: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=drivers/gpu/drm/radeon;h=7ba043b079bdbbcbc1a06a761daecae0745ef9e8;hb=HEAD The main suspend and resume entry points are in radeon_device.c (radeon_suspend_kms() and radeon_resume_kms()). Alex Thanks, -Bala S 2012/4/3 Michel Dänzer mic...@daenzer.net On Die, 2012-04-03 at 09:30 +0530, Balasubramanian S wrote: Which talks about the suspend and resume of graphics card, which will reduce the shutdown time during the reboot. I would like to know if this changes are made and submitted in xrog. Yes, suspend/resume generally works with current X and kernel drivers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: suspend graphics card - ATI
On Mon, 2012-11-19 at 13:34 +0530, Balasubramanian S wrote: Hello Alex and Mike, Who's Mike? ;) do we have the functionality for delete also? I'm not sure what you mean by that, can you elaborate? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: suspend graphics card - ATI
Please always follow up to the mailing list. On Mon, 2012-11-19 at 16:15 +0530, Balasubramanian S wrote: I mean that remove functionality, which will be getting invoked while remove the card after putting the card into suspend mode. You mean hot-unplugging a graphics card? Not sure we can support that yet, possibly via the VGA switcheroo functionality. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
