From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Herrmann Subject: Re: Handling of non-positional data through evdev Date: Thu, 17 Mar 2016 10:27:25 +0100 Message-ID: References: <1458082753.4785.27.camel@hadess.net> <1458141032.29084.0.camel@hadess.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-wm0-f46.google.com ([74.125.82.46]:32813 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932329AbcCQJ11 (ORCPT ); Thu, 17 Mar 2016 05:27:27 -0400 Received: by mail-wm0-f46.google.com with SMTP id l68so16895357wml.0 for ; Thu, 17 Mar 2016 02:27:26 -0700 (PDT) In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Roderick Colenbrander , Dmitry Torokhov Cc: Bastien Nocera , linux-input Hi On Wed, Mar 16, 2016 at 8:00 PM, Roderick Colenbrander wrote: > Hi David, > > On Wed, Mar 16, 2016 at 8:26 AM, David Herrmann wrote: >> Hi >> >> On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera wrote: >>> On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote: >>>> Hi Bastien, >>>> >>>> Thanks for providing this suggestion. I can see this approach work >>>> for >>>> situations like screen rotation on tablets. The device I'm involved >>>> with is an input device, which needs a high poll rate for >>>> acceleration >>>> / velocity and needs to be paired with the button / axes data. Evdev >>>> would be most appropriate. >>> >>> So more like a Wiimote than a builtin sensor. What will consume events >>> in user-space? A specialised application? >> >> I really think evdev is the right place to put any of those devices. >> The real problem is that the current set of ABS types is very limited >> and strongly overloaded. We didn't do this for other types, but >> somehow ABS turned out that way. >> >> In general, Dmitry was ok with introducing new ABS types, properly >> representing those types. I sent an RFC some years ago, which also >> introduces gyro and accelerometer types (see patch #4): >> >> https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html >> >> The problem is, however, that the current ABS_* namespace is >> exhausted. That is, we have to introduce some new way to add new ABS >> types (the series introduced ABS2 for that). No-one continued that >> effort so far, so we are stuck with the current ABS types. Feel free >> to pick this up. It might be a lengthy effort, though. You might be >> better off doing it the wiimote way: pick you ABS types and make >> user-space recognize them depending on the device name/etc. >> >> Thanks >> David > > Your work was definitely interesting and exactly what I would have > needed. It felt like a reasonable path forward. What was ultimately > the main blocker? There was no interest? I don't think there was any big blocker, I just never pushed it forward. Feel free to pick it up. But given that it has to introduce new evdev APIs, it might take a while to get upstream. Thanks David