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

Side by Side 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:

OLD	NEW
1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.	1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 #ifndef UI_EVENTS_EVENT_CONSTANTS_H_	5 #ifndef UI_EVENTS_EVENT_CONSTANTS_H_

6 #define UI_EVENTS_EVENT_CONSTANTS_H_	6 #define UI_EVENTS_EVENT_CONSTANTS_H_

7	7

8 namespace ui {	8 namespace ui {

9	9

10 // Event types. (prefixed because of a conflict with windows headers)	10 // Event types. (prefixed because of a conflict with windows headers)

(...skipping 21 matching lines...) Expand all Loading...
32 // PointerEvent types	32 // PointerEvent types

33 ET_POINTER_DOWN,	33 ET_POINTER_DOWN,

34 ET_POINTER_MOVED,	34 ET_POINTER_MOVED,

35 ET_POINTER_UP,	35 ET_POINTER_UP,

36 ET_POINTER_CANCELLED,	36 ET_POINTER_CANCELLED,

37 ET_POINTER_ENTERED,	37 ET_POINTER_ENTERED,

38 ET_POINTER_EXITED,	38 ET_POINTER_EXITED,

39 ET_POINTER_WHEEL_CHANGED,	39 ET_POINTER_WHEEL_CHANGED,

40 ET_POINTER_CAPTURE_CHANGED,	40 ET_POINTER_CAPTURE_CHANGED,

41	41

	42 // GamepadEvent types

	43 ET_GAMEPAD_BTN_PRESSED,

	44 ET_GAMEPAD_BTN_RELEASED,

	45 ET_GAMEPAD_ABS_MOVED,

	46 ET_GAMEPAD_FRAME,
	sadrul 2017/04/10 18:14:05 What's GAMEPAD_FRAME event? What's GAMEPAD_FRAME event? jkwang 2017/04/10 18:19:08 It's essentially a successful sync (syn_reported i Show quoted text 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... dtapuska 2017/04/10 19:13:35 Is this mapped to a vsync signal? Show quoted text 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... 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 Show quoted text On 2017/04/10 19:13:35, dtapuska 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... > > Is this mapped to a vsync signal? Sorry, I am not aware of vsync signal. Could you point me to it? (Vertical Sync? Why is gamepad mapped to vsync?) Currently, when the frame is seen, the gamepad events will be accumulated and processed together. sadrul 2017/04/12 18:03:58 OK. Can this be handled from the evdev-handler? Fo Show quoted text 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? jkwang 2017/04/12 20:51:55 Yeah. I took a look at how Touch EV_SYN is handled Show quoted text 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. 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. sadrul 2017/04/12 21:26:32 The spec says "A client is expected to accumulate Show quoted text 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. Show quoted text > 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? jkwang 2017/04/12 21:41:19 Sorry, there is no draft CL yet. But it will be ve Show quoted text 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.
	47

42 // GestureEvent types	48 // GestureEvent types

43 ET_GESTURE_SCROLL_BEGIN,	49 ET_GESTURE_SCROLL_BEGIN,

44 ET_GESTURE_TYPE_START = ET_GESTURE_SCROLL_BEGIN,	50 ET_GESTURE_TYPE_START = ET_GESTURE_SCROLL_BEGIN,

45 ET_GESTURE_SCROLL_END,	51 ET_GESTURE_SCROLL_END,

46 ET_GESTURE_SCROLL_UPDATE,	52 ET_GESTURE_SCROLL_UPDATE,

47 ET_GESTURE_TAP,	53 ET_GESTURE_TAP,

48 ET_GESTURE_TAP_DOWN,	54 ET_GESTURE_TAP_DOWN,

49 ET_GESTURE_TAP_CANCEL,	55 ET_GESTURE_TAP_CANCEL,

50 ET_GESTURE_TAP_UNCONFIRMED, // User tapped, but the tap delay hasn't expired.	56 ET_GESTURE_TAP_UNCONFIRMED, // User tapped, but the tap delay hasn't expired.

51 ET_GESTURE_DOUBLE_TAP,	57 ET_GESTURE_DOUBLE_TAP,

(...skipping 148 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
200 // Device type for gesture events.	206 // Device type for gesture events.

201 enum class GestureDeviceType : int {	207 enum class GestureDeviceType : int {

202 DEVICE_UNKNOWN = 0,	208 DEVICE_UNKNOWN = 0,

203 DEVICE_TOUCHPAD,	209 DEVICE_TOUCHPAD,

204 DEVICE_TOUCHSCREEN,	210 DEVICE_TOUCHSCREEN,

205 };	211 };

206	212

207 } // namespace ui	213 } // namespace ui

208	214

209 #endif // UI_EVENTS_EVENT_CONSTANTS_H_	215 #endif // UI_EVENTS_EVENT_CONSTANTS_H_

OLD	NEW

« 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')