Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1472921 > unrolled thread

screen rotation flipped in 4.8-rc

Back to article view | Back to linux.kernel

Contents

  screen rotation flipped in 4.8-rc "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> - 2016-08-31 00:50 +0200
    Re: screen rotation flipped in 4.8-rc Matt Ranostay <mranostay@gmail.com> - 2016-08-31 02:50 +0200
      Re: screen rotation flipped in 4.8-rc Matt Ranostay <mranostay@gmail.com> - 2016-08-31 22:30 +0200
        Re: screen rotation flipped in 4.8-rc "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> - 2016-08-31 22:40 +0200
          Re: screen rotation flipped in 4.8-rc Matt Ranostay <mranostay@gmail.com> - 2016-08-31 22:50 +0200
            Re: screen rotation flipped in 4.8-rc Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-09-01 01:00 +0200
              Re: screen rotation flipped in 4.8-rc Matt Ranostay <mranostay@gmail.com> - 2016-09-01 02:50 +0200
    Re: screen rotation flipped in 4.8-rc Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-09-03 00:50 +0200
      Re: screen rotation flipped in 4.8-rc Jonathan Cameron <jic23@kernel.org> - 2016-09-03 17:10 +0200
      Re: screen rotation flipped in 4.8-rc Bastien Nocera <hadess@hadess.net> - 2016-09-06 14:30 +0200

#1472921 — screen rotation flipped in 4.8-rc

Hi All,

I observed that using iio-sensor-proxy.service, the auto screen
rotation flipped on my laptop (Normal -> vertical, vertical->normal)
using kernel v4.8.

Anyone else has seen this?

I did a bisect and found a commit, which I am not sure how can it
impact.


commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
Author: George Spelvin <linux@sciencehorizons.net>
Date:   Fri Jun 10 00:22:12 2016 -0400

    fs/dcache.c: Save one 32-bit multiply in dcache lookup
    
    Noe that we're mixing in the parent pointer earlier, we
    don't need to use hash_32() to mix its bits.  Instead, we can
    just take the msbits of the hash value directly.
    
    For those applications which use the partial_name_hash(),
    move the multiply to end_name_hash.
    
    Signed-off-by: George Spelvin <linux@sciencehorizons.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Thanks,
Srinivas

[toc] | [next] | [standalone]

#1472961

On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
<srinivas.pandruvada@intel.com> wrote:
> Hi All,
>
> I observed that using iio-sensor-proxy.service, the auto screen
> rotation flipped on my laptop (Normal -> vertical, vertical->normal)
> using kernel v4.8.
>
> Anyone else has seen this?
>
> I did a bisect and found a commit, which I am not sure how can it
> impact.

Could you post the results of CONFIG_TEST_HASH enabled?

Thanks,

Matt

>
>
> commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> Author: George Spelvin <linux@sciencehorizons.net>
> Date:   Fri Jun 10 00:22:12 2016 -0400
>
>     fs/dcache.c: Save one 32-bit multiply in dcache lookup
>
>     Noe that we're mixing in the parent pointer earlier, we
>     don't need to use hash_32() to mix its bits.  Instead, we can
>     just take the msbits of the hash value directly.
>
>     For those applications which use the partial_name_hash(),
>     move the multiply to end_name_hash.
>
>     Signed-off-by: George Spelvin <linux@sciencehorizons.net>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
>
> Thanks,
> Srinivas

[toc] | [prev] | [next] | [standalone]

#1473833

On Wed, Aug 31, 2016 at 1:18 PM, Pandruvada, Srinivas
<srinivas.pandruvada@intel.com> wrote:
> On Tue, 2016-08-30 at 17:41 -0700, Matt Ranostay wrote:
>> On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
>> <srinivas.pandruvada@intel.com> wrote:
>> >
>> > Hi All,
>> >
>> > I observed that using iio-sensor-proxy.service, the auto screen
>> > rotation flipped on my laptop (Normal -> vertical, vertical-
>> > >normal)
>> > using kernel v4.8.
>> >
>> > Anyone else has seen this?
>> >
>> > I did a bisect and found a commit, which I am not sure how can it
>> > impact.
>> Could you post the results of CONFIG_TEST_HASH enabled?
> Attached dmesg.txt with the CONFIG_TEST_HASH=y.
>
> I see
> [    4.276138] test_hash: __hash_32() has no arch implementation to
> test.
> [    4.276138] test_hash: hash_32() has no arch implementation to test.
> [    4.276139] test_hash: hash_64() has no arch implementation to test.
> [    4.276141] test_hash: 33152 tests passed.
>

