diff for duplicates of <1515260592.23948.23.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 5800a00..6e1bb16 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,82 +1,46 @@ -On Sat, 2018-01-06 at 13:12 +0000, Jonathan Cameron wrote: -> On Sat, 6 Jan 2018 00:20:24 +0000 -> Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: -> -> > -> > > -> > > > -> > > > From an IIO sensor point of view A Gesture sensor: -> > > Outputs -> > > A pre defined activity type -> > > WAKE -> > > TILT -> > > GLANCE -> > > PICK_UP -> > > & -> > > more -> > > -> > > A user defined activity type as "string" -> > > -> > > Inputs -> > > A raw binary cdev interface to download templates/patterns -> > > -> > > -> > > I want to gather more opinions before submitting a RFC patch. -> > The only question I have is should it appear under IIO or should it -> > be an -> > input event interface. It feels to me more like an input device in -> > that in -> > this case while it's not keys or joystick it is still 'please do -> > X'. That -> > might also make it much easier (in the non-Android space in -> > particular) -> > to bind these activities to actions in things like web browsers. -> > -> I agree that this may well be an option for many of the gestures -> specifically -> metioned (flicks etc and glyphs). -> -> However, there are other obvious uses of this technology such as step -> detection -> or activity classification (running, walking sitting) that so far -> have fallen -> in the scope of IIO as they aren't really things you expect the -> device to -> perform an an action in response to. Another one of those messy -> corners -> that fall through the gaps! -> -> The drivers/iio/accel/mma9553.c does activity detection, but that -> isn't -> really 'events' in the same way as we have here... -> -> So right answer might be a hybrid of an underlying flexible IIO -> device -> and an input front end for when it makes sense. - -What about we can also send an input event, if the event is one of the -input event type which is defined in uapi/linux/input-event-codes.h? - - -> -> We probably need to get the in kernel use of IIO events sorted. Non -> event -> stuff has been sorted for years, but this last corner was never of -> enough -> interest to anyone to actually implement it (it's fairly straight -> forward -> to do). -Currently in IIO event is a u64 value in Fifo. But here we need some -user defined events also. Since this ABI may already may be in use so -can't change u64 to a structure with data type definition and -associated data. But we can define additional predefined ids for custom -events (Similar to HID sensor usage spec added CUSTOM usage ids). - -Thanks, -Srinivas - -> -> > -> > (+ linux-input) -> > -> > Alan +T24gU2F0LCAyMDE4LTAxLTA2IGF0IDEzOjEyICswMDAwLCBKb25hdGhhbiBDYW1lcm9uIHdyb3Rl +Og0KPiBPbiBTYXQsIDYgSmFuIDIwMTggMDA6MjA6MjQgKzAwMDANCj4gQWxhbiBDb3ggPGdub21l +c0BseG9yZ3VrLnVrdXUub3JnLnVrPiB3cm90ZToNCj4gDQo+ID4gDQo+ID4gPiANCj4gPiA+ID4g +DQo+ID4gPiA+IEZyb20gYW4gSUlPIHNlbnNvciBwb2ludCBvZiB2aWV3IEEgR2VzdHVyZSBzZW5z +b3I6wqDCoMKgwqANCj4gPiA+IE91dHB1dHMNCj4gPiA+IAlBIHByZSBkZWZpbmVkIGFjdGl2aXR5 +IHR5cGUNCj4gPiA+IAkJV0FLRQ0KPiA+ID4gCQlUSUxUDQo+ID4gPiAJCUdMQU5DRQ0KPiA+ID4g +CQlQSUNLX1VQDQo+ID4gPiAJCcKgJg0KPiA+ID4gCQnCoG1vcmUNCj4gPiA+IA0KPiA+ID4gCUEg +dXNlciBkZWZpbmVkIGFjdGl2aXR5IHR5cGUgYXMgInN0cmluZyINCj4gPiA+IA0KPiA+ID4gSW5w +dXRzDQo+ID4gPiAJQSByYXcgYmluYXJ5IGNkZXYgaW50ZXJmYWNlIHRvIGRvd25sb2FkIHRlbXBs +YXRlcy9wYXR0ZXJucw0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IEkgd2FudCB0byBnYXRoZXIgbW9y +ZSBvcGluaW9ucyBiZWZvcmUgc3VibWl0dGluZyBhIFJGQyBwYXRjaC7CoMKgDQo+ID4gVGhlIG9u +bHkgcXVlc3Rpb24gSSBoYXZlIGlzIHNob3VsZCBpdCBhcHBlYXIgdW5kZXIgSUlPIG9yIHNob3Vs +ZCBpdA0KPiA+IGJlIGFuDQo+ID4gaW5wdXQgZXZlbnQgaW50ZXJmYWNlLiBJdCBmZWVscyB0byBt +ZSBtb3JlIGxpa2UgYW4gaW5wdXQgZGV2aWNlIGluDQo+ID4gdGhhdCBpbg0KPiA+IHRoaXMgY2Fz +ZSB3aGlsZSBpdCdzIG5vdCBrZXlzIG9yIGpveXN0aWNrIGl0IGlzIHN0aWxsICdwbGVhc2UgZG8N +Cj4gPiBYJy4gVGhhdA0KPiA+IG1pZ2h0IGFsc28gbWFrZSBpdCBtdWNoIGVhc2llciAoaW4gdGhl +IG5vbi1BbmRyb2lkIHNwYWNlIGluDQo+ID4gcGFydGljdWxhcikNCj4gPiB0byBiaW5kIHRoZXNl +IGFjdGl2aXRpZXMgdG8gYWN0aW9ucyBpbiB0aGluZ3MgbGlrZSB3ZWIgYnJvd3NlcnMuDQo+ID4g +DQo+IEkgYWdyZWUgdGhhdCB0aGlzIG1heSB3ZWxsIGJlIGFuIG9wdGlvbiBmb3IgbWFueSBvZiB0 +aGUgZ2VzdHVyZXMNCj4gc3BlY2lmaWNhbGx5DQo+IG1ldGlvbmVkIChmbGlja3MgZXRjIGFuZCBn +bHlwaHMpLg0KPiANCj4gSG93ZXZlciwgdGhlcmUgYXJlIG90aGVyIG9idmlvdXMgdXNlcyBvZiB0 +aGlzIHRlY2hub2xvZ3kgc3VjaCBhcyBzdGVwDQo+IGRldGVjdGlvbg0KPiBvciBhY3Rpdml0eSBj +bGFzc2lmaWNhdGlvbiAocnVubmluZywgd2Fsa2luZyBzaXR0aW5nKSB0aGF0IHNvIGZhcg0KPiBo +YXZlIGZhbGxlbg0KPiBpbiB0aGUgc2NvcGUgb2YgSUlPIGFzIHRoZXkgYXJlbid0IHJlYWxseSB0 +aGluZ3MgeW91IGV4cGVjdCB0aGUNCj4gZGV2aWNlIHRvDQo+IHBlcmZvcm0gYW4gYW4gYWN0aW9u +IGluIHJlc3BvbnNlIHRvLsKgwqBBbm90aGVyIG9uZSBvZiB0aG9zZSBtZXNzeQ0KPiBjb3JuZXJz +DQo+IHRoYXQgZmFsbCB0aHJvdWdoIHRoZSBnYXBzIQ0KPiANCj4gVGhlIGRyaXZlcnMvaWlvL2Fj +Y2VsL21tYTk1NTMuYyBkb2VzIGFjdGl2aXR5IGRldGVjdGlvbiwgYnV0IHRoYXQNCj4gaXNuJ3QN +Cj4gcmVhbGx5ICdldmVudHMnIGluIHRoZSBzYW1lIHdheSBhcyB3ZSBoYXZlIGhlcmUuLi4NCj4g +DQo+IFNvIHJpZ2h0IGFuc3dlciBtaWdodCBiZSBhIGh5YnJpZCBvZiBhbiB1bmRlcmx5aW5nIGZs +ZXhpYmxlIElJTw0KPiBkZXZpY2UNCj4gYW5kIGFuIGlucHV0IGZyb250IGVuZCBmb3Igd2hlbiBp +dCBtYWtlcyBzZW5zZS4NCg0KV2hhdCBhYm91dCB3ZSBjYW4gYWxzbyBzZW5kIGFuIGlucHV0IGV2 +ZW50LCBpZiB0aGUgZXZlbnQgaXMgb25lIG9mIHRoZQ0KaW5wdXQgZXZlbnQgdHlwZSB3aGljaCBp +cyBkZWZpbmVkIGluwqB1YXBpL2xpbnV4L2lucHV0LWV2ZW50LWNvZGVzLmg/DQoNCg0KPiANCj4g +V2UgcHJvYmFibHkgbmVlZCB0byBnZXQgdGhlIGluIGtlcm5lbCB1c2Ugb2YgSUlPIGV2ZW50cyBz +b3J0ZWQuwqDCoE5vbg0KPiBldmVudA0KPiBzdHVmZiBoYXMgYmVlbiBzb3J0ZWQgZm9yIHllYXJz +LCBidXQgdGhpcyBsYXN0IGNvcm5lciB3YXMgbmV2ZXIgb2YNCj4gZW5vdWdoDQo+IGludGVyZXN0 +IHRvIGFueW9uZSB0byBhY3R1YWxseSBpbXBsZW1lbnQgaXQgKGl0J3MgZmFpcmx5IHN0cmFpZ2h0 +DQo+IGZvcndhcmQNCj4gdG8gZG8pLg0KQ3VycmVudGx5IGluIElJTyBldmVudCBpcyBhIHU2NCB2 +YWx1ZSBpbiBGaWZvLiBCdXQgaGVyZSB3ZSBuZWVkIHNvbWUNCnVzZXIgZGVmaW5lZCBldmVudHMg +YWxzby4gU2luY2UgdGhpcyBBQkkgbWF5IGFscmVhZHkgbWF5IGJlIGluIHVzZSBzbw0KY2FuJ3Qg +Y2hhbmdlIHU2NCB0byBhIHN0cnVjdHVyZSB3aXRoIGRhdGEgdHlwZSBkZWZpbml0aW9uIGFuZA0K +YXNzb2NpYXRlZCBkYXRhLiBCdXQgd2UgY2FuIGRlZmluZSBhZGRpdGlvbmFsIHByZWRlZmluZWQg +aWRzIGZvciBjdXN0b20NCmV2ZW50cyAoU2ltaWxhciB0byBISUQgc2Vuc29yIHVzYWdlIHNwZWMg +YWRkZWQgQ1VTVE9NIHVzYWdlIGlkcykuDQoNClRoYW5rcywNClNyaW5pdmFzDQoNCj4gDQo+ID4g +DQo+ID4gKCsgbGludXgtaW5wdXQpDQo+ID4gDQo+ID4gQWxhbg== diff --git a/a/content_digest b/N1/content_digest index bb240e3..d32fe46 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,87 +11,51 @@ " linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>\0" "\00:1\0" "b\0" - "On Sat, 2018-01-06 at 13:12 +0000, Jonathan Cameron wrote:\n" - "> On Sat, 6 Jan 2018 00:20:24 +0000\n" - "> Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:\n" - "> \n" - "> > \n" - "> > > \n" - "> > > > \n" - "> > > > From an IIO sensor point of view A Gesture sensor:\302\240\302\240\302\240\302\240\n" - "> > > Outputs\n" - "> > > \tA pre defined activity type\n" - "> > > \t\tWAKE\n" - "> > > \t\tTILT\n" - "> > > \t\tGLANCE\n" - "> > > \t\tPICK_UP\n" - "> > > \t\t\302\240&\n" - "> > > \t\t\302\240more\n" - "> > > \n" - "> > > \tA user defined activity type as \"string\"\n" - "> > > \n" - "> > > Inputs\n" - "> > > \tA raw binary cdev interface to download templates/patterns\n" - "> > > \n" - "> > > \n" - "> > > I want to gather more opinions before submitting a RFC patch.\302\240\302\240\n" - "> > The only question I have is should it appear under IIO or should it\n" - "> > be an\n" - "> > input event interface. It feels to me more like an input device in\n" - "> > that in\n" - "> > this case while it's not keys or joystick it is still 'please do\n" - "> > X'. That\n" - "> > might also make it much easier (in the non-Android space in\n" - "> > particular)\n" - "> > to bind these activities to actions in things like web browsers.\n" - "> > \n" - "> I agree that this may well be an option for many of the gestures\n" - "> specifically\n" - "> metioned (flicks etc and glyphs).\n" - "> \n" - "> However, there are other obvious uses of this technology such as step\n" - "> detection\n" - "> or activity classification (running, walking sitting) that so far\n" - "> have fallen\n" - "> in the scope of IIO as they aren't really things you expect the\n" - "> device to\n" - "> perform an an action in response to.\302\240\302\240Another one of those messy\n" - "> corners\n" - "> that fall through the gaps!\n" - "> \n" - "> The drivers/iio/accel/mma9553.c does activity detection, but that\n" - "> isn't\n" - "> really 'events' in the same way as we have here...\n" - "> \n" - "> So right answer might be a hybrid of an underlying flexible IIO\n" - "> device\n" - "> and an input front end for when it makes sense.\n" - "\n" - "What about we can also send an input event, if the event is one of the\n" - "input event type which is defined in\302\240uapi/linux/input-event-codes.h?\n" - "\n" - "\n" - "> \n" - "> We probably need to get the in kernel use of IIO events sorted.\302\240\302\240Non\n" - "> event\n" - "> stuff has been sorted for years, but this last corner was never of\n" - "> enough\n" - "> interest to anyone to actually implement it (it's fairly straight\n" - "> forward\n" - "> to do).\n" - "Currently in IIO event is a u64 value in Fifo. But here we need some\n" - "user defined events also. Since this ABI may already may be in use so\n" - "can't change u64 to a structure with data type definition and\n" - "associated data. But we can define additional predefined ids for custom\n" - "events (Similar to HID sensor usage spec added CUSTOM usage ids).\n" - "\n" - "Thanks,\n" - "Srinivas\n" - "\n" - "> \n" - "> > \n" - "> > (+ linux-input)\n" - "> > \n" - > > Alan + "T24gU2F0LCAyMDE4LTAxLTA2IGF0IDEzOjEyICswMDAwLCBKb25hdGhhbiBDYW1lcm9uIHdyb3Rl\n" + "Og0KPiBPbiBTYXQsIDYgSmFuIDIwMTggMDA6MjA6MjQgKzAwMDANCj4gQWxhbiBDb3ggPGdub21l\n" + "c0BseG9yZ3VrLnVrdXUub3JnLnVrPiB3cm90ZToNCj4gDQo+ID4gDQo+ID4gPiANCj4gPiA+ID4g\n" + "DQo+ID4gPiA+IEZyb20gYW4gSUlPIHNlbnNvciBwb2ludCBvZiB2aWV3IEEgR2VzdHVyZSBzZW5z\n" + "b3I6wqDCoMKgwqANCj4gPiA+IE91dHB1dHMNCj4gPiA+IAlBIHByZSBkZWZpbmVkIGFjdGl2aXR5\n" + "IHR5cGUNCj4gPiA+IAkJV0FLRQ0KPiA+ID4gCQlUSUxUDQo+ID4gPiAJCUdMQU5DRQ0KPiA+ID4g\n" + "CQlQSUNLX1VQDQo+ID4gPiAJCcKgJg0KPiA+ID4gCQnCoG1vcmUNCj4gPiA+IA0KPiA+ID4gCUEg\n" + "dXNlciBkZWZpbmVkIGFjdGl2aXR5IHR5cGUgYXMgInN0cmluZyINCj4gPiA+IA0KPiA+ID4gSW5w\n" + "dXRzDQo+ID4gPiAJQSByYXcgYmluYXJ5IGNkZXYgaW50ZXJmYWNlIHRvIGRvd25sb2FkIHRlbXBs\n" + "YXRlcy9wYXR0ZXJucw0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IEkgd2FudCB0byBnYXRoZXIgbW9y\n" + "ZSBvcGluaW9ucyBiZWZvcmUgc3VibWl0dGluZyBhIFJGQyBwYXRjaC7CoMKgDQo+ID4gVGhlIG9u\n" + "bHkgcXVlc3Rpb24gSSBoYXZlIGlzIHNob3VsZCBpdCBhcHBlYXIgdW5kZXIgSUlPIG9yIHNob3Vs\n" + "ZCBpdA0KPiA+IGJlIGFuDQo+ID4gaW5wdXQgZXZlbnQgaW50ZXJmYWNlLiBJdCBmZWVscyB0byBt\n" + "ZSBtb3JlIGxpa2UgYW4gaW5wdXQgZGV2aWNlIGluDQo+ID4gdGhhdCBpbg0KPiA+IHRoaXMgY2Fz\n" + "ZSB3aGlsZSBpdCdzIG5vdCBrZXlzIG9yIGpveXN0aWNrIGl0IGlzIHN0aWxsICdwbGVhc2UgZG8N\n" + "Cj4gPiBYJy4gVGhhdA0KPiA+IG1pZ2h0IGFsc28gbWFrZSBpdCBtdWNoIGVhc2llciAoaW4gdGhl\n" + "IG5vbi1BbmRyb2lkIHNwYWNlIGluDQo+ID4gcGFydGljdWxhcikNCj4gPiB0byBiaW5kIHRoZXNl\n" + "IGFjdGl2aXRpZXMgdG8gYWN0aW9ucyBpbiB0aGluZ3MgbGlrZSB3ZWIgYnJvd3NlcnMuDQo+ID4g\n" + "DQo+IEkgYWdyZWUgdGhhdCB0aGlzIG1heSB3ZWxsIGJlIGFuIG9wdGlvbiBmb3IgbWFueSBvZiB0\n" + "aGUgZ2VzdHVyZXMNCj4gc3BlY2lmaWNhbGx5DQo+IG1ldGlvbmVkIChmbGlja3MgZXRjIGFuZCBn\n" + "bHlwaHMpLg0KPiANCj4gSG93ZXZlciwgdGhlcmUgYXJlIG90aGVyIG9idmlvdXMgdXNlcyBvZiB0\n" + "aGlzIHRlY2hub2xvZ3kgc3VjaCBhcyBzdGVwDQo+IGRldGVjdGlvbg0KPiBvciBhY3Rpdml0eSBj\n" + "bGFzc2lmaWNhdGlvbiAocnVubmluZywgd2Fsa2luZyBzaXR0aW5nKSB0aGF0IHNvIGZhcg0KPiBo\n" + "YXZlIGZhbGxlbg0KPiBpbiB0aGUgc2NvcGUgb2YgSUlPIGFzIHRoZXkgYXJlbid0IHJlYWxseSB0\n" + "aGluZ3MgeW91IGV4cGVjdCB0aGUNCj4gZGV2aWNlIHRvDQo+IHBlcmZvcm0gYW4gYW4gYWN0aW9u\n" + "IGluIHJlc3BvbnNlIHRvLsKgwqBBbm90aGVyIG9uZSBvZiB0aG9zZSBtZXNzeQ0KPiBjb3JuZXJz\n" + "DQo+IHRoYXQgZmFsbCB0aHJvdWdoIHRoZSBnYXBzIQ0KPiANCj4gVGhlIGRyaXZlcnMvaWlvL2Fj\n" + "Y2VsL21tYTk1NTMuYyBkb2VzIGFjdGl2aXR5IGRldGVjdGlvbiwgYnV0IHRoYXQNCj4gaXNuJ3QN\n" + "Cj4gcmVhbGx5ICdldmVudHMnIGluIHRoZSBzYW1lIHdheSBhcyB3ZSBoYXZlIGhlcmUuLi4NCj4g\n" + "DQo+IFNvIHJpZ2h0IGFuc3dlciBtaWdodCBiZSBhIGh5YnJpZCBvZiBhbiB1bmRlcmx5aW5nIGZs\n" + "ZXhpYmxlIElJTw0KPiBkZXZpY2UNCj4gYW5kIGFuIGlucHV0IGZyb250IGVuZCBmb3Igd2hlbiBp\n" + "dCBtYWtlcyBzZW5zZS4NCg0KV2hhdCBhYm91dCB3ZSBjYW4gYWxzbyBzZW5kIGFuIGlucHV0IGV2\n" + "ZW50LCBpZiB0aGUgZXZlbnQgaXMgb25lIG9mIHRoZQ0KaW5wdXQgZXZlbnQgdHlwZSB3aGljaCBp\n" + "cyBkZWZpbmVkIGluwqB1YXBpL2xpbnV4L2lucHV0LWV2ZW50LWNvZGVzLmg/DQoNCg0KPiANCj4g\n" + "V2UgcHJvYmFibHkgbmVlZCB0byBnZXQgdGhlIGluIGtlcm5lbCB1c2Ugb2YgSUlPIGV2ZW50cyBz\n" + "b3J0ZWQuwqDCoE5vbg0KPiBldmVudA0KPiBzdHVmZiBoYXMgYmVlbiBzb3J0ZWQgZm9yIHllYXJz\n" + "LCBidXQgdGhpcyBsYXN0IGNvcm5lciB3YXMgbmV2ZXIgb2YNCj4gZW5vdWdoDQo+IGludGVyZXN0\n" + "IHRvIGFueW9uZSB0byBhY3R1YWxseSBpbXBsZW1lbnQgaXQgKGl0J3MgZmFpcmx5IHN0cmFpZ2h0\n" + "DQo+IGZvcndhcmQNCj4gdG8gZG8pLg0KQ3VycmVudGx5IGluIElJTyBldmVudCBpcyBhIHU2NCB2\n" + "YWx1ZSBpbiBGaWZvLiBCdXQgaGVyZSB3ZSBuZWVkIHNvbWUNCnVzZXIgZGVmaW5lZCBldmVudHMg\n" + "YWxzby4gU2luY2UgdGhpcyBBQkkgbWF5IGFscmVhZHkgbWF5IGJlIGluIHVzZSBzbw0KY2FuJ3Qg\n" + "Y2hhbmdlIHU2NCB0byBhIHN0cnVjdHVyZSB3aXRoIGRhdGEgdHlwZSBkZWZpbml0aW9uIGFuZA0K\n" + "YXNzb2NpYXRlZCBkYXRhLiBCdXQgd2UgY2FuIGRlZmluZSBhZGRpdGlvbmFsIHByZWRlZmluZWQg\n" + "aWRzIGZvciBjdXN0b20NCmV2ZW50cyAoU2ltaWxhciB0byBISUQgc2Vuc29yIHVzYWdlIHNwZWMg\n" + "YWRkZWQgQ1VTVE9NIHVzYWdlIGlkcykuDQoNClRoYW5rcywNClNyaW5pdmFzDQoNCj4gDQo+ID4g\n" + DQo+ID4gKCsgbGludXgtaW5wdXQpDQo+ID4gDQo+ID4gQWxhbg== -1a2a5e95cc5cef90a4206256bb57a4f7e5df3324f0bfaa63ff87a9cd84631d8d +351b362440608446e7e6ca82a0024e551617ab1565d39467422bb31403d5ab89
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.