Xorg input thread (2)

[Jesse Barnes]

On Sunday, July 8, 2007 11:51:49 pm Keith Packard wrote:
> 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).

It's fairly easy using gcc extensions, e.g. using 
__attribute__((section("mouse_functions")) for all mouse related functions 
and data.  Then at startup time, the mlock routine would lock that whole 
section (you'd have to use some ELF parsing routines to get the address and 
length of the section used).

Jesse