Ok have you tested with that patchset reverted? And if so does the
regression disappear?
I would highly doubt if it was a issue with that dcache patchsets it
wouldn't be breaking a ton of things.

> Thanks,
> Srinivas
>>
>> Thanks,
>>
>> Matt
>>
>> >
>> >
>> >
>> > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
>> > Author: George Spelvin <linux@sciencehorizons.net>
>> > Date:   Fri Jun 10 00:22:12 2016 -0400
>> >
>> >     fs/dcache.c: Save one 32-bit multiply in dcache lookup
>> >
>> >     Noe that we're mixing in the parent pointer earlier, we
>> >     don't need to use hash_32() to mix its bits.  Instead, we can
>> >     just take the msbits of the hash value directly.
>> >
>> >     For those applications which use the partial_name_hash(),
>> >     move the multiply to end_name_hash.
>> >
>> >     Signed-off-by: George Spelvin <linux@sciencehorizons.net>
>> >     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>> >
>> >
>> > Thanks,
>> > Srinivas

[toc] | [prev] | [next] | [standalone]

#1473835

On Wed, 2016-08-31 at 13:24 -0700, Matt Ranostay wrote:
> On Wed, Aug 31, 2016 at 1:18 PM, Pandruvada, Srinivas
> <srinivas.pandruvada@intel.com> wrote:
> > 
> > On Tue, 2016-08-30 at 17:41 -0700, Matt Ranostay wrote:
> > > 
> > > On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
> > > <srinivas.pandruvada@intel.com> wrote:
> > > > 
> > > > 
> > > > Hi All,
> > > > 
> > > > I observed that using iio-sensor-proxy.service, the auto screen
> > > > rotation flipped on my laptop (Normal -> vertical, vertical-
> > > > > 
> > > > > normal)
> > > > using kernel v4.8.
> > > > 
> > > > Anyone else has seen this?
> > > > 
> > > > I did a bisect and found a commit, which I am not sure how can
> > > > it
> > > > impact.
> > > Could you post the results of CONFIG_TEST_HASH enabled?
> > Attached dmesg.txt with the CONFIG_TEST_HASH=y.
> > 
> > I see
> > [    4.276138] test_hash: __hash_32() has no arch implementation to
> > test.
> > [    4.276138] test_hash: hash_32() has no arch implementation to
> > test.
> > [    4.276139] test_hash: hash_64() has no arch implementation to
> > test.
> > [    4.276141] test_hash: 33152 tests passed.
> > 
> Ok have you tested with that patchset reverted? And if so does the
> regression disappear?
Yes, but not after adding CONFIG_TEST_HASH=y.
regression disappears.

> I would highly doubt if it was a issue with that dcache patchsets it
> wouldn't be breaking a ton of things.
I also think that.

Thanks,
Srinivas

> 
> > 
> > Thanks,
> > Srinivas
> > > 
> > > 
> > > Thanks,
> > > 
> > > Matt
> > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> > > > Author: George Spelvin <linux@sciencehorizons.net>
> > > > Date:   Fri Jun 10 00:22:12 2016 -0400
> > > > 
> > > >     fs/dcache.c: Save one 32-bit multiply in dcache lookup
> > > > 
> > > >     Noe that we're mixing in the parent pointer earlier, we
> > > >     don't need to use hash_32() to mix its bits.  Instead, we
> > > > can
> > > >     just take the msbits of the hash value directly.
> > > > 
> > > >     For those applications which use the partial_name_hash(),
> > > >     move the multiply to end_name_hash.
> > > > 
> > > >     Signed-off-by: George Spelvin <linux@sciencehorizons.net>
> > > >     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.or
> > > > g>
> > > > 
> > > > 
> > > > Thanks,
> > > > Srinivas

[toc] | [prev] | [next] | [standalone]

#1473841

