Date: Sun, 21 Jun 1998 21:10:23 -0700 From: Mike Smith <mike@smith.net.au> To: sos@FreeBSD.ORG Cc: rhh@ct.picker.com (Randall Hopper), nirva@ishiboo.com, hasty@netcom.com, yokota@zodiac.mech.utsunomiya-u.ac.jp, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG, hasty@rah.star-gate.com Subject: Re: X-10 Mouse Remote patch Message-ID: <199806220410.VAA03380@antipodes.cdrom.com> In-Reply-To: Your message of "Fri, 19 Jun 1998 13:02:30 %2B0200." <199806191102.NAA00901@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> You got me wrong here, moused should have no pipes/sockets/etc > interfaces, it shall have exactly what it needs and that is the > device/devices of the mouse hw. If you need a deamon for a new > device (and I see a X10-remote-anything as a new device) you > should write one, not try to bend an old one into shape... Just be careful where you take this one; it's a sliding scale of greys from everything standalone (which for the cascaded MouseRemote case would reek) through to Streams in user-space. It seems that Amancio has again abandoned his "solution" partway, so let me elaborate on a stacked pointer-interface model which I originally devised to deal with Randall's original suggestion. It owes a little to Streams and a lot to dlopen(). In the new model, moused serves as a framework for modules related to auxiliary input devices, specifically those whose operational domain may overlap that of the primary pointing device. This should primarily involve managing a single input source, which may have more than one layer of protocol embedded within it. A combination of manual and automatic configuration serves to build a stack of processing modules. Configuration would include active discovery (COM PnP, traditional mouse probes, perhaps delayed protocol-sensitive determination - the first two we have, the third might serve as an elaborate technique for avoiding manual configuration). Modules are, naturally, separate objects dynamically loaded and unloaded as required. Protocol data are passed into the top of the stack, where it ripples down, and is possibly passed out sideways either to a module-specific endpoint or to the standard 'pointer event stream' which is consolidated and passed to the console driver (etc.) as it is currently. This is a highly generalised design, and one which would facilitate the rapid production of new modules to handle auxiliary input devices. It is, of course, overkill in the current situation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806220410.VAA03380>