| Re: [AD] Using system mouse cursor |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Evert Glebbeek wrote:
Personally, I think those are (logically) seperate issues. The way I see
it, we would have the following:
- software mouse, with implicit warping (current default)
- software mouse, with explicit warping or without
- hardware mouse, no warping
when warping is disabled, mouse mickeys are unreliable.
I'm trying to get away from implicit warping, though. That's the hack
I've been talking about. It undermind's the usual (Windows/X) mousing
system, trying to make it do something it can't.. provide unlimited
mickeys within a confined space (the window in X and the desktop in
Windows).
Yes. I'd rather get the hardware cursor stabilized first though and then
work on modifying the explicit/implicit cursor warping hack for X11.
Absolutely.. but I wasn't aware that there were still problems with the
hardware cursor itself (besides being X-only for now). The problems with
position_mouse and get_mouse_mickeys are related to the warping hack.
But existing code won't know about this. I think optionally changing
behavior is ok, but not default behavior.
The default behavior is to have unlimited mouse mickeys. No where in the
docs does it say the mouse will or will not be trapped to the window
automatically. Yes, the /current/ behavior is preferred, but it's too
hacky, buggy, and non-conformant to stay (don't forget, no other port
does this implicit warping).
The problem is, there is no way to get reliable mickeys under X.
Yes there is.. wait for a movement event, get the mickeys, center the
hardware mouse to the app window, and toss the next event that centering
the mouse triggers (or offset the internal variables so that the next
event will correct it). But this will require trapping the mouse to the
program window.
I'm ok with this modification, but we should check if a mouse cursor is
currently being displayed. If not, safe the hard/software mode setting,
enable the hardware cursor, and restore the previous setting at the end.
We should save/restore the current mode anyway. Even if the mouse isn't
displayed, those functions shouldn't change the behavior for when the
mouse is used next.
My first thought was to modify the way the cursor warping is currently done
in X, which is done from the input thread (I think) and already waits
before doing repeated warps. An alternate hack would be to use the
retrace_count variable, but that would be less than ideal IMO.
If you really need to do it, you can set up a volatile counter that's
checked and incremented for every position_mouse call (or really, every
input function if you wanted), and busywaits if it gets to a certain
threshold. That same counter would be reset to 0 at the end of the input
callback. Though you'd have to be careful it never reaches that
threshold within an acquire/release_bitmap, or else the input thread
would wait for the release_bitmap, which won't run until the input call
finishes, which is waiting on the input thread.. Nice deadlock there. :)
Or you could just change some internal vars so that the next input
handler call will change the mouse position, so there's no risk at all
to the event queue.
- Kitty Cat