Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 15:22 +0200, Lauri Kasanen wrote: Hi list Tracing why there's the occasional delay in Irrlicht apps showed the culprit as XQueryPointer. It's called once per frame, but occasionally it takes much longer than the average 80us - up to 30ms. This is a huge delay and easily noticable as a skip/jitter. Trying various alternatives, like using the mouse position from the last Motion/Click event proved jerky/jittery and seemed to lag the mouse by some frames. Any suggestions on making the call faster? Would it be possible to use it with a timeout, say, if it takes over 1ms, abort? Xlib doesn't work that way. You could do that with XCB and a main loop though. I'd suspect one of two scenarios. Either the X server has some periodic work it's doing, or the kernel's not waking up X promptly enough. Both should be fairly easy to work through. In the former case, it's most likely to be something on the WakeupHandler or BlockHandler call chains in the X server, which run on either side of the call to select() in the main loop. Probably the easiest way to see what's going on is to have your app print timestamps when it calls QueryPointer, and 'strace -t -e file' on the X server (from an ssh session into the machine under test). Then compare. If there's a long lag between your call to QueryPointer to the X server waking up from select and handling it, then the kernel's not getting the message across in time. If there's a lag between the server waking up and writing back the response, then the server's doing excess work. If it's a server issue we'd need to know what driver and hardware you're using. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] glproto 1.4.15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick (1): glproto: Document GLX_ARB_create_context and GLX_ARB_create_context_profile protocol git tag: glproto-1.4.15 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.15.tar.bz2 MD5: d1ff0c1acc605689919c1ee2fc9b5582 glproto-1.4.15.tar.bz2 SHA1: 4cee35232f1926312b29d59a94da1c526b01e5c3 glproto-1.4.15.tar.bz2 SHA256: 990356ebe2e8966aa643287c9a485777957a49299dfb211654df5ff212dec171 glproto-1.4.15.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.15.tar.gz MD5: be7c4e3c289db480b9e1238c03637eb7 glproto-1.4.15.tar.gz SHA1: 22772072f3c960ee53485d9978816a191e9b2027 glproto-1.4.15.tar.gz SHA256: ed719337ad352309f28f8188fb9c46bd8a402ffea836d6073795e2300acef865 glproto-1.4.15.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPIWXKAAoJEAx081l5xIa+7n0P/RS59UFv2NlPt3Y9eS479gtp yjnRf1SlW4QjumOtZKxYG1LLD1J6J/DSbEKmsfvjJRDw1T1PA2rUWMbxe/NEMth0 tlsO7iqQvIn+AOIBxNqsmgrN/lLsfBMfa4rT85tWtdXG8Mup6BV9IKMU9v82ne0O JMweVbzE2cZEv0riDVuIml/jl8RzVA0fdJT9PA2NW9TgMkYBeoH8apAZ8s5Mfo+O SPs9MqoCxrYIWsoxis6Ige96TJ+T82siU9RkT80VjRGw1Xmt0o4ImZlnlNeUtzHk bScZkOC50zbaVAapg2Eq5y8TNyJ5GQUqt8LBXabDZgQDVsWVmE0z5kDYbN/UyFD7 T6ZvXrRv3MrRWq4vL1qs0qm4ElrQ9JSDT9y9GPMjN4YVn1Ap25+3uJ0JZMVwh7LQ lE1X8j7wh7smTi9P2pm6NV1wfABKyXbLD6LFk1KNgVMw3EZ3eJUz5K+7IeLoun22 5mJXyiW/KYfafToOBps4QFymGUJZKYMmvBGyW/KrW8Iyy08KkaaggN2+jduqRLrJ LTEOebBStQpPIRgqkdkT1Jw+U8Q1tx06c6UX3Yp7Ga+ADmUNMAb37ZpaOG1RSK/W qVtvES3eE7nZbLZaqwjA6QTfGHWd0v9N8Fa8c8n8Uzsq9AwA+f34SBjXNk1varpp 1i8XYsNOo9HoclYUSqLF =pU20 -END 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: Slow XQueryPointer?
On Thu, 26 Jan 2012 09:37:28 -0500 Adam Jackson a...@redhat.com wrote: Hi Adam Any suggestions on making the call faster? Would it be possible to use it with a timeout, say, if it takes over 1ms, abort? Xlib doesn't work that way. You could do that with XCB and a main loop though. XCB is unfortunately not possible. I'd suspect one of two scenarios. Either the X server has some periodic work it's doing, or the kernel's not waking up X promptly enough. Both should be fairly easy to work through. In the former case, it's most likely to be something on the WakeupHandler or BlockHandler call chains in the X server, which run on either side of the call to select() in the main loop. Probably the easiest way to see what's going on is to have your app print timestamps when it calls QueryPointer, and 'strace -t -e file' on the X server (from an ssh session into the machine under test). Then compare. If there's a long lag between your call to QueryPointer to the X server waking up from select and handling it, then the kernel's not getting the message across in time. If there's a lag between the server waking up and writing back the response, then the server's doing excess work. For this particular call, my app called XQueryPointer at 1327592221.398620 and reported the call took 12177 usec. The relevant portion of the strace is attached. I'm not fully confident in my ability to grok strace, but to me it looks like the latter case (excess work?). There is a select call soon after the call, and there's a write about 12ms later. If it's a server issue we'd need to know what driver and hardware you're using. Linux 3.0.9 X Server 1.9.5 mouse 1.7.0 / usb mouse kbd 1.6.0 / usb kbd -ati 6.14.3 / HD4350 Let me know if that's not the correct info. -- - Lauri xserver.ptrace.txt Description: Binary data ___ 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: Slow XQueryPointer?
On Thu, 2012-01-26 at 11:58 -0500, Adam Jackson wrote: I think a more complete solution would involve changing the main loop's logic slightly: if we get to the end of requests for a single client within a single timeslice, start pulling requests from any other clients that have pending requests (in priority order) until the timeslice expires (at which point we'd loop back around to select and start again). This would punish absolute throughput for any one client when contended, but I'm willing to take that if it means we stop dropping frames. Just a quick followup since it was an easy experiment to run. Test machine: model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz The reproducer scenario is two apps, one that's throughput-bound and one that's latency-bound. Easiest way to get this is one x11perf -noop and one x11perf -pointer. With the stock tuning on an idle server, -noop performance is about 21.6e6 per second, and -pointer is about 28.7e3 per second. With both running at once, -noop performance is essentially unchanged but -pointer drops to a mere 1.02e3/s. If I change the default timeslice to 2ms (and the max to 16ms, not that this case would hit it), baseline performance is unchanged. Running both -noop and -pointer at once, -noop drops to about 20.6e6/s but -pointer climbs to 3.8e3/s. So, there's that. You lose about 5% in the pathologically throughput-bound case, but your peak latency goes way down. Sounds like a no-brainer to me, honestly. And I'm pretty sure if you wanted that 5% back that the other code change I proposed would recover it. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 19:34 +0200, Lauri Kasanen wrote: Hi ajax Thanks for taking the time to look into this. Trying -schedInterval 5 had slight improvement - the skips weren't as high, the highest was 7ms. But the skips still happen about just as often. That's about what I'd expect. The worst-case latency with the current algorithm is linear [1] on the number of clients you're contending with, so you're still going to see latencies greater than the timeslice if you have more than one other app to compete with. This sounds good. Could this make it to the next xserver release? Well, we can try. Certainly tuning the defaults would be an improvement even if we don't fix the algorithm. I don't know if I'll have a better algorithm for 1.12.0 but it should be easy to backport whenever it gets written. Also, even when this is fixed, there's going to be many linux systems without it for a year or two. Would there be any workaround for affected systems my app could do? Simplest thing (although kind of hideous) might be to launch another thread with its own Display connection and only ever run XQueryPointer from that, save the coordinates in some shared variable protected by a mutex, and read from that in the main thread. Or in a separate process over a pipe, if you don't like threads. I don't really know what you need the result for, though, so I don't know if that's a viable technique for you. [1] - Not actually sure it's not worse than that, tbh. I suspect there's ways you could end up starved forever with no more than two other clients (and without even going into the sync extension's priority levels). - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-video-ark 0.7.4
On Thu, 26 Jan 2012 19:14:32 -0500 Matt Turner matts...@gmail.com wrote: On Thu, Jan 26, 2012 at 7:04 PM, Robby Workman ro...@rlworkman.net wrote: On Thu, 26 Jan 2012 18:10:30 -0500 Matt Turner matts...@gmail.com wrote: This release contains a bunch of janitorial fixes, but does contain an actual bug fix from Ondrej Zary (bug 28249). Why does it depend on a devel release of libpciaccess? checking for PCIACCESS... no configure: error: Package requirements (pciaccess = 0.12.901) were not met: Requested 'pciaccess = 0.12.901' but version of pciaccess is 0.12.1 It uses the pci_device_map_legacy function in place of the deprecated xf86MapDomainMemory function. I assume that you're a packager, and not an xf86-video-ark user, Correct :) so if you want to avoid the development libpciaccess dependency, you can reverse http://cgit.freedesktop.org/xorg/driver/xf86-video-ark/commit/?id=99ed4177 I think a new libpciaccess release will be along before too much longer. Hrm, okay, I think I'll just wait for a new libpciaccess then; thanks! -RW ___ 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] xf86: add rgb ordering helper
From: Dave Airlie airl...@redhat.com
At least the intel, nouveau and radeon driver contain this chunk of code.
We should move it into the server just for the sake of stopping further
cut-n-paste.
Drivers can be adapted to use it later.
Signed-off-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86.h |1 +
hw/xfree86/common/xf86Helper.c | 16
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index b711f05..00dd229 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -227,6 +227,7 @@ extern _X_EXPORT Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int
depth, int bpp, int
extern _X_EXPORT void xf86PrintDepthBpp(ScrnInfoPtr scrp);
extern _X_EXPORT Bool xf86SetWeight(ScrnInfoPtr scrp, rgb weight, rgb mask);
extern _X_EXPORT Bool xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual);
+extern _X_EXPORT void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr screen);
extern _X_EXPORT Bool xf86SetGamma(ScrnInfoPtr scrp, Gamma newGamma);
extern _X_EXPORT void xf86SetDpi(ScrnInfoPtr pScrn, int x, int y);
extern _X_EXPORT void xf86SetBlackWhitePixels(ScreenPtr pScreen);
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 248ccf4..0cfbece 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -808,6 +808,22 @@ xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual)
}
}
+void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr screen)
+{
+VisualPtr visual;
+visual = screen-visuals + screen-numVisuals;
+while (--visual = screen-visuals) {
+ if ((visual-class | DynamicClass) == DirectColor) {
+ visual-offsetRed = scrn-offset.red;
+ visual-offsetGreen = scrn-offset.green;
+ visual-offsetBlue = scrn-offset.blue;
+ visual-redMask = scrn-mask.red;
+ visual-greenMask = scrn-mask.green;
+ visual-blueMask = scrn-mask.blue;
+ }
+}
+}
+
#define TEST_GAMMA(g) \
(g).red GAMMA_ZERO || (g).green GAMMA_ZERO || (g).blue GAMMA_ZERO
--
1.7.6
___
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 04/11] glx: Add tracking for GLX_ARB_create_context and GLX_ARB_create_context_profile
On Fri, Dec 23, 2011 at 11:18 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com Reviewed-by: Dave Airlie airl...@redhat.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 06/11] glx: Implement GLX SetClientInfoARB protocol
On Fri, Dec 23, 2011 at 11:18 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com Reviewed-by: Dave Airlie airl...@redhat.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 10/11] glx: Make several functions available outside the glxcmds.c compilation unit
On Fri, Dec 23, 2011 at 11:18 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com validGlxScreen, validGlxFBConfig, validGlxContext, and __glXdirectContextCreate will soon be used by createcontext.c. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Reviewed-by: Dave Airlie airl...@redhat.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 11/11] glx: Implement protocol for glXCreateContextAttribsARB
On Fri, Dec 23, 2011 at 11:18 PM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com Reviewed-by: Dave Airlie airl...@redhat.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
[PATCH] configure.ac: bump GL requirements
From: Dave Airlie airl...@redhat.com Once Ian's GLX changes are commited for GL3.0 support, then we need to bump the minimum requirements for glproto and gl (from Mesa). Signed-off-by: Dave Airlie airl...@redhat.com --- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b0bb9bb..64a8420 100644 --- a/configure.ac +++ b/configure.ac @@ -765,7 +765,7 @@ DRI2PROTO=dri2proto = 2.6 XINERAMAPROTO=xineramaproto BIGFONTPROTO=xf86bigfontproto = 1.2.0 DGAPROTO=xf86dgaproto = 2.0.99.1 -GLPROTO=glproto = 1.4.14 +GLPROTO=glproto = 1.4.15 DMXPROTO=dmxproto = 2.2.99.1 VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1 WINDOWSWMPROTO=windowswmproto @@ -790,7 +790,7 @@ LIBAPPLEWM=applewm = 1.4 LIBDMX=dmx = 1.0.99.1 LIBDRI=dri = 7.8.0 LIBDRM=libdrm = 2.3.0 -LIBGL=gl = 7.1.0 +LIBGL=gl = 8.0.0 LIBXEXT=xext = 1.0.99.4 LIBXFONT=xfont = 1.4.2 LIBXI=xi = 1.2.99.1 -- 1.7.6 ___ 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] configure.ac: bump GL requirements
On Thu, Jan 26, 2012 at 03:44:58PM +, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com Once Ian's GLX changes are commited for GL3.0 support, then we need to bump the minimum requirements for glproto and gl (from Mesa). Signed-off-by: Dave Airlie airl...@redhat.com --- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -LIBGL=gl = 7.1.0 +LIBGL=gl = 8.0.0 Wow. 8.0 is not even released yet. Even if it were released already, that is a pretty narrow base. Is there any good reason to not make openGL 3.0 GLX changes build conditionally? Luc Verhaegen. ___ 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] hw/xwin fixes + a warning fix
Hi Keith, Please consider pulling into master. Thanks. The following changes since commit 02775efb8930291cc62fc84086c97da75b912a55: int10: Fix unmapping of the BIOS scratch area (2012-01-25 09:26:23 -0800) are available in the git repository at: git://people.freedesktop.org/~jturney/xserver xserver-next Colin Harrison (3): hw/xwin: Ignore WM_DISPLAYCHANGE messages with 0 bpp hw/xwin: Fix winEnqueueMotion() for change in miPointerSetPosition() hw/xwin: Fix spelling of 'Canadian' in winkeybd.h Jon TURNEY (9): Xext: Warning fix for shm.c hw/xwin: Give the X window for the clipboard integration client a name hw/xwin: Chain IOError handlers to avoid longjmp across threads hw/xwin: Remove some redundant OS version reporting hw/xwin: In multiwindow mode, don't grab native input focus for new windows which hint they don't want it hw/xwin: turn on -emulate3buttons if less than 3 mouse buttons are reported hw/xwin: Handle the virtual key code generated by the Fn key on IBM Lenovo laptops hw/xwin: Handle more motif window decoration hinting hw/xwin: Avoid WIN_WINDOW_PROP races during Windows window destruction Michel Hummel (3): hw/xwin: Automatically restart clipboard thread hw/xwin: Remove no-longer needed tricks used to prevent the clipboard client from being killed hw/xwin: Mitigate a race condition in clipboard thread initialization Oliver Schmidt (1): hw/xwin: Fix AltGr key sometimes firing an additional Ctrl-L key Roland Cassard (1): hw/xwin: Don't assume we'll always have converted the clipboard selection after 2 attempts Yaakov Selkowitz (1): hw/xwin: Improve XWinrc loading and error recovery Xext/shm.c |2 +- hw/xwin/InitInput.c |6 -- hw/xwin/InitOutput.c| 31 +- hw/xwin/man/XWin.man|3 +- hw/xwin/win.h |2 + hw/xwin/winclipboard.h |2 + hw/xwin/winclipboardthread.c| 93 +- hw/xwin/winclipboardunicode.c |4 +- hw/xwin/winclipboardwndproc.c | 23 +-- hw/xwin/winclipboardwrappers.c | 122 +-- hw/xwin/winengine.c | 14 - hw/xwin/winglobals.c|2 - hw/xwin/winkeybd.c | 95 ++ hw/xwin/winkeybd.h |6 +- hw/xwin/winkeynames.h |2 +- hw/xwin/winmouse.c |6 +- hw/xwin/winmultiwindowclass.h | 10 +++ hw/xwin/winmultiwindowwindow.c |2 - hw/xwin/winmultiwindowwm.c | 72 +-- hw/xwin/winmultiwindowwndproc.c | 25 +++- hw/xwin/winprefs.c | 74 ++- hw/xwin/winprefslex.l | 10 ++- hw/xwin/winprocarg.c| 15 - hw/xwin/winwindow.h | 11 ++- hw/xwin/winwndproc.c| 12 +++- 25 files changed, 365 insertions(+), 279 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
[PATCH modular] Format cleanup of help output
From: Trevor Woerner twoer...@gmail.com
Miscellaneous cleanups of the help text that is printed.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index 5878ef1..9068f29 100755
--- a/build.sh
+++ b/build.sh
@@ -20,7 +20,8 @@ Environment variables specific to build.sh:
Each module/components is invoked with --datadir
LIBDIR Install object code libraries [EPREFIX/lib]
Each module/components is invoked with --libdir
- LOCALSTATEDIR Modifiable single-machine data [PREFIX/var]
+ LOCALSTATEDIR
+ Modifiable single-machine data [PREFIX/var]
Each module/components is invoked with --localstatedir
QUIET Do not print messages saying which checks are being made
Each module/components is invoked with --quite
@@ -33,7 +34,7 @@ Environment variables defined by the GNU Build System:
ACLOCAL The aclocal cmd name [aclocal -I \${DESTDIR}/\${DATADIR}/aclocal]
DESTDIR Path to the staging area where installed objects are relocated
MAKEThe name of the make command [make]
- MAKEFLAGS: Options to pass to all \$(MAKE) invocations
+ MAKEFLAGS Options to pass to all \$(MAKE) invocations
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a
@@ -47,13 +48,15 @@ Environment variables defined by the shell:
\$DESTDIR/\$BINDIR is prepended
Environment variables defined by the dynamic linker:
- LD_LIBRARY_PATH List directories that the linker searches for shared objects
- \$DESTDIR/\$LIBDIR is prepended
+ LD_LIBRARY_PATH
+ List directories that the linker searches for shared objects
+ \$DESTDIR/\$LIBDIR is prepended
Environment variables defined by the pkg-config system:
- PKG_CONFIG_PATH List directories that pkg-config searches for libraries
- \$DESTDIR/\$DATADIR/pkgconfig and
- \$DESTDIR/\$LIBDIR/pkgconfig are prepended
+ PKG_CONFIG_PATH
+ List directories that pkg-config searches for libraries
+ \$DESTDIR/\$DATADIR/pkgconfig and
+ \$DESTDIR/\$LIBDIR/pkgconfig are prepended
EOF
}
@@ -1052,22 +1055,26 @@ usage() {
echo -g Compile and link with debug information
echo -h, --help Display this help and exit successfully
echo -n Do not quit after error; just print error message
-echo -o module/component Build just this module/component
+echo -o module/component
+echo Build just this module/component
echo -p Update source code before building (git pull --rebase)
echo -s sudo The command name providing superuser privilege
-echo --autoresume file Append module being built to, and autoresume
from, file
+echo --autoresume file
+echo Append module being built to, and autoresume from,
file
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
-echo --confflags options Pass options to autgen.sh/configure of all
modules
-echo --modfile file Only process the module/components specified in
file
+echo --confflags options
+echo Pass options to autgen.sh/configure of all modules
+echo --modfile file
+echo Only process the module/components specified in file
echo Any text after, and on the same line as, the
module/component
echo is assumed to be configuration options for the
configuration
echo of each module/component specifically
echo --retry-v1 Remake 'all' on failure with Automake silent rules
disabled
echo
echo Usage: $basename -L
-echo -L : just list modules to build
+echo -L Just list modules to build
echo
envoptions
}
--
1.7.6.233.gd79bc
___
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: Slow XQueryPointer?
On Thu, 2012-01-26 at 17:51 +0200, Lauri Kasanen wrote:
For this particular call, my app called XQueryPointer at
1327592221.398620 and reported the call took 12177 usec. The relevant
portion of the strace is attached.
I'm not fully confident in my ability to grok strace, but to me it
looks like the latter case (excess work?). There is a select call soon
after the call, and there's a write about 12ms later.
Okay, I think I know what this is.
Right after your request there's:
1327592221.398755 select(256, [1 3 6 8 10 11 12 13 14 15 16 17 18 19 20 21 22],
NULL, NULL, {7, 519000}) = 2 (in [20 22], left {7, 518990})
1327592221.398868 setitimer(ITIMER_REAL, {it_interval={0, 2}, it_value={0,
2}}, NULL) = 0
1327592221.398944 read(20,
5\30\4\0\206_q\1\2\1\0\0\325\1\27\0007\0\4\0\207_q\1\206_q\1\0\0\0\0...,
4096) = 3452
1327592221.399071 ioctl(8, 0xc020645d, 0x7fff61bdc420) = 0
1327592221.399189 ioctl(8, 0x40086409, 0x7fff61bdc440) = 0
1327592221.399279 ioctl(8, 0xc0086464, 0x7fff61bdc210) = 0
1327592221.400355 ioctl(8, 0xc0206466, 0x1f81a38) = 0
1327592221.401180 ioctl(8, 0xc008646a, 0x7fff61bdc460) = 0
1327592221.401255 ioctl(8, 0xc0086464, 0x7fff61bdc170) = 0
1327592221.401604 read(20, 0x2c06920, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
1327592221.401680 ioctl(8, 0xc0206466, 0x1f81a38) = 0
1327592221.401954 ioctl(8, 0xc008646a, 0x7fff61bdc880) = 0
1327592221.402024 writev(20,
[{\16\0\r\304\206_q\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
3808}], 1) = 3808
1327592221.402446 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}},
NULL) = 0
So this is showing a wakeup to handle a request on fd 20, but it
completes in under 4ms (and isn't your request anyway; 5 is 53 decimal
which is CreatePixmap). Much much later we finally get around to
handling your request:
1327592221.410274 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}},
NULL) = 0
1327592221.410366 select(256, [1 3 6 8 10 11 12 13 14 15 16 17 18 19 20 21 22],
NULL, NULL, {7, 507000}) = 1 (in [22], left {7, 506978})
1327592221.410492 setitimer(ITIMER_REAL, {it_interval={0, 2}, it_value={0,
2}}, NULL) = 0
1327592221.410568 read(22, \0\2\0\2\1\0\0, 4120) = 8
1327592221.410651 read(22, 0x2c05900, 4120) = -1 EAGAIN (Resource temporarily
unavailable)
1327592221.410721 writev(22,
[{\1\1'\1\0\0\0\0\2\1\0\0\211_`\0\330\1\243\0\330\1\243\0\0\0\0\0\0\0\0\0,
32}], 1) = 32
1327592221.410858 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}},
NULL) = 0
1327592221.410936 select(256, [1 3 6 8 10 11 12 13 14 15 16 17 18 19 20 21 22],
NULL, NULL, {7, 507000}) = 1 (in [22], left {7, 506988})
1327592221.411051 setitimer(ITIMER_REAL, {it_interval={0, 2}, it_value={0,
2}}, NULL) = 0
And this is definitely you, is 38 decimal is QueryPointer. So:
writev(22) returns: 1327592221.410721
Your printed timestamp: 1327592221.398620
--- -
0.012101
That plus another context switch back to your process comes to the
12177us you're seeing. So it's not that the server has excess work,
just that it's ignoring you.
Now the question, of course, is why we'd do such a thing, and the answer
is to try to guarantee fairness among clients. The way we do this is by
trying to time how long we're handling requests for a given client
(that'd be the setitimer calls in the trace), and switching to a new
client if one exhausts its timeslice. And now we see the problem:
#define SMART_SCHEDULE_DEFAULT_INTERVAL 20 /* ms */
#define SMART_SCHEDULE_MAX_SLICE200 /* ms */
Bool SmartScheduleDisable = FALSE;
long SmartScheduleSlice = SMART_SCHEDULE_DEFAULT_INTERVAL;
long SmartScheduleInterval = SMART_SCHEDULE_DEFAULT_INTERVAL;
long SmartScheduleMaxSlice = SMART_SCHEDULE_MAX_SLICE;
20ms at a time for a single client is clearly insane.
You can tune this on the command line with the -schedInterval ms
argument; it would be interesting to see how things fare at closer to
(say) 5ms. I suspect we need to tune that default down to below 16ms at
least, allowing a single client to monopolize the server for more than a
frame is not acceptable.
I think a more complete solution would involve changing the main loop's
logic slightly: if we get to the end of requests for a single client
within a single timeslice, start pulling requests from any other clients
that have pending requests (in priority order) until the timeslice
expires (at which point we'd loop back around to select and start
again). This would punish absolute throughput for any one client when
contended, but I'm willing to take that if it means we stop dropping
frames.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure.ac: bump GL requirements
On Thu, Jan 26, 2012 at 3:53 PM, Luc Verhaegen l...@skynet.be wrote: On Thu, Jan 26, 2012 at 03:44:58PM +, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com Once Ian's GLX changes are commited for GL3.0 support, then we need to bump the minimum requirements for glproto and gl (from Mesa). Signed-off-by: Dave Airlie airl...@redhat.com --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -LIBGL=gl = 7.1.0 +LIBGL=gl = 8.0.0 Wow. 8.0 is not even released yet. Even if it were released already, that is a pretty narrow base. Is there any good reason to not make openGL 3.0 GLX changes build conditionally? I'm just doing what my builds locally produced, I've no idea, Ian? it looks like at least some of the defines in dri_interface.h. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
On Thu, 26 Jan 2012 16:13:59 +, Jon TURNEY jon.tur...@dronecode.org.uk wrote: hw/xwin: Fix winEnqueueMotion() for change in miPointerSetPosition() This looks like it's missing x = dx; y = dy; Without that, you'll miss any changes to position made by miPointerSetPosition. -- keith.pack...@intel.com pgpdFsR4wwTfe.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: Slow XQueryPointer?
On Thu, 2012-01-26 at 11:58 -0500, Adam Jackson wrote: I think a more complete solution would involve changing the main loop's logic slightly: if we get to the end of requests for a single client within a single timeslice, start pulling requests from any other clients that have pending requests (in priority order) until the timeslice expires (at which point we'd loop back around to select and start again). This would punish absolute throughput for any one client when contended, but I'm willing to take that if it means we stop dropping frames. Just a quick followup since it was an easy experiment to run. Test machine: model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz The reproducer scenario is two apps, one that's throughput-bound and one that's latency-bound. Easiest way to get this is one x11perf -noop and one x11perf -pointer. With the stock tuning on an idle server, -noop performance is about 21.6e6 per second, and -pointer is about 28.7e3 per second. With both running at once, -noop performance is essentially unchanged but -pointer drops to a mere 1.02e3/s. If I change the default timeslice to 2ms (and the max to 16ms, not that this case would hit it), baseline performance is unchanged. Running both -noop and -pointer at once, -noop drops to about 20.6e6/s but -pointer climbs to 3.8e3/s. So, there's that. You lose about 5% in the pathologically throughput-bound case, but your peak latency goes way down. Sounds like a no-brainer to me, honestly. And I'm pretty sure if you wanted that 5% back that the other code change I proposed would recover it. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 19:34 +0200, Lauri Kasanen wrote: Hi ajax Thanks for taking the time to look into this. Trying -schedInterval 5 had slight improvement - the skips weren't as high, the highest was 7ms. But the skips still happen about just as often. That's about what I'd expect. The worst-case latency with the current algorithm is linear [1] on the number of clients you're contending with, so you're still going to see latencies greater than the timeslice if you have more than one other app to compete with. This sounds good. Could this make it to the next xserver release? Well, we can try. Certainly tuning the defaults would be an improvement even if we don't fix the algorithm. I don't know if I'll have a better algorithm for 1.12.0 but it should be easy to backport whenever it gets written. Also, even when this is fixed, there's going to be many linux systems without it for a year or two. Would there be any workaround for affected systems my app could do? Simplest thing (although kind of hideous) might be to launch another thread with its own Display connection and only ever run XQueryPointer from that, save the coordinates in some shared variable protected by a mutex, and read from that in the main thread. Or in a separate process over a pipe, if you don't like threads. I don't really know what you need the result for, though, so I don't know if that's a viable technique for you. [1] - Not actually sure it's not worse than that, tbh. I suspect there's ways you could end up starved forever with no more than two other clients (and without even going into the sync extension's priority levels). - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
Hi, This looks like it's missing x = dx; y = dy; With this in I get no mouse events (on the left monitor) when the main display is not leftmost with multiple monitors. The casting is probably messing up negative x's on Windows? As in the [PULL] I can't detect any position errors. Thanks, Colin ___ 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] xf86: add rgb ordering helper
On 01/26/2012 03:36 AM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
At least the intel, nouveau and radeon driver contain this chunk of code.
vesa, nv, and tegra do too.
They explicitly check for pScrn-bitsPerPixel 8, but I don't see why any of
the visuals would match the (visual-class | DynamicClass) == DirectColor check
in that case...
We should move it into the server just for the sake of stopping further
cut-n-paste.
Yes.
Drivers can be adapted to use it later.
Signed-off-by: Dave Airlieairl...@redhat.com
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
---
hw/xfree86/common/xf86.h |1 +
hw/xfree86/common/xf86Helper.c | 16
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index b711f05..00dd229 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -227,6 +227,7 @@ extern _X_EXPORT Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int
depth, int bpp, int
extern _X_EXPORT void xf86PrintDepthBpp(ScrnInfoPtr scrp);
extern _X_EXPORT Bool xf86SetWeight(ScrnInfoPtr scrp, rgb weight, rgb mask);
extern _X_EXPORT Bool xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual);
+extern _X_EXPORT void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr
screen);
extern _X_EXPORT Bool xf86SetGamma(ScrnInfoPtr scrp, Gamma newGamma);
extern _X_EXPORT void xf86SetDpi(ScrnInfoPtr pScrn, int x, int y);
extern _X_EXPORT void xf86SetBlackWhitePixels(ScreenPtr pScreen);
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 248ccf4..0cfbece 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -808,6 +808,22 @@ xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual)
}
}
+void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr screen)
+{
+VisualPtr visual;
+visual = screen-visuals + screen-numVisuals;
+while (--visual= screen-visuals) {
+ if ((visual-class | DynamicClass) == DirectColor) {
+ visual-offsetRed = scrn-offset.red;
+ visual-offsetGreen = scrn-offset.green;
+ visual-offsetBlue = scrn-offset.blue;
+ visual-redMask = scrn-mask.red;
+ visual-greenMask = scrn-mask.green;
+ visual-blueMask = scrn-mask.blue;
+ }
+}
+}
+
#define TEST_GAMMA(g) \
(g).red GAMMA_ZERO || (g).green GAMMA_ZERO || (g).blue GAMMA_ZERO
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
On Thu, 26 Jan 2012 19:27:42 -, Colin Harrison colin.harri...@virgin.net wrote: This looks like it's missing x = dx; y = dy; With this in I get no mouse events (on the left monitor) when the main display is not leftmost with multiple monitors. I don't understand how that can happen -- miSetPointerPosition isn't supposed to change the position unless the pointer is constrained. The casting is probably messing up negative x's on Windows? As in the [PULL] I can't detect any position errors. You won't be clipping mouse positions, which makes this change significantly different from the commit message (as it now discards information that it used to use). Perhaps Peter has some idea of what's going on here... -- keith.pack...@intel.com pgpBArAgk3lDl.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] render: don't bother with animated cursors on floating slaves (#39989)
Hi,
On my Windows build this patch...
diff --git a/render/animcur.c b/render/animcur.c
index 4cf1fdf..0f174fd 100644
--- a/render/animcur.c
+++ b/render/animcur.c
@@ -208,6 +208,9 @@ AnimCurDisplayCursor (DeviceIntPtr pDev,
AnimCurScreenPtras = GetAnimCurScreen(pScreen);
Bool ret;
+if (IsFloating(pDev))
+ return FALSE;
+
Unwrap (as, pScreen, DisplayCursor);
if (IsAnimCur(pCursor))
{
causes the 'default' cursor to disappear...(I like to party_like_its 1989!)
I always need a cursor as when the X root window isn't hidden on Windows you
can't easily control anything as the 'black or stippled X window' blots out
Microsoft's stuff :)
Thanks,
Colin
___
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] xf86: add rgb ordering helper
On 26 January 2012 22:36, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com At least the intel, nouveau and radeon driver contain this chunk of code. We should move it into the server just for the sake of stopping further cut-n-paste. Drivers can be adapted to use it later. Signed-off-by: Dave Airlie airl...@redhat.com Can you not drop the ScreenPtr argument and just say that the function relies on ScrnInfoPtr::pScreen being valid? With that: 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] xf86: add rgb ordering helper
On Thu, 26 Jan 2012 11:36:47 +, Dave Airlie airl...@gmail.com wrote: +void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr screen) This name is very misleading; it's filling out visual pixel format information, not somehow 'fixing' RGB ordering. Otherwise, sure, sharing code is always nice. -- keith.pack...@intel.com pgpAZniTdlMQW.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Format cleanup of help output
On Thu, Jan 26, 2012 at 11:29:46AM -0500, Trevor Woerner wrote:
From: Trevor Woerner twoer...@gmail.com
Miscellaneous cleanups of the help text that is printed.
Signed-off-by: Trevor Woerner twoer...@gmail.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
build.sh | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index 5878ef1..9068f29 100755
--- a/build.sh
+++ b/build.sh
@@ -20,7 +20,8 @@ Environment variables specific to build.sh:
Each module/components is invoked with --datadir
LIBDIR Install object code libraries [EPREFIX/lib]
Each module/components is invoked with --libdir
- LOCALSTATEDIR Modifiable single-machine data [PREFIX/var]
+ LOCALSTATEDIR
+ Modifiable single-machine data [PREFIX/var]
Each module/components is invoked with --localstatedir
QUIET Do not print messages saying which checks are being made
Each module/components is invoked with --quite
@@ -33,7 +34,7 @@ Environment variables defined by the GNU Build System:
ACLOCAL The aclocal cmd name [aclocal -I
\${DESTDIR}/\${DATADIR}/aclocal]
DESTDIR Path to the staging area where installed objects are relocated
MAKEThe name of the make command [make]
- MAKEFLAGS: Options to pass to all \$(MAKE) invocations
+ MAKEFLAGS Options to pass to all \$(MAKE) invocations
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a
@@ -47,13 +48,15 @@ Environment variables defined by the shell:
\$DESTDIR/\$BINDIR is prepended
Environment variables defined by the dynamic linker:
- LD_LIBRARY_PATH List directories that the linker searches for shared
objects
- \$DESTDIR/\$LIBDIR is prepended
+ LD_LIBRARY_PATH
+ List directories that the linker searches for shared objects
+ \$DESTDIR/\$LIBDIR is prepended
Environment variables defined by the pkg-config system:
- PKG_CONFIG_PATH List directories that pkg-config searches for libraries
- \$DESTDIR/\$DATADIR/pkgconfig and
- \$DESTDIR/\$LIBDIR/pkgconfig are prepended
+ PKG_CONFIG_PATH
+ List directories that pkg-config searches for libraries
+ \$DESTDIR/\$DATADIR/pkgconfig and
+ \$DESTDIR/\$LIBDIR/pkgconfig are prepended
EOF
}
@@ -1052,22 +1055,26 @@ usage() {
echo -g Compile and link with debug information
echo -h, --help Display this help and exit successfully
echo -n Do not quit after error; just print error message
-echo -o module/component Build just this module/component
+echo -o module/component
+echo Build just this module/component
echo -p Update source code before building (git pull
--rebase)
echo -s sudo The command name providing superuser privilege
-echo --autoresume file Append module being built to, and autoresume
from, file
+echo --autoresume file
+echo Append module being built to, and autoresume from,
file
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
-echo --confflags options Pass options to autgen.sh/configure of
all modules
-echo --modfile file Only process the module/components specified in
file
+echo --confflags options
+echo Pass options to autgen.sh/configure of all modules
+echo --modfile file
+echo Only process the module/components specified in
file
echo Any text after, and on the same line as, the
module/component
echo is assumed to be configuration options for the
configuration
echo of each module/component specifically
echo --retry-v1 Remake 'all' on failure with Automake silent rules
disabled
echo
echo Usage: $basename -L
-echo -L : just list modules to build
+echo -L Just list modules to build
echo
envoptions
}
--
1.7.6.233.gd79bc
___
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
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
Re: [PATCH] xf86: add rgb ordering helper
On 01/26/2012 01:46 PM, Daniel Stone wrote: On 26 January 2012 22:36, Dave Airlieairl...@gmail.com wrote: From: Dave Airlieairl...@redhat.com At least the intel, nouveau and radeon driver contain this chunk of code. We should move it into the server just for the sake of stopping further cut-n-paste. Drivers can be adapted to use it later. Signed-off-by: Dave Airlieairl...@redhat.com Can you not drop the ScreenPtr argument and just say that the function relies on ScrnInfoPtr::pScreen being valid? It would presumably be typically called from ScreenInit, where pScrn-pScreen is NULL. If you want to have the server wire that up earlier, that'd be another matter. With that: Reviewed-by: Daniel Stonedan...@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] xf86: add rgb ordering helper
Hi, On 27 January 2012 09:28, Aaron Plattner aplatt...@nvidia.com wrote: On 01/26/2012 01:46 PM, Daniel Stone wrote: Can you not drop the ScreenPtr argument and just say that the function relies on ScrnInfoPtr::pScreen being valid? It would presumably be typically called from ScreenInit, where pScrn-pScreen is NULL. If you want to have the server wire that up earlier, that'd be another matter. Rather. A few drivers (at least radeon, nouveau, and vmware, as well as the one I just wrote) wire it up during ScreenInit, which I'd thought was more widespread. I don't see any downside to doing it in the server before ScreenInit though. 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: [PULL] hw/xwin fixes + a warning fix
Hi,
Looking into it further the code at the end of miPointerSetPosition() maybe
the cause of this...
/* In the event we actually change screen or we get confined, we just
* drop the float component on the floor
* FIXME: only drop remainder for ConstrainCursorHarder, not for screen
* crossings */
if (x != trunc(*screenx))
*screenx = x;
if (y != trunc(*screeny))
*screeny = y;
this was introduced at the same time the function switched to doubles.
If I revert those traps and then call the function...
void winEnqueueMotion(int x, int y)
{
int valuators[2];
ValuatorMask mask;
double dx = (double)x;
double dy = (double)y;
miPointerSetPosition(g_pwinPointer, POINTER_RELATIVE, dx, dy);
x = trunc(dx);
y = trunc(dy);
valuators[0] = x;
valuators[1] = y;
valuator_mask_set_range(mask, 0, 2, valuators);
QueuePointerEvents(g_pwinPointer, MotionNotify, 0,
POINTER_ABSOLUTE | POINTER_SCREEN, mask);
}
I now get no problem...I could however do better by just using doubles for x
and y in the hw/xwin function headers and get rid of those hacky casts and
trunc()'s. Will now test that + use of POINTER_RELATIVE looks dodgy!
Thanks,
Colin
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
Hi,
On 27 January 2012 10:22, Colin Harrison colin.harri...@virgin.net wrote:
If I revert those traps and then call the function...
void winEnqueueMotion(int x, int y)
{
int valuators[2];
ValuatorMask mask;
double dx = (double)x;
double dy = (double)y;
miPointerSetPosition(g_pwinPointer, POINTER_RELATIVE, dx, dy);
x = trunc(dx);
y = trunc(dy);
valuators[0] = x;
valuators[1] = y;
valuator_mask_set_range(mask, 0, 2, valuators);
QueuePointerEvents(g_pwinPointer, MotionNotify, 0,
POINTER_ABSOLUTE | POINTER_SCREEN, mask);
}
I now get no problem...I could however do better by just using doubles for x
and y in the hw/xwin function headers and get rid of those hacky casts and
trunc()'s. Will now test that + use of POINTER_RELATIVE looks dodgy!
Why are you actually calling miPointerSetPosition at all?
QueuePointerEvents (- GetPointerEvents - positionSprite, both in
dix/getevents.c) already do that for you. You can also avoid the need
for the valuators[] array by just calling valuator_mask_set(mask, 0,
x); valuator_mask_set(mask, 1, y); at which point your function gets
very short indeed.
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: [PULL] hw/xwin fixes + a warning fix
Hi, Daniel wrote: Why are you actually calling miPointerSetPosition at all? Someone had to be daft enough to use it. As in if it isn't defined static then it must be useful And if it is then I want to access it anyway :) It's late...more coffee is required to wash away the dust! Thanks, Colin ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
On Thu, Jan 26, 2012 at 01:10:53PM -0800, Keith Packard wrote: On Thu, 26 Jan 2012 19:27:42 -, Colin Harrison colin.harri...@virgin.net wrote: This looks like it's missing x = dx; y = dy; With this in I get no mouse events (on the left monitor) when the main display is not leftmost with multiple monitors. I don't understand how that can happen -- miSetPointerPosition isn't supposed to change the position unless the pointer is constrained. The casting is probably messing up negative x's on Windows? As in the [PULL] I can't detect any position errors. You won't be clipping mouse positions, which makes this change significantly different from the commit message (as it now discards information that it used to use). Perhaps Peter has some idea of what's going on here... quick peek only but just removing the miSetPointerPosition() call altogether seems like the right thing to do. Not sure why the other one doesn't move the pointer but rough guess: with the newfangled coord scaling using the clipped valuators in QueuePointerEvents may actually cancel out the miPointerSetPosition() effect. That's really just a guess though. Jon confirmed on IRC that just removing miSetPointerPosition() fixes it anyways, so let's do that. 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
[RFC PATCH v2] fixesproto v6: Pointer barrier improvements.
From: Christopher James Halse Rogers r...@ubuntu.com
Adds a velocity-gated pointer barrier, events to notify a client when barriers
are hit, and a mechanism for clients to temporarily allow movement through
a barrier.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
After further prototyping with DX it became clear that, apart from the
initial block, the logic really needed to be client-side. Which, fortunately,
makes for a nicer protocol. Yay!
fixesproto.txt | 86
xfixesproto.h | 44
xfixeswire.h | 24 +--
3 files changed, 150 insertions(+), 4 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..5e680f0 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,92 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierThresholdKind: {None, Velocity, HitCount}
+ BarrierEvent: {Hit, ThresholdExceeded}
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ barrier:BARRIER
+ kind: BarrierThresholdKind
+ threshold: CARD32
+ timestamp: Timestamp
+ value: CARD32
+ x, y: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered, which has a
+ threshold type of kind and threshold value threshold. The value of
+ the property which is compared against the threshold was value.
+
+ (x,y) contain the coordinates of the pointer after restriction by any
+ applicable barriers.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierThreshold
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ type: BarrierThresholdKind
+ threshold: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold is
+ exceeded.
+
+ Type can be None, in which case behaviour is identical to
+ CreatePointerBarrier and threshold is ignored.
+
+ Type can be Velocity, in which case the pointer will pass through the
+ barrier if the instantaneous velocity perpendicular to the barrier
+ in px/sec is greater than threshold.
+
+ Type can be HitCount, in which case the pointer will pass through the
+ barrier once the barrier has been hit threshold times. The count is
+ not automatically reset, so once the threshold has been reached the
+ barrier will not block any further pointer movement.
+
+ If type is not one of these values, BadValue is generated.
+
+ In the case of overlapping barriers each one is tested against, even
+ after the first one blocks the pointer.
+
+ Errors: IDChoice, Window, Value, Device
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..d4d657c 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,50 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ CARD32 directions;
+ Barrier barrier;
+ INT16 x B16;
+ INT16 y B16;
+ CARD32 velocity B32;
+ Time timestamp B32;
+}
[PATCH RFC inputproto] specs: Don't allow for early acceptance/rejection
Definition of early acceptance/rejection: If supported, a client may accept or reject a touch sequence before it becomes the current owner of the sequence. In some cases, this can speed up touch processing as it removes one ore more clients from the listeners and thus reduce the number of events to send and process client-side. Unfortunately, we likely won't have time to implement early acceptance/rejection for XI 2.2 so drop it from the protocol. This can easily be added in XI 2.3 if we get the time to implement it. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- I'm going to hold this patch back until we really can't get the patches into the server anymore but I really doubt we'll get this feature in time. It's quite easy to add to XI 2.3 (reverting this patch) once we have the implementation in place. Meanwhile, a heads up, this part will likely be dropped from 2.2 specs/XI2proto.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt index 10f953a..e1b5b8a 100644 --- a/specs/XI2proto.txt +++ b/specs/XI2proto.txt @@ -1449,8 +1449,8 @@ later than the current X server time. The time parameter must be CurrentTime for requests with event modes of AcceptTouch and RejectTouch. When event-mode is AcceptTouch, a BadValue error occurs if the touch ID is -invalid. A BadAccess error occurs if this client is not the current or potential -owner of the specified touch ID. +invalid. A BadAccess error occurs if this client is not the current owner of +the specified touch ID. The following describes the processing that occurs depending on what constant you pass to the event-mode argument: -- 1.7.7.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Format cleanup of help output
On 12-01-26 11:29 AM, Trevor Woerner wrote:
From: Trevor Woerner twoer...@gmail.com
Miscellaneous cleanups of the help text that is printed.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index 5878ef1..9068f29 100755
--- a/build.sh
+++ b/build.sh
@@ -20,7 +20,8 @@ Environment variables specific to build.sh:
Each module/components is invoked with --datadir
LIBDIR Install object code libraries [EPREFIX/lib]
Each module/components is invoked with --libdir
- LOCALSTATEDIR Modifiable single-machine data [PREFIX/var]
+ LOCALSTATEDIR
+ Modifiable single-machine data [PREFIX/var]
Each module/components is invoked with --localstatedir
QUIET Do not print messages saying which checks are being made
Each module/components is invoked with --quite
@@ -33,7 +34,7 @@ Environment variables defined by the GNU Build System:
ACLOCAL The aclocal cmd name [aclocal -I
\${DESTDIR}/\${DATADIR}/aclocal]
DESTDIR Path to the staging area where installed objects are relocated
MAKEThe name of the make command [make]
- MAKEFLAGS: Options to pass to all \$(MAKE) invocations
+ MAKEFLAGS Options to pass to all \$(MAKE) invocations
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a
@@ -47,13 +48,15 @@ Environment variables defined by the shell:
\$DESTDIR/\$BINDIR is prepended
Environment variables defined by the dynamic linker:
- LD_LIBRARY_PATH List directories that the linker searches for shared
objects
- \$DESTDIR/\$LIBDIR is prepended
+ LD_LIBRARY_PATH
+ List directories that the linker searches for shared objects
+ \$DESTDIR/\$LIBDIR is prepended
Environment variables defined by the pkg-config system:
- PKG_CONFIG_PATH List directories that pkg-config searches for libraries
- \$DESTDIR/\$DATADIR/pkgconfig and
- \$DESTDIR/\$LIBDIR/pkgconfig are prepended
+ PKG_CONFIG_PATH
+ List directories that pkg-config searches for libraries
+ \$DESTDIR/\$DATADIR/pkgconfig and
+ \$DESTDIR/\$LIBDIR/pkgconfig are prepended
EOF
}
@@ -1052,22 +1055,26 @@ usage() {
echo -g Compile and link with debug information
echo -h, --help Display this help and exit successfully
echo -n Do not quit after error; just print error message
-echo -o module/component Build just this module/component
+echo -o module/component
+echo Build just this module/component
echo -p Update source code before building (git pull
--rebase)
echo -s sudo The command name providing superuser privilege
-echo --autoresume file Append module being built to, and autoresume
from, file
+echo --autoresume file
+echo Append module being built to, and autoresume from,
file
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
-echo --confflags options Pass options to autgen.sh/configure of
all modules
-echo --modfile file Only process the module/components specified in
file
+echo --confflags options
+echo Pass options to autgen.sh/configure of all modules
+echo --modfile file
+echo Only process the module/components specified in
file
echo Any text after, and on the same line as, the
module/component
echo is assumed to be configuration options for the
configuration
echo of each module/component specifically
echo --retry-v1 Remake 'all' on failure with Automake silent rules
disabled
echo
echo Usage: $basename -L
-echo -L : just list modules to build
+echo -L Just list modules to build
echo
envoptions
}
Pushed
116f670..a68aacc master - master
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app-transset] COPYING: make the content reflect the copyright statements in source code
Hello,
Gaetan Nadon mems...@videotron.ca writes:
The author of the code should submit a patch to clarify his rights
over the code. The X.Org preferred license can be found here:
http://www.x.org/releases/X11R7.6/doc/xorg-docs/License.html#id2521948
That would be great indeed.
The role of the COPYING file is to reflect (or summarize) the
copyright statements in the source code. Currently it is wrong. If
this patch makes it correct, it should be applied. If and when the
source code changes, the COPYING file would need to be updated again
(business as usual).
I agree with you, but the patch you sent only reflects the copyright
statements of a part of dsimple.{c,h}.
Regards,
--
Arnaud Fontaine
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] hw/xwin fixes + a warning fix
On Fri, 27 Jan 2012 10:28:40 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Jon confirmed on IRC that just removing miSetPointerPosition() fixes it anyways, so let's do that. Makes a lot more sense to me anyways... -- keith.pack...@intel.com pgpX9OtWdnRR5.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: [RFC PATCH v2] fixesproto v6: Pointer barrier improvements.
Here are some patches for a quick, prototype implementation of this
protocol. They're what we've been using to test the protocol is
sufficiently useful.
These are provided for people who'd like to test the behaviour; they are
in no way intended to be applied as-is.
Chris
diff --git a/include/protocol-versions.h b/include/protocol-versions.h
index 479ac2f..f965d6f 100644
--- a/include/protocol-versions.h
+++ b/include/protocol-versions.h
@@ -122,7 +122,7 @@
#define SERVER_XF86VIDMODE_MINOR_VERSION 2
/* Fixes */
-#define SERVER_XFIXES_MAJOR_VERSION 5
+#define SERVER_XFIXES_MAJOR_VERSION 6
#define SERVER_XFIXES_MINOR_VERSION 0
/* X Input */
diff --git a/mi/mipointer.c b/mi/mipointer.c
index 998c86c..c728283 100644
--- a/mi/mipointer.c
+++ b/mi/mipointer.c
@@ -619,6 +619,9 @@ miPointerSetPosition(DeviceIntPtr pDev, int mode, double *screenx, double *scree
}
}
}
+if (pScreen-ConstrainCursorHarder)
+ pScreen-ConstrainCursorHarder(pDev, pScreen, mode, x, y);
+
/* Constrain the sprite to the current limits. */
if (x pPointer-limits.x1)
x = pPointer-limits.x1;
@@ -629,9 +632,6 @@ miPointerSetPosition(DeviceIntPtr pDev, int mode, double *screenx, double *scree
if (y = pPointer-limits.y2)
y = pPointer-limits.y2 - 1;
-if (pScreen-ConstrainCursorHarder)
- pScreen-ConstrainCursorHarder(pDev, pScreen, mode, x, y);
-
if (pPointer-x != x || pPointer-y != y ||
pPointer-pScreen != pScreen)
miPointerMoveNoEvent(pDev, pScreen, x, y);
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 53f9f20..40e1ff5 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -61,6 +61,7 @@ static RESTYPE CursorClientType;
static RESTYPE CursorHideCountType;
static RESTYPE CursorWindowType;
RESTYPE PointerBarrierType;
+static RESTYPE PointerBarrierClientType;
static CursorPtr CursorCurrent[MAXDEVICES];
static DevPrivateKeyRec CursorScreenPrivateKeyRec;
@@ -129,6 +130,7 @@ typedef struct _CursorScreen {
ConstrainCursorHarderProcPtr ConstrainCursorHarder;
CursorHideCountPtr pCursorHideCounts;
struct list barriers;
+struct list barrierClients;
} CursorScreenRec, *CursorScreenPtr;
#define GetCursorScreen(s) ((CursorScreenPtr)dixLookupPrivate((s)-devPrivates, CursorScreenPrivateKey))
@@ -1220,14 +1222,65 @@ barrier_clamp_to_barrier(struct PointerBarrier *barrier, int dir, int *x, int *y
}
static void
+SendBarrierEvent(CursorScreenPtr cs, struct PointerBarrier *barrier,
+ int x, int y, int velocity, Bool threshold_exceeded)
+{
+PointerBarrierEventClientPtr client;
+list_for_each_entry(client, cs-barrierClients, entry) {
+ xXFixesBarrierNotifyEvent ev;
+ ev.type = XFixesEventBase + XFixesBarrierNotify;
+ ev.subtype = threshold_exceeded ? XFixesBarrierThresholdExceededNotify :
+ XFixesBarrierHitNotify;
+ ev.event_id = barrier-barrierEventID;
+ ev.barrier = barrier-barrier;
+ ev.x = x;
+ ev.y = y;
+ ev.velocity = velocity;
+ ev.timestamp = currentTime.milliseconds;
+ WriteEventsToClient (client-client, 1, (xEvent *) ev);
+}
+}
+
+static void
+barrier_calculate_velocity_components (int x1, int y1, int x2, int y2,
+ int *vel_x, int *vel_y)
+{
+static CARD32 last_timestamp = 0;
+CARD32 timestamp = GetTimeInMillis();
+int dx, dy;
+int dt = timestamp - last_timestamp;
+
+if (last_timestamp == 0) {
+ /* Not much we can do for the first event */
+ *vel_x = 0;
+ *vel_y = 0;
+ last_timestamp = timestamp;
+ return;
+}
+
+/* Lets not divide by zero if we can avoid it */
+dt = dt 0 ? dt : 1;
+
+dx = x2 - x1;
+dy = y2 - y1;
+
+*vel_x = abs(dx) * 1000.0 / dt;
+*vel_y = abs(dy) * 1000.0 / dt;
+
+last_timestamp = timestamp;
+}
+
+static void
CursorConstrainCursorHarder(DeviceIntPtr dev, ScreenPtr screen, int mode, int *x, int *y)
{
CursorScreenPtr cs = GetCursorScreen(screen);
if (!list_is_empty(cs-barriers) !IsFloating(dev) mode == Relative) {
int ox, oy;
+ int vel_x, vel_y;
int dir;
struct PointerBarrier *nearest = NULL;
+ PointerBarrierClientPtr c;
/* where are we coming from */
miPointerGetPosition(dev, ox, oy);
@@ -1240,11 +1293,27 @@ CursorConstrainCursorHarder(DeviceIntPtr dev, ScreenPtr screen, int mode, int *x
* destination, again finding the nearest barrier and clamping.
*/
dir = barrier_get_direction(ox, oy, *x, *y);
+ barrier_calculate_velocity_components(ox, oy, *x, *y, vel_x, vel_y);
nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
if (nearest) {
- barrier_clamp_to_barrier(nearest, dir, x, y);
+ int velocity = barrier_is_vertical(nearest) ? vel_x : vel_y;
+ Bool threshold_exceeded = (nearest-velocity == 0) ||
+ (velocity nearest-velocity);
+
+ if (!nearest-lastHit) {
+ /* This is the start of a new barrier event */
+ nearest-barrierEventID++;
+ }
+ if (!threshold_exceeded
+ (nearest-barrierEventID !=
[PATCH] Removal of early acceptance and grab_window
These two features were still marked with a FIXME in the server, both unimplemented (early acceptance responded with a BadAccess, the window argument was ignored completely). Drop them from XI 2.2, they're a nice feature to have but it's unlikely that they will get implemented in time and so far the MT implementations do not seem to require either feature. Dropping grab_window from libXi's XIAllowEvents is a bit of a pain for clients, but since the argument was ignored anyway, clients can just remove it and recompile - no logic changes required. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH inputproto 1/3] Unbreak protocol ABI for XIAllowEvents.
XIAllowEvents was extended with touchid and grab_window in
2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d. This extended the size of the
request from 12 to 20 but also broke the ABI. Older server match the request
size exactly, so compiling libXi 1.5 against inputproto 2.2 and then running
it against a pre-XI 2.2 server causes a BadLength for any XIAllowEvent
request.
Change the new fields from actual fields to simple comments and let the
library/server deal with the extra data.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
XI2proto.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 93d7e32..9039fe7 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -647,10 +647,10 @@ typedef struct {
uint16_tdeviceid;
uint8_t mode;
uint8_t pad;
-uint32_ttouchid;/** Since XI 2.2 */
-Window grab_window;/** Since XI 2.2 */
+/* uint32_ttouchid;Since XI 2.2 */
+/* Window grab_window;Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2 */
+#define sz_xXIAllowEventsReq 12 /** 20 in XI 2.2 */
/**
--
1.7.7.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH inputproto 2/3] Drop grab_window from XIAllowEvents
With the drop of early acceptance/rejection the grab_window argument is not
as necessary anymore as it would be with early acceptance/rejection. Right
now, it is unlikely that the grab_window handling will be implemented in
time for XI 2.2, so drop it from the protocol - let's not pretend we can
actually handle it.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
XI2proto.h |3 +--
specs/XI2proto.txt |4
2 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 9039fe7..9ff3402 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,9 +648,8 @@ typedef struct {
uint8_t mode;
uint8_t pad;
/* uint32_ttouchid;Since XI 2.2 */
-/* Window grab_window;Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 12 /** 20 in XI 2.2 */
+#define sz_xXIAllowEventsReq 12 /** 16 in XI 2.2 */
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e1b5b8a..5035693 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1420,7 +1420,6 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
RejectTouch* }
touchid*:CARD32
-grab_window*:Window
└───
* since XI 2.2
@@ -1439,9 +1438,6 @@ ownership processing.
touchid
The ID of the touch sequence to accept or reject. The value is
undefined
for event modes other than AcceptTouch and RejectTouch.
-grab_window
-The window on which to accept or reject a touch sequence grab. The
value
-is undefined for event modes other than AcceptTouch and RejectTouch.
The request has no effect if the specified time is earlier than the last-grab
time of the most recent active grab for the client, or if the specified time is
--
1.7.7.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH inputproto 3/3] inputproto 2.1.99.6
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index abd8355..028538b 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.60]) -AC_INIT([InputProto], [2.1.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [2.1.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -- 1.7.7.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXi 3/3] libXi 1.5.99.3
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 46f2fb8..77341da 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ # Initialize Autoconf AC_PREREQ([2.60]) -AC_INIT([libXi], [1.5.99.2], +AC_INIT([libXi], [1.5.99.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXi]) AC_CONFIG_SRCDIR([Makefile.am]) AC_CONFIG_HEADERS([src/config.h]) -- 1.7.7.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 1/3] Xi: handle new XIAllowEvents request in inputproto 2.1.99.6
grab_window was dropped completely, touchid was removed from the struct for
ABI compatibility reasons, we need to pull that in manually now.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/xiallowev.c |9 -
configure.ac |2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/Xi/xiallowev.c b/Xi/xiallowev.c
index a4b2f57..5d3116d 100644
--- a/Xi/xiallowev.c
+++ b/Xi/xiallowev.c
@@ -52,7 +52,6 @@ SProcXIAllowEvents(ClientPtr client)
swaps(stuff-deviceid);
swapl(stuff-time);
/* FIXME swap touchid */
-/* FIXME swap window */
return ProcXIAllowEvents(client);
}
@@ -73,8 +72,6 @@ AllowTouch(ClientPtr client, DeviceIntPtr dev, int mode,
uint32_t touchid, XID *
return BadDevice;
}
-/* FIXME window is unhandled */
-
ti = TouchFindByClientID(dev, touchid);
if (!ti)
{
@@ -104,9 +101,10 @@ ProcXIAllowEvents(ClientPtr client)
TimeStamp time;
DeviceIntPtr dev;
int ret = Success;
+uint32_t touchid;
REQUEST(xXIAllowEventsReq);
-/* FIXME: check request length, 12 for XI 2.0+, 20 for XI 2.2+ */
+/* FIXME: check request length, 12 for XI 2.0+, 16 for XI 2.2+ */
ret = dixLookupDevice(dev, stuff-deviceid, client, DixGetAttrAccess);
if (ret != Success)
@@ -138,8 +136,9 @@ ProcXIAllowEvents(ClientPtr client)
break;
case XIRejectTouch:
case XIAcceptTouch:
+touchid = *(uint32_t*)stuff[1];
ret = AllowTouch(client, dev,
- stuff-mode, stuff-touchid,
+ stuff-mode, touchid,
client-errorValue);
break;
default:
diff --git a/configure.ac b/configure.ac
index b0bb9bb..27ba7d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -776,7 +776,7 @@ XPROTO=xproto = 7.0.22
RANDRPROTO=randrproto = 1.2.99.3
RENDERPROTO=renderproto = 0.11
XEXTPROTO=xextproto = 7.1.99
-INPUTPROTO=inputproto = 2.1.99.5
+INPUTPROTO=inputproto = 2.1.99.6
KBPROTO=kbproto = 1.0.3
FONTSPROTO=fontsproto
FIXESPROTO=fixesproto = 5.0
--
1.7.7.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 2/3] Xi: check request size for xXIAllowEvents based on client version
This request got 4 bytes added in XI 2.2.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/xiallowev.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Xi/xiallowev.c b/Xi/xiallowev.c
index 5d3116d..aadcf62 100644
--- a/Xi/xiallowev.c
+++ b/Xi/xiallowev.c
@@ -41,6 +41,7 @@
#include X11/extensions/XI2proto.h
#include exglobals.h /* BadDevice */
+#include exevents.h
#include xiallowev.h
int
@@ -102,9 +103,22 @@ ProcXIAllowEvents(ClientPtr client)
DeviceIntPtr dev;
int ret = Success;
uint32_t touchid;
+XIClientPtr xi_client;
+int has_xi22 = FALSE;
REQUEST(xXIAllowEventsReq);
-/* FIXME: check request length, 12 for XI 2.0+, 16 for XI 2.2+ */
+
+xi_client = dixLookupPrivate(client-devPrivates, XIClientPrivateKey);
+if (!xi_client)
+return BadRequest;
+
+if (version_compare(xi_client-major_version,
+xi_client-minor_version, 2, 2) = 0)
+{
+has_xi22 = TRUE;
+REQUEST_AT_LEAST_SIZE(xXIAllowEventsReq);
+} else
+REQUEST_SIZE_MATCH(xXIAllowEventsReq);
ret = dixLookupDevice(dev, stuff-deviceid, client, DixGetAttrAccess);
if (ret != Success)
@@ -136,6 +150,9 @@ ProcXIAllowEvents(ClientPtr client)
break;
case XIRejectTouch:
case XIAcceptTouch:
+if (!has_xi22)
+return BadValue;
+
touchid = *(uint32_t*)stuff[1];
ret = AllowTouch(client, dev,
stuff-mode, touchid,
--
1.7.7.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 3/3] Xi: swap touchid for xXIAllowEventsReq
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/xiallowev.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Xi/xiallowev.c b/Xi/xiallowev.c
index aadcf62..95eef40 100644
--- a/Xi/xiallowev.c
+++ b/Xi/xiallowev.c
@@ -52,7 +52,12 @@ SProcXIAllowEvents(ClientPtr client)
swaps(stuff-length);
swaps(stuff-deviceid);
swapl(stuff-time);
-/* FIXME swap touchid */
+
+if (stuff-length = 4) /* XI 2.2+ has touchid */
+{
+uint32_t *touchid = (uint32_t*)stuff[1];
+swapl(touchid);
+}
return ProcXIAllowEvents(client);
}
--
1.7.7.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH inputproto] specs: explain touch behaviour for dependent devices
Dependent devices don't send touch events until the interaction is a true touch interaction (i.e. doesn't just serve to move the pointer). Once that happens, all touchpoints send touch events exclusively. Pointer movement restarts once we're down to one touch that controls the pointer again. For clients listening to touch events in addition to pointer events, this also means that a two-finger tap looks identical to holding one finger down and tapping with a second-finger. Both actions will result in short TouchBegin/TouchEnd sequences for both fingers. The above is the default behaviour we expect from touchpads, the protocol is more generically worded to leave more room for drivers to decide when a touch only controls the pointer and when it doesn't. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Chase Douglas chase.doug...@canonical.com --- specs/XI2proto.txt | 50 ++ 1 files changed, 50 insertions(+), 0 deletions(-) diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt index 9a9217a..10f953a 100644 --- a/specs/XI2proto.txt +++ b/specs/XI2proto.txt @@ -445,6 +445,56 @@ A window set is calculated on TouchBegin and remains constant until the end of the sequence. Modifications to the window hierarchy, new grabs or changed event selection do not affect the window set. +Pointer control of dependent devices + +On a dependent device, the device may differ between a pointer-controlling +touch and a non-pointer-controlling touch. For example, on a touchpad the +first touch is pointer-controlling (i.e. serves only to move the visible +pointer). Multi-finger gestures on a touchpad cause all touches to be +non-pointer-controlling. + +For pointer-controlling touches, no touch events are sent; the touch +generates regular pointer events instead. Non-pointer-controlling touches +send touch events. A touch may change from pointer-controlling to +non-pointer-controlling, or vice versa. + +- If a touch changes from pointer-controlling to non-pointer-controlling, + a new touch ID is assigned and a TouchBegin is sent for the last known + position of the touch. Further events are sent as TouchUpdate events, or as + TouchEnd event if the touch terminates. + +- If a touch changes from non-pointer-controlling to pointer-controlling, a + TouchEnd is sent for that touch at the last known position of the touch. + Further events are sent as pointer events. + +The conditions to switch from pointer-controlling to non-pointer-controlling +touch is implementation-dependent. A device may support touches that are +both pointer-controlling and a touch event. + +.Dependent touch example event sequence on a touchpad, touches are marked +when switching to pointer-controlling (pc) or to non-pointer-controlling (np) +[width=50%, options=header] +| +| Finger 1 | Finger 2 | Event generated(touchid) +| down| | Motion +| move| | Motion +| move| | Motion +| (np)| down | TouchBegin(0), TouchBegin(1) +| move|--| TouchUpdate(0) +| -- | move | TouchUpdate(1) +| up | (pc) | TouchEnd(0), TouchEnd(1) +| | move | Motion +| down| (np) | TouchBegin(2), TouchBegin(3) +| move|--| TouchUpdate(2) +| up | (pc) | TouchEnd(2), TouchEnd(3) +| |up| Motion +| down| | Motion +| (np)| down | TouchBegin(4), TouchBegin(5) +| (pc)|up| TouchEnd(4), TouchEnd(5) +| move| | Motion +| up | | Motion +| + [[multitouch-emulation]] Pointer emulation from multitouch events -- 1.7.7.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[RFC PATCH v3] fixesproto v6: Pointer barrier improvements.
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
Adds a velocity-gated pointer barrier, events to notify a client when barriers
are hit, and a mechanism for clients to temporarily allow movement through
a barrier.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
Whoops. git-fail.
Here's the *actual* simplified protocol those patches implement, and that
we've found to be sufficiently useful.
fixesproto.txt | 87
xfixesproto.h | 57
xfixeswire.h | 23 --
3 files changed, 163 insertions(+), 4 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..1f4fa3e 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,93 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ timestamp: Timestamp
+ velocity: CARD32
+ x, y: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer perpendicular to the barrier.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ threshold: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer remains in contact with the barrier.
+
+ Requests to release the pointer for an event-id which is not current
+ are silently ignored.
+
+ Errors: Barrier
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..9189c19 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,63 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ BarrierEventID event_id B32;
+ Barrier barrier;
+ Timetimestamp B32;
+ CARD32 velocity B32;
+ INT16 x B16;
+ INT16 y B16;
+} xXFixesBarrierNotifyEvent;
+
+typedef struct {
+CARD8 reqType;
Re: [PATCH] xf86: add rgb ordering helper
On Thu, Jan 26, 2012 at 10:32 PM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 27 January 2012 09:28, Aaron Plattner aplatt...@nvidia.com wrote: On 01/26/2012 01:46 PM, Daniel Stone wrote: Can you not drop the ScreenPtr argument and just say that the function relies on ScrnInfoPtr::pScreen being valid? It would presumably be typically called from ScreenInit, where pScrn-pScreen is NULL. If you want to have the server wire that up earlier, that'd be another matter. Rather. A few drivers (at least radeon, nouveau, and vmware, as well as the one I just wrote) wire it up during ScreenInit, which I'd thought was more widespread. I don't see any downside to doing it in the server before ScreenInit though. Yeah thats not the shed I was painting right now. So we can either change it to passing pScreen, and doing the xf86Screens[pScreen-myNum] dance, or we can leave as it is. Dave. 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] xf86: add rgb ordering helper
On Thu, Jan 26, 2012 at 9:57 PM, Keith Packard kei...@keithp.com wrote: On Thu, 26 Jan 2012 11:36:47 +, Dave Airlie airl...@gmail.com wrote: +void xf86FixupRGBOrdering(ScrnInfoPtr scrn, ScreenPtr screen) This name is very misleading; it's filling out visual pixel format information, not somehow 'fixing' RGB ordering. The name is from the comment that is cut-n-pasted in every driver. /* Fixup RGB ordering */ It makes replacing it in drivers easier to find, but please suggest a good name and I'll use it, and/or fix the comments in the drivers. Dave. ___ 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
