kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: twunknown@gmail.com (Brock York)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Is this a good first patch for enabling screen rotation?
Date: Wed, 11 Feb 2015 23:33:27 +0800	[thread overview]
Message-ID: <1423668807.10708.30.camel@gmail.com> (raw)
In-Reply-To: <5684.1422551543@turing-police.cc.vt.edu>

Hello Valdis

Sorry for such a late reply and thank you for such a quick reply.

On Thu, 2015-01-29 at 12:12 -0500, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 30 Jan 2015 00:45:30 +0800, Brock York said:
> 
> (Note, I don't have an Acer, nor am I an HID expert...  so take this
> all with a grain of salt...)
> 
> > Swap the x and y values and negate the x value converting the
> > accelerometers coordinate system into the coordinate system
> > userspace udev expects.
> 
> This part looks fishy...
> 
> 1) I wasn't aware that udev had a coordinate system.  I think you
> meant that something *else* was using values that udev passed
> to userspace.  You probably want to clarify what you meant.

I haven't really explained this very well. It's not udev specifically
that is 'consuming' the output. From what my research has turned up is
that udev creates a event and then runs a program called accelerometer.
Which is part of the udev package. It then reads the coordinates from
the udev event and then modifies the event adding the orientation to the
event.

I've read the source code for accelerometer but I don't quite understand
it. So I guess I should probably look at the udev docs or contact the
udev developers. But from what I can understand it expects the
accelerometer axes to be how I described in the expected coordinates.
But first I should probably make sure the acceleromter is actually
correctly being read and etc.

> 2) There obviously was *some* consumer of the input_report_abs()
> value before you added the kobject_uevent() call - convince us
> that said consumer is OK with its axes being twiddled like this.
> 
> >  	input_report_abs(acer_wmi_accel_dev, ABS_X,
> > -		(s16)out_obj->package.elements[0].integer.value);
> > +		-(s16)out_obj->package.elements[1].integer.value);
> >  	input_report_abs(acer_wmi_accel_dev, ABS_Y,
> > -		(s16)out_obj->package.elements[1].integer.value);
> > +		(s16)out_obj->package.elements[0].integer.value);

Do you have any advice on what else could be consuming the output?
The only thing I know of would be udev. I'd like to test it
on another Acer laptop that has a acceleromter to see whether this
breaks things. But I don't have the hardware.

> Other issues:
> 
> 3) "when accelerometer position is updated."
> 
> Is that going to generate a flood of events if (for example) you're walking
> with the device and it's swinging back and forth a bit?  It's one thing to
> have HID devices generating a near-constant stream of updates for mouse
> tracking and so on - it's a whole 'nother can of worms to additionally
> bash udev with an update stream.
> 
> Perhaps udev events should be clamped to only trigger when it's time for
> an actual axis swap?

I was thinking this myself, whether I would be flooding udev. But it
means I would need to reimplement the functionality that is in
userspace. Which is determining what the orientation of the device is
and then emiting a udev event with the orientation. Would this be
acceptable though, to add code that would be duplicating what is
currently in userspace? 
Or do you mean just checking if the x or y axis go from negative to
positive and only then emiting a udev event?

> 
> 4) This should probably be 2 patches - one to swap the input_report_abs()
> values, and a second to add the kobject_uevent() call.

Thanks I was really wondering whether this is one or two logical
changes. So that clears it up thank you.

> 
> 5) I almost have to wonder if the input_report_abs() part is sufficient,
> and udev events aren't needed?

Well I had been waiting for automatic screen rotation to come to my
tablet for quite some time. After searching for a year or two now
I finally found a blog about the weetabs automatic screen rotation in
Gnome 3. It explained the basic idea behind how it works. So I read the
asus driver (which is what the weetab uses) and the only line missing
from the acer driver seemed to be the kobject_uevent() call. As soon as
I added that call automatic rotation started working. But the detected
screen orientation was wrong which is why I started twidling the x and y
coordinates.

      reply	other threads:[~2015-02-11 15:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 16:45 Is this a good first patch for enabling screen rotation? Brock York
2015-01-29 17:12 ` Valdis.Kletnieks at vt.edu
2015-02-11 15:33   ` Brock York [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1423668807.10708.30.camel@gmail.com \
    --to=twunknown@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).