[PATCH] don't invert mightymouse hwheel

[PATCH] don't invert mightymouse hwheel

[Johannes Berg]

Commit a82e49b8aeb9f8dafdf6cf2e617c8b95bf056257 said:

    Further, the quirks for the Apple Mighty Mouse are not quite right: the
    horizontal scrolling needs its axis reversed, and the left and center
    buttons are transposed.

This is not true. With this X configuration:

    Section "InputDevice"
        Identifier  "EvDev"
        Driver      "evdev"
        Option      "SendCoreEvents"    "true"
        Option      "evBits"            "+1-2"
        Option      "keyBits"           "~272-287"
        Option      "relBits"           "~0-2 ~6 ~8"
        Option      "Pass"              "3"
    EndSection

I can scroll up in a window by moving my finger up, and scroll left in a
window by moving my finger right. That makes no sense, this patch therefore
removes the INVERT_HWHEEL quirk from the USB mightymouse.

I didn't change the bluetooth mightymouse, maybe it has this quirk after
all. My USB one definitely doesn't. If the bluetooth version doesn't have
that quirk either, we can completely remove the INVERT_HWHEEL quirk.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Bart Massey <bart@cs.pdx.edu>
Cc: Antonio-M. Corbi Bellot <antonio.corbi@ua.es>

---
 drivers/usb/input/hid-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- wireless-dev.orig/drivers/usb/input/hid-core.c	2007-04-12 00:09:17.754507072 +0200
+++ wireless-dev/drivers/usb/input/hid-core.c	2007-04-12 00:09:25.334507072 +0200
@@ -898,7 +898,7 @@ static const struct hid_blacklist {
 	{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_DUAL_USB_JOYPAD, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 	{ USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SMARTJOY_DUAL_PLUS, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 
-	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE, HID_QUIRK_MIGHTYMOUSE | HID_QUIRK_INVERT_HWHEEL },
+	{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE, HID_QUIRK_MIGHTYMOUSE },
 	{ USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU, HID_QUIRK_2WHEEL_MOUSE_HACK_7 },
 	{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE, HID_QUIRK_2WHEEL_MOUSE_HACK_5 },
 

Re: [PATCH] don't invert mightymouse hwheel

[Jiri Kosina]

On Thu, 12 Apr 2007, Johannes Berg wrote:

> This is not true. With this X configuration:
> 
>     Section "InputDevice"
>         Identifier  "EvDev"
>         Driver      "evdev"
>         Option      "SendCoreEvents"    "true"
>         Option      "evBits"            "+1-2"
>         Option      "keyBits"           "~272-287"
>         Option      "relBits"           "~0-2 ~6 ~8"
>         Option      "Pass"              "3"
>     EndSection
> I can scroll up in a window by moving my finger up, and scroll left in a
> window by moving my finger right. That makes no sense, this patch therefore
> removes the INVERT_HWHEEL quirk from the USB mightymouse.

Johannes, Bart, 

I unfortunately don't have the hardware in question to test with. This X 
configuration is of course perfectly valid.

Bart, as you wrote the original patch which inverted the wheel, could you 
provide some more information please? It seems to me that you guys have 
different versions of mightymouse ... but I wouldn't believe they would 
have the same PID :)

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

In message <Pine.LNX.4.64.0704121800000.19492@jikos.suse.cz> you wrote:
> On Thu, 12 Apr 2007, Johannes Berg wrote:
> 
> > This is not true. With this X configuration:
> > 
> >     Section "InputDevice"
> >         Identifier  "EvDev"
> >         Driver      "evdev"
> >         Option      "SendCoreEvents"    "true"
> >         Option      "evBits"            "+1-2"
> >         Option      "keyBits"           "~272-287"
> >         Option      "relBits"           "~0-2 ~6 ~8"
> >         Option      "Pass"              "3"
> >     EndSection
> > I can scroll up in a window by moving my finger up, and scroll left in a
> > window by moving my finger right. That makes no sense, this patch therefore
> > removes the INVERT_HWHEEL quirk from the USB mightymouse.
> 
> Johannes, Bart, 
> 
> I unfortunately don't have the hardware in question to test with. This X 
> configuration is of course perfectly valid.
> 
> Bart, as you wrote the original patch which inverted the wheel, could you 
> provide some more information please? It seems to me that you guys have 
> different versions of mightymouse ... but I wouldn't believe they would 
> have the same PID :)

