Mouse wheel in SDL?

Hello, I just noticed I dont’ see anything in the SDL_Events struct for a mouse wheel? Is this the case or am I not seeing it? Thanks

Mars_999 wrote:

Hello, I just noticed I dont’ see anything in the SDL_Events struct for
a mouse wheel? Is this the case or am I not seeing it? Thanks

if SDL handles mouse buttons higher than 3 then:

SDL_BUTTON(4) would be MOUSE_WHEEL_UP
SDL_BUTTON(5) would be MOUSE_WHEEL_DOWN–
-==-
Jon Atkins
http://jcatki.2y.net/

Mars_999 wrote:

Hello, I just noticed I dont’ see anything in the SDL_Events struct for
a mouse wheel? Is this the case or am I not seeing it? Thanks

if SDL handles mouse buttons higher than 3 then:

SDL_BUTTON(4) would be MOUSE_WHEEL_UP
SDL_BUTTON(5) would be MOUSE_WHEEL_DOWN

I’m not sure if this works at all, but suppose it works for 3 button mice,
how would it handle 4- or 5-button mice?

Dirk Gerrits

We have observed in some versions of Win32 at least only the first
movement of the mouse wheel works, and only if it’s up. We aren’t happy
about this and we’re not sure what the problem is. Yet. I’ve not tried
to form a coherent report for this list yet since I’m not sure what’s
wrong exactly. You may be experiencing the same bug. A synopsis:

Version:
1.2.2-1.2.4cvs (snapshot date unknown)

Symptom:
First mwheel movement works if the wheel is moved up. Further movement
in any direction is not recognized by SDL.

Affected platforms:
Windows 2000 has been confirmed.
Windows NT platorms (NT4, XP) are likely affected.
Uncertain if Windows 9x (95, 98, ME) are also affected.

Workarounds:
None known.

Cause:
Not known at this time.On Mon, Mar 11, 2002 at 11:50:41PM -0600, Mars_999 wrote:

Hello, I just noticed I dont’ see anything in the SDL_Events struct for
a mouse wheel? Is this the case or am I not seeing it? Thanks


Joseph Carter Sooner or later, BOOM!

who gives a shit about US law
anyone living in the US.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020311/86030778/attachment.pgp

Button 4 becomes button 6, button 5 becomes button 7. This somewhat
confusing arrangement you can thank X11 for. SDL’s Linux roots are
showing here. I know many would argue it’s a gratuitous change at this
point, but I would rather see X11 be the platform with the hack in future
API revisions than have everyone else have to cope with it personally.On Tue, Mar 12, 2002 at 08:16:56AM +0100, Dirk Gerrits wrote:

SDL_BUTTON(4) would be MOUSE_WHEEL_UP
SDL_BUTTON(5) would be MOUSE_WHEEL_DOWN

I’m not sure if this works at all, but suppose it works for 3 button mice,
how would it handle 4- or 5-button mice?


Joseph Carter Sanity is counterproductive

<change_m2> Will LINUX ever overtake sliced bread as the #1 achievement
of mankind?

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020312/507f0366/attachment.pgp

Hmm, does it map the mouse wheel to buttons under WIN32 as well? Or only X
under Linux? It doesn’t make any sense to have this behavior for a
cross-platform library such as SDL. Mapping mouse wheel to buttons was only
a hack in the first place, because people wanted to use the mouse wheel, but
developers were too lazy to redesign things to handle it, or expected it to
take too long. A hack shouldn’t become a standard if you ask me. Doesn’t X
v4 have the ability to read the mouse wheel directly now, instead of mapping
to buttons? I seem to remember that last time I was trying to write the X
config file for my box.

It should be read as the z axis for the mouse in my opinion.

-Jason

| take too long. A hack shouldn’t become a standard if you ask me. Doesn’t X
| v4 have the ability to read the mouse wheel directly now, instead of mapping
| to buttons? I seem to remember that last time I was trying to write the X
| config file for my box.

What you do is tell X you’ve got a 5 button mouse, and that buttons 4
and 5 map to the Z axis.

