Date: Wed, 22 Sep 1999 09:41:25 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Douglas Pokorny <dpokorny@pcocd2.intel.com> Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Infrared trackball diffs available Message-ID: <199909220041.JAA09918@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Mon, 20 Sep 1999 09:46:39 MST." <37E664EF.15758999@eng.fm.intel.com> References: <37E664EF.15758999@eng.fm.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>A few days ago I was at Office Max and bought an InterAct "Web.Remote >professional". For those of you who don't know, its an infrared >remote control which contains a trackball, two trackball buttons, and >an 18-key keypad. It was a pretty good deal for $17US. > >My ultimate goal is to use it to control my mp3 playing FreeBSD server. > >As a result, I spent time this weekend figuring out the protocol it uses >and modified moused to work with it. It's a completely non-standard >6-byte-per-packet protocol, but was fairly easy to integrate into the >existing moused daemon. > >If anyone would like the diffs to the daemon, please let me know and >I'd be happy to send them out. > >The current moused supports up to 31 buttons on a device. However, the >level 1 sysmouse protocol only supports 10. As a result, I'm still >trying >to decide how to handle the keypad on the remote. > >I'm probably going to follow the x10netremote example, but would >appreciate any suggestions that people have. Probably moused is getting too bloat nowadays. I rather think we had better start thinking about creating a new daemon for remote control devices, including X10Remote and this Web.Remote. I expect this would be more logical, as these remotes may use proprietary packet formats, which may not comfortably fit into the way moused processes mouse data stream. We can use MOUSE_XXX ioctl commands to feed mouse/trackball part of data from the remotes to the console driver (and subsequently make it available via /dev/sysmouse). Key data can be made available to application programs (and the X server and client programs, perhaps) via FIFO, like x10remote does, or in any other means. I don't think overloading additional data from the remote control onto mouse data so that it would go through MOUSE_XXX ioctl commands and /dev/sysmouse (thus we don't need the second data channel) is too much; sooner or later we shall encounter a new remote control device about which we can no longer pretend it is a mouse-like device this way. Ok, the application program will read data of the remote control device from two separate channels: mouse/trackball data via /dev/sysmouse and key data, and other additional info from something else. Will that be a problem? No, I wouldn't think so. The mouse/trackball part of the remote should act like the ordinary pointing device :-) If the mouse/trackball part performs more than the pointing-device-like function, such data should go through the second channel together with key data and else, as it will probably need to be parsed/interpreted together with the data from other parts of the device. The `remote' daemon would be able to share code with or copy some code from the existing moused if necessary. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909220041.JAA09918>