[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4df52628-9f20-ce4f-0a93-33c7f64f0ecd@gmail.com>
Date: Wed, 9 Aug 2017 23:51:52 -0400
From: Harinath Nampally <harinath922@...il.com>
To: Martin Kepplinger <martink@...teo.de>
Cc: Jonathan Cameron <jic23@...nel.org>, knaack.h@....de,
lars@...afoo.de, Peter Meerwald-Stadler <pmeerw@...erw.net>,
Greg KH <gregkh@...uxfoundation.org>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
Alison Schofield <amsfield22@...il.com>
Subject: Re: [PATCH] iio: accel: Bugfix to enbale and allow different events
to work parallely.
> My only suggestion for adding all these chips' orientation features, is
> to start the discussion independently from this driver. Are there other
> device series that provide such an orientation interrupt? Is it worth
> finding a representation in iio?
Given the number of accelerometers these days have built in orientation
event support,
I think its worth to have a representation in IIO,
> Additionally to portait up/down, landscape left/right there is
> back/front facing, so you'd have 8 new channel modifiers.
Yes that's correct but I wonder if its good idea to add 8(too many!) new
channel modifiers.
> If IIO_ROT is a current userspace "standard" to read for rotating the
> screen, it may be worth discussing how to fit this in without new
> modifiers. Would you have to make up fake angle values? Anything else
> userspace already uses for getting the orientation?
Yes I agree, I don't think I need to make up fake angle values, not sure
how userspace gets orientation currently. Need to do some research on that.
> But again, instead of replying here and going off topic, write up a
> proposal and post it independently.
Sure will do that. Thanks for your response.
On 08/01/2017 11:50 AM, Martin Kepplinger wrote:
> On 2017-08-01 05:08, Harinath Nampally wrote:
>>> Thanks for doing that work. I have had it on my list for a long time
>>> and you seem to fix it. Although I'd happily review and possibly test
>>> it, unfortunately I can't do so before the week of August 21st.
>>>
>>> If this might go in quick, nothing will stop me from reviewing either,
>>> so, whatever. Thanks again!
>> Sure no problem, looking forward to your review comments.
>> Actually I am planning to add Orientation events for FXLS8471Q, for
>> that is it good idea to overload existing
>> IIO_ROT channel type? Also thinking of adding 4 channel modifiers i.e
>> portrait up/down, landscape left/right.
>> Any suggestions are welcome. Thank you.
>>
> My only suggestion for adding all these chips' orientation features, is
> to start the discussion independently from this driver. Are there other
> device series that provide such an orientation interrupt? Is it worth
> finding a representation in iio?
>
> Additionally to portait up/down, landscape left/right there is
> back/front facing, so you'd have 8 new channel modifiers.
>
> If IIO_ROT is a current userspace "standard" to read for rotating the
> screen, it may be worth discussing how to fit this in without new
> modifiers. Would you have to make up fake angle values? Anything else
> userspace already uses for getting the orientation?
>
> But again, instead of replying here and going off topic, write up a
> proposal and post it independently.
Powered by blists - more mailing lists