It is a bit of a hack, but so are mouse wheels in general (especially
since I’ve seen mice with two wheels. Given the mouse is X-Y and the
wheel is Z, does a second wheel control time? :-).On Tue, Mar 12, 2002 at 05:36:12AM -0500, Jason Hoffoss wrote:


Goldfish don’t bounce
6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

| take too long. A hack shouldn’t become a standard if you ask me.
Doesn’t X
| v4 have the ability to read the mouse wheel directly now, instead of
mapping
| to buttons? I seem to remember that last time I was trying to write the
X
| config file for my box.

What you do is tell X you’ve got a 5 button mouse, and that buttons 4
and 5 map to the Z axis.

Ya, I know, that’s how they hacked support in for it quickly, and it became
traditional to do that. I think the new X now has Z axis support for mice
natively though. But of course, in the Unix world, once people become used
to something for more than 2 seconds, they’d rather cut off their left arm
than do things differently than what they are used to now, so no one is
using it.

And so what if you have, say, an Intellimouse Explorer, which has 5 buttons
already, plus a mouse wheel? If all software assumes that buttons 4 and 5
are the wheel, the real buttons 4 and 5 need to be 6 and 7 now? It’s just a
bad system for handling it.

It is a bit of a hack, but so are mouse wheels in general (especially
since I’ve seen mice with two wheels.

I wouldn’t say mice wheels are a hack. It’s just technological extension on
traditional hardware is all. I think 2 wheels is a little overkill, though,
but then I’ve never used one. Maybe I just don’t know what I’m missing.

Given the mouse is X-Y and the
wheel is Z, does a second wheel control time? :-).

Only if you properly configure it to. :wink:

-Jason

----- Original Message -----
From: james@piku.org.uk (James)
To:
Sent: Tuesday, March 12, 2002 6:33 AM
Subject: Re: [SDL] Mouse wheel in SDL??
On Tue, Mar 12, 2002 at 05:36:12AM -0500, Jason Hoffoss wrote:

Hmm, does it map the mouse wheel to buttons under WIN32 as well? Or only X
under Linux? It doesn’t make any sense to have this behavior for a
cross-platform library such as SDL. Mapping mouse wheel to buttons was only
a hack in the first place, because people wanted to use the mouse wheel, but
developers were too lazy to redesign things to handle it, or expected it to
take too long. A hack shouldn’t become a standard if you ask me. Doesn’t X
v4 have the ability to read the mouse wheel directly now, instead of mapping
to buttons? I seem to remember that last time I was trying to write the X
config file for my box.

XFree4 looks at the mouse wheel as button 4 and 5. You can technically
choose any two buttons you want in your XF86Config, but it has to be
buttons, and I think every app (including GTK+ itself, etc) expects it to
be 4/5, and will act accordingly even if you map it to something else.

It’s lame, it should be fixed, but it’s probably too late already to do
so. But hey, if you can change XFree dogma, I’ll make the SDL patch. :slight_smile:

–ryan.

I heard that it might have something to do with using Direct Input w/ OpenGL
instead of WinDib w/ OpenGL for the mouse input? Anyone know/hear of this?

-EvilTypeGuyOn Mon, Mar 11, 2002 at 11:58:52PM -0800, Joseph Carter wrote:

On Mon, Mar 11, 2002 at 11:50:41PM -0600, Mars_999 wrote:

Hello, I just noticed I dont’ see anything in the SDL_Events struct for
a mouse wheel? Is this the case or am I not seeing it? Thanks

We have observed in some versions of Win32 at least only the first
movement of the mouse wheel works, and only if it’s up. We aren’t happy
about this and we’re not sure what the problem is. Yet. I’ve not tried
to form a coherent report for this list yet since I’m not sure what’s
wrong exactly. You may be experiencing the same bug. A synopsis:

Version:
1.2.2-1.2.4cvs (snapshot date unknown)

Symptom:
First mwheel movement works if the wheel is moved up. Further movement
in any direction is not recognized by SDL.

Affected platforms:
Windows 2000 has been confirmed.
Windows NT platorms (NT4, XP) are likely affected.
Uncertain if Windows 9x (95, 98, ME) are also affected.

Workarounds:
None known.

Cause:
Not known at this time.

