I got a 12 button logitech MX1000 mouse. The buttons 11 and 12 which
are the horizontal direction of the tilt wheel gives me this the log
Jan 5 15:56:26 quasar keyboard.c: can't emulate rawmode for keycode 240
.. every time I press either button 11 or 12
I needed CONFIG_INPUT_EVDEV to read these events, btw
This gives me problems in some applications it seems, as it won't
allow me to move in one of the horizontal directions by holding the
tilt wheel for a period. It only moves me the length of a single
click. I can continue clicking myself in a direction, but when holding
down the tilt wheel, I'll only move one click in the direction.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
Hi,
> I got a 12 button logitech MX1000 mouse. The buttons 11 and 12 which
> are the horizontal direction of the tilt wheel gives me this the log
>
> Jan 5 15:56:26 quasar keyboard.c: can't emulate rawmode for keycode
240
>
> .. every time I press either button 11 or 12
Me too. I get the warning, and the holding it down doesn't work.
Anyone else have any ideas how to get rid of the warning, and possibly
make it work correctly?
Aaron Gyes
Esben Stien <[email protected]> writes:
> I got a 12 button logitech MX1000 mouse.
I have still not resolved this issue. Anyone who can point me in any
direction?
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
On Thu, Feb 03, 2005 at 03:42:16PM +0100, Esben Stien wrote:
> Esben Stien <[email protected]> writes:
>
> > I got a 12 button logitech MX1000 mouse.
>
> I have still not resolved this issue. Anyone who can point me in any
> direction?
Please try if 2.6.11-rc3 is any better.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On ven, 2005-02-04 at 20:54 +0100, Vojtech Pavlik wrote:
> On Thu, Feb 03, 2005 at 03:42:16PM +0100, Esben Stien wrote:
> > Esben Stien <[email protected]> writes:
> >
> > > I got a 12 button logitech MX1000 mouse.
> >
> > I have still not resolved this issue. Anyone who can point me in any
> > direction?
>
> Please try if 2.6.11-rc3 is any better.
Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10.
2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the
evdev driver as two seperate mouse buttons being pressed simultaneously.
(Please CC me in replies).
Vojtech Pavlik <[email protected]> writes:
> Please try if 2.6.11-rc3 is any better.
Yes, nice, the error is gone and I've verified with blender that the
horizontal scroll works as it should;).
Firefox gives me something strange, but the kernel issue is resolved.
I'll explain what firefox gives me, in case you're interested, but
I'll take this issue over to the firefox mailinglist.
I'm using xbindkeys to set up what the mouse is supposed to do:
"xvkbd -xsendevent -text "\[Left]""
b:11
"xvkbd -xsendevent -text "\[Right]""
b:12
#11 = HORIZONTAL LEFT
#12 = HORIZONTAL RIGHT
With this config, it is supposed to scroll in the horizontal direction
when keys 11/12 are pressed/moved/tilted.
Now, in firefox, I tilt the wheel in the right direction. It moves one
cm to the right, but then proceeds to move up and it continues to do
so until it reaches the top of the page or I release the button.
It is supposed to just move right, of course, as long as the tilt
wheel is not released and there is more data in the right direction.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
Jeremy Nickurak <[email protected]> writes:
> Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10.
> 2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the
> evdev driver as two seperate mouse buttons being pressed simultaneously.
I'm a little unclear as to what you mean here. Could you elaborate?
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
On mar, 2005-02-15 at 03:45 +0100, Esben Stien wrote:
> Jeremy Nickurak <[email protected]> writes:
>
> > Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10.
> > 2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the
> > evdev driver as two seperate mouse buttons being pressed simultaneously.
>
> I'm a little unclear as to what you mean here. Could you elaborate?
I use X.org with the following mouse configuration:
> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "evdev"
> Option "Device" "/dev/input/event-mx1000"
> Option "Buttons" "12"
> Option "ZAxisMapping" "11 12"
> Option "Resolution" "800"
> EndSection
With an Xmodmap rule:
> pointer = 1 2 3 8 9 10 11 12 6 7 4 5
This is to make sure that the scroll wheel shows up as 4/5 as expected,
and that the horizontal scroll shows up as 6/7, which most software
interprets as the left/right scroll buttons.
Xev says that the horizontal scrollers produce:
Scroll Left:
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935139, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x10, button 5, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x1010, button 5, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935267, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
And right:
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935915, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x10, button 4, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x810, button 4, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
I'm being very careful not accidentally press the horizontal scroller
buttons. If there's a different mouse configuration I'm supposed to be
using here, I'd love to hear it. I spent alot of time trying out various
configurations under the 2.6.10 to find one that made everything
(including the cruise control buttons, which still don't work quite
right... see: http://bugzilla.kernel.org/show_bug.cgi?id=1786 ) working.
Various software versions below.
> atrus@agaeris:~$ xdpyinfo | grep 'X.Org version'
> X.Org version: 6.8.1.902
> atrus@agaeris:~$ uname -a
> Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686
> GNU/Linux
--
Jeremy Nickurak <[email protected]>
Jeremy Nickurak <[email protected]> writes:
> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "evdev"
> Option "Device" "/dev/input/event-mx1000"
> Option "Buttons" "12"
> Option "ZAxisMapping" "11 12"
> Option "Resolution" "800"
> EndSection
Section "InputDevice" # MX1000
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "evdev"
Option "Dev Name" "Logitech USB Receiver" # cat /proc/bus/input/devices
Option "Dev Phys" "usb-0000:00:04.2-1/input0" # cat /proc/bus/input/devices
Option "Device" "/dev/input/event0" # (/dev/input/mice also appears to work)
Option "Buttons" "12"
Option "ZAxisMapping" "11 12"
Option "Resolution" "800"
EndSection
How did you get that /dev/input/event-mx1000?
> With an Xmodmap rule:
> pointer = 1 2 3 8 9 10 11 12 6 7 4 5
pointer = 1 2 3 6 7 8 9 10 11 12 4 5\n
which gives me..:
#1 = LMB
#2 = MMB
#3 = RMB
#4 = ROLL UP
#5 = ROLL DOWN
#6 = SIDE CLICK BACK
#7 = SIDE CLICK FORWARD
#8 = SIDE CLICK
#9 = TOP CLICK FORWARD
#10 = TOP CLICK BACK
#11 = HORIZONTAL LEFT
#12 = HORIZONTAL RIGHT
> This is to make sure that the scroll wheel shows up as 4/5
Mine too
> and that the horizontal scroll shows up as 6/7 which most software
> interprets as the left/right scroll buttons.
I got mine on 11/12, but what do you mean most software interprets
horizontal scroll as 6/7?. This has to be incorrect. It's logical that
horizontal directions turns up as 11/12 along with top clicks as 9/10
and side click 8 as these features/buttons were the last added to the
mouse.
> Scroll Left:
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935139, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x10, button 5, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x1010, button 5, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935267, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
KeyPress event, serial 26, synthetic YES, window 0x2800001,
root 0x48, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic YES, window 0x2800001,
root 0x48, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,
XLookupString gives 0 bytes:
ButtonRelease event, serial 29, synthetic NO, window 0x2800001,
root 0x48, subw 0x2800002, time 67867107, (35,38), root:(391,417),
state 0x0, button 12, same_screen YES
> And right:
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935915, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
>
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x10, button 4, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x810, button 4, same_screen YES
>
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
KeyPress event, serial 26, synthetic YES, window 0x2800001,
root 0x48, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic YES, window 0x2800001,
root 0x48, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
ButtonRelease event, serial 29, synthetic NO, window 0x2800001,
root 0x48, subw 0x2800002, time 68497761, (45,38), root:(424,440),
state 0x0, button 11, same_screen YES
> I'm being very careful not accidentally press the horizontal scroller
> buttons.
Why is that?
> [..] a different mouse configuration I'm supposed to be using [..]
We're obviously getting different data here from xev. You're using a
newer build, though. Are you running xbindkeys, btw?.
> the cruise control buttons, which still don't work quite
> right... see: http://bugzilla.kernel.org/show_bug.cgi?id=1786
I've never experienced this issue..!
> X.Org version: 6.8.1.902
6.8.1
> 2.6.11-rc3
2.6.11-rc3-RT-V0.7.38-06. I got the realtime patches.
For me, this is only a firefox issue now;). I got all buttons working
properly, but firefox got this damn issue. I'll do some thinking and
post to the firefox/mozilla mailinglist.
In firefox, btw, I got this setup:
#1 = LMB
#2 = MMB
#3 = RMB
#4 = ROLL UP - scroll manually down
#5 = ROLL DOWN - scroll manually down
#6 = SIDE CLICK BACK - back
#7 = SIDE CLICK FORWARD - forward
#8 = SIDE CLICK
#9 = TOP CLICK FORWARD - scroll up
#10 = TOP CLICK BACK - scroll down
#11 = HORIZONTAL LEFT - scroll left (firefox scrolls one cm to the left
and proceeds to scroll up)
#12 = HORIZONTAL RIGHT - scroll right (firefox scrolls one cm to the right
and proceeds to scroll down)
So, an issue with firefox.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
On mar, 2005-02-15 at 21:01 +0100, Esben Stien wrote:
> How did you get that /dev/input/event-mx1000?
A custom rule in /etc/udev/rules.d/00_logitech.rules:
> KERNEL="event*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/event-mx1000" SYMLINK="input/%k"
> KERNEL="mouse*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/mouse-mx1000" SYMLINK="input/%k"
gets event-mx1000 and mouse-mx1000 rules, with compatibility symlinks
for other configurations. This is basically so don't have to tell evdev
where exactly on the USB hierarchy the mouse is. (You'll note that my
xorg.conf lacks the Phys descriptor line). I can now plug my mouse into
different ports, or ports on a hub, and still have it work ok.
> > and that the horizontal scroll shows up as 6/7 which most software
> > interprets as the left/right scroll buttons.
>
> I got mine on 11/12, but what do you mean most software interprets
> horizontal scroll as 6/7?. This has to be incorrect. It's logical that
> horizontal directions turns up as 11/12 along with top clicks as 9/10
> and side click 8 as these features/buttons were the last added to the
> mouse.
This certainly seems to be the convention. Just like programs interpret
buttons 4 and 5 as vertical scrolling, they interpret 6 and 7 as the
horizontal scrollers. GTK, mozilla, galeon, and firefox all go by this
principal, so you don't actually need to use a program like xbindkeys to
fake keyboard events.
(Mozilla/galeon/firefox use the horizontal scroll for backward/foreward
by default. You can change this by setting
> mousewheel.horizscroll.withnokey.action = 0
> mousewheel.horizscroll.withnokey.numlines = 1
> mousewheel.horizscroll.withnokey.sysnumlines = true
in about:config. )
--
Jeremy Nickurak <[email protected]>
On Fri, Feb 11, 2005 at 08:50:12AM +0100, Jeremy Nickurak wrote:
> On ven, 2005-02-04 at 20:54 +0100, Vojtech Pavlik wrote:
> > Please try if 2.6.11-rc3 is any better.
>
> Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10.
> 2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the
> evdev driver as two seperate mouse buttons being pressed simultaneously.
The breakage introduced in 2.6.11-rc3 is still observed in 2.6.11. If in fact my configuration is wrong, I'd love to know how and why, as the configuration I'm using worked fine (with the exception of http://bugzilla.kernel.org/show_bug.cgi?id=1786 ) under 2.6.10:
> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "CorePointer"
> Option "Protocol" "evdev"
> Option "Dev Phys" "usb-0000:00:07.2-2.1/input0"
> Option "Device" "/dev/input/event-mx1000"
> Option "Buttons" "12"
> Option "ZAxisMapping" "11 12"
> Option "Resolution" "800"
> EndSection
With an Xmodmap rule:
> pointer = 1 2 3 8 9 10 11 12 6 7 4 5
This is to make sure that the scroll wheel shows up as 4/5 as expected,
and that the horizontal scroll shows up as 6/7, which most software
interprets as the left/right scroll buttons.
Xev says that the horizontal scrollers produce:
Scroll Left:
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935139, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x10, button 5, same_screen YES
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x1010, button 5, same_screen YES
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935267, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
And right:
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935915, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
> ButtonPress event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x10, button 4, same_screen YES
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x810, button 4, same_screen YES
> ButtonRelease event, serial 29, synthetic NO, window 0xe00001,
> root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
Various software versions below.
> atrus@agaeris:~$ xdpyinfo | grep 'X.Org version'
> X.Org version: 6.8.1.902
> atrus@agaeris:~$ uname -a
> Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686
> GNU/Linux
--
Jeremy Nickurak -= Email/Jabber: [email protected] =-
Remember, when you buy major label CD's, you're paying
companies to sue families and independant music. Learn
more now at downhillbattle.org.
Esben Stien <[email protected]> writes:
>> Please try if 2.6.11-rc3 is any better.
> Firefox gives me something strange, but the kernel issue is
> resolved.
Sorry, false report. 2.6.11-rc3 makes my tilt button show up as 2
buttons being pressed simultaneously, just like that previous report.
I also tried linux-2.6.11 today and it was the same.
It shows up as both button 4 and 12 being pressed simultaneously.
ButtonPress event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x1e00002, time 3916883, (28,38), root:(779,177),
state 0x0, button 12, same_screen YES
EnterNotify event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x0, time 3916883, (28,38), root:(779,177),
mode NotifyGrab, detail NotifyInferior, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 21, synthetic NO, window 0x0,
keys: 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ButtonPress event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x1e00002, time 3916907, (28,38), root:(779,177),
state 0x0, button 4, same_screen YES
ButtonRelease event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x1e00002, time 3916907, (28,38), root:(779,177),
state 0x800, button 4, same_screen YES
LeaveNotify event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x0, time 3916907, (28,38), root:(779,177),
mode NotifyUngrab, detail NotifyInferior, same_screen YES,
focus YES, state 0
ButtonRelease event, serial 21, synthetic NO, window 0x1e00001,
root 0x48, subw 0x1e00002, time 3917067, (28,38), root:(779,177),
state 0x0, button 12, same_screen YES
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
Jeremy Nickurak <[email protected]> writes:
> A custom rule in /etc/udev/rules.d/00_logitech.rules:
Nice.
> Just like programs interpret buttons 4 and 5 as vertical scrolling,
> they interpret 6 and 7 as the horizontal scrollers. GTK, mozilla,
> galeon, and firefox all go by this principal
Hmm, where is this defined in firefox?. It would be logical to assume that the side buttons for going back and forth would be 6/7 as the
> (Mozilla/galeon/firefox use the horizontal scroll for
> backward/foreward by default. You can change this by setting
> mousewheel.horizscroll.withnokey.action = 0
> mousewheel.horizscroll.withnokey.numlines = 1
> mousewheel.horizscroll.withnokey.sysnumlines = true
Hmm, mk, nice, I'll try that when evdev works properly.
Now I see I got the same problem as you. I get two buttons pressed
when using the tilt wheel. Check my other reply for xev output.
The issue is also present in linux-2.6.11
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
On sab, 2005-03-05 at 13:52 +0100, Esben Stien wrote:
>Sorry, false report. 2.6.11-rc3 makes my tilt button show up as 2
>buttons being pressed simultaneously, just like that previous report.
>
>I also tried linux-2.6.11 today and it was the same.
>
>It shows up as both button 4 and 12 being pressed simultaneously.
Right, this is just a result of our different xmodmap configurations.
Otherwise we're seeing exactly the same symptoms.
--
Jeremy Nickurak <[email protected]>
I worked around the weird two button thing by disabling cruise control.
Get logitecH-applet (http://freshmeat.net/projects/logitech_applet) and
run "logitech-applet -d".
It's a fairly useful app, and for other logitech mice it can put them
into 800 dpi mode, but it's not implemented for the MX1000. Anyone here
smart enough to figure something out?
Aaron Gyes
On sab, 2005-03-05 at 22:01 -0800, Aaron Gyes wrote:
>I worked around the weird two button thing by disabling cruise control.
Unfortunately:
1) This requires third-party software to work
2) This also disables the up/down scrolling cruise control buttons. The
buttons above and below the scroll wheel are supposed to not only be
remapped to buttons 4 and 5, but also have a auto-repeat added when held
down. (The same auto-repeat is also required by the horizontal
scrollers, unless it's to be dictated that user-space software needs to
apply their own repeat mechanism)
Jeremy Nickurak <[email protected]> writes:
> this is just a result of our different xmodmap configurations.
Yes.
> Otherwise we're seeing exactly the same symptoms.
Hmm, I'm getting the same hash for evdev.c between 2.6.10 and
2.6.11. I hope Vojtech Pavlik got the reports.
Is this reported as a bug?
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
Esben Stien <[email protected]> writes:
> Hmm, I'm getting the same hash for evdev.c between 2.6.10 and
> 2.6.11. I hope Vojtech Pavlik got the reports.
Ahh, I see he got lots of juicy patches lined up. I guess I'll try
linux-2.6.11-mm1 then.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[email protected]
On Mon, Mar 07, 2005 at 07:31:45PM +0100, Esben Stien wrote:
> Esben Stien <[email protected]> writes:
>
> > Hmm, I'm getting the same hash for evdev.c between 2.6.10 and
> > 2.6.11. I hope Vojtech Pavlik got the reports.
>
> Ahh, I see he got lots of juicy patches lined up. I guess I'll try
> linux-2.6.11-mm1 then.
I don't think I have a patch for the MX1000 among them. I do have the
MX1000, though, and I'm still thinking about what to do with it.
The problem is that the mouse really does reports all the double-button
stuff and autorepeat, and horizontal wheel together with button press on
wheel tilt.
It has all that in the report descriptor, and the HID driver correctly
interprets it and passes it on.
It's annoying, though.
I could kill the extra buttons (via a HID quirk), which would leave us
with autoscroll up/down/left/right, but the wheel wouldn't be
distinguishable from the autoscroll anymore.
I can't kill the autoscroll alone and leave the buttons, because again
the driver can't easily tell if it's the wheel or not.
In the end I think the best option is to leave the filtering to
userspace, which will mean more configuration necessary in the X event
mouse driver.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
>In the end I think the best option is to leave the filtering to
>userspace, which will mean more configuration necessary in the X event
>mouse driver.
Who needs to be contacted on the xorg/xfree86/other-x-implementation
sides to discuss how this should work?
Vojtech Pavlik <[email protected]> writes:
> I don't think I have a patch for the MX1000 among them. I do have the
> MX1000, though, and I'm still thinking about what to do with it.
;)
> The problem is that the mouse really does reports all the double-button
> stuff and autorepeat, and horizontal wheel together with button press on
> wheel tilt.
This is a terrible hardware flaw if it can't be controlled.
Isnt't there a unique sequence we can determine when the horizontal
wheel is tilted?. When I turn off cruise control, all my buttons work
flawlessly, but not getting the autorepeat data. This autorepeat data
occurs between button press and button release and could be easily
forged.
> It has all that in the report descriptor, and the HID driver correctly
> interprets it and passes it on.
We should manipulate this data when it arrives in the kernel, in my
opinion. It's a faulty device and we should present it to userspace as
working.
> It's annoying, though.
Yeah, very, considering the capabilities of this device.
> I could kill the extra buttons (via a HID quirk), which would leave us
> with autoscroll up/down/left/right, but the wheel wouldn't be
> distinguishable from the autoscroll anymore.
Not an option
> I can't kill the autoscroll alone and leave the buttons, because again
> the driver can't easily tell if it's the wheel or not.
I've killed the autoscroll by turning cruise control off; buttons work
then without auto repeat. I'm not sure what you mean here.
> In the end I think the best option is to leave the filtering to
> userspace, which will mean more configuration necessary in the X event
> mouse driver.
I hope this is not the final solution. I should be possible to disable
the data stream intervention if userspace wants to handle this, though.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:esben-stien.name
Vojtech Pavlik <[email protected]> writes:
> I'm still thinking about what to do with it.
You still thinking?.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:esben-stien.name
On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
> The problem is that the mouse really does reports all the double-button
> stuff and autorepeat, and horizontal wheel together with button press on
> wheel tilt.
Okay, I'm playing with this under 2.6.11.4 some more, and it really
seems out of whack. The vertical cruise control buttons work properly,
with the exception of the extra button press. But the horizontal buttons
are mapping to 6/7 as non-repeat buttons, and adding simulateously the
4/5 events auto-repeated for as long as the button is down. That is to
say, pressing the the horizontal scroll in a 2d scrolling area will
scroll *diagonally* one step, then vertically until the button is
released.
--
Jeremy Nickurak <[email protected]>
Jeremy Nickurak <[email protected]> writes:
> I'm playing with this under 2.6.11.4
I got 2.6.12-rc1
> The vertical cruise control buttons work properly, with the
> exception of the extra button press.
Yup, nice, I see the same
> But the horizontal buttons are mapping to 6/7 as non-repeat buttons,
> and adding simulateously the 4/5 events auto-repeated for as long as
> the button is down. That is to say, pressing the the horizontal
> scroll in a 2d scrolling area will scroll *diagonally* one step,
> then vertically until the button is released.
Yup, seeing exactly the same here.
--
Esben Stien is [email protected]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:esben-stien.name
Esben Stien <[email protected]> writes:
> Jeremy Nickurak <[email protected]> writes:
>
>> I'm playing with this under 2.6.11.4
>
> I got 2.6.12-rc1
>
>> The vertical cruise control buttons work properly, with the
>> exception of the extra button press.
>
> Yup, nice, I see the same
Same here.
>> But the horizontal buttons are mapping to 6/7 as non-repeat
>> buttons, and adding simulateously the 4/5 events auto-repeated for
>> as long as the button is down. That is to say, pressing the the
>> horizontal scroll in a 2d scrolling area will scroll *diagonally*
>> one step, then vertically until the button is released.
>
> Yup, seeing exactly the same here.
Horizontal scrolling works fine for me. I just get repeated 6/7
events, nothing else.
I'm using the configuration described at:
http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
Jeremy Nickurak <[email protected]> writes:
> On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
> > The problem is that the mouse really does reports all the double-button
> > stuff and autorepeat, and horizontal wheel together with button press on
> > wheel tilt.
>
> Okay, I'm playing with this under 2.6.11.4 some more, and it really
> seems out of whack. The vertical cruise control buttons work properly,
> with the exception of the extra button press. But the horizontal buttons
> are mapping to 6/7 as non-repeat buttons, and adding simulateously the
> 4/5 events auto-repeated for as long as the button is down. That is to
> say, pressing the the horizontal scroll in a 2d scrolling area will
> scroll *diagonally* one step, then vertically until the button is
> released.
Have you tried the Logitech mouse applet?
http://freshmeat.net/projects/logitech_applet/
"logitech_applet --disable-cc" used to work for me when I owned an
MX1000 mouse.
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On dim, 2005-04-03 at 18:01 +0200, Juergen Kreileder wrote:
> Esben Stien <[email protected]> writes:
>
> > Jeremy Nickurak <[email protected]> writes:
> >
> >> I'm playing with this under 2.6.11.4
> >
> > I got 2.6.12-rc1
> >
> >> The vertical cruise control buttons work properly, with the
> >> exception of the extra button press.
> >
> > Yup, nice, I see the same
>
> Same here.
>
> >> But the horizontal buttons are mapping to 6/7 as non-repeat
> >> buttons, and adding simulateously the 4/5 events auto-repeated for
> >> as long as the button is down. That is to say, pressing the the
> >> horizontal scroll in a 2d scrolling area will scroll *diagonally*
> >> one step, then vertically until the button is released.
> >
> > Yup, seeing exactly the same here.
>
> Horizontal scrolling works fine for me. I just get repeated 6/7
> events, nothing else.
>
> I'm using the configuration described at:
> http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/
Well that's a big step up. My horizontal scrolling is now working
perfectly. I had never in my life seen a ZAxisMapping line with 4
buttons, but it seems to do the trick, and it's even worked its way into
the mouse man page since the last time I remember seeing it. (Running
current Xorg here, can't speak for XFree86 users)
Now it's just the vertical scroller issue.
-
Jeremy Nickurak
Juergen Kreileder <[email protected]> writes:
> http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/
This did it. I got it completely working now. Both the horizontal and
the vertical cruise control is working with no problems. I'm scrolling
and I can't find a single problem with the device.
--
Esben Stien is [email protected]
http://www.
irc://irc. /%23contact
[sip|iax]:
jid:b0ef@
Jeremy Nickurak <[email protected]> writes:
> Now it's just the vertical scroller issue.
It's working perfectly here; just following that last link.
--
Esben Stien is [email protected]
http://www.
irc://irc. /%23contact
[sip|iax]:
jid:b0ef@
> This did it. I got it completely working now. Both the horizontal
> and the vertical cruise control is working with no problems. I'm
> scrolling and I can't find a single problem with the device.
Using these same instructions on Debian Unstable, with my
Thinkpad T42P (2373Q1U), this doesn't work at all. I only get
scrolling up/down and left/middle/right click, no horizontal
scrolling, and none of the other buttons seem to do much of anything.
I suspect the TP handles these events differently.
David A. Desrosiers
[email protected]
http://gnu-designs.com
Esben Stien <[email protected]> writes:
> can't find a single problem with the device.
I should mention a couple of things after some testing: There are some
inconsistencies with regard to cruise control.
When I press TOP CLICK BACKWARD/TOP CLICK FORWARD to cruise control
down/up, it waits about 100ms before it starts cruising. This means
that pressing a single click does not move me anywhere. I have to hold
the key down and wait until it starts cruising.
When I press HORIZONTAL LEFT/HORIZONTAL RIGHT to cruise control
left/right, it starts immediately going one step in the direction,
then waits about 100ms before it starts cruising left/right
again. This means that a single click takes me one click in the
horizontal direction.
The proper way of working in both horizontal and vertical direction
should be to start immediately going one of the directions. Also, a
single click should take me a single click in the respective
direction.
I still believe this is a kernel issue and the device should be
presented to userspace as a working device.
I'm using linux-2.6.12-rc1-RT-V0.7.41-15 with evdev and
xorg-6.8.1. (As a side note, remember to not enable radeon dri with
linux-2.6.12-rc1 as xorg will freeze)
I'll summarize my new setup:
I've turned off cruise control:
logitech_applet --disable-cc
This is my ~/.xbindkeysrc file: (yup, the whole one). Executing
xbindkeys with the -v switch yields useful debug info.
# "cruise control" disabled:
"true"
m:0x10 + b:11
"true"
m:0x10 + b:12
The ~/.Xmodmap file:
pointer = 1 2 3 8 9 10 11 12 6 7 4 5\n
In firefox:
mousewheel.horizscroll.withnokey.action = 0
mousewheel.horizscroll.withnokey.sysnumlines = true
Here's xorg: (I'll also setup the usb settings from Jeremy Nickurak,
but they are not important here and now).
Section "InputDevice" # Logitech MX1000
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "evdev"
Option "Dev Name" "Logitech USB Receiver" # cat /proc/bus/input/devices
Option "Dev Phys" "usb-0000:00:04.2-1/input0" # cat /proc/bus/input/devices
Option "Device" "/dev/input/event0" # (/dev/input/mice also appears to work)
Option "Buttons" "12"
Option "ZAxisMapping" "11 12 10 9"
Option "Emulate3Buttons" "false"
Option "Resolution" "800"
Option "SampleRate" "800"
EndSection
I'll do a mapping of how the keys correspond to key numbers in another
followup as I'm about to leave.
--
Esben Stien is [email protected]
http://www.
irc://irc. /%23contact
[sip|iax]:
jid:b0ef@
"David A. Desrosiers" <[email protected]> writes:
> Using these same instructions [..] doesn't work at all
This is too little information to work with. Please be more specific
as to what you've done.
--
Esben Stien is [email protected]
http://www.
irc://irc. /%23contact
[sip|iax]:
jid:b0ef@
Esben Stien <[email protected]> writes:
> "David A. Desrosiers" <[email protected]> writes:
>
>> Using these same instructions [..] doesn't work at all
>
> This is too little information to work with. Please be more specific
> as to what you've done.
I've looked at his configuration a bit, it's maybe an X bug. I've
only tried using the MX1000 standalone, there might be some issues
when using multiple pointer devices with different button counts at
the same time (e.g. normal 3 button mouse + 12 button MX1000).
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
Esben Stien <[email protected]> writes:
> Esben Stien <[email protected]> writes:
>
>> can't find a single problem with the device.
>
> I should mention a couple of things after some testing: There are
> some inconsistencies with regard to cruise control.
>
> When I press TOP CLICK BACKWARD/TOP CLICK FORWARD to cruise control
> down/up, it waits about 100ms
The pause is actually generated by the device, probably to make single
step scrolling easier.
> before it starts cruising. This means that pressing a single click
> does not move me anywhere. I have to hold the key down and wait
> until it starts cruising.
That's a problem with xbindkeys. Without xbindkeys, the X events are
(p = press, r = release)
p 11/12, p 4/5, r 4/5, ( <pause>, ( p 4/5, r 4/5 )* )?, r 11/12
As the 11/12 events are a bit annoying (Mozilla, but not Firefox,
interprets them as a left click), I use xbindkeys to bind them to
nothing. But xbindkeys seems to have problems with the press 11/12
and release 11/12 events being interrupted by 4/5 events, it eats
everything before the pause =>
( <pause>, ( p 4/5, r 4/5 )* )?, r 11/12
> When I press HORIZONTAL LEFT/HORIZONTAL RIGHT to cruise control
> left/right, it starts immediately going one step in the direction,
> then waits about 100ms before it starts cruising left/right
> again. This means that a single click takes me one click in the
> horizontal direction.
For horizontal scrolling I see:
p 6/7, r 6/7, ( <pause>, ( p 6/7, r 6/7 )* )?
That's OK with me. If vertical scrolling would work the same way
(ie. without the additional 11/12 events), I'd be happy.
Anyhow, this looks a problem with X not the kernel. evtest shows that
the device reports similar event sequences for tilting the wheel and
the cruise control buttons.
E.g. scrolling left by tilting the wheel:
,----
| Event: time 1112723029.967722, type 1 (Key), code 280 (?), value 1
| Event: time 1112723029.967729, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723029.983709, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723029.983715, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.359712, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723030.359719, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.463706, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723030.463715, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.551708, type 1 (Key), code 280 (?), value 0
| Event: time 1112723030.551712, type 0 (Reset), code 0 (Reset), value 0
`----
and scrolling down with the cruise controll button:
,----
| Event: time 1112723159.628081, type 1 (Key), code 279 (?), value 1
| Event: time 1112723159.628090, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723159.644084, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723159.644091, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.020068, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723160.020075, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.124067, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723160.124075, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.212060, type 1 (Key), code 279 (?), value 0
`----
Note the 280 and 279 events at the start and end.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
On mar, 2005-04-05 at 16:56 +0200, Esben Stien wrote:
> Esben Stien <[email protected]> writes:
>
> > can't find a single problem with the device.
>
> I should mention a couple of things after some testing: There are some
> inconsistencies with regard to cruise control.
>
> When I press TOP CLICK BACKWARD/TOP CLICK FORWARD to cruise control
> down/up, it waits about 100ms before it starts cruising. This means
> that pressing a single click does not move me anywhere. I have to hold
> the key down and wait until it starts cruising.
This is probabbly because you're using the referenced xbindkeys trick to
delete the button11/12 event. Unfortunately, binding 11/12 while cruise
control is enabled also obscures the first scroll event.
The horrible-ugly-very-nasty-workaround is to bind that event to a
command that re-simulates the up/down click. I've attached a piece of C
code that'll do that. ('./click 4' will simulate button 4 going up and
down.)
> >
> > # "cruise control" disabled:
> > "~/click/click 4"
> > m:0x10 + b:11
> > "~/click/click 5"
> > m:0x10 + b:12
I'm sort of guessing at the xbindkeys setting for this. Myself, i've
performed this bind event in my openbox configuration.
This still doesn't catch the button 11/12 mouse-up event, although that
doesn't seem to bother many applications