button->down used inconsistently

[Keith Packard]

On Sun, 2008-06-15 at 12:10 +0930, Peter Hutterer wrote:
> On Sat, Jun 14, 2008 at 01:31:58PM -0700, Keith Packard wrote:
> > Some parts of the server use button->down as a bitmask, other parts use
> > it as a per-button down count. It seems like using it consistently as a
> > bitmask would match the keyboard behaviour nicely. Also, lots of the
> > server already uses this as a bitmask, so changing that would be a lot
> > more invasive.
> 
> NACK.
> 
> This changes the server behaviour if 2 or more SDs are attached to the same
> MD. In the current server, the button count is increased and the release is
> sent when the _last_ SD releases the respective button.
> With this patch, the release is sent for each SD that releases a button.

Given that this is new behaviour, and that the server didn't do this
before, I'd say it's fixing a new bug. Whether the  button is released
on the first or final release is a matter of opinion, and having it
released on the first is more reliable, in case the button down count is
broken, hitting and releasing a button will fix it in the boolean case,
but not in the counting case.

> 
> Reproducable by simply using mouse + touchpad, press button 1 on both, release
> button 1 on both and the event sequence is 
> 
> press 1 - state 0x0 
>   (second press is swallowed)
> release 1 - state 0x100 
> release 1 - state 0x0

If you look at the patch, the second release is swallowed as releases
when the button is up aren't reported.

>  So the
> current code, albeit messy, is preferable since it provides the correct
> behaviour.

The current code has a horrible bug -- it misreports button state as it
copies the 'down' array to the wire.

Given the increased reliability of using simple booleans, and the fact
that the protocol requires the booleans, it seems like my patch fixed
the protocol incorrectness, increased overall reliability in the face of
stuck buttons and still preserved the up/down serialization requirement,
although with slightly different 'first occurance' semantics.

>   Peter
-- 
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/20080617/99f7f3e3/attachment.pgp>