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