On Tue, 09 Aug 2011 22:24:37 -0400
Alan Ott [off-list ref] wrote:
[...]
quoted
+ ret = create_sixaxis_association(adapter,
+ SIXAXIS_NAME,
+ device_bdaddr,
+ VENDOR, PRODUCT, SIXAXIS_PNP_RECORD);
You create the association with a hard-coded VID/PID. You match the
device on string name below (not VID/PID), so what if you used the
actual VID/PID of the device for the association instead?
Or use statically defined VID/PID to match the device, see below.
[...]
quoted
+ /*
+ * the total time the led is active (0xff means forever)
+ * | duty_length: how long a cycle is in deciseconds:
+ * | | (0 means "blink very fast")
+ * | | ??? (Maybe a phase shift or duty_length multiplier?)
+ * | | | % of duty_length led is off (0xff means 100%)
+ * | | | | % of duty_length led is on (0xff is 100%)
+ * | | | | |
+ * 0xff, 0x27, 0x10, 0x00, 0x32,
+ */
+ unsigned char leds_report[] = {
+ 0x01,
+ 0x00, 0x00, 0x00, 0x00, 0x00, /* rumble values TBD */
+ 0x00, 0x00, 0x00, 0x00, 0x1e, /* LED_1=0x02, LED_2=0x04 ... */
+ 0xff, 0x27, 0x10, 0x00, 0x32, /* LED_4 */
+ 0xff, 0x27, 0x10, 0x00, 0x32, /* LED_3 */
+ 0xff, 0x27, 0x10, 0x00, 0x32, /* LED_2 */
+ 0xff, 0x27, 0x10, 0x00, 0x32, /* LED_1 */
+ 0x00, 0x00, 0x00, 0x00, 0x00,
+ };
+ int leds = 0;
+ if (leds_status[0])
+ leds |= LED_1;
+ if (leds_status[1])
+ leds |= LED_2;
+ if (leds_status[2])
+ leds |= LED_3;
+ if (leds_status[3])
+ leds |= LED_4;
+
+ leds_report[10] = leds;
If you are overwriting leds_report[10] unconditionally, why is it
initialized to 0x1e in the leds_report initializer (unless I counted wrong)?
You are right having it initialized to 0x1e is not necessary at all,
but I'd still keep it to 0x1e in the initializer because this is the
"hardware default", meaning "all leds blinking", I see it as a form of
documentation-inside-code, but if it is confusing I will avoid that.
[...]
quoted
+
+static inline gboolean is_sixaxis(const char *hid_name)
+{
+ return g_str_has_suffix(hid_name, "PLAYSTATION(R)3 Controller") ||
+ g_str_has_suffix(hid_name,
+ "Sony Computer Entertainment Wireless Controller");
+}
Why do you key on the string name here. This seems problematic,
especially if you want to support things like the PSMove. I'd expect a
table of VID/PIDs or something.
Right, I like this suggestion, I generalized the code a little bit to
handle different devices, see the two follow-up incremental patches, in
the first one I remove static #defines in favor of a structure
representing a device type, in the second one I match devices using
VID/PID from a table of device types.
If the idea looks OK I'll fold those patches in v5, along with the
plugin renaming to "sony-controller", and maybe I'll split the plugin in
several modules too:
sony-controller.c /* udev and bluez stuff */
sony-controller-hid.c /* hidraw and device specific stuff */
sony-controlled-hid.h
[...]
quoted
+
+static gboolean device_event_idle(struct udev_device *udevice)
+{
+ handle_device_plug(udevice);
+ udev_device_unref(udevice);
+ return FALSE;
+}
I'm a little confused why this is called "idle."
I don't know either, maybe trying to communicate that it is called
asynchronously by glib (via g_timeout_add_seconds())? But even if so
this is not a property of the function itself, so I think we can just
call it device_event().
Ah Bastien, I noticed we are using g_timeout_add_seconds() with the
callback always returning FALSE, so the latter is called only once,
can't we in this case just sleep and then call the function directly?
Isn't the main loop in sixaxis_init() enough to handle multiple
overlapping udev events? Maybe I asked that already... :P
Thanks for your work on this, Antonio. Linux working out of the box with
these controllers will be really cool.
Alan.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
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?