Well, I’d guess it doesn’t.

At least, XFree86 seems to simply ignore my thumb button, as it’s
overidden by the wheel up/down “buttons”. Might be possible to work
around by hacking the config, but I assume that would break most
applications instead… heh

How does SDL know which “buttons” are mouse wheel up/down on X? (If
they’re hardcoded to 4/5), changing the X config would indeed break the
wheel input.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 12 March 2002 08:16, Dirk Gerrits wrote:

Mars_999 wrote:

Hello, I just noticed I dont’ see anything in the SDL_Events struct
for a mouse wheel? Is this the case or am I not seeing it? Thanks

if SDL handles mouse buttons higher than 3 then:

SDL_BUTTON(4) would be MOUSE_WHEEL_UP
SDL_BUTTON(5) would be MOUSE_WHEEL_DOWN

I’m not sure if this works at all, but suppose it works for 3 button
mice, how would it handle 4- or 5-button mice?

SDL_BUTTON(4) would be MOUSE_WHEEL_UP
SDL_BUTTON(5) would be MOUSE_WHEEL_DOWN

I’m not sure if this works at all, but suppose it works for 3 button
mice, how would it handle 4- or 5-button mice?

Button 4 becomes button 6, button 5 becomes button 7. This somewhat
confusing arrangement you can thank X11 for.

Does this actually work for anyone, on XFree86? (I could have missed
it, IIRC, I did try to read that thumb button in my “VisTk”, but it was
just not generating any events… :-/ )

(Just tried checkkeys, which terminates on any mouse button - except the
thumb button, of course.)

<change_m2> Will LINUX ever overtake sliced bread as the #1 achievement
of mankind?

Despite all this bashing of it’s video drivers, hasn’t it already? :slight_smile:

(At least, I would rather spend long nights trying to solve the “smooth
animation” problem than doing anything serious for Windows…)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 12 March 2002 09:06, Joseph Carter wrote:

On Tue, Mar 12, 2002 at 08:16:56AM +0100, Dirk Gerrits wrote:

[…]

Ya, I know, that’s how they hacked support in for it quickly, and it
became traditional to do that. I think the new X now has Z axis
support for mice natively though. But of course, in the Unix world,
once people become used to something for more than 2 seconds, they’d
rather cut off their left arm than do things differently than what they
are used to now, so no one is using it.

That’s just because we don’t want to force people to upgrade half their
system every two seconds.

And so what if you have, say, an Intellimouse Explorer, which has 5
buttons already, plus a mouse wheel? If all software assumes that
buttons 4 and 5 are the wheel, the real buttons 4 and 5 need to be 6
and 7 now? It’s just a bad system for handling it.

Yes it is. The hack is just another one that should not have been, and
that will take years to get rid of, now that every other toolkit
(including my VisTk) and application relies on it… heh

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 12 March 2002 14:14, Jason Hoffoss wrote:

How does SDL know which “buttons” are mouse wheel up/down on X? (If
they’re hardcoded to 4/5), changing the X config would indeed break the
wheel input.)

If you change them from 4/5, wheel input breaks.

You can, however, remap any mouse button in your XF86Config, so that when
the hardware sends the REAL mouse button 4, XFree reports to the
application that button 6 (or whatever) was touched instead. This is also
handy if the mouse wheel is reported as something other than 4/5 by the
hardware.

It’s a cruddy convention, though, and it really should be changed. Without
looking at the Xfree code, I would imagine that to do it right would
require a protocol change that sends a new event type, and that’s
really not going to happen, so the mouse wheel being mapped to a button
makes a lot of sense from a practical view, even if it offends our techie
souls. :slight_smile:

–ryan.

It’s button 6.

Nothing uses button 6. In fact, if you have more than 6 buttons, X does
not even support the extras other than via XInput, which is not compatible
with the concept of DGA’s mouse stuff and therefore unsuited for games.

At least, so it was explained to me.

Also, if you’re using IntelliMouse or IMPS/2 as your mouse protocol, your
thumb button does not even exist as far as X knows. Use the Explorer or
ExplorerPS/2 protocol if you’re not already.