Give me a day or so to check all this out.  I don't think
looking at the X behavior is too useful: too many place that
the direction can be swapped.  Instead, look which way the
bits coming directly out of evdev point.  IIRC I set things
up so that positive X was the same as on other evdev
devices.  Is the supplied X config swapping the X axis with
this line?

  > >         Option      "evBits"            "+1-2"

One possible source of confusion is that Iceweasel scrolls
backward by default (on all devices, not just MM).  You can
fix this by changing a setting in the Iceweasel config.

	Bart

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

--------
> In message <Pine.LNX.4.64.0704121800000.19492@jikos.suse.cz> I wrote:
> > On Thu, 12 Apr 2007, Johannes Berg wrote:
> > 
> > > This is not true. With this X configuration:
> > > 
> > >     Section "InputDevice"
> > >         Identifier  "EvDev"
> > >         Driver      "evdev"
> > >         Option      "SendCoreEvents"    "true"
> > >         Option      "evBits"            "+1-2"
> > >         Option      "keyBits"           "~272-287"
> > >         Option      "relBits"           "~0-2 ~6 ~8"
> > >         Option      "Pass"              "3"
> > >     EndSection
> > > I can scroll up in a window by moving my finger up, and scroll left in a
> > > window by moving my finger right. That makes no sense, this patch therefore
> > > removes the INVERT_HWHEEL quirk from the USB mightymouse.
> > 
> > I unfortunately don't have the hardware in question to test with. This X 
> > configuration is of course perfectly valid.
> > 
> > Bart, as you wrote the original patch which inverted the wheel, could you 
> > provide some more information please? It seems to me that you guys have 
> > different versions of mightymouse ... but I wouldn't believe they would 
> > have the same PID :)
> 
> Give me a day or so to check all this out.  I don't think
> looking at the X behavior is too useful: too many places that
> the direction can be swapped.  Instead, look which way the
> bits coming directly out of evdev point.  IIRC I set things
> up so that positive X was the same as on other evdev
> devices.  Is the supplied X config swapping the X axis with
> this line?
> 
>   > >         Option      "evBits"            "+1-2"
> 
> One possible source of confusion is that Iceweasel scrolls
> backward by default (on all devices, not just MM).  You can
> fix this by changing a setting in the Iceweasel config.

After checking further I've found that my memory is correct.
With the patch as I originally submitted it (including the
INVERT_HWHEEL quirk):

  1) Moving the scroll ball to the right sends positive
     deltas (to /dev/input/event*), and moving it to the
     left sends negative deltas.  This is the same as the
     mouse itself, of course.

  2) You can use an xorg.conf entry as simple as

	Section "InputDevice"
	  Identifier  "MouseMightyMouse0"
	  Driver      "mouse"
	  Option      "Device" "/dev/input/mouse1"
	  Option      "Dev Name" "Mitsumi Electric Apple Optical USB Mouse"
	EndSection
				
  3) X SW (other than Iceweasel, which has the misfeature
     described earlier) just works properly.

Please don't remove the axis flip on the MM; it seems like
something most folks, including me, are quite happy with.
Instead, I'd suggest to Johannes that simplifying his X
config and/or fixing his Iceweasel config will straighten
his situation out.  (Most of that config is unnecessary at
best anyhow; I got all the button remaps right in my
original patch.)

These results are for the USB MM.  I have a Bluetooth MM
now, and am trying to find time to get it working also.
Sorry I haven't had time to do that yet.  Soon, honest.

    Bart Massey
    Assoc. Prof. Computer Science
    Portland State University
    bart@cs.pdx.edu

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

--------
I wrote:

> 	Section "InputDevice"
> 	  Identifier  "MouseMightyMouse0"
> 	  Driver      "mouse"
> 	  Option      "Device" "/dev/input/mouse1"
> 	  Option      "Dev Name" "Mitsumi Electric Apple Optical USB Mouse"
> 	EndSection

Oops---thinko.  The config I'm actually using is

  Section "InputDevice"
    Identifier  "EvMightyMouse0"
    Driver "evdev"
    Option "Name" "Mitsumi Electric Apple Optical USB Mouse"
  EndSection

Sorry for the confusion.

	Bart

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote:

> > I unfortunately don't have the hardware in question to test with. This X 
> > configuration is of course perfectly valid.

