ui/events/event_constants.h - Issue 2805793002: ozone: evdev: Add gamepad support

Unified Diff: ui/events/event_constants.h

Issue 2805793002: ozone: evdev: Add gamepad support (Closed)

Patch Set: Created 3 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Index: ui/events/event_constants.h

diff --git a/ui/events/event_constants.h b/ui/events/event_constants.h

index c7736622783d2335da227a73f470beeaa3012a38..2bac6b940cafbc4c0c0d1100d16d448c5fe24776 100644

--- a/ui/events/event_constants.h

+++ b/ui/events/event_constants.h

@@ -39,6 +39,12 @@ enum EventType {

ET_POINTER_WHEEL_CHANGED,

ET_POINTER_CAPTURE_CHANGED,

+ // GamepadEvent types

+ ET_GAMEPAD_BTN_PRESSED,

+ ET_GAMEPAD_BTN_RELEASED,

+ ET_GAMEPAD_ABS_MOVED,

+ ET_GAMEPAD_FRAME,

sadrul 2017/04/10 18:14:05 What's GAMEPAD_FRAME event?

jkwang 2017/04/10 18:19:08 It's essentially a successful sync (syn_reported i

dtapuska 2017/04/10 19:13:35 Is this mapped to a vsync signal?

jkwang 2017/04/10 20:07:47 Sorry, I am not aware of vsync signal. Could you p

sadrul 2017/04/12 18:03:58 OK. Can this be handled from the evdev-handler? Fo

jkwang 2017/04/12 20:51:55 Yeah. I took a look at how Touch EV_SYN is handled

sadrul 2017/04/12 21:26:32 The spec says "A client is expected to accumulate

The spec says "A client is expected to accumulate the data in all events within the frame before proceeding.", so accumulating the data in evdev-handler makes most sense to me.

In the current approach, each consumer (i.e. any ui::EventHandler) of gamepad events will need to do the aggregation separately, which doesn't make sense. There is also the risk that events in the same frame go to different handlers. I would also like to see how these events are actually going to be consumed from exo. Is there a draft CL I could look at for that part?

jkwang 2017/04/12 21:41:19 Sorry, there is no draft CL yet. But it will be ve

On 2017/04/12 21:26:32, sadrul wrote: > On 2017/04/12 20:51:55, jkwang wrote: > > On 2017/04/12 18:03:58, sadrul wrote: > > > On 2017/04/10 18:19:08, jkwang wrote: > > > > On 2017/04/10 18:14:05, sadrul wrote: > > > > > What's GAMEPAD_FRAME event? > > > > > > > > It's essentially a successful sync (syn_reported instead of syn_dropped). > > > > Currently the wayland protocol send explicit gamepad frame to sync with > the > > > > client. > > > > > > > > > > https://cs.chromium.org/chromium/src/third_party/wayland-protocols/unstable/g... > > > > > > OK. Can this be handled from the evdev-handler? For touch-events, for > example, > > > we do not generate a TouchEvent until the EV_SYN. Is there a reason gamepad > > > should be different here? > > > > Yeah. I took a look at how Touch EV_SYN is handled. For gamepad, I have > several > > concerns. > > > > 1. Generate Gamepad Event until EV_SYN means we have to aggregate the event, > > which easily results in jamming all buttons and axes state into one gamepad > > event. This does not feel event-driven. > > The spec says "A client is expected to accumulate the data in all events within > the frame before proceeding.", so accumulating the data in evdev-handler makes > most sense to me. > > > 2. Currently, the client of this gamepad implementation will be exo. Exo send > > gamepad frame explicitly. If we aggregate gamepad events here, we will end up > > keeping a state in exo, the we have to diff the state, and disassemble the > > events and send a gamepad frame (sync) again. That seems to be unnecessary > > complexity. > > > > If there is not strong reason that EV_SYN should not be send explicitly, I > think > > current approach will make things simpler. > > In the current approach, each consumer (i.e. any ui::EventHandler) of gamepad > events will need to do the aggregation separately, which doesn't make sense. > There is also the risk that events in the same frame go to different handlers. > > I would also like to see how these events are actually going to be consumed from > exo. Is there a draft CL I could look at for that part?

Sorry, there is no draft CL yet. But it will be very straight forward. Other than binding gamepad to the gaming seat. It will route the events through gamepad delegate. Which is here : https://cs.chromium.org/chromium/src/components/exo/gamepad_delegate.h. Exo is not going to do any aggregation, the aggregation will be in the android side. If the aggregation is done here, I am afraid there won't be + ET_GAMEPAD_BTN_PRESSED, + ET_GAMEPAD_BTN_RELEASED, + ET_GAMEPAD_ABS_MOVED,. There will only be ET_GAMEPAD cause all the pressed/released can happen at the same time. It will be one event sending the state of gamepad.

// GestureEvent types

ET_GESTURE_SCROLL_BEGIN,

ET_GESTURE_TYPE_START = ET_GESTURE_SCROLL_BEGIN,

« ui/events/event.h ('K') | « ui/events/event.cc ('k') | ui/events/event_handler.h » ('j') | ui/events/ozone/evdev/event_device_info_unittest.cc » ('J')