On 3/4/2014 07:34, Antonio Ospite wrote:
This can be done in the driver. See
https://www.mail-archive.com/linux-input@xxxxxxxxxxxxxxx/msg08103.html
xpad is a joystick driver, while hid-sony is a HID driver.
I tried it and the hack works from HID space with some tweaking, but,
yeah, it's a hack and doesn't belong in *any* driver.
Let me answer the last question first, the rationale was:
1. the common use case for the sixaxis is considered to be its use
via Bluetooth, can we agree on that?
2. under this assumption BlueZ was chosen as a convenient place to do
the pairing and association.
3. Paring requires to access the device via USB in order to retrieve
its bdaddr and set the master bdaddr.
4. Once we are accessing the device via USB and BT in the BlueZ plugin
anyway, just let's set the LEDs here.
A more general "excuse" is that clutter in userspace is slightly more
acceptable than clutter in kernel code.
And to reply to the other questions, yes, the bluez plugin is not
perfect by any means: it enforces dependencies, it's not using the leds
class yet, but it can be improved and IMHO it's still the most
convenient way to have responsibilities separated: the kernel driver
provides access to the hardware functionality and the userspace
software decides what to do with them.
However, since you are the one currently working on things you are
entitled with a stronger voice here, I am just whispering my opinions :)
Ciao,
Antonio
I understand your rationale, but I still think that the driver should
assign sane defaults for cases where there isn't userspace software to
set the LEDs. Leaving the Sixaxis LEDs blinking doesn't differentiate
between whether or not the controller is connected or trying to connect
and on the Dualshock 4 the default is a bright-white battery draining
light. On the other hand, the current default of 'all-off', which has
been the default since the initial LED patch, doesn't indicate whether
the controller connected successfully or timed-out when using Bluetooth.
I currently have David's suggestion of assigning an id via an IDA
allocator implemented in my working copy. This can be used to both
initialize the LEDs relative to other Sony controllers and provide a
sane unique identifier for the battery identification string instead of
the constantly incrementing atomic integer used now. This is the most
ideal solution IMO since it clearly communicates the current power and
connection status of the controller, lets the user easily differentiate
between controllers 1, 2, etc... and it provides defaults that most
users shouldn't find annoying. Of course, these are just defaults so if
you want to use a BlueZ plugin or something else to set the values via
userspace, there is nothing stopping you.
I'm going wait on v2 of this series until Benjamin Tissoires finishes
his latest patches since I think patch #2 and beyond will conflict with
his work. Patch #1 is just a trivial one-line fix though, so that
should still be good to go.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
