[PATCH 5/5] input: use a thread for the generation of input events

[Daniel Stone]

Hi,

On Thu, Dec 16, 2010 at 03:31:40PM -0500, Adam Jackson wrote:
> If configured, and enabled at runtime, use a separate thread for
> handling input devices.  Use pipes to communicate plug events from main
> thread to input thread, and to communicate event queue updates from
> input thread to main thread.

The locking in this isn't quite sufficient.  Pretty much all
Get*Events() users will need locking around their event-handling body,
as the following can go badly wrong:
  * One master device with an XTest and a physical slave device
  * Main thread gets a request to generate an XTest event, calls
    GetPointerEvents which sends a DeviceChangedEvent to switch the MD
    to the XTest SD's caps, as well as the pointer event itself
  * Main thread posts DCE through mieqEnqueue
  * Input thread turns up and griefs the entire process by calling
    GetPointerEvents, generating a DCE to switch the MD's caps to the
    physical SD's, posts its DCE
  * XTest posts its pointer event
  * Input thread posts its pointer event

(Took me three goes to type GetPointerEvents instead of GetTouchEvents.
 Ugh.)

Mind you, we have the same race with SIGIO, so it's not a strictly a
regression, but still not ideal.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110120/8ebd492e/attachment.pgp>