I copied it straight out of the manpage so I'd hope so :>

> Give me a day or so to check all this out.  I don't think
> looking at the X behavior is too useful: too many place that
> the direction can be swapped.  Instead, look which way the
> bits coming directly out of evdev point.

I can do that (early next week), but I don't have any other devices to
test with. Can provide a dump.

> IIRC I set things
> up so that positive X was the same as on other evdev
> devices.  Is the supplied X config swapping the X axis with
> this line?
> 
>   > >         Option      "evBits"            "+1-2"

No idea! I just copied it out of the manpage from evdev(4)

> One possible source of confusion is that Iceweasel scrolls
> backward by default (on all devices, not just MM).  You can
> fix this by changing a setting in the Iceweasel config.

I didn't use Iceweasel but GTK.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Thu, 2007-04-12 at 17:21 -0700, Barton C Massey wrote:

> After checking further I've found that my memory is correct.
> With the patch as I originally submitted it (including the
> INVERT_HWHEEL quirk):
> 
>   1) Moving the scroll ball to the right sends positive
>      deltas (to /dev/input/event*), and moving it to the
>      left sends negative deltas.  This is the same as the
>      mouse itself, of course.
> 
>   2) You can use an xorg.conf entry as simple as
> 
> 	Section "InputDevice"
> 	  Identifier  "MouseMightyMouse0"
> 	  Driver      "mouse"
> 	  Option      "Device" "/dev/input/mouse1"
> 	  Option      "Dev Name" "Mitsumi Electric Apple Optical USB Mouse"
> 	EndSection
> 				
>   3) X SW (other than Iceweasel, which has the misfeature
>      described earlier) just works properly.
> 
> Please don't remove the axis flip on the MM; it seems like
> something most folks, including me, are quite happy with.

Alright, I'll talk to the X folks about including an axis flip in the
evdev manpage or something. Or maybe GTK is inverting my axis... Thanks
for investigating.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Jiri Kosina]

On Thu, 12 Apr 2007, Barton C Massey wrote:

> These results are for the USB MM.  I have a Bluetooth MM now, and am 
> trying to find time to get it working also. Sorry I haven't had time to 
> do that yet.  Soon, honest.

Bart,

thanks for the information.

Regarding the Bluetooth mouse - I have a bug in bugzilla stating that the 
Bluetooth version of the mightymouse requires the very same quirky 
handling as the USB version. Now that bluetooth and USB are hooked to the 
same common HID layer, this is pretty easy thing to do.

Mainline kernel already contains the quirk for Bluetooth mouse, since 
2.6.21-rc6. It would be nice if you could verify that the Bluetooth 
version works fine with this kernel (or any newer).

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Thu, 2007-04-12 at 17:21 -0700, Barton C Massey wrote:

>   1) Moving the scroll ball to the right sends positive
>      deltas (to /dev/input/event*), and moving it to the
>      left sends negative deltas.  This is the same as the
>      mouse itself, of course.

My regular mouse sends positive deltas on "move finger up". That means
with positive right too we'd have a coordinate system rooted at the
lower left of the screen which makes sense. I better fix my X config
then :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

In message <Pine.LNX.4.64.0704130940190.19492@jikos.suse.cz> you wrote:
> On Thu, 12 Apr 2007, Barton C Massey wrote:
> 
> > These results are for the USB MM.  I have a Bluetooth MM now, and am 
> > trying to find time to get it working also. Sorry I haven't had time to 
> > do that yet.  Soon, honest.
> 
> Regarding the Bluetooth mouse - I have a bug in bugzilla stating that the 
> Bluetooth version of the mightymouse requires the very same quirky 
> handling as the USB version. Now that bluetooth and USB are hooked to the 
> same common HID layer, this is pretty easy thing to do.
> 
> Mainline kernel already contains the quirk for Bluetooth mouse, since 
> 2.6.21-rc6. It would be nice if you could verify that the Bluetooth 
> version works fine with this kernel (or any newer).

I just tried out the Bluetooth MM with 2.6.20.4 plus the
bluez patches.  Everything seemed to work fine.  (Actually,
it was horribly slow and laggy, but all the buttons and
knobs worked and made things go in the right directions and
stuff.  I'm hoping my USB BT dongle just sucks.)  I don't
know if 2.6.21-rc6 is flipped from 2.6.20.4, though :-).
I'll try to grab a newer kernel eventually.

	Bart

