Improved scroll wheel support

is it the mouse which is generating the inverted data, or is it the OS?

The old – now discontinued – Apple wired mouse works in the same was as any other mouse with a scroll wheel: when using a different (HP) mouse it scrolled in the same direction. The Apple “Magic Mouse” is Bluetooth-only, so cannot be used on RISC OS at present.

FWIW, Microsoft have offered “inverted scroll” as an option since Windows 8 or thereabouts. It’s a more familiar experience for anyone who is used to using a tablet: moving the mouse moves the pointer on the screen, while moving the scroll wheel moves the “paper” in much the same way as dragging your finger up/down the screen of a tablet.

For many years my only exposure to RISC OS was via the Mac version of Virtual Acorn, where I couldn’t get the scroll wheel to work at all. This of course meant that I got used to the way an “inverted” scroll wheel worked, so when I finally bought a Raspberry Pi the scroll wheel was now scrolling in the wrong direction…

I’ve checked this under RISC OS 4.39.

Resetting to zero sounds a bit counter-intuitive – can anyone confirm if that’s what OSPointer actually does?

Yes, it really does. You can try to work around this silliness by treating it as a 31-bit value:

DEF FNy_scroll_delta
  LOCAL y_scroll%, delta%
  SYS "OS_Pointer", 2 TO , y_scroll%
  y_scroll% = y_scroll% << 1
  delta% = (y_scroll% - previous_y_scroll%) >> 1
  previous_y_scroll% = y_scroll%
=delta%

The trouble is that treats the difference between &80000000 and 0 as 0, so you lose one scroll tick when it resets. I’ve observed this happening when scrolling a window in RISC OS 4.39. This API would be simpler to use correctly if it didn’t reset to 0.

Honestly though, who’s ever going to scroll the mouse wheel 2^31 times in one direction? With the exception of deliberately fiddling with the scroll position for testing purposes, I can’t see the reset to zero ever actually happening.

Does claiming the event just stop it propagating to other EventV listeners, or does it also stop the OS_Pointer 2 values from updating?

I can change the OS_Pointer 2 values by calling OS_GenerateEvent. It would appear that the scroll position is updated by an EventV listener.

ROL’s docs don’t mention where settings are saved.

!Boot.Choices.Users.Single.Boot.Tasks.WimpScroll
(It’s an obey file which contains *X WimpScroll …).

I’m assuming it’s Apple mice which you’re having trouble with, since macOS is the only platform I know of which uses an inverted scroll direction

Fortunately the macOS inverted scroll direction has a preference setting to re-invert it, which is how it is here. Default just doesn’t work in my head.

so when I finally bought a Raspberry Pi the scroll wheel was now scrolling in the wrong direction…

Hmm, it’s a hard one because of the different UI logic in play. I move my scroll wheel down and the window scrolls down. This, to me, makes sense because logically the scroll wheel is attached to the scroll bar, and down means down. Anything else would be utterly bizarre.
On a phone/tablet, however, you move up to scroll down. Because in the absence of any sort of scroll bars, one instead literally “grabs the content and shoves it downwards” (or vice versa). You will note that NetSurf actually does as well this if you click-drag on a page.

so you lose one scroll tick when it resets.

Well, at least they suppress “weirdness happens” by not treating a wrap-around as zero.

Honestly though, who’s ever going to scroll the mouse wheel 2^31 times in one direction?

What’s your average uptime?

support for exchanging the primary and secondary mouse buttons (Select|Adjust) for those who – like me – often use the mouse left-handed.

Back in the 26 bit days, there was a module that hijacked button presses and swapped them around.

I’m a leftie with the mouse on the left, but I got used to the Sel-Menu-Adj ordering.

such that those new to the platform have the more familiar ‘right button = menu’ functionality.

It’s naff, but I guess it has merit. Pressing the middle mouse button might seem extremely counter-intuitive to people used to systems where it’s nothing more than a wheel.

