Hi,
I have a question about udev events generated by a bluetooth joystick:
when the bt joystick generates the joystick event, the ID_SERIAL
property matches the one of the bt adapter not the one of the joystick.
For example (using "udevadm monitor --property"), when connecting the
Sony Sixaxis via usb I get:
ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
in the input and joystick events, but when I connect it via bt, I get:
ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
which matches my bluetooth adapter.
Is this expected/known, or is it a bug?
I am using kernel 2.6.37, udev 164
For the records, I also get ID_BUS=usb when connecting via bt, but I can
live with that since I can differenciate usb and bt operation using
ID_USB_DRIVER=usbhid
versus
ID_USB_DRIVER=btusb
Some insight of what I am trying to achieve with udev:
1. Monitor new joystick devices.
2. If ID_SERIAL != Sony_PLAYSTATION_R_3_Controller, then STOP.
3. Get the associated hidraw device node navigating the event tree.
4. Set leds using the value from the ID_INPUT_JOYSTICK property.
5. If ID_USB_DRIVER=usbhid do the needed pairing.
And with the current behaviour for ID_SERIAL I cannot enforce 2.
I could listen for the (hid) event and use HID_NAME which seems to be a
little more consistent:
usb -> HID_NAME=Sony PLAYSTATION(R)3 Controller
bt -> HID_NAME=PLAYSTATION(R)3 Controller
and navigate the event hierarchy to get ID_INPUT_JOYSTICK, but that is
slightly more complicated, and I am curious about the ID_SERIAL
behavior anyways :)
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?
On Tue, Feb 08, 2011 at 12:05:33PM +0100, Antonio Ospite wrote:
> On Mon, 7 Feb 2011 23:48:42 -0800
> Dmitry Torokhov <[email protected]> wrote:
>
> > On Fri, Feb 04, 2011 at 11:34:27PM +0100, Antonio Ospite wrote:
> > > Hi,
> > >
> > > I have a question about udev events generated by a bluetooth joystick:
> > > when the bt joystick generates the joystick event, the ID_SERIAL
> > > property matches the one of the bt adapter not the one of the joystick.
> > >
> > > For example (using "udevadm monitor --property"), when connecting the
> > > Sony Sixaxis via usb I get:
> > > ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
> > > in the input and joystick events, but when I connect it via bt, I get:
> > > ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
> > > which matches my bluetooth adapter.
> > >
> [...]
>
> > This should be directed to udev list as composition of ID_SERIAL is
> > done exclusively by udev. It looks like it scans parent till it finds
> > first USB device (thus skipping all BT-specific data).
> >
>
> Thanks Dmitry, I'll resend this to linux-hotplug.
>
> Is it OK for cases like this to still keep linux-bluetooth and
> linux-input in CC?
Sure, why not.
--
Dmitry
On Mon, 7 Feb 2011 23:48:42 -0800
Dmitry Torokhov <[email protected]> wrote:
> On Fri, Feb 04, 2011 at 11:34:27PM +0100, Antonio Ospite wrote:
> > Hi,
> >
> > I have a question about udev events generated by a bluetooth joystick:
> > when the bt joystick generates the joystick event, the ID_SERIAL
> > property matches the one of the bt adapter not the one of the joystick.
> >
> > For example (using "udevadm monitor --property"), when connecting the
> > Sony Sixaxis via usb I get:
> > ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
> > in the input and joystick events, but when I connect it via bt, I get:
> > ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
> > which matches my bluetooth adapter.
> >
[...]
> This should be directed to udev list as composition of ID_SERIAL is
> done exclusively by udev. It looks like it scans parent till it finds
> first USB device (thus skipping all BT-specific data).
>
Thanks Dmitry, I'll resend this to linux-hotplug.
Is it OK for cases like this to still keep linux-bluetooth and
linux-input in CC?
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?
On Fri, Feb 04, 2011 at 11:34:27PM +0100, Antonio Ospite wrote:
> Hi,
>
> I have a question about udev events generated by a bluetooth joystick:
> when the bt joystick generates the joystick event, the ID_SERIAL
> property matches the one of the bt adapter not the one of the joystick.
>
> For example (using "udevadm monitor --property"), when connecting the
> Sony Sixaxis via usb I get:
> ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
> in the input and joystick events, but when I connect it via bt, I get:
> ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
> which matches my bluetooth adapter.
>
> Is this expected/known, or is it a bug?
> I am using kernel 2.6.37, udev 164
>
> For the records, I also get ID_BUS=usb when connecting via bt, but I can
> live with that since I can differenciate usb and bt operation using
> ID_USB_DRIVER=usbhid
> versus
> ID_USB_DRIVER=btusb
>
> Some insight of what I am trying to achieve with udev:
> 1. Monitor new joystick devices.
> 2. If ID_SERIAL != Sony_PLAYSTATION_R_3_Controller, then STOP.
> 3. Get the associated hidraw device node navigating the event tree.
> 4. Set leds using the value from the ID_INPUT_JOYSTICK property.
> 5. If ID_USB_DRIVER=usbhid do the needed pairing.
>
> And with the current behaviour for ID_SERIAL I cannot enforce 2.
> I could listen for the (hid) event and use HID_NAME which seems to be a
> little more consistent:
> usb -> HID_NAME=Sony PLAYSTATION(R)3 Controller
> bt -> HID_NAME=PLAYSTATION(R)3 Controller
> and navigate the event hierarchy to get ID_INPUT_JOYSTICK, but that is
> slightly more complicated, and I am curious about the ID_SERIAL
> behavior anyways :)
This should be directed to udev list as composition of ID_SERIAL is
done exclusively by udev. It looks like it scans parent till it finds
first USB device (thus skipping all BT-specific data).
Thanks.
--
Dmitry