Date: Thu, 18 Jun 1998 17:04:24 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Danny Dulai <nirva@ishiboo.com> Cc: multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG, Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, Amancio Hasty <hasty@rah.star-gate.com> Subject: Re: X-10 Mouse Remote patch Message-ID: <19980618170424.B8162@ct.picker.com> In-Reply-To: <19980618161154.03428@bleep.ishiboo.com>; from Danny Dulai on Thu, Jun 18, 1998 at 04:11:54PM -0400 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980618170424.B8162>