Back in the 26 bit days, there was a module that hijacked button presses and swapped them around.

Well, there has been one called LHMouse on my site (https://sendiri.co.uk/downloads/LHMouse.zip) for years too. It’s nothing clever, but it’d be good to have an equivalent in the OS and for it to be configurable. FWIW, I’m essentially ambidextrous these days and can use a mouse equally well on either side, but I prefer to switch the buttons for symmetry.

The three-button mouse is an odd subject; they’ve had three buttons for so very long before the common operating systems reluctantly adopted them. IIRC Apple/Jobs argued that one button was simpler and easier for its audience, just as Jobs argued against the use of a stylus, and I’m not sure (collectively) we’ve yet understood that the needs of the novice are different from the needs of the productive/experienced.

argued that one button was simpler and easier for its audience

I’m not sure I want to be educated on the merits of mice by a company that managed to supply the iMac with the most god awful mouse I’ve ever come across. One single button (as far as I can tell) and a design that is basically a miniature Roomba with a wire attached.

Oh, and a horribly broken Windows-like UI where it has to waste screen area on a menu bar because the mouse paradigm was too broken to support context sensitive behaviour.
Actually, worse, it’s a screen top menu bar that changes depending on the current program. An idea that is, frankly, awful and sadly I saw it in a recent Ubuntu, just to show that bad ideas linger.

I believe Apple mice these days have more than a single button, because reality clearly caught up.

there has been called LHMouse on my site

Well worth remembering, in case anybody wants inverted mouse buttons.
[I suppose the same method could be used to swap Menu and Adjust as was previously mentioned]

!HID from XAT will also let you swap mouse buttons, you can configure which button does what. It works for mice with more than 3 buttons too!

Well, at least they suppress “weirdness happens” by not treating a wrap-around as zero.

What weirdness? The returned scroll positions are meaningless by themselves. You need a previous value to compare against. So the most obvious way to use this SWI call would be:

SYS "OS_Pointer", 2 TO , y_scroll%
delta% = y_scroll% - previous_y_scroll%
previous_y_scroll% = y_scroll%

If the scroll position didn’t get reset to zero then the above code would work perfectly.

Suppose the Y scroll position was &7FFFFFFF, and we scroll up one tick. If the new position is &80000000, then delta% = &8000000 – &7FFFFFFF = 1, i.e. the desired result. On the other hand, if the new position is 0 then delta% = 0 – &7FFFFFFF = -2147483647. A massive offset in the wrong direction. This is why I had to add the shifts in my previous post. ((0<<1) – (&7FFFFFFF<<1))>>1 = 1.

Resetting to zero means the OS had to include extra code to do it, and applications have to include extra code to undo it.

What’s your average uptime?

It takes about 248 days for OS_ReadMonotonicTime to wrap around to negative. No one can scroll the mouse wheel a hundred times a second so it’ll take a lot longer than that—especially given you also need to eat, sleep, etc. I really can’t imagine anyone would scroll the mouse wheel 2^31 times in a lifetime of realistic usage, never mind doing that without resetting the computer.

The kernel will gain code for tracking the scroll wheel position and any extra mouse buttons (under Select this is all handled by the OSPointer module)

It would be nice to see a single, simple method of reading and writing pointer position, scroll movement and button state. All this to allow the sort of scripted mouse movement actions akin to AutoIT on a PC. It also makes implementation of a keyboard driven pointer an easier prospect. While talk of a keyboard driven pointer might seem heretical various RO programmers of note have produced modules to do that over the years, but even the ones claiming 32bit status still fail. I knocked up something that works (but only when the Filer has the focus)

t’s nothing clever, but it’d be good to have an equivalent in the OS and for it to be configurable. FWIW, I’m essentially ambidextrous these days

I was discouraged from eating with the implements “the wrong way round” by what were known as “dinner ladies”. My father said if he’d known “before the damage was done” they would probably have been known as casualties. I now use the most convenient side or whatever habit has left me.

Oh, and a horribly broken Windows-like UI where it has to waste screen area on a menu bar because the mouse paradigm was too broken to support context sensitive behaviour.
Actually, worse, it’s a screen top menu bar that changes depending on the current program.

You’ve just brought back some horrible memories of the time period I had to do the maintenance on one of those piles of….
As an Acorn user I was the only one familiar with a GUI – early version Windows was so sh** that even the P devotees at work didn’t like it so there was a delay after W3.11 crawled into the workplace.(Or was that slithered?) :)

