Date: Fri, 19 Jun 1998 14:14:19 +0200 (CEST) From: Søren Schmidt <sos@FreeBSD.ORG> To: rhh@ct.picker.com (Govt Conspiracy) Cc: sos@FreeBSD.ORG, 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: <199806191214.OAA01044@sos.freebsd.dk> In-Reply-To: <19980619075646.A10481@ct.picker.com> from Govt Conspiracy at "Jun 19, 98 07:56:46 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Govt Conspiracy who wrote:
> 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.
This wont work, you HAVE to have the mouseevents through something that
knows about virtual screens.
> 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.
pcvt is dying, syscons is THE console driver in freebsd.
If we need more functionality we will have to extend the API with
those new items (allready happend once with the nw "wheel" mouse)
that is inherent through all of the systems drivers, nothing special
here.
> 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!
So we should just rush along kludging the system however everybody
see fit ??, it wont be long before this great OS based on lots of
effort will be a crash and burn experience then.
I'm sorry but I cannot follow here. I will have to use my -core hat
and tell you that this is simply not going to be happening, we will
have to maintain the high (but admittedly declining) standard, or
we will not be able to maintain the system in the long run..
So, the buttom line will have to be that either this is done right,
or it will have to be kept as patches outside the system.
EOS.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end?
..
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?199806191214.OAA01044>