On Wed, Aug 31, 2016 at 1:29 PM, Pandruvada, Srinivas
<srinivas.pandruvada@intel.com> wrote:
> On Wed, 2016-08-31 at 13:24 -0700, Matt Ranostay wrote:
>> On Wed, Aug 31, 2016 at 1:18 PM, Pandruvada, Srinivas
>> <srinivas.pandruvada@intel.com> wrote:
>> >
>> > On Tue, 2016-08-30 at 17:41 -0700, Matt Ranostay wrote:
>> > >
>> > > On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
>> > > <srinivas.pandruvada@intel.com> wrote:
>> > > >
>> > > >
>> > > > Hi All,
>> > > >
>> > > > I observed that using iio-sensor-proxy.service, the auto screen
>> > > > rotation flipped on my laptop (Normal -> vertical, vertical-
>> > > > >
>> > > > > normal)
>> > > > using kernel v4.8.
>> > > >
>> > > > Anyone else has seen this?
>> > > >
>> > > > I did a bisect and found a commit, which I am not sure how can
>> > > > it
>> > > > impact.
>> > > Could you post the results of CONFIG_TEST_HASH enabled?
>> > Attached dmesg.txt with the CONFIG_TEST_HASH=y.
>> >
>> > I see
>> > [    4.276138] test_hash: __hash_32() has no arch implementation to
>> > test.
>> > [    4.276138] test_hash: hash_32() has no arch implementation to
>> > test.
>> > [    4.276139] test_hash: hash_64() has no arch implementation to
>> > test.
>> > [    4.276141] test_hash: 33152 tests passed.
>> >
>> Ok have you tested with that patchset reverted? And if so does the
>> regression disappear?
> Yes, but not after adding CONFIG_TEST_HASH=y.
> regression disappears.
>
>> I would highly doubt if it was a issue with that dcache patchsets it
>> wouldn't be breaking a ton of things.
> I also think that.

Only thing I could suspect is a toolchain bug.. Have crazy idea for
you to try below..

From the patchset notice the return doesn't cast the result to
(unsigned int) as before. But __hash_32_generic is "static inline
u32", and maybe the end_name_hash is returning the whole result as a
64-bit unsigned long rather than 32-bit unsigned int.

....
static inline unsigned long end_name_hash(unsigned long hash)
{
- return (unsigned int)hash;
+ return __hash_32((unsigned int)hash);
}
....

Just a theory.. Could totally be wrong :).

>
> Thanks,
> Srinivas
>
>>
>> >
>> > Thanks,
>> > Srinivas
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Matt
>> > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
>> > > > Author: George Spelvin <linux@sciencehorizons.net>
>> > > > Date:   Fri Jun 10 00:22:12 2016 -0400
>> > > >
>> > > >     fs/dcache.c: Save one 32-bit multiply in dcache lookup
>> > > >
>> > > >     Noe that we're mixing in the parent pointer earlier, we
>> > > >     don't need to use hash_32() to mix its bits.  Instead, we
>> > > > can
>> > > >     just take the msbits of the hash value directly.
>> > > >
>> > > >     For those applications which use the partial_name_hash(),
>> > > >     move the multiply to end_name_hash.
>> > > >
>> > > >     Signed-off-by: George Spelvin <linux@sciencehorizons.net>
>> > > >     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.or
>> > > > g>
>> > > >
>> > > >
>> > > > Thanks,
>> > > > Srinivas

[toc] | [prev] | [next] | [standalone]

#1473956

