> My concern with adding cancellation behaviour is that there'll be no existing client or toolkit that expects it, and we can't make it opt-in (like the opt-in touch cancellation support).
That's a good point but extra events are kind of opt-in already with zero code change for most clients. If clients see an event they don't understand they should ignore it and not treat it as an error. On the other hand, cancellation support would help the VT switching problem with modifier press/release. And on the third hand ;) I continue to believe we should just be writing more robust code that can survive seeing a press without a release and a release without a press. Because clearly we have two real-world use cases (on phone and desktop!) where that can happen. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1547864 Title: libinput doesn't handle EV_KEY event with a value of 255 (BUTTON_CANCLED), to support Android home buttons Status in Mir: Triaged Status in libinput package in Ubuntu: New Status in mir package in Ubuntu: Triaged Bug description: I port Ubuntu Touch to LG L90 Dual. When I press a button below the screen (it's the touch button and is part of the touch screen), then slide the finger up, a letter will repeatedly appear in any text field selected (for instance, if the button is a menu button, letter 'e' will appear repeatedly). Using evtest with the touch screen device, I can see what happened: Event: time 75.605520, type 1 (EV_KEY), code 139 (KEY_MENU), value 1 Event: time 75.605525, -------------- EV_SYN ------------ Event: time 75.707065, type 1 (EV_KEY), code 139 (KEY_MENU), value 255 (See the full log here: http://paste.ubuntu.com/15112114/) When I place the finger down, touch screen will send an event with type 1 (EV_KEY), code 139 (KEY_MENU), and value 1, indicating that the button is placed. And when I move the finger away from the button, touch screen will send an event with type 1 (EV_KEY), code 139 (KEY_MENU), and value 255. Digging in kernel code reveals that this is defined as "BUTTON_CANCLED". Looking in libevent code, it seems that it always assume that anything that is not 0 will be considered as pressed, which makes it looks like the button is hold. To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1547864/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