Re: [PATCH] don't invert mightymouse hwheel

[Jiri Kosina]

On Mon, 23 Apr 2007, Barton C Massey wrote:

> I just tried out the Bluetooth MM with 2.6.20.4 plus the bluez patches.  
> Everything seemed to work fine.  (Actually, it was horribly slow and 
> laggy, but all the buttons and knobs worked and made things go in the 
> right directions and stuff.  I'm hoping my USB BT dongle just sucks.)  
> I don't know if 2.6.21-rc6 is flipped from 2.6.20.4, though :-). I'll 
> try to grab a newer kernel eventually.

This is strange, I have a bugreport in our bugzilla which states that BT 
version of the mightymouse needs the very same quirk as USB version. 
Recent kernels contain a duplication of the USB quirk for Bluetooth 
version of the mouse, in order to make the scrollwheel work. But 
2.6.20.4+bluez patches don't provide this quirk yet.

What product/vendor ids does your mightymouse have?

Thanks,

-- 
Jiri Kosina

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Mon, 2007-04-23 at 15:13 +0200, Jiri Kosina wrote:

> This is strange, I have a bugreport in our bugzilla which states that BT 
> version of the mightymouse needs the very same quirk as USB version. 
> Recent kernels contain a duplication of the USB quirk for Bluetooth 
> version of the mouse, in order to make the scrollwheel work. But 
> 2.6.20.4+bluez patches don't provide this quirk yet.

Same problem I had maybe with X or GTK or something flipping the axis?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Jiri Kosina]

On Mon, 23 Apr 2007, Johannes Berg wrote:

> > This is strange, I have a bugreport in our bugzilla which states that 
> > BT version of the mightymouse needs the very same quirk as USB 
> > version. Recent kernels contain a duplication of the USB quirk for 
> > Bluetooth version of the mouse, in order to make the scrollwheel work. 
> > But 2.6.20.4+bluez patches don't provide this quirk yet.
> Same problem I had maybe with X or GTK or something flipping the axis?

Hi Johannes,

no, that's not the case, the bugreport states that scrolling the wheel 
produces no input events at all, i.e. mapping of HID_GD_Z to REL_HWHEEL 
(HID_QUIRK_MIGHTYMOUSE quirk) is needed.

-- 
Jiri Kosina

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Mon, 2007-04-23 at 16:07 +0200, Jiri Kosina wrote:

> no, that's not the case, the bugreport states that scrolling the wheel 
> produces no input events at all, i.e. mapping of HID_GD_Z to REL_HWHEEL 
> (HID_QUIRK_MIGHTYMOUSE quirk) is needed.

Good point, strange. Well, that remapping doesn't hurt if it never
reports HID_GD_Z. Maybe OSX does it and they produced too version, I
could try to find out...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Zephaniah E. Hull]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Fri, Apr 13, 2007 at 08:40:18AM +0200, Johannes Berg wrote:
> On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote:
> 
> > > I unfortunately don't have the hardware in question to test with. This X 
> > > configuration is of course perfectly valid.
> 
> I copied it straight out of the manpage so I'd hope so :>
> 
> > Give me a day or so to check all this out.  I don't think
> > looking at the X behavior is too useful: too many place that
> > the direction can be swapped.  Instead, look which way the
> > bits coming directly out of evdev point.
> 
> I can do that (early next week), but I don't have any other devices to
> test with. Can provide a dump.
> 
> > IIRC I set things
> > up so that positive X was the same as on other evdev
> > devices.  Is the supplied X config swapping the X axis with
> > this line?
> > 
> >   > >         Option      "evBits"            "+1-2"
> 
> No idea! I just copied it out of the manpage from evdev(4)

As the xf86-input-evdev maintainer, I can tell you quite firmly that the
answer is a solid no.

However I can also tell you that I may infact have the behavior
backwards in the driver. :)

Yell, scream, and shout if that's the case.

Zephaniah E. Hull.


-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

If I have trouble installing Linux, something is wrong. Very wrong.
  -- Linus Torvalds on l-k.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

As far as I can tell you have it right, all the way up the
stack for me.  There's so many places it can get flipped,
though, that it's hard to tell.

	Bart

