[paint] Fix cursor wrap and last line not displayed, fix keyboard ignored until mouse event

[ghaerr]

Several enhancements and fixes included in this PR:

• Fix XOR cursor wrap when using fast VGA drawcursor
• Fix ignored keyboard events until mouse moved from Paint fix flood fill on 'f' key #2303 (comment)
• Draws last line of XOR cursor previously not displayed
• Rewrite ia16-gcc graphics macros for improved speed and code generation
• Mouse acceleration now optional and default OFF, better with no acceleration when using faster XOR cursor display
• Fixed ia16-gcc code generation bug when using ASM "d" constraint and char variable as function parameter
• Rewrote drawbits function for higher speed

Very long story short, the ignored keypress bug turned out not to be a kernel problem, although I ended up fully tracing through all the select() codepaths before finding that the issue was in the Paint event code. The fd_set file descriptor array being passed to select() was not being reset in the inner event wait loop. When the kernel happened to send a mouse event with the same X,Y location as just previous, which apparently happens on occasion, then the select() loop was reentered with just the mouse file descriptor set and wasn't in fact selecting for keyboard events - so none were delivered until the next (mouse) event.

Learned more about ia16-gcc magic asm macro constraints: when specifying "d" as modified for DX, the compiler still thinks that DH or DL are available and was generating code loading DH which corrupted the function, but only when the function used a char parameter (or likely a char variable as well). Just goes to show that using char parameters for functions ends up using lesser-used compiler code paths, and this one was buggy. Also found that the
cross/build/gcc-src/gcc/config.ia16/constraints.md file which lists the asm constraints doesn't actually match the compiler constraints accepted. There seems to be no documentation for this anywhere, so its trial and error.

After fiddling lots with the asm constraints, it was seen that far better code is generated if AX and DX were loaded via parameters to the asm macro, rather than internally and specifying modifiers. This ended up making the VGA hardware set_op and other functions faster, since the compiler knew what was in each register and could optimize its own code generation around that.

[Vutshi]

Wow, that’s a bug apocalypse!
Does anyone develop ia16-gcc these days?

[Vutshi]

When the kernel happened to send a mouse event with the same X,Y location as just previous, which apparently happens on occasion

This is what I was wondering about when seeing a sequence of x=0, y=0 on a tiny tiny mouse move. Why does kernel send this nonevents?

[ghaerr]

seeing a sequence of x=0, y=0 on a tiny tiny mouse move.

Why does kernel send this nonevents?

You may have suggested an answer with your keen observation: when the resolution of the trackpad or emulated mouse device is greater than that of a "real" MS serial mouse, perhaps the tiny location change generates the same X,Y values in the emulated serial mouse. It shouldn't, but it seems to anyways. I'm only running on QEMU and it sends them on occasion from my macOS laptop hardware. It sounds like you're running on MartyPC and it's doing the same.

[EDIT: Remember, the kernel isn't generating mouse events; its just sending serial input to our mouse data decoder. So the ELKS kernel can't do much about it.]

In any event (definitely no pun intended there), my new code handles the problem of "duplicate" mouse events, and does not send duplicates to the Paint application.

So I would think we can now call this mouse issue a "non-event" 🤷‍♂️, or perhaps a mouse-scrap.

Does anyone develop ia16-gcc these days?

TkChia used to on Github, but he's moved off this platform entirely. I did see a little bit of activity over on GitLab a month or so ago, but nothing here.