linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Martin Costabel <costabel@wanadoo.fr>
To: paulus@linuxcare.com.au
Cc: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: Patches for 2.4.0-test7
Date: Mon, 28 Aug 2000 09:38:21 +0200	[thread overview]
Message-ID: <39AA16ED.58CF5B8F@wanadoo.fr> (raw)
In-Reply-To: 14761.39952.597917.43823@argo.linuxcare.com.au


Paul Mackerras wrote:
>
> Michael Schmitz writes:
>
> > That would have been me - I still claim that keeping adbmouse working for
> > backwards compatibility would be a good thing, but my word doesn't carry
> > much weight.

> The way it is at the moment in the linuxppc_2_3 bk tree and in my
> rsync tree, you have 3 choices:
>
> 1. use mac_keyb.c/adbmouse.c and don't have the input layer at all
> 2. use the input layer for USB devices and mac_keyb.c/adbmouse.c for
>    ADB keyboard and mouse
> 3. use the input layer for both USB and ADB devices.
>
> The adbmouse driver references some external variables which are
> declared in mac_keyb.c.  If there is really a need to have adbmouse.c
> in the system without mac_keyb.c, we can probably work out a way to
> allow that, but I don't see the need.

While I fully agree with Paul that it is better to impose clear choices
so you need not check for weird interactions between incompatible mouse
drivers, I find Michael's wish for coexisting old and new ADB mouse
drivers understandable:

When I try different kernels, 2.2.x ones without knowledge about the new
input layer, or 2.4.0 ones with or without new input layer switched on,
the different drivers for the ADB *keyboard* don't present any problem
(as long as I choose to work with raw-adb-keycodes). The whole
configuration is in the kernel, and even X works with either keyboard
model.

For the ADB *mouse*, this is quite different: When I want to use a
kernel with the new input layer for the mouse, it is not sufficient to
boot the correspondingly configured kernel. I also have to change a
couple of files in /etc to tell about the new mouse driver, in my case

/etc/devfsd.conf
/etc/sysconfig/mouse
/etc/X11/XF86Config

Then I have to restart devfsd, rm /dev/mouse, and restart gpm. (In this
order, and all this before starting X, of course).

When I go back to a kernel without new input layer, I have to change all
this back. This wouldn't be necessary if drivers for both /dev/adbmouse
and /dev/input/mice could coexist..

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-08-28  7:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-26 13:12 Patches for 2.4.0-test7 Martin Costabel
2000-08-26 16:41 ` Benjamin Herrenschmidt
2000-08-26 21:33   ` Martin Costabel
2000-08-26 22:36     ` Benjamin Herrenschmidt
2000-08-27 16:28     ` Michael Schmitz
2000-08-27 22:54       ` Paul Mackerras
2000-08-28  7:38         ` Martin Costabel [this message]
2000-08-28  9:34           ` Benjamin Herrenschmidt
2000-08-28 10:43             ` Michael Schmitz
     [not found]             ` <Pine.LNX.4.10.10008281239570.28749-100000@opal.biophys.uni -duesseldorf.de>
2000-08-28 11:51               ` Franz Sirl
2000-08-27  9:59 ` Paul Mackerras
2000-08-27 12:02   ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39AA16ED.58CF5B8F@wanadoo.fr \
    --to=costabel@wanadoo.fr \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paulus@linuxcare.com.au \
    --cc=schmitz@opal.biophys.uni-duesseldorf.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).