An idea that is, frankly, awful and sadly I saw it in a recent Ubuntu, just to show that bad ideas linger.

Yup, there’s some stains you just can’t shift. You just have to ditch it and get something new that’s probably better.

Out of interest, what needs to go in the Configure plugin? The Windows plugin is already pretty a big window (and includes the Iconbar settings, which has always struck me as odd – the Iconbar is only a ‘window’ from a programmer’s point of view). Even if the new settings only make sense in the Wimp context, are these not better placed in the Mouse plugin?

The settings available via the *WimpScroll command.

Now that I’m at home to check, I agree that the Mouse plugin is probably the better place to put the settings. There are already some Wimp-specific settings in there, and it’s the more obvious place for an ordinary user to look.

Not immediately connected with scroll wheel support, but related… if the Mouse plugin and handling is changed can we please finally have support for exchanging the primary and secondary mouse buttons (Select|Adjust) for those who – like me – often use the mouse left-handed.

Also, and perhaps someone who was present would care to comment/clarify, I overheard part of a discussion at the South West Show about having a configuration switch to exchange Menu and Adjust such that those new to the platform have the more familiar ‘right button = menu’ functionality.

I think for that to work, it would have to be built into each of the mouse drivers, so that they can send the correct button codes via KeyV. Otherwise we’d end up in a situation where one set of APIs says one thing, while another says something else.

