cand at gmx.com
Thu Jan 26 07:51:12 PST 2012
On Thu, 26 Jan 2012 09:37:28 -0500
Adam Jackson <ajax at redhat.com> wrote:
> > 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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6865 bytes
Desc: not available
More information about the xorg