On Wed, 2016-08-31 at 13:43 -0700, Matt Ranostay wrote:
> On Wed, Aug 31, 2016 at 1:29 PM, Pandruvada, Srinivas
> <srinivas.pandruvada@intel.com> wrote:
> > 
> > On Wed, 2016-08-31 at 13:24 -0700, Matt Ranostay wrote:
> > > 
> > > On Wed, Aug 31, 2016 at 1:18 PM, Pandruvada, Srinivas
> > > <srinivas.pandruvada@intel.com> wrote:
> > > > 
> > > > 
> > > > On Tue, 2016-08-30 at 17:41 -0700, Matt Ranostay wrote:
> > > > > 
> > > > > 
> > > > > On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
> > > > > <srinivas.pandruvada@intel.com> wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi All,
> > > > > > 
> > > > > > I observed that using iio-sensor-proxy.service, the auto
> > > > > > screen
> > > > > > rotation flipped on my laptop (Normal -> vertical,
> > > > > > vertical-
> > > > > > > 
> > > > > > > 
> > > > > > > normal)
> > > > > > using kernel v4.8.
> > > > > > 
> > > > > > Anyone else has seen this?
> > > > > > 
> > > > > > I did a bisect and found a commit, which I am not sure how
> > > > > > can
> > > > > > it
> > > > > > impact.
> > > > > Could you post the results of CONFIG_TEST_HASH enabled?
> > > > Attached dmesg.txt with the CONFIG_TEST_HASH=y.
> > > > 
> > > > I see
> > > > [    4.276138] test_hash: __hash_32() has no arch
> > > > implementation to
> > > > test.
> > > > [    4.276138] test_hash: hash_32() has no arch implementation
> > > > to
> > > > test.
> > > > [    4.276139] test_hash: hash_64() has no arch implementation
> > > > to
> > > > test.
> > > > [    4.276141] test_hash: 33152 tests passed.
> > > > 
> > > Ok have you tested with that patchset reverted? And if so does
> > > the
> > > regression disappear?
> > Yes, but not after adding CONFIG_TEST_HASH=y.
> > regression disappears.
> > 
> > > 
> > > I would highly doubt if it was a issue with that dcache patchsets
> > > it
> > > wouldn't be breaking a ton of things.
> > I also think that.
> Only thing I could suspect is a toolchain bug.. Have crazy idea for
> you to try below..
> 
> From the patchset notice the return doesn't cast the result to
> (unsigned int) as before. But __hash_32_generic is "static inline
> u32", and maybe the end_name_hash is returning the whole result as a
> 64-bit unsigned long rather than 32-bit unsigned int.
> 
> ....
> static inline unsigned long end_name_hash(unsigned long hash)
> {
> - return (unsigned int)hash;
> + return __hash_32((unsigned int)hash);
> }
> ....
> 
> Just a theory.. Could totally be wrong :).
> 
I casted to unsigned int, still result is same. I need to look at the
user space program and compare data it is reading.

Thanks,
Srinivas
> > 
> > 
> > Thanks,
> > Srinivas
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > Srinivas
> > > > > 
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Matt
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> > > > > > Author: George Spelvin <linux@sciencehorizons.net>
> > > > > > Date:   Fri Jun 10 00:22:12 2016 -0400
> > > > > > 
> > > > > >     fs/dcache.c: Save one 32-bit multiply in dcache lookup
> > > > > > 
> > > > > >     Noe that we're mixing in the parent pointer earlier, we
> > > > > >     don't need to use hash_32() to mix its bits.  Instead,
> > > > > > we
> > > > > > can
> > > > > >     just take the msbits of the hash value directly.
> > > > > > 
> > > > > >     For those applications which use the
> > > > > > partial_name_hash(),
> > > > > >     move the multiply to end_name_hash.
> > > > > > 
> > > > > >     Signed-off-by: George Spelvin <linux@sciencehorizons.ne
> > > > > > t>
> > > > > >     Signed-off-by: Linus Torvalds <torvalds@linux-foundatio
> > > > > > n.or
> > > > > > g>
> > > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > Srinivas

[toc] | [prev] | [next] | [standalone]

#1473992

