On Wed, 08 Jun 2011 15:33:42 +0100 Bastien Nocera <hadess@xxxxxxxxxx> wrote: > On Wed, 2011-06-08 at 15:09 +0200, Antonio Ospite wrote: > > > > - When the controller is connected via USB the led is set, but then > > it goes blinking again waiting for the PS button to be pressed, > > maybe we should wait for the PS button before setting leds, maybe > > with a simple blocking read() on the hidraw device. > > One hard thing to handle is when the device is already in use via USB, > it should automatically connect via Bluetooth when unplugged. I'm not > sure this works right now (I'm a bit hazy on the interaction with the > PS button tbh). > Oh, this works if the user already pressed the PS button when connected via USB, it is just the LED setting which is still weak on USB connection (before and after PS button) because of the PS button requirement. BTW Bastien I'd really appreciate a run-time test by other people before this gets is :) > > - When the controller is connected via USB after it is working over > > BT, it is seen as a second controller and the second led it turned > > on, should we force BT disconnection on USB connection? > > As we can identify the device uniquely through its bdaddr, I'd say > yes. > I had done some experiment about that, but I didn't find a good way using the bluez API, I'll be back on that after the first iteration goes in, OK? I guess one problem will be about the numbering of /dev/input/jsX, can we disconnect the BT device _before_ the kernel enumerates the USB one? Thanks, 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?
Attachment:
pgprKqRoucXvQ.pgp
Description: PGP signature
