Mouse forward and reverse buttons

I see that the input preference for mouse has configuration for five-button mouse. Are buttons 4 & 5 for anything you want? Can it be used for the mouse forward and reverse buttons found on the side of some mice (forward and reverse pages in the web browser). Or, can it be used for left and right tilt of the mouse scroll wheel? Thanks.

It is used for the forward/back buttons. I don’t think the web browser actually goes back/forward on these yet, but it could be added.

The mouse wheel tilt is handled as an horizontal mouse wheel, used for scrolling just like the vertical one.

I have similar interests. I replaced my old wireless mouse a week or so ago (because its scroll wheel was jamming – now fixed, too) with the closest match I could find. This one was about twice as much as the old one, and the only enhancement is the sideways-clickable scroll wheel. As seems to be typical these days, there was no manual – just some rather unhelpful graphics on the packaging.

The blurb says: “up-down and left-right scrolling”, and that to me means moving the (current) page around, but I don’t see that. On Linux, the left/right clicks move back or forward a page in the history; in Haiku there’s no effect.

I tried the “5-button” setting in the Preferences, but the preference crashes if I try to do anything with it. (I’m not in Haiku now so I can’t be more specific.)

I did dig out an old test program to find that the mouse-button codes are (rather arbitrarily?) 0xffff0000 and 0x30000. I have no idea if this is standard in any way. Would be a nice enhancement, though to be able to select a function for them in the Preferences.

There are two things we handle in Haiku:

  • Mouse wheels: these only act on scrollbars. A vertical mouse wheel on vertical scrollbars, and an horizontal one on horizontal scrollbars
  • Extra buttons. These are usable in applications just like the other buttons in the MouseDown function. Normally each button is assigned a bit in the button mask. Bit 1 for button 1 (left click / B_PRIMARY_MOUSE_BUTTON), bit 2 for button 2 (right click, B_SECONDARY_MOUSE_BUTTON), and so on. Applications and the interface kit then handle this. For now I made the 4th and 5th button move to the next/previous tab in BTabView, but I’m open to better ideas, it was just to test if everything worked.

Wether your mouse reports the event as a mouse wheel event or buttons 4 and 5 doesn’t depend on us. We get the information from the USB HID descriptor.

The buttons are mapped from the mouse preferences to their respective bitmaps. It looks like your mouse indeed has back/forward buttons there (not an horizontal scrollwheel), and that your mouse preferences does not have valid values for buttons 4 and 5, resulting in both the crash and the incorrect values for the button events.

If you can share your mouse settings file, it would help reproducing the problem and we can see how to catch that issue. The problem being that old version of the mouse preferences left the memory there uninitialized so we can’t trust the old setting files, we need to check and clean all values in it. In the current version of the Input preferences, the settings are saved as a BMessage and with a bit more checking, but for this to work the preferences must be able to save it without crashing, of course.

Thanks, Adrien. I’ve done a little more checking.

It looks as if the crash in the input preferences is not a result of this particular mouse, as I don’t have to touch the extra functions. If I have the usual “3 buttons”, I can select one of the buttons in the preference diagram to bring up a menu of button numbers. If I select “5 buttons”, the moment I click on either of the two new buttons that appear, the app crashes.

Looking at the actual messages that come from the mouse (with a PrintToStream in my test app), I see that the bit for each of the normal 3 buttons corresponds (as it should) to the Preferences setting. OTOH, moving the scroll wheel left always generates 0x30000, moving right gives 0xffff0000. I now also notice there actually is a second-level click on each side that adds in the normal bit for the middle button – 0x30004 for instance.

Not sure what you mean about the mouse settings file. I tried looking ot the file, and it doesn’t seem to be a (flattened) BMessage? [hrev 54154]

It was changed recently from a raw dump of the mouse_settings structure to a BMessage. I suspect you are still using the old format.

There were fixes to the input preferences about this in hrev54330 and hrev54551. Maybe it’s time for an update :slight_smile: