Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Darren Hart]

On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
> Hi there,
> 
> 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@infradead.org>:
> > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
> >> The accelerometer sensor is very sensitive, and having userspace
> >> poll the sysfs position entry is not very battery friendly.
> >>
> >> This patch removes the sysfs entry and instead, it creates an
> >> input polled device (joystick) for the built-in accelerometer.
> >
> > Hrm, while sysfs details can change across kernel versions, usually due to
> > driver core changes, we try to keep them as consistent as possible so as not to
> > break userspace.
> >
> > That said, if we are going to try and come up with a better model for
> > representing an accelerometer, wouldn't treating it as an IIO device be the more
> > logical approach?
> 
> Yes of course, but the actual accelerometer device (sensor?) is not
> really exposed,
> only certain "functions" it provides, and they are divided across two
> different ACPI devices,
> TOS620A exposes the protection, and the TOS1900 (and et. al.) only
> exposes the axes.

As I understand it, IIO defines an interface to a device, a standard sysfs set
of properties. I should think we could provide the appropriate callbacks even
for a partially implemented (or a pair of) accelerometer.

Jonathan, what are your thoughts here. Is such a "device" (ACPI accessors to
axis and threshold) a candidate for IIO, or is this input polled device more
appropriate?

> 
> I see your point in breaking userspace, but given the fact that it was
> recently introduced,
> I didn't thought it was already "adopted", that's why I decided to
> remove the sysfs entry.

Looks like since 3.15 if I read the log correctly. That is fairly recent and
this is not one of the "defined interfaces" in the sysfs documentation.

Greg, can you weigh in here - does this change count as "breaking userspace", or
is this more inline with the scheduler knobs in /proc/sched_debug which can
change from version to version.

> 
> Then we might as well keep the sysfs entry and have the input polled
> device as well.

Let's see what Greg has to say. If he isn't bothered by the change, I won't push
the issue.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Greg Kroah-Hartman]

On Mon, Sep 08, 2014 at 05:04:30PM -0700, Darren Hart wrote:
> On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
> > Hi there,
> > 
> > 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@infradead.org>:
> > > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
> > >> The accelerometer sensor is very sensitive, and having userspace
> > >> poll the sysfs position entry is not very battery friendly.
> > >>
> > >> This patch removes the sysfs entry and instead, it creates an
> > >> input polled device (joystick) for the built-in accelerometer.
> > >
> > > Hrm, while sysfs details can change across kernel versions, usually due to
> > > driver core changes, we try to keep them as consistent as possible so as not to
> > > break userspace.
> > >
> > > That said, if we are going to try and come up with a better model for
> > > representing an accelerometer, wouldn't treating it as an IIO device be the more
> > > logical approach?
> > 
> > Yes of course, but the actual accelerometer device (sensor?) is not
> > really exposed,
> > only certain "functions" it provides, and they are divided across two
> > different ACPI devices,
> > TOS620A exposes the protection, and the TOS1900 (and et. al.) only
> > exposes the axes.
> 
> As I understand it, IIO defines an interface to a device, a standard sysfs set
> of properties. I should think we could provide the appropriate callbacks even
> for a partially implemented (or a pair of) accelerometer.
> 
> Jonathan, what are your thoughts here. Is such a "device" (ACPI accessors to
> axis and threshold) a candidate for IIO, or is this input polled device more
> appropriate?
> 
> > 
> > I see your point in breaking userspace, but given the fact that it was
> > recently introduced,
> > I didn't thought it was already "adopted", that's why I decided to
> > remove the sysfs entry.
> 
> Looks like since 3.15 if I read the log correctly. That is fairly recent and
> this is not one of the "defined interfaces" in the sysfs documentation.
> 
> Greg, can you weigh in here - does this change count as "breaking userspace", or
> is this more inline with the scheduler knobs in /proc/sched_debug which can
> change from version to version.
> 
> > 
> > Then we might as well keep the sysfs entry and have the input polled
> > device as well.
> 
> Let's see what Greg has to say. If he isn't bothered by the change, I won't push
> the issue.

If it should be an IIO device, great, make it an IIO device, and move
away from a custom sysfs interface that matches nothing else.

But I really doubt it should be a joystick device, that just doesn't
make sense at all.

thanks,

greg k-h

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Darren Hart]