A useful addition, but probably a bit out of scope (the plan is to do something about ticket #478 in time for RISC OS 5.28, so I don’t want to pick up too much feature creep along the way)

Will software that sees the window scroll events (currently faked up by the USB code (eek!)) still work?

Yes.

If you think about it, going from +veBIG wrapping to -veBIG (or vice versa) would basically be the exact opposite scroll position, which could be disturbing to see; but if one is right at the boundary then gently scrolling up and down might cause the UI to freak out if the system is seeing alternating between +most and -most. It’s likely that resetting to zero is to rebase the pointer so that it’ll be a small glitch, not a big one.

The benefit of the +veBIG to -veBIG approach is that you can simply do “SUB Rdelta, Rnew, Rold” to calculate how much the wheel has moved since you last checked. That’ll work in any programming language which implements integer arithmetic modulo 2^32 (BASIC integers, C integers, etc.)

Resetting to zero on overflow is a nuisance because (as edwardx says) you can only calculate deltas correctly if you throw away the top bit and start performing arithmetic modulo 2^31 (which isn’t as straightforward in most languages).

That said, it sounds like a lurking gotcha. How does the current impementation work, and might it not make sense to quietly reset it to zero (and teach OS/Wimp that zero means “leave it where it is”) rather than continually adding/subtracting until something eventually wraps?

OS_Pointer 2 is expected to return the “absolute” position of the scroll wheel (i.e. an accumulation of all the deltas reported by the drivers); software which uses OS_Pointer 2 can then compare the old absolute value against the new to work out how far the wheel has travelled since they last checked. The OS can’t realistically track what “old position” values apps are remembering, so resetting it to zero at arbitrary points will just break things.

How does the Wimp handle mouse movements? Does it look at PointerV?

I believe it relies solely on OS_Mouse for reading the mouse state.

Why CMOS?

Consistency with the other keyboard/mouse settings.

I’ve checked this under RISC OS 4.39.

That’s useful – thanks.

It is worth mentionning that long ago I added code to use OS_Pointer, 2 in KinoAmp till I found out that the call crashed on OS 4.02. I can’t remember how it behaved on OS 5. Since I had no sure way to detect when the call was safe to use, I had to comment the code.

It is worth mentionning that long ago I added code to use OS_Pointer, 2 in KinoAmp till I found out that the call crashed on OS 4.02.

That doesn’t seem to be the case for me

SYS"OS_Pointer",2

A quick check in RPCEmu with OS 3.50 also didn’t crash, merely gives that same error. Is it possible you have/had some buggy extension module loaded?

A quick check in RPCEmu with OS 3.50 also didn’t crash, merely gives that same error. Is it possible you have/had some buggy extension module loaded?

I can’t check anymore since the RISC PC I used at the time is no more.
One possibility is the ps2 to acorn mouse adapter from Stuart Tyrell that I used. IIRC it came with a wheel driver for versions of the OS which didn’t directly support it.

SYS"OS_Pointer",2

I just tested it on OS 5.24, and RPCEmu crashed!

SYS"OS_Pointer",2

I just tested it on OS 5.24, and RPCEmu crashed!

Huh, so it does! But not on my Titanium, running notionally the same kernel. After a quick look at PointerSWI I see it’s not preserving lr across a call to TranslateError, and for a Risc PC that seems fatal.

A quick search of the kernel for similar syndromes reveals another bear trap set with

SYS"OS_ConvertDateAndTime",,,-1

Well that’s annoying!

It looks like the LR corruption bug has always been around (e.g. on RISC OS 3.5, I’d expect a call to OS_Pointer 2 to malfunction if made from SVC mode). Producing ROM patches for it should be easy enough, but I’m struggling to think of a concise way for software to determine whether it’s been fixed.

Before I spend too long hunting around myself, does anyone know of any (free) software which supports the extended scroll requests? Preferably an example of window scrolling and icon scrolling.

You mean like scrolling the window with the mouse wheel?

I would point you towards Manga, but there’s a risk your productivity might go down. ;-)

I can take a look at it, but if it doesn’t support extended scroll requests I’ll be sorely disappointed ;-)

PipeDream ought to be responsive to extended scroll requests – scroll by five lines is what the code says!

PipeDream ought to be responsive to extended scroll requests – scroll by five lines is what the code says!

Pipedream scrolls using the scrollwheel IFF the pointer is over the scroll bar. Otherwise scrolling is ignored.

PipeDream’s main content window is set up to accept extended scroll requests but never receives them, presumably because of the issue that Jeffrey is addressing…

PipeDream’s main content window is set up to accept extended scroll requests but never receives them, presumably because of the issue that Jeffrey is addressing…

Yep. Currently scrollwheels will only scroll windows which support regular scroll requests (window flag bits 8 or 9 set). E.g. you can’t scroll the task manager window because it doesn’t set those bits! The new code should support all three methods (extended scroll requests to icon or window, regular scroll requests, and “manual” scrolling via OpenWindow requests)

but if it doesn’t support extended scroll requests I’ll be sorely disappointed ;-)

Oh, right. I see. You mean that multiples of four stuff? No, I don’t support that, I read the documentation here.

Having said that, how is “extended scroll” different to having multiple simple scroll requests? Surely the desktop can keep up with a user fiddling with a scroll wheel? ;-)

BTW, the ROLtd documentation is faulty – it says the same thing for +1 and +2.

scroll the task manager window because it doesn’t set those bits!

Yeah, I think the USB scrolling has to make some checks to see if an app can handle scrolling. Not so useful if the app leaves that to the Wimp to deal with!

The new code should support all three methods

I don’t suppose it might be possible to scroll menus under the pointer? Something that would be useful for Manga. I’d have done it myself, but menu handling is the Wimp’s domain, not mine.