MirEvent 2.0

2014-10-21 Thread Robert Carr
Notes from me and chris mir-event.org Description: Binary data -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: MirEvent 2.0

2014-10-21 Thread Daniel van Vugt
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). On 21/10/14 12:18, Robert Carr wrote: Notes from me and chris -- Mir-devel mailing list Mir-devel@lists

Re: MirEvent 2.0

2014-10-21 Thread Christopher James Halse Rogers
On Tue, Oct 21, 2014 at 1:10 PM, Daniel van Vugt wrote: Missing (possibly just due to over-simplification in the high level design): * Non-input events Correct. Non-input events aren't input events, and so will be treated separately :) * Event struct size field (would allow for compression

Re: MirEvent 2.0

2014-10-21 Thread Daniel van Vugt
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 s

Re: MirEvent 2.0

2014-10-21 Thread Robert Carr
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) repla

Re: MirEvent 2.0

2014-10-21 Thread Daniel van Vugt
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