🚀 go-pugleaf

In article <1105@hub.ucsb.edu> dougp@sbphy.ucsb.edu writes:
>Is that all you are going to support with drivers in 1.4? I think a
>more generic schieme should be used for the controller ports. 
>Specificly, How would you handle a driving simulator which wanted
> [ goes on to describe a pretty wild configuration ]

It is a really valid point, of course the game writers out there wouldn't
use it because they just go to the metal anyway :-) but for those of us
that stay within the bounds of reason, how about a super miscio.device.

This device would have a structure that included values for all of the
pins and pots on both ports. You would open it with a flag value that
would tell the device what pieces you were interested in and what 
direction the I/O would go. So the structure might look something like
struct Postition {
	short	X, Y;
}

struct MiscIO {
	short			Pots[4];	/* Analog pot values 	   */
	struct Postition	XY[2];		/* Mouse "position" values */
	unsigned char 		Buttons[10];	/* Button states	   */
}

You may have noticed that there are 16 things there, give each one a 
bit to determine if you want a message if it changes. 

I know really rough sketch, but assuming that this was the underlying
device, all of the existing devices could be built on top of it and
custom devices like the one doug mentioned could be built with some
guaruntee of future compatibility.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.