>On Apr  3,  8:42am, Thomas Seidmann wrote:
>> problems with the behaviour of the mouse on the 5000/25. First, there is a
>> part of the screen (approximately the right 1/5), which can't be reached
>> by the pointer. Second, while having more than one window on the desktop,
>
>  This appears to be a bug in the cursor position routine for the 5000/xx
>display.  The ims332PosCursor() procedure in pmax/devs/ims332.c compares the
>x position against the framebuffer height and the y position against the
>framebuffer width.  I think the x position is the horizontal position and
>needs to be compared with the framebuffer width (and y compared with the
>fb height).  I made this change on my kernel and I am now able to position
>the cursor to any position on the screen.

OK, I think I got it now.

The rewrite of the pmax code to use rcons had the has the x and y
comparisons against height and width, *everywhere*, rather than width
and height.  All that code is broken (and always has been), on all
the framebuffer drivers.

This doesn't show up on the sfb or cfb, because that code is #ifdef'ed
out (#ifdef MELLON) in the bt459 driver. It doens't show up on the
pmax framebuffer because that driver still uses the older code for
checking the cursor is onscreen.

The comparisons should be transposed, and i guess then the bt459
driver should use the same code as the others.  I _guess_ that if the
mfb framebuffer is laid out with 2048 bytes between
vertically-adjacent pixels, then the older code (as in pm.c and
bt459.c) is the right comparison to use: even when fixed, the new code
would let you move a cursor into pixels between 1280 and 2048 (which
aren't visible).

Is anyone with an SFB or MFB willing to test such a change?