Patches for 2.4.0-test7

Hi,

here are some patches that are necessary for 2.4.0-test7 (bitkeeper as
well as pmac-devel) to compile and run.

Some of them have been sent to the list (even repeatedly) before (by me
and
others). Now that the gun smoke over the drivers/input battlefield has
lifted, I dare resubmit them and hope they won't continue to be ignored.

- The patch for arch/ppc/kernel/ppc_ksyms.c is necessary if you want to
compile rtc as a module. If you don't want it as a module, you don't
need to EXPORT these variables at all.

- The patch for include/asm-ppc/mman.h is necessary so that the loop
device ("mount -o loop") works. I suppose the values for these MCL_*
variables have been chosen by analogy to some other architectures, but
they are already defined by glibc in /usr/include/bits/mman.h, so you
can't take arbitrary values.

- The patch for drivers/macintosh/Makefile is necessary for successful
compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
which is possible with the latest version of the new input layer. (Not
that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
that's another story).

I have 3 other pet peeves that I would like to recall:

- I think the new input layer with CONFIG_INPUT_ADBHID=y and
CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
that they differ from what all other kernels from the oldest times up to
linux-pmac-devel before yesterday were giving. The tables,
mac_keycodes[]
in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c, are probably correct. But then
adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
if it detects an ISO ADB keyboard. IMHO the swapping should occur for
USB
keyboards and not for ADB keyboards. I had some discussion with Franz
which was not conclusive.

My question is: Are these 2 keys giving correct results if one has
either dev.mac_hid.keyboard_sends_linux_keycodes=1 or an ISO USB
keyboard?

- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
variable, therefore stopping Mozilla from running. This is so weird (but
consistent since several months) that I have not the faintest idea where
it could come from. It is a feature of linux-pmac-devel, not present in
linux-bk-devel.

- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
from working. I have no idea what's wrong, but it would be nice to have
a working strace again.

--
Martin

- The patch for arch/ppc/kernel/ppc_ksyms.c is necessary if you want to
compile rtc as a module. If you don't want it as a module, you don't
need to EXPORT these variables at all.

I'll merge that one.

- The patch for include/asm-ppc/mman.h is necessary so that the loop
device ("mount -o loop") works. I suppose the values for these MCL_*
variables have been chosen by analogy to some other architectures, but
they are already defined by glibc in /usr/include/bits/mman.h, so you
can't take arbitrary values.

This one is waiting for Cort or Paul ack.

- The patch for drivers/macintosh/Makefile is necessary for successful
compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
which is possible with the latest version of the new input layer. (Not
that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
that's another story).

AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
the current bk tree. I'm also doing additional config fixes, so that ADB-
less pmacs can remove all the ADB stuffs and keep the PMU for example.
CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...

I though about making adbhid.c call the appropriate hooks in adbmouse to
make it work. After more thinking, I beleive it would be only bloat. Use
either the old drivers with your old userland setup, or the new drivers
with a new userland setup, with the mice all coming from /dev/input/mice.

I have 3 other pet peeves that I would like to recall:

- I think the new input layer with CONFIG_INPUT_ADBHID=y and
CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
that they differ from what all other kernels from the oldest times up to
linux-pmac-devel before yesterday were giving. The tables,
mac_keycodes[]
in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c, are probably correct. But then
adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
if it detects an ISO ADB keyboard. IMHO the swapping should occur for
USB
keyboards and not for ADB keyboards. I had some discussion with Franz
which was not conclusive.

They need to be fixed in the userland keymaps. We had it wrong at first.
Some keyboards have those actually swapped, and Franz cold should be ok
(it was tested with all sorts of keyboards, AFAIK, and now, a fixed
keymap should give good results everywhere).

- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
variable, therefore stopping Mozilla from running. This is so weird (but
consistent since several months) that I have not the faintest idea where
it could come from. It is a feature of linux-pmac-devel, not present in
linux-bk-devel.

The two kernels are now in sync. Do you still have the problem ?

- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
from working. I have no idea what's wrong, but it would be nice to have
a working strace again.

AFAIK, Paul pushed a fix for that in bk a couple of days ago.

Ben.

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

Benjamin Herrenschmidt wrote:

quoted

- The patch for drivers/macintosh/Makefile is necessary for successful
compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
which is possible with the latest version of the new input layer. (Not
that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
that's another story).

AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
the current bk tree. I'm also doing additional config fixes, so that ADB-
less pmacs can remove all the ADB stuffs and keep the PMU for example.
CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...

Someone recently wrote that one could have both /dev/adbmouse and
/dev/input/mice working at the same time, so I tried this, too. And I
*could* select CONFIG_ADBMOUSE without CONFIG_ADB_KEYBOARD, only it
didn't compile due to undefined variables. My patch fixes these, but
indeed it is probably better to change the config.in files to forbid
this choice.

quoted

I have 3 other pet peeves that I would like to recall:

- I think the new input layer with CONFIG_INPUT_ADBHID=y and
CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
that they differ from what all other kernels from the oldest times up to
linux-pmac-devel before yesterday were giving. The tables,
mac_keycodes[]
in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c, are probably correct. But then
adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
if it detects an ISO ADB keyboard. IMHO the swapping should occur for
USB
keyboards and not for ADB keyboards. I had some discussion with Franz
which was not conclusive.

They need to be fixed in the userland keymaps. We had it wrong at first.
Some keyboards have those actually swapped, and Franz cold should be ok
(it was tested with all sorts of keyboards, AFAIK, and now, a fixed
keymap should give good results everywhere).

I wouldn't mind changing the keymaps, but I really would like to use the
same keymaps for 2.2.x kernels, for 2.4.0-test kernels with
CONFIG_ADB_KEYBOARD and with CONFIG_INPUT_ADBHID.

quoted

- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
variable, therefore stopping Mozilla from running. This is so weird (but
consistent since several months) that I have not the faintest idea where
it could come from. It is a feature of linux-pmac-devel, not present in
linux-bk-devel.

The two kernels are now in sync. Do you still have the problem ?

Yes, it is still there, I just verified. There must be some difference
between Paul's kernel and the bitkeeper tree that causes this. Here is
another strange observation:

I type "printenv", and LD_LIBARY_PATH is listed with the other env
variables (with "env", it does not get listed). Now I use the newly
recovered strace (see below) to try to understand what printenv does
differently from env. Well, "strace printenv" does not show
LD_LIBARY_PATH any more!

quoted

- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
from working. I have no idea what's wrong, but it would be nice to have
a working strace again.

AFAIK, Paul pushed a fix for that in bk a couple of days ago.

Yes, sorry, you are right. strace works again. I had tried it with a
kernel from 2 days ago. I see now Paul's yesterday's 1-line fix in
arch/ppc/kernel/entry.S. Very good!

Ben.

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

I wouldn't mind changing the keymaps, but I really would like to use the
same keymaps for 2.2.x kernels, for 2.4.0-test kernels with
CONFIG_ADB_KEYBOARD and with CONFIG_INPUT_ADBHID.

Well, my kernel for now are the only 2.2 to contain the new stuff and
support for linux keycodes. It's currently a different implementation
than the one in 2.4. I beleive that at a given point in the future, we'll
inherit from the 2.4 version in our 2.2 kernels via the USB backport.

Yes, it is still there, I just verified. There must be some difference
between Paul's kernel and the bitkeeper tree that causes this. Here is
another strange observation:

I type "printenv", and LD_LIBARY_PATH is listed with the other env
variables (with "env", it does not get listed). Now I use the newly
recovered strace (see below) to try to understand what printenv does
differently from env. Well, "strace printenv" does not show
LD_LIBARY_PATH any more!

Ok, I'll look if I see something, but we are in parts of the kernel here
that I don't know very well. Paul, any idea ?

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

Martin Costabel writes:

- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
variable, therefore stopping Mozilla from running. This is so weird (but
consistent since several months) that I have not the faintest idea where
it could come from. It is a feature of linux-pmac-devel, not present in
linux-bk-devel.

Found this one. :-)  Thanks for alerting me to it.  This was because I
have some mods in my tree to add extra aux table entries for the ppc
cache line size.  I was using the numbers assigned in the Sys V ABI
but these conflict with numbers assigned to other things by linux.
The end result was that ld.so always thought it was loading a setuid
program and therefore disabled LD_LIBRARY_PATH.  It's now fixed in my
rsync tree.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

Found this one. :-)  Thanks for alerting me to it.  This was because I
have some mods in my tree to add extra aux table entries for the ppc
cache line size.  I was using the numbers assigned in the Sys V ABI
but these conflict with numbers assigned to other things by linux.
The end result was that ld.so always thought it was loading a setuid
program and therefore disabled LD_LIBRARY_PATH.  It's now fixed in my
rsync tree.

BTW. The cset I sent you contains code from Dan Malek that implements an
elegant solution to the CPU detection stuff by emulating the "mfspr"
instruction when issued from userland. We can also (not done yet)
masquerade the CPU (by letting it think it's a G3 and not a G4 when
altivec is not enabled in the kernel for example).


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

quoted

AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
the current bk tree. I'm also doing additional config fixes, so that ADB-
less pmacs can remove all the ADB stuffs and keep the PMU for example.
CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...

Someone recently wrote that one could have both /dev/adbmouse and
/dev/input/mice working at the same time, so I tried this, too. And I
*could* select CONFIG_ADBMOUSE without CONFIG_ADB_KEYBOARD, only it
didn't compile due to undefined variables. My patch fixes these, but
indeed it is probably better to change the config.in files to forbid
this choice.

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 adbmouse driver only relies on the keyboard driver for mouse button
emulation. At least in 2.2.17, it won't interfere with the new input code,
I haven't tried 2.4.0 yet.

	Michael

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

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 adbmouse driver only relies on the keyboard driver for mouse button
emulation. At least in 2.2.17, it won't interfere with the new input code,
I haven't tried 2.4.0 yet.

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.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

Paul Mackerras wrote:

Michael Schmitz writes:

quoted

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/

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..

Well, that's the reason why I originally wanted this compatibility code.
However, after more thinking, I figured out that if we do that, all it
will result is yet another configuration mess with users and more support
emails ;)

Note that you can have the new input layer with 2.2 using my kernels. I
still have to verify what's up with Vojtech, but I beleive the input
layer is part of the USB backport, meaning that future "kernel.org"
2.2s+backport will provide the same functionality as 2.4.

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

quoted

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..

Well, that's the reason why I originally wanted this compatibility code.
However, after more thinking, I figured out that if we do that, all it
will result is yet another configuration mess with users and more support
emails ;)

We'll have the configuration mess either way. And few things are as
frustrating as answering the question 'why does the screen just keep
flashing on me when I boot this new 2.4 kernel, and how do I fix it' a
hundred times.

Note that you can have the new input layer with 2.2 using my kernels. I

Which has working adbmouse if you remove all #ifndef INPUT_MOUSEDEV and
corresponding #endif in adbmouse.c.

still have to verify what's up with Vojtech, but I beleive the input
layer is part of the USB backport, meaning that future "kernel.org"
2.2s+backport will provide the same functionality as 2.4.

Meaning that functionality will be lost ... thanks for the warning.

	Michael


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