Re: [PATCH] input: xpad.c - Xbox 360 wireless and sysfs support

[Mike Murphy <mamurph@cs.clemson.edu>]

On Mon, Feb 16, 2009 at 11:13 AM, Greg KH <greg@kroah.com> wrote:
...
>
> The bigger question is why are you using a struct kobject in the first
> place?  As you are a device, just use a struct device.  What are you
> trying to do in sysfs here to make you want to use a "raw" kobject in a
> driver?
>
> thanks,
>
> greg k-h
>

The purpose of the struct xpad_data (which contains the struct
kobject) is to expose parameters that can be read and/or tweaked at
runtime. At the moment, the adjustable parameters are the size of the
dead zone around the center of the stick, and the choice of whether to
map to a square axis. Read-only data include a unique identifier for
each pad (wireless) and an indication as to whether the wireless pad
is actually connected.

The idea behind this interface is to enable a future userspace
application, likely using HAL and D-BUS, to receive events whenever a
wireless pad connects, and to identify the particular pad in question
(specifically, the unique ID of the pad). The user could then, for
example, have a different dead zone size for each pad, based upon the
actual manufacturing variations in the sticks on that pad (some appear
more precise at centering than others). Ideally, this functionality
could be designed in a "common" way so that the userspace code could
eventually work with other, non-xpad gaming devices.

So I really just wanted a way to get some parameters to userspace. The
consensus opinion of everything I read was that /proc additions were
frowned upon for cluttering up /proc with kernel stuff, ioctls were
viewed negatively because of their inconsistent nature from device to
device, and that sysfs was the best solution for this problem.

I didn't use a struct device because of the existing struct usb_xpad
that was created on a per-gamepad basis (not necessarily per device,
as the wireless 360 adapter is one physical device but exposes 4
gamepads by exposing 4 logical devices [and then each gamepad, in
turn, is technically a USB hub that can have other stuff
attached...]). I tried not to break existing functionality.
Additionally, struct usb_xpad contains two device pointers: one to the
actual USB device, and one to an input device (see source of the
in-tree xpad.c). So I followed your kobject.txt documentation and
samples to create a new object whose sole purpose in life is to expose
the sysfs interface, without interfering with the existing device
entries in the driver. I'm not sure I see a clean way to use a single
struct device here....

Thanks,
Mike
-- 
Mike Murphy
Ph.D. Candidate and NSF Graduate Research Fellow
Clemson University School of Computing
120 McAdams Hall
Clemson, SC 29634-0974 USA
Tel: +1 864.656.2838   Fax: +1 864.656.0145
http://cirg.cs.clemson.edu/~mamurph