[PATCH weston 1/2] libinput: Ignore non seat wide pointer button events

[Peter Hutterer]

On Wed, Jan 28, 2015 at 01:09:09PM -0800, Bill Spitzak wrote:
> I would greatly prefer to get an event when this happens. The user expects
> something to happen when they push a button. You cannot just throw it away.

X does this, OS X does this too. I suspect Windows does as well because
quite frankly the other option doesn't make sense.

> I think it is perfectly safe to send multiple press and release events. No
> program is going to fail because of this. 

[citation needed]

> And as this demonstrates, trying
> to avoid that means you are going to throw away information, and vastly
> complicate the code.

the alternative is leave button/key release behaviour up to the client,
resulting in duplicated code across the various clients/toolkits,
inconsistent behaviour across clients, increased chance of implementation
bugs, etc.

a 11-line fix (times 2 for key events) doesn't strike me as "vastly
complicate the code".

Anyway, you've made it clear multiple times in the past that you are a
proponent of laxer guarantees regarding paired events from the compositor
stack and leaving the messy details to the clients. It has been rejected
every single time so far, I think at this point you should either drop the
topic or spec out an implementation that explains why it is technically
superior and that actually convinces us.

Cheers,
   Peter
 
> On 01/27/2015 08:18 PM, Jonas Ådahl wrote:
> >Pointer button events will be received from a device where a button has
> >been pressed, even though an equivalent button has been pressed (same
> >button code) on a device connected to the same seat. notify_button()
> >expects to only be called as if there was only one pointer device
> >associated with the given seat, so to achieve this, ignore every event
> >where forwarding it would result in multiple 'pressed' or 'released'
> >notifications.
> >
> >Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> >---
> >
> >These two should be safe for the upcoming stable release IMO.
> >
> >
> >Jonas
> >
> >  src/libinput-device.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> >diff --git a/src/libinput-device.c b/src/libinput-device.c
> >index 3ce74b8..5c5b9b9 100644
> >--- a/src/libinput-device.c
> >+++ b/src/libinput-device.c
> >@@ -119,6 +119,17 @@ handle_pointer_button(struct libinput_device *libinput_device,
> >  {
> >  	struct evdev_device *device =
> >  		libinput_device_get_user_data(libinput_device);
> >+	int button_state =
> >+		libinput_event_pointer_get_button_state(pointer_event);
> >+	int seat_button_count =
> >+		libinput_event_pointer_get_seat_button_count(pointer_event);
> >+
> >+	/* Ignore button events that are not seat wide state changes. */
> >+	if ((button_state == LIBINPUT_BUTTON_STATE_PRESSED &&
> >+	     seat_button_count != 1) ||
> >+	    (button_state == LIBINPUT_BUTTON_STATE_RELEASED &&
> >+	     seat_button_count != 0))
> >+		return;
> >
> >  	notify_button(device->seat,
> >  		      libinput_event_pointer_get_time(pointer_event),
> >