Xorg input thread (2)

[Keith Packard]

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.

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

> 
> > Q: How to reproduce 2)? A: a malloc hog.
> >
> >
> > 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.

> 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.

-- 
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/20070706/e3f6ccde/attachment.pgp>