[gpm] wheelmouse up event not propagated?

[Piotr Sawuk]

Bruno Boettcher wrote:
> 
> Hello!
> 
> i use the -Rraw flag to pass on all the events from the mouse through
> gpm to X, i have a wireless Trust-ami 250S mouse, which works quite
> well, and is perfectly functional when run through X directly...
> 
> but when i pipe it through gpm, the wheel up event is somehow captured
> and eaten up.... xev doesn't show anything when hitting the wheel up,
> wheel down works perfectly....
> 
> here's my gpm.conf:
> 
> device=/dev/input/mouse0
> responsiveness=
> repeat_type=raw
> type=autops2
> append="-l \"a-zA-Z0-9_.:~/\300-\326\330-\366\370-\377\""
> 
> that was the setup i had with my previous logitech mouse, and which
> worked flawlessly (until the mouse broke down..)
> 
> setup is debian unstable, with gpm 1.19.6
> please add a CC since i am not on the list

funnily for me the opposite happened: until recently my mouse-wheel
did only produce up and down events happening at exactly the same
time whenever I did move the wheel up, and button6 events when I
did move the wheel down (in X). now everything works fine, even
though the configuration didn't change much. I guess the only thing
changed was mouse-initialization:

my 350WL cradle mouse wireless optical (wheel-mouse with 4.5 buttons
and a single wheel -- the wheel I count as half an additional button)
does behave very strangely when I disconnect it from power and PC.
gpm (old 1.20.1 cvs-version) does not manage to read mouse-movement
(I told it that I have imps2 type of mouse, even though X does know
it as a ExplorerPS/2) and the mouse-cursor jumps and selects at random.
then I need to kill gpm and restart it again, and the mouse works
perfectly. however, this time I didn't need to do any of that, as
windows did take over mouse-initialization, and strangely the raw
interface now does work correctly. other than that I also linked
/dev/xmouse to gpmdata, but I doubt that would have anything to
do with the situation (I'm using XFree86 4.4 with NVIDIA driver).
however, only the 2.5 buttons and wheel are recognized by X,
unless I turn off gpm and link /dev/xmouse to psaux (which is
the reason I created the symlink in the first place). what I
would wish is to alter my keymap and X-configuration so that:

1) gpm gets turned off whenever I start X
2) gpm gets turned on whenever I ctrl-alt-F* switch to text-console
3) gpm gets turned off whenever I alt-F7 switch back to X
4) gpm gets turned on whenever X does end
5) gpm's copy&paste buffer can get saved and loaded at each exit and restart

so far I didn't manage to do any of those, even though I remember seeing
in some howto that the exact command executed upon alt-F7 can be altered
somehow -- I just can't find where. I have no idea how to do 2) or 4)
relieably, and for 5) I would probably need to alter gpm's sources. does
anyone have any useful hints for me?

Anyway, it really isn't important, since I can not get imwheel to work
properly anyway: enlightenment combined with mozilla1.6 does make the
impression that the mozilla-windown has title, name and id all set to
(null), and therefore imwheel (even the newest cvs) does fall back to
the defaults compiled in, instead of using the defaults written into
its configuration-file. so, I'm better off with gpm's raw-data forwarding.
should I ever need the additional 2 buttons I would simply kill gpm
and alter a symlink, as described above, but this wont happen in the
near future since I am mostly using programs which rely on libXt for
their configuration-files and thereby disallow mapping any buttons beyond
button5 to some program-function.

in my experience the most useful program for information on mouse-buttons
is xhkey and its xhkconf. imwheel was only useful since it did point me
to a project called "jam" which is supposed to become a replacement for
gpm, but which doesn't seem to be actively developed either. strangely
"xhkconf -m" does recognize mozilla's title name and window-id, and I'm
already considering to fix the ugly imwheel-bug myself, but I don't have
the time. another useful thing is the /etc/X11/xinit/.Xmodmap which gets
passed to xmodmap whenever I start X, since in that file I can alter the
order of the mouse-buttons, which is important with 4.5-button mice. maybe
altering that file might also solve the original poster's problem after
some further experiments with "xhkconf -m"...

btw, turning off the computer does not turn off the light on my
mouse-cradle, and so the initialization only needs to be done
once. further restarts do not mess things up. only once I did
notice this light going off upon power-off, even my usb-devices
do not get turned off at all. probably a hardware-bug which did
save me a lot of hassle with my mouse -- till the next power-failure...

P