Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jun 1998 07:56:46 -0400
From:      Govt Conspiracy <rhh@ct.picker.com>
To:        sos@FreeBSD.ORG
Cc:        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:  <19980619075646.A10481@ct.picker.com>
In-Reply-To: <199806191124.NAA00947@sos.freebsd.dk>; from Sren Schmidt on Fri, Jun 19, 1998 at 01:24:41PM %2B0200
References:  <19980619070646.A10032@ct.picker.com> <199806191124.NAA00947@sos.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Sren Schmidt:
 |Randall Hopper:
 |>                        /----> syscons-specific ---->
 |>                       /           back door          \
 |>  serial port -> moused                                ---> /dev/sysmouse -> X11
 |> 
 |> 
 |> This having-to-change-the-console-driver to extend the sysmouse protocol
 |> crossed several cleaner design options off my list at the start.  
 |> 
 |> Why should the console driver have any special status?  Just another mouse
 |> client, right?
 |
 |Nope.
 |
 |Moused is ONLY a frontend in the mouse system as such. Moused is a deamon
 |that nows about different mouse protocols, and not much else. This is
 |because we dont want mouse specific code in the kernel.

Agreed.  My point is that the diagram should look like this:

                                              |---> syscons 
    serial port -> moused -> /dev/sysmouse# --|
                                              |---> X11
                                              |
                                              |---> whatever

sysmouse is the canonical mouse event output.  Everyone else just uses what
it provides.

Now there may be a technical problem in BSD with having the kernel make use
of the output of devices, or letting processes feed devices rather than the
kernel, but this conceptually is the cleaner solution (IMO).  It might not be
the quick-fix approach, but it is more general.

 |Moused delivers the mouse events to syscons, the console driver, which
 |then in turn multiplexes the mouseevents between the active virtual
 |screens, provides support for sending a signal to a process when the
 |mouse moves or a button is pressed. I also provides a generalize 
 |mouse on /dev/sysmouse that oldstyle apps like X can use, otherwise
 |you can only have ONE apps using the mouse, now it can be shared between
 |the virtual consoles.

What if I want to use PCVT or some other not-yet-written console driver?
What if someone else wants to write a new console driver?  They have to
duplicate this sysmouse handling or they just have to live with losing it.
And if one want to extend the sysmouse protocol, they have to extend the
syscons driver because the protocol and any extensions (e.g. 3- or
5-byte-extended sysmouse formats) have to pass through syscons.

Anyway, probably enough about this.  Bottom line is that we can't always do
what is ideal.  Given time yes, but time is a factor in the equation.  If
someone has time and desire to write a completely generalized remote daemon
and extend moused (or update FreeBSD for generalized device handing for
that matter), that's great!  More power to them!

Randall

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?19980619075646.A10481>