This is of course assuming your mouse conforms to one of these protocols.
If it is PS/2, it probably does. If it’s USB, you can guarantee that
these protocols ALWAYS work. ExplorerPS/2 is now the preferred way to
use /dev/input/mice since it happens to be an extensible protocol designed
to allow for expansion.On Tue, Mar 12, 2002 at 05:42:20PM +0100, David Olofson wrote:

I’m not sure if this works at all, but suppose it works for 3 button
mice, how would it handle 4- or 5-button mice?

Well, I’d guess it doesn’t.


Joseph Carter Have chainsaw will travel

And don’t get me started on perl!
:>
perl is beyond evil
you don’t know perl yet?
gotta love a language with no definable syntax

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020312/2911c25c/attachment.pgp

Ryan wrote:

How does SDL know which “buttons” are mouse wheel up/down on X? (If
they’re hardcoded to 4/5), changing the X config would indeed break the
wheel input.)

If you change them from 4/5, wheel input breaks.

You can, however, remap any mouse button in your XF86Config, so that when
the hardware sends the REAL mouse button 4, XFree reports to the
application that button 6 (or whatever) was touched instead. This is also
handy if the mouse wheel is reported as something other than 4/5 by the
hardware.

Ryan’s exactly right. See:
http://www.xfree86.org/4.2.0/mouse7.html
and:
http://www-personal.engin.umich.edu/~agorski/linuxhelp.html

(BTW, In Xfree86 3.x, a max of 5 buttons are supported.)

All X apps which say they support the “mouse wheel”, actually support
buttons 4/5 acting like a wheel. So 5-button+1-wheel (like my
IntelliMouse Explorer) need the xmodmap hackery (detailed on the above
page to map the wheel to the right place).

You can use ‘xev’ to see which events get through, so Xfree86 4.x does
support buttons 6/7 (which I, for example, have my mouse’s thumb
buttons mapped to). However, I’ve yet to find an X application that
does anything with these buttons.

In terms of SDL and games, I think the best that can be done on the X
side is to assume buttons 4/5 are the wheel, since that’s now the
defacto standard that X apps use. Unless there is some way to query
the X server to ask which buttons have the “ZAxisMapping” hack
associated with them (which I doubt since no X app that I know of can
handle a wheel on buttons 6/7 — I tried a bunch.)

Perhaps SDL could hide this grossness a bit by (1) mapping the wheel
to buttons on X and Windows (which I gather is what it already does),
and (2) providing an API to say which buttons are the wheel buttons
(the implementation could default to reporting 4/5 on X, but use real
information on Windows). That’s at least backwards compatible.

-Pat


Pat Tullmann @Patrick_Tullmann
That which does not kill you merely postpones the inevitable.

Ryan wrote:

How does SDL know which “buttons” are mouse wheel up/down on X? (If
they’re hardcoded to 4/5), changing the X config would indeed break
the wheel input.)

If you change them from 4/5, wheel input breaks.

You can, however, remap any mouse button in your XF86Config, so that
when the hardware sends the REAL mouse button 4, XFree reports to the
application that button 6 (or whatever) was touched instead. This is
also handy if the mouse wheel is reported as something other than 4/5
by the hardware.

Ryan’s exactly right. See:
http://www.xfree86.org/4.2.0/mouse7.html
and:
http://www-personal.engin.umich.edu/~agorski/linuxhelp.html

(BTW, In Xfree86 3.x, a max of 5 buttons are supported.)

All X apps which say they support the “mouse wheel”, actually support
buttons 4/5 acting like a wheel. So 5-button+1-wheel (like my
IntelliMouse Explorer) need the xmodmap hackery (detailed on the above
page to map the wheel to the right place).

You can use ‘xev’ to see which events get through, so Xfree86 4.x does
support buttons 6/7 (which I, for example, have my mouse’s thumb
buttons mapped to). However, I’ve yet to find an X application that
does anything with these buttons.

I might hack some eventually… :wink:

Perhaps SDL could hide this grossness a bit by (1) mapping the wheel
to buttons on X and Windows (which I gather is what it already does),
and (2) providing an API to say which buttons are the wheel buttons
(the implementation could default to reporting 4/5 on X, but use real
information on Windows). That’s at least backwards compatible.

