Hi,
can anybody reply to this and share his/her opinion?
Thanks a lot
Michal
---------- P?edan? zpr?va ----------
Subject: Re: Phis in /proc/bus/input/devices same for all devices?
Date: st?eda 21 ?nor 2007 23:06
From: Marcel Holtmann <[email protected]>
To: CIJOML <[email protected]>
Cc: [email protected]
Hi Michal,
> I use 2.6.20-mh1 patch and would like to differ devices based on Phis, but
> it is the same for all devices??
>
> I: Bus=0005 Vendor=045e Product=007c Version=0035
> N: Name="Microsoft Five Button Mouse"
> P: Phys=00:0D:88:8E:AB:2F
> S: Sysfs=/class/input/input19
> H: Handlers=mouse1 event6
> B: EV=7
> B: KEY=1f0000 0 0 0 0 0 0 0 0
> B: REL=103
>
> I: Bus=0005 Vendor=045e Product=007b Version=0039
> N: Name="Microsoft Bluetooth keyboard"
> P: Phys=00:0D:88:8E:AB:2F
> S: Sysfs=/class/input/input20
> H: Handlers=kbd event7
> B: EV=12000b
> B: KEY=10f80 44007 ffe01878 800d7ff febeffdf f3cfffff ffffffff fffffffe
> B: ABS=700 0
> B: LED=107
>
> I: Bus=0005 Vendor=046d Product=b3e3 Version=2503
> N: Name="Logitech Bluetooth Mediapad"
> P: Phys=00:0D:88:8E:AB:2F
> S: Sysfs=/class/input/input21
> H: Handlers=kbd event8
> B: EV=12000f
> B: KEY=7fff 2c3027 bf004440 0 0 1 10f80 8807c007 ffe67bfa d9415fff febeffdf
> ffefffff ffffffff fffffffe
> B: REL=40
> B: ABS=301 0
> B: LED=1f
>
> Shouldn't be there it's BDADDR?
please post this question to LKML. I am not sure that is the right
approach. Currently we fill in phys and uniq like this:
strncpy(hid->phys, batostr(&src), 64);
strncpy(hid->uniq, batostr(&dst), 64);
Maybe the input or HID subsystem should be changed to also export the
uniq values to udev.
Regards
Marcel
-------------------------------------------------------
On 2/21/07, CIJOML <[email protected]> wrote:
> Hi,
>
> can anybody reply to this and share his/her opinion?
Input core already exports uniq to udev and also via sysfs.
--
Dmitry
So where is that damned bug, that I don't see those uniq BDADDRESSes there?
Michal
Dne st?eda 21 ?nor 2007 23:27 Dmitry Torokhov napsal(a):
> On 2/21/07, CIJOML <[email protected]> wrote:
> > Hi,
> >
> > can anybody reply to this and share his/her opinion?
>
> Input core already exports uniq to udev and also via sysfs.
Hi Dmitry,
> > can anybody reply to this and share his/her opinion?
>
> Input core already exports uniq to udev and also via sysfs.
so do you think it would be better to create phys as a string of the
source and destination address like "<src>-<dst>" for Bluetooth. And
then keep the uniq empty like all USB devices without serial number do?
Regards
Marcel
On 2/21/07, Marcel Holtmann <[email protected]> wrote:
> Hi Dmitry,
>
> > > can anybody reply to this and share his/her opinion?
> >
> > Input core already exports uniq to udev and also via sysfs.
>
> so do you think it would be better to create phys as a string of the
> source and destination address like "<src>-<dst>" for Bluetooth. And
> then keep the uniq empty like all USB devices without serial number do?
>
I'd keep uniq as is and do what you proposed with phys. This way you
can either use uniq to identify your device while moving it from one
receiver to another (if you have several) or do exact match on phys to
get receiver/device pair.
Does this make sense?
--
Dmitry
Hi Dmitry,
> > > > can anybody reply to this and share his/her opinion?
> > >
> > > Input core already exports uniq to udev and also via sysfs.
> >
> > so do you think it would be better to create phys as a string of the
> > source and destination address like "<src>-<dst>" for Bluetooth. And
> > then keep the uniq empty like all USB devices without serial number do?
> >
>
> I'd keep uniq as is and do what you proposed with phys. This way you
> can either use uniq to identify your device while moving it from one
> receiver to another (if you have several) or do exact match on phys to
> get receiver/device pair.
>
> Does this make sense?
actually it doesn't help to keep uniq around since the Bluetooth HID
always reconnects to the same source/host address. Making it reconnect
results in a virtual cable unplug. So I think that I am going to modify
the phys to include source and destination address. In the end it is
only a string.
Regards
Marcel
I need this for differing Option "XkbModel" in Xorg, so I can bind to each
device it's model and has correct xev's scancodes based on model.
So I prefer to have as Phis just only BDADDR, because for me this doesn't make
sense to have there device to which keyboard connect. Then I should have 1
section for each receiver, which is stupid.
Section "InputDevice"
Identifier "Bluetooth Keyboard"
Driver "kbd"
Option "Name" "Bluetooth HID Boot Protocol Device"
Option "Phis" "BDADDR"
Option "XkbRules" "xfree86"
Option "XkbModel" "dinovo"
Option "XkbLayout" "us"
EndSection
and so on for every other BT keyboard I own.
Michal
Dne st?eda 21 ?nor 2007 23:48 Dmitry Torokhov napsal(a):
> On 2/21/07, Marcel Holtmann <[email protected]> wrote:
> > Hi Dmitry,
> >
> > > > can anybody reply to this and share his/her opinion?
> > >
> > > Input core already exports uniq to udev and also via sysfs.
> >
> > so do you think it would be better to create phys as a string of the
> > source and destination address like "<src>-<dst>" for Bluetooth. And
> > then keep the uniq empty like all USB devices without serial number do?
>
> I'd keep uniq as is and do what you proposed with phys. This way you
> can either use uniq to identify your device while moving it from one
> receiver to another (if you have several) or do exact match on phys to
> get receiver/device pair.
>
> Does this make sense?
Hi Michal,
> I need this for differing Option "XkbModel" in Xorg, so I can bind to each
> device it's model and has correct xev's scancodes based on model.
> So I prefer to have as Phis just only BDADDR, because for me this doesn't make
> sense to have there device to which keyboard connect. Then I should have 1
> section for each receiver, which is stupid.
it makes sense to make it analogous to the USB driver, where the phys
includes the USB path. The equivalent for Bluetooth is the source plus
destination.
> Section "InputDevice"
> Identifier "Bluetooth Keyboard"
> Driver "kbd"
> Option "Name" "Bluetooth HID Boot Protocol Device"
> Option "Phis" "BDADDR"
> Option "XkbRules" "xfree86"
> Option "XkbModel" "dinovo"
> Option "XkbLayout" "us"
> EndSection
I don't know how "Phis" suppose to work, but I might think it is better
using vendor and product ID for matching.
Regards
Marcel
Marcel how can you differ what is src and what is dst, when device can connect
first time from hub to keyboard and later keyboard to hub?
Michal
Dne st?eda 21 ?nor 2007 23:53 Marcel Holtmann napsal(a):
> Hi Dmitry,
>
> > > > > can anybody reply to this and share his/her opinion?
> > > >
> > > > Input core already exports uniq to udev and also via sysfs.
> > >
> > > so do you think it would be better to create phys as a string of the
> > > source and destination address like "<src>-<dst>" for Bluetooth. And
> > > then keep the uniq empty like all USB devices without serial number do?
> >
> > I'd keep uniq as is and do what you proposed with phys. This way you
> > can either use uniq to identify your device while moving it from one
> > receiver to another (if you have several) or do exact match on phys to
> > get receiver/device pair.
> >
> > Does this make sense?
>
> actually it doesn't help to keep uniq around since the Bluetooth HID
> always reconnects to the same source/host address. Making it reconnect
> results in a virtual cable unplug. So I think that I am going to modify
> the phys to include source and destination address. In the end it is
> only a string.
>
> Regards
>
> Marcel
Hi Michal,
> how can you differ what is src and what is dst, when device can connect
> first time from hub to keyboard and later keyboard to hub?
the source is always the host (meaning the adapter) and the destination
is always the device.
Regards
Marcel
Dne ?tvrtek 22 ?nor 2007 00:00 Marcel Holtmann napsal(a):
> Hi Michal,
>
> > I need this for differing Option "XkbModel" in Xorg, so I can bind to
> > each device it's model and has correct xev's scancodes based on model. So
> > I prefer to have as Phis just only BDADDR, because for me this doesn't
> > make sense to have there device to which keyboard connect. Then I should
> > have 1 section for each receiver, which is stupid.
>
> it makes sense to make it analogous to the USB driver, where the phys
> includes the USB path. The equivalent for Bluetooth is the source plus
> destination.
>
> > Section "InputDevice"
> > Identifier "Bluetooth Keyboard"
> > Driver "kbd"
> > Option "Name" "Bluetooth HID Boot Protocol Device"
> > Option "Phis" "BDADDR"
> > Option "XkbRules" "xfree86"
> > Option "XkbModel" "dinovo"
> > Option "XkbLayout" "us"
> > EndSection
>
> I don't know how "Phis" suppose to work, but I might think it is better
> using vendor and product ID for matching.
Xorg just reads lines from devices and match devices against it. So Phis makes
configuration easier ;), because only one line is enough to match device.
>
> Regards
>
> Marcel
Michal
Hi Marcel,
On 2/21/07, Marcel Holtmann <[email protected]> wrote:
> Hi Dmitry,
>
> > > > > can anybody reply to this and share his/her opinion?
> > > >
> > > > Input core already exports uniq to udev and also via sysfs.
> > >
> > > so do you think it would be better to create phys as a string of the
> > > source and destination address like "<src>-<dst>" for Bluetooth. And
> > > then keep the uniq empty like all USB devices without serial number do?
> > >
> >
> > I'd keep uniq as is and do what you proposed with phys. This way you
> > can either use uniq to identify your device while moving it from one
> > receiver to another (if you have several) or do exact match on phys to
> > get receiver/device pair.
> >
> > Does this make sense?
>
> actually it doesn't help to keep uniq around since the Bluetooth HID
> always reconnects to the same source/host address. Making it reconnect
> results in a virtual cable unplug. So I think that I am going to modify
> the phys to include source and destination address. In the end it is
> only a string.
>
Matching on uniq (and having uniq available) makes sense when you want
to perform device-specific setup and want it to work even if you
change your BT adapter. Imagne yopu have a keyboard that yoou want to
handle in a special way and after you set up your BT card gets fried
and you buy another one. When matchign on uniq your setup will not
change at all.
--
Dmitry