On Wed, Aug 31, 2016 at 3:53 PM, Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
> On Wed, 2016-08-31 at 13:43 -0700, Matt Ranostay wrote:
>> On Wed, Aug 31, 2016 at 1:29 PM, Pandruvada, Srinivas
>> <srinivas.pandruvada@intel.com> wrote:
>> >
>> > On Wed, 2016-08-31 at 13:24 -0700, Matt Ranostay wrote:
>> > >
>> > > On Wed, Aug 31, 2016 at 1:18 PM, Pandruvada, Srinivas
>> > > <srinivas.pandruvada@intel.com> wrote:
>> > > >
>> > > >
>> > > > On Tue, 2016-08-30 at 17:41 -0700, Matt Ranostay wrote:
>> > > > >
>> > > > >
>> > > > > On Tue, Aug 30, 2016 at 3:42 PM, Pandruvada, Srinivas
>> > > > > <srinivas.pandruvada@intel.com> wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Hi All,
>> > > > > >
>> > > > > > I observed that using iio-sensor-proxy.service, the auto
>> > > > > > screen
>> > > > > > rotation flipped on my laptop (Normal -> vertical,
>> > > > > > vertical-
>> > > > > > >
>> > > > > > >
>> > > > > > > normal)
>> > > > > > using kernel v4.8.
>> > > > > >
>> > > > > > Anyone else has seen this?
>> > > > > >
>> > > > > > I did a bisect and found a commit, which I am not sure how
>> > > > > > can
>> > > > > > it
>> > > > > > impact.
>> > > > > Could you post the results of CONFIG_TEST_HASH enabled?
>> > > > Attached dmesg.txt with the CONFIG_TEST_HASH=y.
>> > > >
>> > > > I see
>> > > > [    4.276138] test_hash: __hash_32() has no arch
>> > > > implementation to
>> > > > test.
>> > > > [    4.276138] test_hash: hash_32() has no arch implementation
>> > > > to
>> > > > test.
>> > > > [    4.276139] test_hash: hash_64() has no arch implementation
>> > > > to
>> > > > test.
>> > > > [    4.276141] test_hash: 33152 tests passed.
>> > > >
>> > > Ok have you tested with that patchset reverted? And if so does
>> > > the
>> > > regression disappear?
>> > Yes, but not after adding CONFIG_TEST_HASH=y.
>> > regression disappears.
>> >
>> > >
>> > > I would highly doubt if it was a issue with that dcache patchsets
>> > > it
>> > > wouldn't be breaking a ton of things.
>> > I also think that.
>> Only thing I could suspect is a toolchain bug.. Have crazy idea for
>> you to try below..
>>
>> From the patchset notice the return doesn't cast the result to
>> (unsigned int) as before. But __hash_32_generic is "static inline
>> u32", and maybe the end_name_hash is returning the whole result as a
>> 64-bit unsigned long rather than 32-bit unsigned int.
>>
>> ....
>> static inline unsigned long end_name_hash(unsigned long hash)
>> {
>> - return (unsigned int)hash;
>> + return __hash_32((unsigned int)hash);
>> }
>> ....
>>
>> Just a theory.. Could totally be wrong :).
>>
> I casted to unsigned int, still result is same. I need to look at the
> user space program and compare data it is reading.

Which sensor or sensorhub are you using?   Any chance the data being
read isn't cachealigned?

Thanks,

Matt

>
> Thanks,
> Srinivas
>> >
>> >
>> > Thanks,
>> > Srinivas
>> >
>> > >
>> > >
>> > > >
>> > > >
>> > > > Thanks,
>> > > > Srinivas
>> > > > >
>> > > > >
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Matt
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
>> > > > > > Author: George Spelvin <linux@sciencehorizons.net>
>> > > > > > Date:   Fri Jun 10 00:22:12 2016 -0400
>> > > > > >
>> > > > > >     fs/dcache.c: Save one 32-bit multiply in dcache lookup
>> > > > > >
>> > > > > >     Noe that we're mixing in the parent pointer earlier, we
>> > > > > >     don't need to use hash_32() to mix its bits.  Instead,
>> > > > > > we
>> > > > > > can
>> > > > > >     just take the msbits of the hash value directly.
>> > > > > >
>> > > > > >     For those applications which use the
>> > > > > > partial_name_hash(),
>> > > > > >     move the multiply to end_name_hash.
>> > > > > >
>> > > > > >     Signed-off-by: George Spelvin <linux@sciencehorizons.ne
>> > > > > > t>
>> > > > > >     Signed-off-by: Linus Torvalds <torvalds@linux-foundatio
>> > > > > > n.or
>> > > > > > g>
>> > > > > >
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Srinivas

[toc] | [prev] | [next] | [standalone]

#1475491

On Tue, 2016-08-30 at 22:42 +0000, Pandruvada, Srinivas wrote:
> Hi All,
> 
> I observed that using iio-sensor-proxy.service, the auto screen
> rotation flipped on my laptop (Normal -> vertical, vertical->normal)
> using kernel v4.8.
> 
> Anyone else has seen this?
> 
> I did a bisect and found a commit, which I am not sure how can it
> impact.
> 
> 
> commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> Author: George Spelvin <linux@sciencehorizons.net>
> Date:   Fri Jun 10 00:22:12 2016 -0400
> 
[...]

It turns out to be some assumption user space program is making about
the traversing directory using glib call g_dir_read_name(). 

