Xorg input thread (2)

[Jesse Barnes]

On Friday, July 6, 2007 10:45:39 pm Keith Packard wrote:
> On Fri, 2007-07-06 at 17:21 -0700, Jesse Barnes wrote:
> > Hm, well if that works well we might consider it.  How much needs to be
> > mlocked?  There are mechanisms to allow processes to lock a small amount
> > of memory if needed, so if it's not too much, we could mlock instead of
> > using a new thread.
>
> The new thread is required to avoid mlock'ing the whole X server; the
> existing problem occurs because the signal handler cannot run while the
> process is waiting for some random pixmap to page back in. The thought
> was that by using a separate thread, we'd avoid waiting for said random
> pixmap to page back in and get right to the cursor drawing.

Well, the curious thing was what Tiago said:

> with or without the input thread when I mlock some mice
> functions I obtained an unbelievable smooth movement

Which would imply that when SIGIOs are sent, the process is woken up and can 
process things just fine, even if other pages are still coming in from disk 
(I didn't think this was possible, I'd have to poke around the kernel).

> Can we determine whether the thread is actually blocked waiting for one
> of its pages to get read back in?

Well, if it's in D state, it's either that or writing out to the X 
log.  /proc/<pid>/wchan might give us a hint too.  A tool like systemtap 
would make finding out for sure pretty easy too.

> > > The small conclusion of 2): if the real focus of the input thread is to
> > > stop with the cursor's lag then we must provide other ways to keep the
> > > cursor's footprint in the physical memory. (Should I consider the
> > > Jesse's suggestion to put this all inside DRM? I really don't know how
> > > difficult this can be. Jesse, please?)
>
> Ultrix systems placed the entire input subsystem in the kernel,
> connecting the mouse hardware directly to the cursor position update
> function. That seems doable again. Note that the only cursor so modified
> was the *hardware* cursor. Painting a cursor image is quite hard as you
> have to save/restore areas under the cursor.
>
> > My thought was that the DRM driver would take care of the actual cursor
> > blt to the screen, based on events it receives from the input layer.
>
> Not blt, just touching the cursor address registers. Those are "know" to
> be safe on most hardware, even when the rendering engine is going
> full-blast. We'd then rewrite the event stream from the pointer device
> to an absolute position, doing all of the acceleration computation in
> the kernel. We'd have to add ioctls to the event device or DRM to
> connect the two together and provide some mechanism for 'warping' the
> cursor around.

Yeah, doing just hw cursors is definitely easiest, but don't many desktop 
cursors these days require sw cursors, either because they're the wrong size 
or have too many colors?  I forgot about acceleration though, you're right 
that would have to be in-kernel as well.

> > Threads (on Linux at least) are fairly lightweight, so even on embedded
> > systems the added thread shouldn't be too much of a burden.  I think the
> > DRM based solution would be even nicer for embedded systems though.
>
> We were rather hoping to avoid adding the complexities of the connection
> between input device and output device to the kernel though.

With a suitable in-kernel API and a new interface it shouldn't be too bad.  
But it might be more than Tiago is willing to tackle for his SoC project. :)

Jesse