In message <20070425200650.GE4831@aehallh.com> you wrote:
> 
> --bajzpZikUji1w+G9
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Fri, Apr 13, 2007 at 08:40:18AM +0200, Johannes Berg wrote:
> > On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote:
> > 
> > > > I unfortunately don't have the hardware in question to test with. This X 
> > > > configuration is of course perfectly valid.
> > 
> > I copied it straight out of the manpage so I'd hope so :>
> > 
> > > Give me a day or so to check all this out.  I don't think
> > > looking at the X behavior is too useful: too many place that
> > > the direction can be swapped.  Instead, look which way the
> > > bits coming directly out of evdev point.
> > 
> > I can do that (early next week), but I don't have any other devices to
> > test with. Can provide a dump.
> > 
> > > IIRC I set things
> > > up so that positive X was the same as on other evdev
> > > devices.  Is the supplied X config swapping the X axis with
> > > this line?
> > > 
> > >   > >         Option      "evBits"            "+1-2"
> > 
> > No idea! I just copied it out of the manpage from evdev(4)
> 
> As the xf86-input-evdev maintainer, I can tell you quite firmly that the
> answer is a solid no.
> 
> However I can also tell you that I may infact have the behavior
> backwards in the driver. :)
> 
> Yell, scream, and shout if that's the case.
> 
> Zephaniah E. Hull.
> 
> 
> -- 
> 	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
> 	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
> 	    CCs of replies from mailing lists are requested.
> 
> If I have trouble installing Linux, something is wrong. Very wrong.
>   -- Linus Torvalds on l-k.
> 
> --bajzpZikUji1w+G9
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFGL7TaRFMAi+ZaeAERAvrAAJ9SbwKUwtHslgyE2aUESD1diHt4yQCg3p1i
> XqAtCSNKgyqhk2OzuppMbOQ=
> =F7/i
> -----END PGP SIGNATURE-----
> 
> --bajzpZikUji1w+G9--

Re: [PATCH] don't invert mightymouse hwheel

[Zephaniah E. Hull]

[-- Attachment #1: Type: text/plain, Size: 3943 bytes --]

Alright, note that at the moment there is no way to invert it except
with xmodmap. (Since they get mapped as buttons, you can swap them there
in a trivial fashion.  If you're already swapping because you're left
handed, it's even easier.)

At the moment, we map positive hwheel to 6, and negative to 7.

We also map positive wheel to 4, and negative to 5, so that fits.

Once xf86-input-evdev is rewritten for the xserver input-hotplug, it
will be a complete config file rewrite, but it will allow lots of really
funky mapping that currently isn't supported.

(It's 1.2.x, first with the old author was 1.0.x, 1.1.x broke everything
but worked so much better it wasn't funny.  1.2.x with the right server
hotplug code (which I'll write if I have to, urgh) should be a similar
improvement.)

Zephaniah E. Hull.

On Wed, Apr 25, 2007 at 04:09:27PM -0700, Barton C Massey wrote:
> As far as I can tell you have it right, all the way up the
> stack for me.  There's so many places it can get flipped,
> though, that it's hard to tell.
> 
> 	Bart
> 
> In message <20070425200650.GE4831@aehallh.com> you wrote:
> > 
> > --bajzpZikUji1w+G9
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > 
> > On Fri, Apr 13, 2007 at 08:40:18AM +0200, Johannes Berg wrote:
> > > On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote:
> > > 
> > > > > I unfortunately don't have the hardware in question to test with. This X 
> > > > > configuration is of course perfectly valid.
> > > 
> > > I copied it straight out of the manpage so I'd hope so :>
> > > 
> > > > Give me a day or so to check all this out.  I don't think
> > > > looking at the X behavior is too useful: too many place that
> > > > the direction can be swapped.  Instead, look which way the
> > > > bits coming directly out of evdev point.
> > > 
> > > I can do that (early next week), but I don't have any other devices to
> > > test with. Can provide a dump.
> > > 
> > > > IIRC I set things
> > > > up so that positive X was the same as on other evdev
> > > > devices.  Is the supplied X config swapping the X axis with
> > > > this line?
> > > > 
> > > >   > >         Option      "evBits"            "+1-2"
> > > 
> > > No idea! I just copied it out of the manpage from evdev(4)
> > 
> > As the xf86-input-evdev maintainer, I can tell you quite firmly that the
> > answer is a solid no.
> > 
> > However I can also tell you that I may infact have the behavior
> > backwards in the driver. :)
> > 
> > Yell, scream, and shout if that's the case.
> > 
> > Zephaniah E. Hull.
> > 
> > 
> > -- 
> > 	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
> > 	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
> > 	    CCs of replies from mailing lists are requested.
> > 
> > If I have trouble installing Linux, something is wrong. Very wrong.
> >   -- Linus Torvalds on l-k.
> > 
> > --bajzpZikUji1w+G9
> > Content-Type: application/pgp-signature; name="signature.asc"
> > Content-Description: Digital signature
> > Content-Disposition: inline
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > 
> > iD8DBQFGL7TaRFMAi+ZaeAERAvrAAJ9SbwKUwtHslgyE2aUESD1diHt4yQCg3p1i
> > XqAtCSNKgyqhk2OzuppMbOQ=
> > =F7/i
> > -----END PGP SIGNATURE-----
> > 
> > --bajzpZikUji1w+G9--
> 

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

}>No.  I just point out to troublemakers that I have an English degree,
}>which means that I am allowed to make changes to the English language.
}>(What _else_ could it possibly be for?)
}Wow; in that case, my physics degree is *WAY* more useful than I
}had thought.
This just proves how useless a computer science degree is:  there is hardly
any useful science involved at all.  I want my computer black magic degree!
	-- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

