Subject: MirEvent 2.0

From: Robert Carr <[email-masked]>
Date: Tue, 21 Oct 2014 12:18:27 -0400

Notes from me and chris

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 21 Oct 2014 13:10:04 -0400

Missing (possibly just due to over-simplification in the high level design):

* Non-input events
* Event struct size field (would allow for compression, omitting unused 
array entries).

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 21 Oct 2014 13:30:25 -0400

> Missing (possibly just due to over-simplification in the high level 
Correct. Non-input events aren't input events, and so will be treated 
separately :)

> * Event struct size field (would allow for compression, omitting 
> unused array entries).

There are no fixed-size arrays there? The only array is the touch 
array, and that already has TouchCount.

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 21 Oct 2014 13:36:44 -0400

Right, so what you call MirEvent should be MirInputEvent. Because 
MirEvent can include non-input events.

Also, that TouchCount is useful but not enough. If we're to have 
variable-sized MirEvents so as to not waste a whole kilobyte on each 
one, then the generic MirEvent struct needs a generic size (in bytes) 
field. So the code that's passing around (and putting on the wire) 
MirEvents knows how big each one is.

On 21/10/14 13:30, Christopher James Halse Rogers wrote:
> There are no fixed-size arrays there? The only array is the touch array,
> and that already has TouchCount.
>

---

From: Robert Carr <[email-masked]>
Date: Tue, 21 Oct 2014 15:12:59 -0400

Notes draft 2

* Split out non input events?

* MirEvent 2.0
** Device events (MirDeviceEvent)
*** give every device an id
*** define attributes
*** device creation, device change, device destruction, attribute retreival
*** xinput list-props
** Key events
*** Source ID (source device class) replaced with device property, dropped
from key event.
*** Is action multiple really a keyevent?
** Motion events
*** Event  ID is for matching syntthetic events (e.g.) scroll to physical
events
*** Client API for supporting cancellation

* Device configuration API
** Grab/ungrabbing
** Event subscription (subscribe to pointer or touch)
** Change mode from absolute to relative (e.g. tablet) (is this a part of
event subscription? e.g. you subscribe to relative or absolute events)
** Change assosciated absolute surface for tablets, etc.

MirEvent
{
EventId # Unique identifier of event
DeviceId # Origin device
EventTime # Lowest level time stamp (w.r.t hardware->kernel->mir...) of
event

SynthesizedTo # Id of synthetic event generated from this event, e.g.
scroll from two finger swipe on touchpad.

MirDeviceEvent

MirKeyEvent
MirTextEvent
MirPointerEvent
MirTouchEvent
}

# Reports addition and removal of devices.
MirDeviceConfigurationEvent
{
Action { added, removed, changed }

AttributeChanged # ID of input device attribute which has been reconfigured.
                 # value can be retreived e.g.
mir_input_device_query_attribute
}

MirKeyEvent
{
Action { down, repeat, up } # Question: Is there a value in supporting
cancellation for text events?
KeyCode (also, get_as_text/get_text) # XKB Keysym. Can be retreived as
unicode string.
ScanCode
Modifiers
DownTime
}

# Support for 'Input Methods' ala CJK input, text completion engines, etc.
# 'Set' begins a transaction, entering the 'pre-edit' state, set will be
called
# repeatedly with new values for GetText reflecting the continued evolution
# of the string. Eventually commit should be called indicating the pre-edit
# phase should be left and the text should be committed. If GetText is null
# then that is interpreted as a "cancellation" and the preddit phase should
# exited but the text not commited.
MirTextEvent
{
Action {set, commit}
GetText
}

# Instantaneous state of relative pointer axes.
MirPointerEvent
{
ButtonState
X
Y
Hscroll
Vscroll
}

# Instantaneous state of touch device
MirTouchEvent
{
TouchCount

MirTouch
{
   TouchId # A unique tracker for this touchpoint, refers to the same
physical touchpoint inbetween
           # a Action::Down event with this touch id and a corresponding
Action::Up event
   Action { Up, Down, Change, Cancel } # The change being reported for this
touch point.
   # may correspond to: a touch going down, a touch coming up, touch axis
changes, or a touch cancellation
   # indicating that client changes made since touch down should be
reverted and touch up will not arrive
   # client must indicate it can support cancellation
   Axis (X, Y, pressure, etc...)
   Tooltype
}[TouchCount]

}

On Tue, Oct 21, 2014 at 1:36 PM, Daniel van Vugt <
[email-masked]> wrote:

> Right, so what you call MirEvent should be MirInputEvent. Because MirEvent
> can include non-input events.
>
> variable-sized MirEvents so as to not waste a whole kilobyte on each one,
> then the generic MirEvent struct needs a generic size (in bytes) field. So
> the code that's passing around (and putting on the wire) MirEvents knows
> how big each one is.
>
>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 21 Oct 2014 15:18:39 -0400

You have input-specific fields "EventId", "DeviceId", "EventTime" in the 
generic event structure. These fields only apply to input events.

So your "MirEvent" needs to be called "MirInputEvent" (slightly nicer 
than "MirDeviceEvent") and MirInputEvent is a variation of a generic 
MirEvent.

On 21/10/14 15:12, Robert Carr wrote:
> EventTime # Lowest level time stamp (w.r.t