mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mike Murphy <mamurph@cs.clemson.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	linux-usb@vger.kernel.org, greg@kroah.com, oliver@neukum.org,
	fweisbec@gmail.com
Subject: Re: PATCH [1/3] drivers/input/xpad.c: Improve Xbox 360 wireless  support and add sysfs interface
Date: Mon, 2 Mar 2009 19:12:30 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0903021902460.3111@localhost.localdomain> (raw)
In-Reply-To: <5aa163d00903021847n525e8704jd332610c45e4675a@mail.gmail.com>



On Mon, 2 Mar 2009, Mike Murphy wrote:
> 
> 3. The outer cast (__s16) converts the unsigned values to signed
> values, while the "~" inverts the y axes to make them function like a
> joystick instead of a flight simulator control.

You should do the ~ before the cast, or use - if you just want to reverse 
things. It probably doesn't much matter (the difference between ~ and - i 
just one), but still..

Also, quite frankly, it looks like your 'coords[]' array should just be of 
type 's16' (rather than 'int') to begin with. You seem to really never use 
it as an int anyway. That would get rid of the cast.

> Is there a cleaner way to accomplish the transition from 16-bit
> unsigned little endian to 16-bit signed host endian?

I think the code is fine, but I think you'd be better off if the "data" 
pointer was perhaps of type "le16 *" to begin with.

That obviously means that your "offset" addition should now be in 16-bit 
words rather than in bytes, so you'd need to divide the offsets by two to 
do that, but those are just numbers anyway. And quite frankly, it looks 
like the actual data is just offset differently - but with the same fixed 
offset between values - for the two cases, so you could just have _one_ 
offset (and even just add that into the 'data' pointer).

That would get rid of the second cast. You'd end up with just

	s16 coords[4];

	/* In words - so this is 12 vs 6 bytes into the data */
	data += (xpad->xtype == XTYPE_XBOX) ? 6 : 3;

	coords[0] = le16_to_cpup(data);
	coords[1] = ~le16_to_cpup(data + 1);
	coords[2] = le16_to_cpup(data + 2);
	coords[3] = ~le16_to_cpup(data + 3);
	..

which looks a bit shorter and avoids those casts. I dunno.

		Linus

  parent reply	other threads:[~2009-03-03  3:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01  4:53 Mike Murphy
2009-03-02 21:04 ` Andrew Morton
2009-03-02 21:18   ` Greg KH
2009-03-02 21:35     ` Andrew Morton
2009-03-02 21:59       ` Greg KH
2009-03-02 21:59       ` Mike Murphy
2009-03-02 22:39         ` Greg KH
2009-03-02 23:04           ` Mike Murphy
2009-03-02 23:13             ` Greg KH
2009-03-02 21:46   ` Mike Murphy
2009-03-02 22:00     ` Andrew Morton
2009-03-02 22:27       ` Mike Murphy
2009-03-03  2:47   ` Mike Murphy
2009-03-03  3:09     ` Mike Murphy
2009-03-03  3:12     ` Linus Torvalds [this message]
2009-03-03  4:16       ` Mike Murphy
2009-03-03  4:20         ` Mike Murphy

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=alpine.LFD.2.00.0903021902460.3111@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=greg@kroah.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mamurph@cs.clemson.edu \
    --cc=oliver@neukum.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

Powered by JetHome