Re: [AD] Linux mouse patch

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Peter Wang <tjaden@xxxxxxxxxx> writes:
>> Adding a mouse_z axis would involve changing quite a lot of files, but 
>> it would mostly just be a matter of searching for mouse_x/mouse_y, and 
>> adding a third entry wherever they are referenced.
> 
> Originally I added a variable `mouse_wh', so it is not too hard to do.

To be properly consistent with the difference between asynchronous, polled, 
and emulated input modes, though, this needs to work the same way as the 
existing variables, with the driver updating an internal _mouse_z variable, 
and then mouse.c mirroring this data across into the user-visible mouse_z at 
the appropriate times.

I'd prefer to call it mouse_z rather than mouse_wh, btw, because that can be 
used for any third axis of input, even if it doesn't happen to be 
implemented as a wheel (I can just imagine the 3d finger sensor devices that 
we'll all be using a decade from now :-)

> However, using the wheel as an axis in the classic case (with scroll bars) 
> would require user programs to constantly store the previous value and 
> compare it with the current value in order to see if it has changed.

That's not a difficult thing to do, though. In fact a majority of mouse 
handling code tends to do exactly that for tracking changes in the x/y 
position.

The big advantage of having a continuous axis is that multiple 'listeners' 
can make sense of the data, and not be upset by the fact that other people 
are reading it at the same time. If the value keeps getting reset to zero as 
part of the read operation, it is impossible for a second bit of code to get 
useful input after a first bit of code has already accessed that value. Ok, 
so normally you don't want the same input going to more than one place at 
the same time, but it can sometimes be useful, and in the interest of being 
consistent, most other Allegro input is stateless, and not affected by the 
process of being read (the only exceptions being readkey(), where the whole 
point is to remove that press from the buffer, and get_mouse_mickeys()).

I'd suggest to add a mouse_z axis which works identically to 
mouse_x/mouse_y, and if you really want, a get_mouse_z_mickey() function 
that will return relative motion since the previous call. I'd tend not to 
bother doing a get_mouse_z_mickey() at all if I was doing this myself, 
though, since that can be trivially implemented as required by just looking 
at mouse_z and comparing that to a stored value.

> poll_mouse() could be used to reset the third axis.

I'd prefer not to use the polling function for this. The idea of polling is 
that it is required to transfer the data from the hardware to where you can 
read it, but it seems strange that this should also modify the data in any 
way. For example it would be very weird that waiting for ten seconds and 
then calling poll_mouse() could ever leave you with different results than 
if you wanted for five seconds, polled, waited another five seconds, and 
then polled again.

The fundamental problem here is that the wheel wants to work with an input 
message queue like Windows uses, but Allegro treats input as a stateless 
thing, without any concept of specific events to be dealt with. It seems 
unnatural to pretend that poll_mouse() is a "get any waiting input events" 
call, though, when it really means "get whatever the current state is". If 
we treat the wheel as an axis, we can do the event to state conversion down 
inside the driver, and go on presenting a single result to the caller.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."