On Thu, 2007-04-12 at 17:21 -0700, Barton C Massey wrote:

>   2) You can use an xorg.conf entry as simple as

[as corrected by your subsequent mail]

>   Section "InputDevice"
>     Identifier  "EvMightyMouse0"
>     Driver "evdev"
>     Option "Name" "Mitsumi Electric Apple Optical USB Mouse"
>   EndSection

The only way I've been able to make it work with evdev is this:
 
Section "InputDevice"
        Identifier      "EvDev"
        Driver          "evdev"
        Option          "SendCoreEvents"        "true"
        Option          "evBits"                "+1-2"
        Option          "keyBits"               "~272-287"
        Option          "relBits"               "~0-2 ~6 ~8"
        Option          "Pass"                  "3"
#(optional)
#       Option          "WHEELRelativeAxisButtons"      "4 5"
        Option          "HWHEELRelativeAxisButtons"     "7 6"
EndSection

(You use Name to match, I used the *Bits stuff but that doesn't matter,
I tried your version too, albeit with SendCoreEvents or I get nothing at
all)

This seems really strange since we both use the evdev driver and all I
do is some matching on which devices are allowed. What version of evdev
are you using? It surely wasn't built before Jan 2005, was it? :)

Oh and before I forget to ask this, are you using a big or little endian
machine? I've had stupid input layer endianness bugs because the kernel
exports the bits there in a strange way... The changelog indicates it
was fixed in May 2006 for evdev though.

What programs are you using for testing? In xev now, I get:
move finger up: button 4
move finger down: button 5
move finger left: button 6
move finger right: button 7

Is that wrong? It seems to indicate that the coordinate system is rooted
at the upper left corner which seems sane. But this is with the
inversion programmed into my X config.

I can live with this inversion in there, but it seems very strange that
the same hardware and same driver should give different results for you
and me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] don't invert mightymouse hwheel

[Barton C Massey]

In message <20070426000037.GF4831@aehallh.com> you wrote:
> Alright, note that at the moment there is no way to invert it except
> with xmodmap. (Since they get mapped as buttons, you can swap them there
> in a trivial fashion.  If you're already swapping because you're left
> handed, it's even easier.)

The six places that an axis can be flipped are:

   1. By the input driver
   2. By the evdev code
   3. By the X evdev driver
   4. By the xmodmap event mapping
   5. By the toolkit
   6. By the application itself

I've seen all but 3 and 5 in various situations in practice.

Five is particularly troublesome, since it's on a per-app
basis, leading to inconsistent bug reports.  Encourage
people to use GIMP when testing, rather than
Firefox/Iceweasel, as the GIMP seems to consistently get it
right and isn't really subject to toolkit troubles.

Somebody probably needs to write a bunch of code that will
look at layers 2-4 and provide a definitive report of what's
going on.  In my copious spare time...

    Bart Massey
    Assoc. Prof. Computer Science
    Portland State University
    bart@cs.pdx.edu