Ticket #383 (Fixed)Sun Apr 27 09:13:45 UTC 2014

I’m thinking this might be possible if Geminus (or something else) is performing red/blue swapping.

Prior to NVidia 0.40, on an FX-series card 32K colour modes would have had the desktop appear red/blue swapped but the mouse pointer correct. In NVidia 0.40 things were switched over to using the new red/blue swapped screen modes where appropriate, so that in 32K colour modes the desktop and pointer should match. Then in NVidia 0.43 the *Configure NVidia option was added to allow manual control over the red/blue swapping – but if you use those options to disable the use of the new screen modes, then it will also disable red/blue swapping of the mouse pointer. So in a 32K colour mode both the desktop and the pointer will be incorrect. And if Geminus (or any other software which does manual red/blue swapping, e.g. ArcEm) is expecting that only the desktop needs red/blue swapping then that will give the end result of the desktop appearing correct but the pointer being red/blue swapped. The gamma tables in 32K colour modes will have also been affected in a similar way.

So I guess the correct fix would be a new config flag to allow red/blue swapping of the mouse + gamma table to be controlled independently of whether a red/blue swapped screen mode is in use (in 16bpp modes). 32bpp modes and 8bpp modes should be fine, as all three parts (desktop, gamma, mouse) always had consistent colour channels.

Should be fixed with NVidia 0.44: https://www.riscosopen.org/viewer/revisions/log…

For an FX-series card, “*Configure NVidia -manual -alt16bpp” will select red/blue swapping behaviour that matches that of versions of the driver pre-0.40.

Reopened. Here’s what happened when I tried this on an Iyonix running RISC OS 5.21 (20th Sep):

<pre>
*Help nvidia
NVidia 0.46 (06 Aug 2014)
*Status nvidia
NVidia -device 2 -auto
*Configure nvidia -manual -alt16bpp
Buffer overflow
*Configure nvidia -device 2 -manual -alt16bpp
Buffer overflow
*Configure nvidia -device 2 -auto
*Configure nvidia -device 2 -manual -alt16bpp
*Status nvidia
NVidia -device 2 -manual -alt16bpp
</pre>

Note: after doing all of this and rebooting, I’m still left with a red mouse pointer that has a yellow border.

Patronising question time: Are you sure you typed the options correctly? In particular if you missed the leading ‘-’ off of any of the keywords then that would have caused OS_ReadArgs to try copying the word verbatim into the output buffer, with the intention of assigning its value to the next applicable keyword (of which there should be none, but the buffer overflow error gets reported first). That’s the only case I can think of where a buffer overflow error could be possible.

It’s also possible to generate a few other nonsense looking errors from OS_ReadArgs (e.g. ‘*Configure nvidia -ass’ results in ‘Argument repeated’ due to it attempting to treat ‘-ass’ as an abbreviation for ‘-auto -swap8bpp -swap8bpp’, while ‘*Configure -foo’ generates ‘Missing operand’), so in NVidia-0_47 I’ve ‘fixed’ these issues by making it replace any error from OS_ReadArgs with the generic but generally more useful ‘Configure option not recognised’ error that’s also used in a few other cases.

Now, on to the problems with the mouse cursor:

• What graphics card do you have? (name from *PCIDevices should suffice)
• Does it have the hardware mod for swapping the red/blue channels?
• Are you running Geminus or anything else that might be messing with video related things?
• If you are using Geminus, are you using the ‘PC format RGB output’ option?
• What colour depths show the problem?

I think the machine Steve was testing has ended up with me for a different reason, so I’ll answer on his behalf:

NVidia GeForce2 MX (from *PCIDEVICES).
Yes, the R&B are swapped over with 2 track cuts on the PCB cross wired.
No add ons or extras loaded, just RISC OS 5.21 (hard disc is blank, no boot sequence, MDF loaded off floppy).

Using the options per above “-manual -alt16bpp”
– 256 greys, colours right, mouse wrong
– 256 colours, colours wrong, mouse wrong
– 32K colours, colours right, mouse wrong
– 64K colours, colours right, mouse wrong
– 16M colours, colours right, mouse wrong

The closest I can get is “-manual -swap8bpp”, that gets me
– 256 greys, colours right, mouse right
– 256 colours, colours right, mouse right
– 32K colours, colours right, mouse right
– 64K colours, colours right, mouse right
– 16M colours, colours right, mouse wrong

For completeness “-manual -swap8bpp -swap32bpp” gives
– 256 greys, colours right, mouse right
– 256 colours, colours right, mouse right
– 32K colours, colours right, mouse right
– 64K colours, colours right, mouse right
– 16M colours, colours wrong, mouse right

Should be fixed with NVidia 0.50: https://www.riscosopen.org/viewer/revisions/log… – Please confirm if you get the chance!

It looks like when adding the configuration option I managed to delete a crucial line of code, so the driver was getting confused and thought that all cards supported red-blue swapping in hardware. Combined with the other logic for handling red/blue swapping it meant that 8 & 16bpp modes could be fixed when using the right options, but 32bpp would always be broken in one way or another.

Now that that’s been fixed, you should just be able to rely on “*Configure NVidia -auto” to select the right settings (which should be equivalent to “*Configure NVidia -manual” for an MX-series card)

> so the driver was getting confused and thought that all cards supported red-blue swapping in hardware.

(i.e. without the assistance of the hardware mod)

> Please confirm if you get the chance!

Yup, all colours and pointers now the right colour with simply “-auto”.

I’ve added the missing new line after the configure text for you too!