> The orientation of the trackball however, is off. When I try to move the > pointer "up" it goes up and about 45 degrees to the left. This sucks. I'm very upset at mouse vendors, as all of them feel they must introduce incompatibilities in protocols or behaviour. It sounds to me like «my device is so better that it can't use standard protocols». This time they probably advertise that «by default people move the mouse with the wrist rotated by 45deg, so this is ergonomics (and all other suck)». Obviously, there is no support for changing orientation in gpm. And now we are forced to add that «feature». Good luck Nico :) > In the meantime I am hacking gpm to do this for me. The solution I am > working on (which is just to do trigonometry on the x and y bytes read > from the mouse) will suffer from rounding error when moving the mouse > slowly. I think the best approach is creating a new mouse type (we have dozens, it's a complete mess -- for the reasons above, mainly). If you rotate each individual movement you should have no rounding error; but you'll probably need to keep track of partial pixels in your mouse type. Partial char-cells are already taken care by the gpm core. Mouse types are defined in mice.c, you won't need to touch any other file. Obivously, if someone wants to implement rotation, that won't be in mice.c but in the core. BTW: if your X doesn't offer rotation, you should repeat gpm packets using another protocol (not "raw" repeating), that should work fine as gpm re-encodes data packets after the mouse type decoded them. Raw repeating, instead, repeats the exact data bytes, so you your gpm hack won't have any effect. Hope this helps /alessandro, no more gpm maintainer after seeing new mouse protocols -- Alessandro Rubini, free software developer. Device drivers, embedded systems, courses. http://ar.linux.it/