Re: Swap partition vs swap file
On ven, 2005-07-08 at 03:22 +0200, Bernd Eckenfels wrote: > No, it is creating files by appending just like any other file write. One > could think about a call to create unfragmented files however since this is > not always working best is to create those files young or defragment them > before usage. Except that this defeats one of the biggest advantages a swap file has over a swap partition: the ability to easilly reconfigure the amount of hd space reserved for swap. -- Jeremy Nickurak <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Swap partition vs swap file
On ven, 2005-07-08 at 03:22 +0200, Bernd Eckenfels wrote: No, it is creating files by appending just like any other file write. One could think about a call to create unfragmented files however since this is not always working best is to create those files young or defragment them before usage. Except that this defeats one of the biggest advantages a swap file has over a swap partition: the ability to easilly reconfigure the amount of hd space reserved for swap. -- Jeremy Nickurak [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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
click.tgz
Description: application/compressed-tar
signature.asc
Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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
click.tgz
Description: application/compressed-tar
signature.asc
Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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 signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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 signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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]> signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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] signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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? signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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? signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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) signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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) signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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]> signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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-: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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150), > state 0x10, button 7, same_screen YES Various software versions below. > [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version' > X.Org version: 6.8.1.902 > [EMAIL PROTECTED]:~$ 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. signature.asc Description: Digital signature
Re: Logitech MX1000 Horizontal Scrolling
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 OptionDev Phys usb-:00:07.2-2.1/input0 Option Device /dev/input/event-mx1000 Option Buttons 12 OptionZAxisMapping 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150), state 0x10, button 7, same_screen YES Various software versions below. [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version' X.Org version: 6.8.1.902 [EMAIL PROTECTED]:~$ 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. signature.asc Description: Digital signature
Re: Logitech MX1000 Horizontal Scrolling
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]>
signature.asc
Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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]
signature.asc
Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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 0xe1, > 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. > [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version' > X.Org version: 6.8.1.902 > [EMAIL PROTECTED]:~$ uname -a > Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686 > GNU/Linux -- Jeremy Nickurak <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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 0xe1, 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. [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version' X.Org version: 6.8.1.902 [EMAIL PROTECTED]:~$ uname -a Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686 GNU/Linux -- Jeremy Nickurak [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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). signature.asc Description: This is a digitally signed message part
Re: Logitech MX1000 Horizontal Scrolling
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). signature.asc Description: This is a digitally signed message part
Logitech MX-Series "Cruise Control" buttons
I recently posted an update to http://bugme.osdl.org/show_bug.cgi?id=1786 that shows the bug escalating on newer hardware, such that there is no user-accessable workaround. It seem that where an MX-series mouse's cruise-control buttons are concerned, the mouse (by default) produces two events for each button press: The button itself, as well as a scroll event simulating a keyboard-style press-delay-repeat cycle on the scroll wheel axis/buttons. Utilities such as logitech_applet (unmaintained afaict) seem to be able to change some settings. For example, on my MX1000 mouse it's able to disable the cruise-control scroll button simulation, which would allow me to use the buttons as ordinary mouse buttons. What I'd love to do is to be able to disable the button's native function and use *only* the cruise-control function, as the mouse was intended. If such a hardware reconfiguration is not possible, perhaps it would be easier to leave the mouse in the default configuration, but filter one event or the other before it reaches userspace? Or is it more natural to filter out the mouse's scroll-simulation, and do a mapping & key-repeat simulation in userspace somewhere? Please CC me in replies. -- Jeremy Nickurak -= Email: [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. signature.asc Description: Digital signature
Logitech MX-Series Cruise Control buttons
I recently posted an update to http://bugme.osdl.org/show_bug.cgi?id=1786 that shows the bug escalating on newer hardware, such that there is no user-accessable workaround. It seem that where an MX-series mouse's cruise-control buttons are concerned, the mouse (by default) produces two events for each button press: The button itself, as well as a scroll event simulating a keyboard-style press-delay-repeat cycle on the scroll wheel axis/buttons. Utilities such as logitech_applet (unmaintained afaict) seem to be able to change some settings. For example, on my MX1000 mouse it's able to disable the cruise-control scroll button simulation, which would allow me to use the buttons as ordinary mouse buttons. What I'd love to do is to be able to disable the button's native function and use *only* the cruise-control function, as the mouse was intended. If such a hardware reconfiguration is not possible, perhaps it would be easier to leave the mouse in the default configuration, but filter one event or the other before it reaches userspace? Or is it more natural to filter out the mouse's scroll-simulation, and do a mapping key-repeat simulation in userspace somewhere? Please CC me in replies. -- Jeremy Nickurak -= Email: [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. signature.asc Description: Digital signature