With the commit 703b5faf22fbddf984a361e6555f3a03fdba63d9 (fs/dcache.c:
Save one 32-bit multiply in dcache lookup)
 in kernel 4.8-rc, somehow the order is changed (so the in_accel_y was
appearing before in_accel_x )

I modified user space program to use correct iio scan element index to
determine byte offset instead depending on the glib_dir_read_name,
which doesn't guarantee any order.

I sent a pull request to author of iio-sensor-proxy to review.

Hadess,
	Please look.

https://github.com/hadess/iio-sensor-proxy/pull/99/commits/de80c50b2678
2ba6e899ee5a95b31b28790c940d


Thanks,
Srinivas

[toc] | [prev] | [next] | [standalone]

#1475659

On 02/09/16 23:48, Srinivas Pandruvada wrote:
> On Tue, 2016-08-30 at 22:42 +0000, Pandruvada, Srinivas wrote:
>> Hi All,
>>
>> I observed that using iio-sensor-proxy.service, the auto screen
>> rotation flipped on my laptop (Normal -> vertical, vertical->normal)
>> using kernel v4.8.
>>
>> Anyone else has seen this?
>>
>> I did a bisect and found a commit, which I am not sure how can it
>> impact.
>>
>>
>> commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
>> Author: George Spelvin <linux@sciencehorizons.net>
>> Date:   Fri Jun 10 00:22:12 2016 -0400
>>
> [...]
> 
> It turns out to be some assumption user space program is making about
> the traversing directory using glib call g_dir_read_name(). 
> 
> With the commit 703b5faf22fbddf984a361e6555f3a03fdba63d9 (fs/dcache.c:
> Save one 32-bit multiply in dcache lookup)
>  in kernel 4.8-rc, somehow the order is changed (so the in_accel_y was
> appearing before in_accel_x )
> 
> I modified user space program to use correct iio scan element index to
> determine byte offset instead depending on the glib_dir_read_name,
> which doesn't guarantee any order.
> 
> I sent a pull request to author of iio-sensor-proxy to review.
> 
> Hadess,
> 	Please look.
> 
> https://github.com/hadess/iio-sensor-proxy/pull/99/commits/de80c50b2678
> 2ba6e899ee5a95b31b28790c940d

Good find Srinivas and thanks for keeping us updated with your progress
tracking this down!

Jonathan
> 
> 
> Thanks,
> Srinivas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [next] | [standalone]

#1477325

On Fri, 2016-09-02 at 15:48 -0700, Srinivas Pandruvada wrote:
> On Tue, 2016-08-30 at 22:42 +0000, Pandruvada, Srinivas wrote:
> > Hi All,
> > 
> > I observed that using iio-sensor-proxy.service, the auto screen
> > rotation flipped on my laptop (Normal -> vertical, vertical-
> > >normal)
> > using kernel v4.8.
> > 
> > Anyone else has seen this?
> > 
> > I did a bisect and found a commit, which I am not sure how can it
> > impact.
> > 
> > 
> > commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> > Author: George Spelvin <linux@sciencehorizons.net>
> > Date:   Fri Jun 10 00:22:12 2016 -0400
> > 
> [...]
> 
> It turns out to be some assumption user space program is making about
> the traversing directory using glib call g_dir_read_name(). 
> 
> With the commit 703b5faf22fbddf984a361e6555f3a03fdba63d9
> (fs/dcache.c:
> Save one 32-bit multiply in dcache lookup)
>  in kernel 4.8-rc, somehow the order is changed (so the in_accel_y
> was
> appearing before in_accel_x )
> 
> I modified user space program to use correct iio scan element index
> to
> determine byte offset instead depending on the glib_dir_read_name,
> which doesn't guarantee any order.
> 
> I sent a pull request to author of iio-sensor-proxy to review.
> 
> Hadess,
> 	Please look.
> 
> https://github.com/hadess/iio-sensor-proxy/pull/99/commits/de80c50b26
> 78
> 2ba6e899ee5a95b31b28790c940d

I fixed it up (styling, and commit message) and merged this.

Note that there might be other problems in this particular piece of
code, that comes from the original Peter F. Patel-Schneider's helper
code for the Lenovo Yoga laptops (and based on 8-year old code from
Jonathan Cameron himself ;)

I'll make a release soonish to include this fix.

Cheers

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web