From owner-freebsd-hackers Thu Jun 18 14:06:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13967 for freebsd-hackers-outgoing; Thu, 18 Jun 1998 14:06:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA13938; Thu, 18 Jun 1998 14:06:28 -0700 (PDT) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 18 Jun 1998 17:04:48 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA01148; Thu, 18 Jun 98 17:04:47 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA08315; Thu, 18 Jun 1998 17:04:24 -0400 Message-Id: <19980618170424.B8162@ct.picker.com> Date: Thu, 18 Jun 1998 17:04:24 -0400 From: Randall Hopper To: Danny Dulai Cc: multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG, Kazutaka YOKOTA , Amancio Hasty Subject: Re: X-10 Mouse Remote patch Mail-Followup-To: Danny Dulai , multimedia@freebsd.org, hackers@freebsd.org, Kazutaka YOKOTA , Amancio Hasty References: <19980601194116.A25497@ct.picker.com> <199806180122.KAA04952@zodiac.mech.utsunomiya-u.ac.jp> <19980618015038.40458@bleep.ishiboo.com> <19980618062844.E3160@ct.picker.com> <19980618124731.02987@bleep.ishiboo.com> <19980618130510.A7551@ct.picker.com> <19980618161154.03428@bleep.ishiboo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980618161154.03428@bleep.ishiboo.com>; from Danny Dulai on Thu, Jun 18, 1998 at 04:11:54PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Danny Dulai: |Randall Hopper: |> Danny Dulai: |> |Randall Hopper: |> |> I have noticed that the spurious events seem to only be mouse |> |> button or motion events. |> | |> |Hrm, I'm using my second com port for just the x10 remote. Are you |> |suggesting to just use the /dev/cuaa1 instead of socket that moused |> |creates? |> |> No, nothing of the kind. Still fire up a moused on the com port that the |> MouseRemote is attached to. That way the interface to the MouseRemote is |> uniform, regardless of how it's plugged up (i.e. the /var/run/MouseRemote |> UNIX domain socket moused manages. | |ok, I'm not understanding something... | |If you run moused, your mouse will jump around if you use /dev/sysmouse. |I don't see how you plan on getting around the rf noise with another |com port. As I mentioned, the end effect of the RF noise surfaces only as regular mouse button and motion events (AFAIK). And mouse button and motion events aren't passed through the MouseRemote socket (they're passed through /dev/sysmouse tty); only the Mouse Remote-specific key events are passed through the MouseRemote socket. So if you connect your Mouse Remote up like this: Std Mouse -> COM1 -> X Windows/syscons Mouse Remote -> COM2 -> moused -> /var/run/MouseRemote You can care less about the spurious mouse button/motion events because they're not even being used (nobody's slurping sysmouse), but rather they're just being tossed into the bit bucket. All you care about and are getting from COM2: is the remote-specific key events via the MouseRemote socket. However, in the pass-through configuration: /--- /dev/sysmouse --- X/syscons Std Mouse -> Mouse Remote -> COM1 -> moused - \--- /var/run/MouseRemote you "do" care about those spurious mouse motion/mouse button events because they end up coming out of /dev/sysmouse with the events from your standard mouse, playing games with your syscons and X windows pointer. |Is /var/run/MouseRemote any different than the direct device? Yes, they are different. The direct (serial) device receives mouse event sequences generally in the 3-byte Microsoft-compatible format. You can see this if you run moused with the -d option. In this form, mouse motion/button events look like normal, but one class of motion events are reserved off by X10 and used to pass remote key events when they occur. The bits for the key event byte are spread across two of the bytes in each mouse event sequence. Also note that the serial device is a tty device. That's the serial port side. moused extracts the remote key events from the data stream and puts them back into byte form, so each byte coming out of the MouseRemote socket represents a single key press (or key repeat if you're holding the key down). Note also that this is a UNIX domain stream socket. |Or is the plan to be able to conform other remotes to the same packets |this remote sends out? No I didn't have any plans to design a general works-for-all-remotes interface. This is the only remote I have that works with a computer, and that's why I put the name of the device in the name of the stream socket pathname. It is device specific. Buttons, features, repeat rates, debounce algorithms, encodings, etc. are going to be different for other remotes, and not having any others, I don't know what that variability will be. If we get some more remotes to play with in the future, we can certainly look into generalizing. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message