Xorg input thread (2)
Keith Packard
keithp at keithp.com
Sun Jul 8 23:51:49 PDT 2007
On Mon, 2007-07-09 at 03:38 -0300, Tiago Vignatti wrote:
> Got it? In summary, I locked to memory all functions until Dispatch is
> called and when the X server is in the D state the cursor lags when some
> clients connected to X are using blocks which aren't locked. And if
> we're using the input thread (consequently not SIGIO) it doesn't lags!
Excellent!
> How easily I could identify these functions? I think that I must dig
> more this way and study these ELF tricks. Keith, could you please tell
> more about it or point me something? Some docs would be good.
It should be fairly easy to statically examine the code to determine
which functions are related to mouse/cursor echoing. If you want an
automatic mechanism, you might look at the -finstrument-functions
compiler option.
When I did the SIGIO analysis to ensure no 'unsafe' functions were used
from a signal handler, I don't recall it taking but an hour or so to
trace the program flow for mouse motion though; it's not that long a
path.
I'm not sure who we can call on to help with suitable ELF magic though;
certainly the kernel uses this kind of stuff to place initialization
code in separate segments (so they can be discarded, I presume).
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070708/5f50fe1d/attachment.pgp>
More information about the xorg
mailing list