I’d guess an API extension that breaks compatibility with older SDL
libraries is not an option for 1.2. (There should have been some run-time
binding API for that kind of stuff. Asking for “keys” using a single set
of functions or something…)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 12 March 2002 21:40, Patrick Tullmann wrote:

XFree4 looks at the mouse wheel as button 4 and 5. You can technically
choose any two buttons you want in your XF86Config, but it has to be
buttons, and I think every app (including GTK+ itself, etc) expects it to
be 4/5, and will act accordingly even if you map it to something else.

Ya, I went looking, and it’s the ZAxisMapping config setting that was what I
remember seeing now. Looks like they added z axis support to the low level
code but not the higher level code the programmer has access to. Weird.

It’s lame, it should be fixed, but it’s probably too late already to do
so. But hey, if you can change XFree dogma, I’ll make the SDL patch. :slight_smile:

Should definately be fixed, and it’s never too late really. Technology is a
moving target and always needs to be updated constantly. New API calls
should be added that handle things better and add support for new things,
and then the old API calls should be documented as obsolete (though you
can’t really get rid of them because old applications use them).

I remember reading in the Microsoft documentation about the mouse wheel that
even though the Z axis right now reads in steps of 72 units, that’s only
because the wheels step right now, and allows for smoothly turning wheels in
the future. Haven’t seen any of these, but what if we did? MSWindow could
handle it already, but X would need yet another hack once again. Like they
say, those who fail to learn from history are doomed to repeat it.

-Jason

----- Original Message -----
From: icculus@icculus.org (Ryan C. Gordon)
To:
Sent: Tuesday, March 12, 2002 9:06 AM
Subject: Re: [SDL] Mouse wheel in SDL??

[…]

Ya, I know, that’s how they hacked support in for it quickly, and it
became traditional to do that. I think the new X now has Z axis
support for mice natively though. But of course, in the Unix world,
once people become used to something for more than 2 seconds, they’d
rather cut off their left arm than do things differently than what they
are used to now, so no one is using it.

That’s just because we don’t want to force people to upgrade half their
system every two seconds.

X has already been upgrade now how many times since this hack was first
introduced? Probably quite a few now. They still haven’t fixed it to work
cleanly instead of being a hack. Adding it to one of these updates wouldn’t
have forced anyone to upgrade any more quickly than they already do, so
that’s not the issue. It seems to me like they are failing to plan ahead in
their designs, and willing to go with hacks if it works good enough for now
than replacing them with solid solutions. They are reactive to technology
changes, and don’t add support for them until after they start becoming
widely available. Then there’s lag before anyone can use it in Linux, while
Windows is already supporting it all.

From what I’ve seen, btw, you don’t need to force people to upgrade half
their system constantly. They seem to enjoy doing that already on their
own.

And so what if you have, say, an Intellimouse Explorer, which has 5
buttons already, plus a mouse wheel? If all software assumes that
buttons 4 and 5 are the wheel, the real buttons 4 and 5 need to be 6
and 7 now? It’s just a bad system for handling it.

Yes it is. The hack is just another one that should not have been, and
that will take years to get rid of, now that every other toolkit
(including my VisTk) and application relies on it… heh

Yep, that’s why you try and avoid hacks in the first place, especially in
software that’s already widely available.

-Jason

----- Original Message -----
From: david.olofson@reologica.se (David Olofson)
To:
Sent: Tuesday, March 12, 2002 12:09 PM
Subject: Re: [SDL] Mouse wheel in SDL??
On Tuesday 12 March 2002 14:14, Jason Hoffoss wrote:

I remember reading in the Microsoft documentation about the mouse wheel that
even though the Z axis right now reads in steps of 72 units, that’s only
because the wheels step right now, and allows for smoothly turning wheels in
the future. Haven’t seen any of these, but what if we did? MSWindow could
handle it already, but X would need yet another hack once again. Like they
say, those who fail to learn from history are doomed to repeat it.

Remember that the Xfree “hack” isn’t so much an API issue, it’s a wire
protocol issue, so it affects much more than the XFree86 project.

–ryan.