On Mon, Sep 08, 2014 at 06:35:53PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 08, 2014 at 05:04:30PM -0700, Darren Hart wrote:
> > On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
> > > Hi there,
> > > 
> > > 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@infradead.org>:
> > > > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
> > > >> The accelerometer sensor is very sensitive, and having userspace
> > > >> poll the sysfs position entry is not very battery friendly.
> > > >>
> > > >> This patch removes the sysfs entry and instead, it creates an
> > > >> input polled device (joystick) for the built-in accelerometer.
> > > >
> > > > Hrm, while sysfs details can change across kernel versions, usually due to
> > > > driver core changes, we try to keep them as consistent as possible so as not to
> > > > break userspace.
> > > >
> > > > That said, if we are going to try and come up with a better model for
> > > > representing an accelerometer, wouldn't treating it as an IIO device be the more
> > > > logical approach?
> > > 
> > > Yes of course, but the actual accelerometer device (sensor?) is not
> > > really exposed,
> > > only certain "functions" it provides, and they are divided across two
> > > different ACPI devices,
> > > TOS620A exposes the protection, and the TOS1900 (and et. al.) only
> > > exposes the axes.
> > 
> > As I understand it, IIO defines an interface to a device, a standard sysfs set
> > of properties. I should think we could provide the appropriate callbacks even
> > for a partially implemented (or a pair of) accelerometer.
> > 
> > Jonathan, what are your thoughts here. Is such a "device" (ACPI accessors to
> > axis and threshold) a candidate for IIO, or is this input polled device more
> > appropriate?
> > 
> > > 
> > > I see your point in breaking userspace, but given the fact that it was
> > > recently introduced,
> > > I didn't thought it was already "adopted", that's why I decided to
> > > remove the sysfs entry.
> > 
> > Looks like since 3.15 if I read the log correctly. That is fairly recent and
> > this is not one of the "defined interfaces" in the sysfs documentation.
> > 
> > Greg, can you weigh in here - does this change count as "breaking userspace", or
> > is this more inline with the scheduler knobs in /proc/sched_debug which can
> > change from version to version.
> > 
> > > 
> > > Then we might as well keep the sysfs entry and have the input polled
> > > device as well.
> > 
> > Let's see what Greg has to say. If he isn't bothered by the change, I won't push
> > the issue.
> 
> If it should be an IIO device, great, make it an IIO device, and move
> away from a custom sysfs interface that matches nothing else.
> 
> But I really doubt it should be a joystick device, that just doesn't
> make sense at all.

I immediately went to a tablet with a marble maze game and it didn't seem too
crazy, but I don't suppose that is what people are actually doing with it...

What are people actually doing with this thing Azael?

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Azael Avalos]

Hi there,

2014-09-09 21:35 GMT-06:00 Darren Hart <dvhart@infradead.org>:
>
> I immediately went to a tablet with a marble maze game and it didn't seem too
> crazy, but I don't suppose that is what people are actually doing with it...
>
> What are people actually doing with this thing Azael?

Gaming mostly (supertuxkart anyone?), but some others (including myself)
want to use it as a movement detection (one exists for the IBM/Lenovo
Thinkpads).

Digging into platform drivers, I've found that the hdaps and also the lis3lv02d
drivers report the axes via polldev, and since I don't want to break userspace,
I'm left with two choices:

1 - Keep sysfs entry and adapt it to properly report direction, and no
polled device.

2 - Keep sysfs entry and adapt it to properly report direction, and also
a polled device.

Let me know your decision so I can send an updated patch.

>
> --
> Darren Hart
> Intel Open Source Technology Center

Cheers
Azael


-- 
-- El mundo apesta y vosotros apestais tambien --

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Greg Kroah-Hartman]

On Wed, Sep 10, 2014 at 09:28:44AM -0600, Azael Avalos wrote:
> Hi there,
> 
> 2014-09-09 21:35 GMT-06:00 Darren Hart <dvhart@infradead.org>:
> >
> > I immediately went to a tablet with a marble maze game and it didn't seem too
> > crazy, but I don't suppose that is what people are actually doing with it...
> >
> > What are people actually doing with this thing Azael?
> 
> Gaming mostly (supertuxkart anyone?), but some others (including myself)
> want to use it as a movement detection (one exists for the IBM/Lenovo
> Thinkpads).
> 
> Digging into platform drivers, I've found that the hdaps and also the lis3lv02d
> drivers report the axes via polldev, and since I don't want to break userspace,
> I'm left with two choices:
> 
> 1 - Keep sysfs entry and adapt it to properly report direction, and no
> polled device.
> 
> 2 - Keep sysfs entry and adapt it to properly report direction, and also
> a polled device.
> 
> Let me know your decision so I can send an updated patch.

3 - use the correct api and change it to iio so that all userspace tools
can correctly interact with it, instead of dealing with a
driver-specific sysfs file.

thanks,

greg k-h

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Jonathan Cameron]

