Message-Id: <20141118233023.4368facdc75a090b9017e53e@ao2.it>
Date:	Tue, 18 Nov 2014 23:30:23 +0100
From:	Antonio Ospite <ao2@....it>
To:	bri <bri@...ij.org>
Cc:	Frank Praznik <frank.praznik@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Henrik Rydberg <rydberg@...omail.se>, open@...ij.org,
	HID CORE LAYER <linux-input@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning

On Tue, 18 Nov 2014 09:26:29 -0500
bri <bri@...ij.org> wrote:

> On Mon, Nov 17, 2014 at 10:21:53PM -0500, Frank Praznik wrote:
> > Hi Brian,
> > 
> > On 11/17/2014 19:00, bri wrote:
> > >
> > >>Yeah, the device ID in the driver is only for tracking devices internally
> > >>and setting sane default LED values.  It has no meaning outside of the
> > >>module.  Like Antonio said, if you want the system number for a controller
> > >>you are better off just getting it from the joystick device.
> > >Would you be amenable to a patch that removes the IDA entirely and just sets
> > >the LEDs to all solid-on?  Since the LEDs are available through sysfs,
> > >udev rule could probably be made to set the LEDs in the absence of bluez
> > >or a higher level controller manager, and then it becomes the distro's
> > >responsibility.
> > >
> > 
> > What would be the benefit of doing this?  Nothing is stopping higher level
> > services from setting the LEDs right now.  The driver just sets sane
> > defaults for systems that don't have anything else to set the 'real' values.
> > Other controllers like Wiimotes and Xbox gamepads do the same thing.  It
> > doesn't get in the way of services like BlueZ setting them once
> > initialization is complete.
> > 
> > Leaving it completely up to the distro just means that there will be
> > situations where there is nothing to set the default values which makes for
> > a bad user experience.
> 
> It would eliminate 50 to 100 lines of code just for that tiny purpose,
> which userspace can and probably should take care of, given the disparity
> with the eventual values.  I'm honestly a bit confused of the criteria in use
> here, as I thought it was mostly deciding between the usefulness of features
> versus maintainability.  In my mind if I weight a master_bdaddr sysfs file
> and the code to support it versus this feature, I don't see where this one
> wins out.
>

I don't find the IDA code and the default LED state super useful
either, and the functionality over USB is limited, but the actual point
is that, in general, removing stuff is a bigger deal than refusing to
add new optional features: people may rely on, or expect the behavior
of, the code that is _already_ there.

The IDA code was added in the first place because Frank found it
useful, and being him the de-facto maintainer of the driver (he
had worked on it for quite a while before he added the IDA code) he has
a stronger voice in the decisions.

If you ask me, wrt. usefulness and necessity the two functionality
are more or less on the same level but the code which is already there
will more likely stay in.

> But whatever.  I made this for my own use, and offered it up, and if the
> community does not want it I am free to keep using what I made, so I'm happy
> either way.
> 

I'll comment on that in the other mail when you talk about the shell
solution.

Ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists