Hi,
I would like my new Logitech V270 to exists under /dev/input/v270,
instead of a changing /dev/input/mouseN.
The goal is to be able to use one of the Logitech control utilities,
which need a device to operate on.
% hidd --show
00:07:61:3B:9B:7C Logitech Bluetooth Mouse [046d:b002] connected
% cat /proc/bus/input/devices
...snipp...
I: Bus=0005 Vendor=046d Product=b002 Version=4809
N: Name="Logitech Bluetooth Mouse"
P: Phys=00:10:C6:22:54:AF
H: Handlers=mouse4 event4
B: EV=f
B: KEY=ff0000 0 0 0 0 0 0 0 0
B: REL=103
B: ABS=300 0
...snipp...
How does this translate to a udev rule ? My attempts so far are failing.
Charles
--
Charles Bueche <[email protected]>
sand, snow, wave, wind and net -surfer
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Le mercredi 08 f=C3=A9vrier 2006 =C3=A0 16:09 +0100, Charles Bueche a =C3=
=A9crit :
> Hi all,
>=20
> thanks for the analysis and explanations. From what I have read and
> tested, here is a resum=C3=A9 of the Logitech V270 situation :
>=20
> - Logitech ignore Linux (this is not new, but need to be repeated)
> - the V270 mouse basically works as expected HID input device, but is
> overly sensible (probably due to its high resolution)
> - the mouse events go into /dev/input/mice by default
> - if evdev is loaded, mouse events go to /dev/input/event{1..N}
> - udev doesn't have the info to create a rule in 10-local.rules so the
> V270 get mapped to a fix name like /dev/input/v270
> - none of the tools I tried (locomo, logitech-applet) know the V270 for
> now. I tried to change some of them, but failed, due to lacking know-ho=
w
> in HID/USB/etc
> - KDE control center or xset cannot reduce the mouse sensibility enough
> to make it usuable (at least for my 40 years muscles control ability)
Thanks for this good resum=C3=A9, you point out the major current issue.
I just can add about udev-rules, Marcel and UDEV team are searching for
a better solution to add more infos on the udev struct, to let user
creates good rules with devices.
We can expect a workaround not so far :)
And about Linux support on Logitech product, I've several friends
working for this compagny, and with some insiders informations, I can
tell that Logitech try now to make better software. They are aware of
the poor quality of their driver / software.
Just hope they can spend some time to change their devs :)
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On mar, 2006-02-07 at 23:24 +0100, Marcel Holtmann wrote:
> Hi Alexandre,
>=20
> > > Did you contact the hotplug team about this issue ?
> >=20
> > I got the folowing answer from hotplug ML :=20
> >=20
> > Kay Sievers <[email protected]>
> >=20
> > The kernel driver needs to set the "struct device", to get a "device"
> > link
> > in sysfs pointing to the physical device, otherwise the USB devices a=
re
> > not
> > reachable and udev can't match.
>=20
> and we don't have a "struct device", because the current integration of
> the Bluetooth subsystem is a class device under /sys/class. It seems we
> need to wait until the /sys/device unification found its way into the
> kernel.
Hi all,
thanks for the analysis and explanations. From what I have read and
tested, here is a resum=E9 of the Logitech V270 situation :
- Logitech ignore Linux (this is not new, but need to be repeated)
- the V270 mouse basically works as expected HID input device, but is
overly sensible (probably due to its high resolution)
- the mouse events go into /dev/input/mice by default
- if evdev is loaded, mouse events go to /dev/input/event{1..N}
- udev doesn't have the info to create a rule in 10-local.rules so the
V270 get mapped to a fix name like /dev/input/v270
- none of the tools I tried (locomo, logitech-applet) know the V270 for
now. I tried to change some of them, but failed, due to lacking know-how
in HID/USB/etc
- KDE control center or xset cannot reduce the mouse sensibility enough
to make it usuable (at least for my 40 years muscles control ability)
There is some hope to make all this work, with new kernel, xorg and udev
versions. Stay tuned :-)
Charles
--=20
Charles Bueche <[email protected]>
sand, snow, wave, wind and net -surfer
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Alexandre,
> > Did you contact the hotplug team about this issue ?
>
> I got the folowing answer from hotplug ML :
>
> Kay Sievers <[email protected]>
>
> The kernel driver needs to set the "struct device", to get a "device"
> link
> in sysfs pointing to the physical device, otherwise the USB devices are
> not
> reachable and udev can't match.
and we don't have a "struct device", because the current integration of
the Bluetooth subsystem is a class device under /sys/class. It seems we
need to wait until the /sys/device unification found its way into the
kernel.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Le jeudi 02 f=C3=A9vrier 2006 =C3=A0 12:45 +0100, Charles Bueche a =C3=A9=
crit :
> Hi Alexandre,
>=20
> I have found your post on 13.1.2006.
>=20
> I don't exactly understand who is faulty :
>=20
> - is it hidd which should add the mouse details to a data structure ?
> - or udev which doesn't search for the info ?
>=20
> Did you contact the hotplug team about this issue ?
I got the folowing answer from hotplug ML :=20
Kay Sievers <[email protected]>
The kernel driver needs to set the "struct device", to get a "device"
link
in sysfs pointing to the physical device, otherwise the USB devices are
not
reachable and udev can't match.
Kay
So seems to be a Bluez stack problem.
--=20
Alexandre
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Le jeudi 02 f=C3=A9vrier 2006 =C3=A0 12:45 +0100, Charles Bueche a =C3=A9=
crit :
> Hi Alexandre,
Charles,=20
> I don't exactly understand who is faulty :
>=20
> - is it hidd which should add the mouse details to a data structure ?
> - or udev which doesn't search for the info ?
I've no ideas who is faulty too.=20
With udev 084, I got :
udevinfo -a -p /sys/class/input/mouse1
--cut--
looking at device '/class/input/input4/mouse1':
KERNEL=3D=3D"mouse1"
SUBSYSTEM=3D=3D"input"
SYSFS{dev}=3D=3D"13:33"
looking at device '/class/input/input4':
ID=3D=3D"input4"
BUS=3D=3D"input"
DRIVER=3D=3D""
SYSFS{uniq}=3D=3D""
SYSFS{phys}=3D=3D""
SYSFS{name}=3D=3D"Bluetooth HID Boot Protocol Device"
So very few infos.
> Did you contact the hotplug team about this issue ?
I'm doing this right now, thanks for the tip.
Best regards
--Alexandre
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Alexandre,
I have found your post on 13.1.2006.
I don't exactly understand who is faulty :
- is it hidd which should add the mouse details to a data structure ?
- or udev which doesn't search for the info ?
Did you contact the hotplug team about this issue ?
Regs,
Charles
On jeu, 2006-02-02 at 11:38 +0100, Alexandre Ghisoli wrote:
> Charles Bueche a =E9crit :
> > Hi,
> >
> > I would like my new Logitech V270 to exists under /dev/input/v270,
> > instead of a changing /dev/input/mouseN.
> >
> > =20
> Charles,
>=20
> I've posted few weeks ago the same request, without any luck.
>=20
> The trick come with the hid2hci, and the udev struct that is not update=
d.
> With the recent udev-081, struct is somewhat updated, and I'm able to=20
> have a fixed device, but without using event driver (witch I want to=20
> use, but I still cannot write udev rules).
>=20
> By now, with the rule :
> KERNEL=3D=3D"mouse*" SYSFS{name}=3D=3D"Bluetooth HID Boot Protoc=
ol=20
> Device", NAME=3D=3D"input/bt-mx900", MODE=3D=3D"0664"
>=20
> i'm able to get a FIXED device at /dev/input/bt-mx900 working mouse.
>=20
> Now, next problem is when the bluetooth stack goes standby (for exemple=
,=20
> let my PC running while lunch), when I touch the mouse to reconnect=20
> (hidd setup the link, correct device name is recreated), X lost my=20
> mouse, and I'm forced to close / open session to get it working again.
>=20
>=20
> > % hidd --show
> > 00:07:61:3B:9B:7C Logitech Bluetooth Mouse [046d:b002] connected
> >
> > % cat /proc/bus/input/devices
> > ...snipp...
> > I: Bus=3D0005 Vendor=3D046d Product=3Db002 Version=3D4809
> > N: Name=3D"Logitech Bluetooth Mouse"
> > P: Phys=3D00:10:C6:22:54:AF
> > H: Handlers=3Dmouse4 event4=20
> > B: EV=3Df=20
> > B: KEY=3Dff0000 0 0 0 0 0 0 0 0=20
> > B: REL=3D103=20
> > B: ABS=3D300 0=20
> > ...snipp...
> >
> > =20
> To show udev properties, use
>=20
> udevinfo -a -p /sys/class/input/event4 (as seen in your dump before)
>=20
> Regards
> --Alexandre
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=12164=
2
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
--=20
Charles Bueche <[email protected]>
sand, snow, wave, wind and net -surfer
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Charles Bueche a =E9crit :
> Hi,
>
> I would like my new Logitech V270 to exists under /dev/input/v270,
> instead of a changing /dev/input/mouseN.
>
> =20
Charles,
I've posted few weeks ago the same request, without any luck.
The trick come with the hid2hci, and the udev struct that is not updated.
With the recent udev-081, struct is somewhat updated, and I'm able to=20
have a fixed device, but without using event driver (witch I want to=20
use, but I still cannot write udev rules).
By now, with the rule :
KERNEL=3D=3D"mouse*" SYSFS{name}=3D=3D"Bluetooth HID Boot Protocol=
=20
Device", NAME=3D=3D"input/bt-mx900", MODE=3D=3D"0664"
i'm able to get a FIXED device at /dev/input/bt-mx900 working mouse.
Now, next problem is when the bluetooth stack goes standby (for exemple,=20
let my PC running while lunch), when I touch the mouse to reconnect=20
(hidd setup the link, correct device name is recreated), X lost my=20
mouse, and I'm forced to close / open session to get it working again.
> % hidd --show
> 00:07:61:3B:9B:7C Logitech Bluetooth Mouse [046d:b002] connected
>
> % cat /proc/bus/input/devices
> ...snipp...
> I: Bus=3D0005 Vendor=3D046d Product=3Db002 Version=3D4809
> N: Name=3D"Logitech Bluetooth Mouse"
> P: Phys=3D00:10:C6:22:54:AF
> H: Handlers=3Dmouse4 event4=20
> B: EV=3Df=20
> B: KEY=3Dff0000 0 0 0 0 0 0 0 0=20
> B: REL=3D103=20
> B: ABS=3D300 0=20
> ...snipp...
>
> =20
To show udev properties, use
udevinfo -a -p /sys/class/input/event4 (as seen in your dump before)
Regards
--Alexandre
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi again,
The V270 works after all. It was my error, I had two devices reporting
the same events in xorg.conf, so the speed was doubled.
Anyway, the V270 is fast, even with pointer acceleration =3D 1.0x in KDE
Another issue I'm having is that after 2 years of the big MX900 in my
right hand, I find the V270 a bit too small.
Charles
On Wed, 2006-02-08 at 16:09 +0100, Charles Bueche wrote:
> On mar, 2006-02-07 at 23:24 +0100, Marcel Holtmann wrote:
> > Hi Alexandre,
> >=20
> > > > Did you contact the hotplug team about this issue ?
> > >=20
> > > I got the folowing answer from hotplug ML :=20
> > >=20
> > > Kay Sievers <[email protected]>
> > >=20
> > > The kernel driver needs to set the "struct device", to get a "devic=
e"
> > > link
> > > in sysfs pointing to the physical device, otherwise the USB devices=
are
> > > not
> > > reachable and udev can't match.
> >=20
> > and we don't have a "struct device", because the current integration =
of
> > the Bluetooth subsystem is a class device under /sys/class. It seems =
we
> > need to wait until the /sys/device unification found its way into the
> > kernel.
>=20
> Hi all,
>=20
> thanks for the analysis and explanations. From what I have read and
> tested, here is a resum=E9 of the Logitech V270 situation :
>=20
> - Logitech ignore Linux (this is not new, but need to be repeated)
> - the V270 mouse basically works as expected HID input device, but is
> overly sensible (probably due to its high resolution)
> - the mouse events go into /dev/input/mice by default
> - if evdev is loaded, mouse events go to /dev/input/event{1..N}
> - udev doesn't have the info to create a rule in 10-local.rules so the
> V270 get mapped to a fix name like /dev/input/v270
> - none of the tools I tried (locomo, logitech-applet) know the V270 for
> now. I tried to change some of them, but failed, due to lacking know-ho=
w
> in HID/USB/etc
> - KDE control center or xset cannot reduce the mouse sensibility enough
> to make it usable (at least for my 40 years muscles control ability)
>=20
> There is some hope to make all this work, with new kernel, xorg and ude=
v
> versions. Stay tuned :-)
>=20
> Charles
--=20
Charles Bueche <[email protected]>
sand, snow, wave, wind and net -surfer
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users