On September 9, 2014 1:04:30 AM GMT+01:00, Darren Hart <dvhart@infradead.org> wrote:
>On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
>> Hi there,
>> 
>> 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@infradead.org>:
>> > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
>> >> The accelerometer sensor is very sensitive, and having userspace
>> >> poll the sysfs position entry is not very battery friendly.
>> >>
>> >> This patch removes the sysfs entry and instead, it creates an
>> >> input polled device (joystick) for the built-in accelerometer.
>> >
>> > Hrm, while sysfs details can change across kernel versions, usually
>due to
>> > driver core changes, we try to keep them as consistent as possible
>so as not to
>> > break userspace.
>> >
>> > That said, if we are going to try and come up with a better model
>for
>> > representing an accelerometer, wouldn't treating it as an IIO
>device be the more
>> > logical approach?
>> 
>> Yes of course, but the actual accelerometer device (sensor?) is not
>> really exposed,
>> only certain "functions" it provides, and they are divided across two
>> different ACPI devices,
>> TOS620A exposes the protection, and the TOS1900 (and et. al.) only
>> exposes the axes.
>
>As I understand it, IIO defines an interface to a device, a standard
>sysfs set
>of properties. I should think we could provide the appropriate
>callbacks even
>for a partially implemented (or a pair of) accelerometer.
>
>Jonathan, what are your thoughts here. Is such a "device" (ACPI
>accessors to
>axis and threshold) a candidate for IIO, or is this input polled device
>more
>appropriate?
Absolutely fine in IIO.

Sorry I took so long to reply. Read the title and expected more detailed issue so queued
 it up for when I had more time. Oops.

Only slight gotcha is that there is some debate over the iio timer trigger
 configuration interface which would be equivalent of a polled input device.

Hence it hasn't merged yet.
Comes down to how these are instantiated. Lars-Peter Clausen is planning a configfs
 proposal rather than how we do the user space trigger creation currently.

A user space trigger would work but then you loose lack of hitting sysfs files.

>
>> 
>> I see your point in breaking userspace, but given the fact that it
>was
>> recently introduced,
>> I didn't thought it was already "adopted", that's why I decided to
>> remove the sysfs entry.
>
>Looks like since 3.15 if I read the log correctly. That is fairly
>recent and
>this is not one of the "defined interfaces" in the sysfs documentation.
>
>Greg, can you weigh in here - does this change count as "breaking
>userspace", or
>is this more inline with the scheduler knobs in /proc/sched_debug which
>can
>change from version to version.
>
>> 
>> Then we might as well keep the sysfs entry and have the input polled
>> device as well.
>
>Let's see what Greg has to say. If he isn't bothered by the change, I
>won't push
>the issue.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Darren Hart]

On Wed, Sep 17, 2014 at 05:36:31PM +0100, Jonathan Cameron wrote:
> 
> 
> On September 9, 2014 1:04:30 AM GMT+01:00, Darren Hart <dvhart@infradead.org> wrote:
> >On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
> >> Hi there,
> >> 
> >> 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@infradead.org>:
> >> > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
> >> >> The accelerometer sensor is very sensitive, and having userspace
> >> >> poll the sysfs position entry is not very battery friendly.
> >> >>
> >> >> This patch removes the sysfs entry and instead, it creates an
> >> >> input polled device (joystick) for the built-in accelerometer.
> >> >
> >> > Hrm, while sysfs details can change across kernel versions, usually
> >due to
> >> > driver core changes, we try to keep them as consistent as possible
> >so as not to
> >> > break userspace.
> >> >
> >> > That said, if we are going to try and come up with a better model
> >for
> >> > representing an accelerometer, wouldn't treating it as an IIO
> >device be the more
> >> > logical approach?
> >> 
> >> Yes of course, but the actual accelerometer device (sensor?) is not
> >> really exposed,
> >> only certain "functions" it provides, and they are divided across two
> >> different ACPI devices,
> >> TOS620A exposes the protection, and the TOS1900 (and et. al.) only
> >> exposes the axes.
> >
> >As I understand it, IIO defines an interface to a device, a standard
> >sysfs set
> >of properties. I should think we could provide the appropriate
> >callbacks even
> >for a partially implemented (or a pair of) accelerometer.
> >
> >Jonathan, what are your thoughts here. Is such a "device" (ACPI
> >accessors to
> >axis and threshold) a candidate for IIO, or is this input polled device
> >more
> >appropriate?
> Absolutely fine in IIO.
> 
> Sorry I took so long to reply. Read the title and expected more detailed issue so queued
>  it up for when I had more time. Oops.
> 
> Only slight gotcha is that there is some debate over the iio timer trigger
>  configuration interface which would be equivalent of a polled input device.
> 
> Hence it hasn't merged yet.
> Comes down to how these are instantiated. Lars-Peter Clausen is planning a configfs
>  proposal rather than how we do the user space trigger creation currently.
> 
> A user space trigger would work but then you loose lack of hitting sysfs files.

Thanks Jonathan,

Azael, please follow-up with the IIO folks and if you want to modify the
interface, please do so via IIO so it uses a consistent interface and we can
eliminate these custom sysfs files.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center