Right now drivers/input/keybdev.o depends on drivers/char/keyboard.o for
handle_scancode, keyboard_tasklet and kbd_ledfunc. However, compiling
drivers/char/keyboard.o isn't quite straight forward, as we have:
ifndef CONFIG_SUN_KEYBOARD
obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
else
obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)
endif
in drivers/char/Makefile
To attempt to work around this, I've come up with the following patch
for drivers/input/Config.in. Comments?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
===== drivers/input/Config.in 1.2 vs edited =====
--- 1.2/drivers/input/Config.in Tue Feb 5 00:45:17 2002
+++ edited/drivers/input/Config.in Tue Jun 25 08:58:41 2002
@@ -6,7 +6,12 @@
comment 'Input core support'
tristate 'Input core support' CONFIG_INPUT
-dep_tristate ' Keyboard support' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
+if [ "$CONFIG_SUN_KEYBOARD" = "y" -a "$CONFIG_PCI" = "y"]; then
+ define_bool CONFIG_SUN_CAN_INPUT_KEYBDEV y
+fi
+if [ "$CONFIG_VT" = "y" -o "$CONFIG_SUN_CAN_INPUT_KEYBDEV" = "y" ]; then
+ dep_tristate ' Keyboard support' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
+fi
dep_tristate ' Mouse support' CONFIG_INPUT_MOUSEDEV $CONFIG_INPUT
if [ "$CONFIG_INPUT_MOUSEDEV" != "n" ]; then
int ' Horizontal screen resolution' CONFIG_INPUT_MOUSEDEV_SCREEN_X 1024
On Wed, 26 Jun 2002 02:06, Tom Rini wrote:
> Right now drivers/input/keybdev.o depends on drivers/char/keyboard.o for
> handle_scancode, keyboard_tasklet and kbd_ledfunc. However, compiling
> drivers/char/keyboard.o isn't quite straight forward, as we have:
> ifndef CONFIG_SUN_KEYBOARD
> obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
> else
> obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)
> endif
> in drivers/char/Makefile
>
> To attempt to work around this, I've come up with the following patch
> for drivers/input/Config.in. Comments?
Here is a bit of arch/i386/config.in:
<extract>
# input before char - char/joystick depends on it. As does USB.
#
source drivers/input/Config.in
source drivers/char/Config.in
</extract>
So it will still crap out, because CONFIG_VT and CONFIG_SUN_KEYBOARD won't be
set early enough.
Three possible options, none of them especially good:
1. Do various munging of config and make setup and try to cover this.
2. Move keyboard handling code to input subsystem
3. Do wholesale backport of input subsystem from 2.5
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> On Wed, 26 Jun 2002 02:06, Tom Rini wrote:
> > Right now drivers/input/keybdev.o depends on drivers/char/keyboard.o for
> > handle_scancode, keyboard_tasklet and kbd_ledfunc. However, compiling
> > drivers/char/keyboard.o isn't quite straight forward, as we have:
> > ifndef CONFIG_SUN_KEYBOARD
> > obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
> > else
> > obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)
> > endif
> > in drivers/char/Makefile
> >
> > To attempt to work around this, I've come up with the following patch
> > for drivers/input/Config.in. Comments?
> Here is a bit of arch/i386/config.in:
> <extract>
> # input before char - char/joystick depends on it. As does USB.
> #
> source drivers/input/Config.in
> source drivers/char/Config.in
> </extract>
Boy, it would be nice if that was mentioned somewhere else. :) alpha,
mips, and mips64 get that wrong..
> So it will still crap out, because CONFIG_VT and CONFIG_SUN_KEYBOARD won't be
> set early enough.
Well CONFIG_SUN_KEYBOARD is define_bool'ed at the begining on
sparc/sparc64 (and PCI is asked before input, so that is OK). But
CONFIG_VT makes things less fun..
> Three possible options, none of them especially good:
> 1. Do various munging of config and make setup and try to cover this.
Probably harder than it's worth.
> 2. Move keyboard handling code to input subsystem
I think that will work out the best. How's the attached look? It moves
drivers/input/Config.in inside of drivers/char/Config.in and then fixes
arches which had both. (Lightly tested from xconfig[1] for all arches
which got changed).
> 3. Do wholesale backport of input subsystem from 2.5
Not really an option (and 2.5 has this problem anyhow) since it's so
invasive, once it's done.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
[1] xconfig because it tends to be the easiest to break.
===== arch/alpha/config.in 1.15 vs edited =====
--- 1.15/arch/alpha/config.in Sat May 25 19:37:06 2002
+++ edited/arch/alpha/config.in Wed Jun 26 07:30:11 2002
@@ -397,7 +397,6 @@
endmenu
source drivers/usb/Config.in
-source drivers/input/Config.in
source net/bluetooth/Config.in
===== arch/arm/config.in 1.14 vs edited =====
--- 1.14/arch/arm/config.in Fri Apr 5 12:12:20 2002
+++ edited/arch/arm/config.in Wed Jun 26 07:30:24 2002
@@ -554,11 +554,6 @@
fi
endmenu
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source drivers/input/Config.in
-
source drivers/char/Config.in
if [ "$CONFIG_ARCH_ACORN" = "y" -a \
"$CONFIG_BUSMOUSE" = "y" ]; then
===== arch/cris/config.in 1.10 vs edited =====
--- 1.10/arch/cris/config.in Tue Feb 5 07:10:18 2002
+++ edited/arch/cris/config.in Wed Jun 26 07:30:29 2002
@@ -222,10 +222,6 @@
fi
endmenu
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source drivers/input/Config.in
source drivers/char/Config.in
#source drivers/misc/Config.in
===== arch/i386/config.in 1.28 vs edited =====
--- 1.28/arch/i386/config.in Tue Apr 16 04:30:28 2002
+++ edited/arch/i386/config.in Wed Jun 26 07:30:32 2002
@@ -375,10 +375,6 @@
fi
endmenu
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source drivers/input/Config.in
source drivers/char/Config.in
#source drivers/misc/Config.in
===== arch/ia64/config.in 1.9 vs edited =====
--- 1.9/arch/ia64/config.in Sat Mar 9 13:41:04 2002
+++ edited/arch/ia64/config.in Wed Jun 26 07:30:36 2002
@@ -203,10 +203,6 @@
fi # !HP_SIM
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source drivers/input/Config.in
source drivers/char/Config.in
#source drivers/misc/Config.in
===== arch/m68k/config.in 1.8 vs edited =====
--- 1.8/arch/m68k/config.in Fri Mar 1 05:29:44 2002
+++ edited/arch/m68k/config.in Wed Jun 26 07:42:36 2002
@@ -171,10 +171,6 @@
source net/Config.in
fi
-if [ "$CONFIG_MAC" = "y" ]; then
- source drivers/input/Config.in
-fi
-
mainmenu_option next_comment
comment 'ATA/IDE/MFM/RLL support'
@@ -396,6 +392,10 @@
if [ "$CONFIG_VT" = "y" ]; then
bool 'Support for console on virtual terminal' CONFIG_VT_CONSOLE
fi
+fi
+
+if [ "$CONFIG_MAC" = "y" ]; then
+ source drivers/input/Config.in
fi
if [ "$CONFIG_ATARI" = "y" ]; then
===== arch/mips/config.in 1.6 vs edited =====
--- 1.6/arch/mips/config.in Thu Feb 28 06:57:19 2002
+++ edited/arch/mips/config.in Wed Jun 26 07:30:46 2002
@@ -628,7 +628,6 @@
fi
source drivers/usb/Config.in
-source drivers/input/Config.in
mainmenu_option next_comment
comment 'Kernel hacking'
===== arch/mips64/config.in 1.6 vs edited =====
--- 1.6/arch/mips64/config.in Thu Feb 28 06:57:19 2002
+++ edited/arch/mips64/config.in Wed Jun 26 07:30:50 2002
@@ -325,7 +325,6 @@
fi
source drivers/usb/Config.in
-source drivers/input/Config.in
mainmenu_option next_comment
comment 'Kernel hacking'
===== arch/ppc/config.in 1.17 vs edited =====
--- 1.17/arch/ppc/config.in Fri Apr 5 03:38:55 2002
+++ edited/arch/ppc/config.in Wed Jun 26 07:31:14 2002
@@ -321,8 +321,6 @@
fi
endmenu
-source drivers/input/Config.in
-
mainmenu_option next_comment
comment 'Macintosh device drivers'
===== arch/ppc64/config.in 1.2 vs edited =====
--- 1.2/arch/ppc64/config.in Fri Mar 29 03:18:26 2002
+++ edited/arch/ppc64/config.in Wed Jun 26 07:31:19 2002
@@ -170,8 +170,6 @@
source drivers/video/Config.in
endmenu
-source drivers/input/Config.in
-
if [ "$CONFIG_PPC_ISERIES" = "y" ]; then
mainmenu_option next_comment
comment 'iSeries device drivers'
===== arch/sh/config.in 1.6 vs edited =====
--- 1.6/arch/sh/config.in Tue Feb 5 07:10:15 2002
+++ edited/arch/sh/config.in Wed Jun 26 07:43:22 2002
@@ -275,11 +275,6 @@
fi
endmenu
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source drivers/input/Config.in
-
# if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then
# source drivers/maple/Config.in
# fi
@@ -312,6 +307,8 @@
"$CONFIG_SH_SOLUTION_ENGINE" = "y" ]; then
bool 'Heartbeat LED' CONFIG_HEARTBEAT
fi
+
+source drivers/input/Config.in
if [ "$CONFIG_SH_DREAMCAST" = "y" -a "$CONFIG_MAPLE" != "n" ]; then
mainmenu_option next_comment
===== drivers/char/Config.in 1.28 vs edited =====
--- 1.28/drivers/char/Config.in Fri May 3 01:49:04 2002
+++ edited/drivers/char/Config.in Wed Jun 26 07:28:09 2002
@@ -137,6 +137,8 @@
source drivers/i2c/Config.in
+source drivers/input/Config.in
+
mainmenu_option next_comment
comment 'Mice'
tristate 'Bus Mouse Support' CONFIG_BUSMOUSE
===== drivers/input/Config.in 1.2 vs edited =====
--- 1.2/drivers/input/Config.in Tue Feb 5 00:45:17 2002
+++ edited/drivers/input/Config.in Tue Jun 25 08:58:41 2002
@@ -6,7 +6,12 @@
comment 'Input core support'
tristate 'Input core support' CONFIG_INPUT
-dep_tristate ' Keyboard support' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
+if [ "$CONFIG_SUN_KEYBOARD" = "y" -a "$CONFIG_PCI" = "y"]; then
+ define_bool CONFIG_SUN_CAN_INPUT_KEYBDEV y
+fi
+if [ "$CONFIG_VT" = "y" -o "$CONFIG_SUN_CAN_INPUT_KEYBDEV" = "y" ]; then
+ dep_tristate ' Keyboard support' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
+fi
dep_tristate ' Mouse support' CONFIG_INPUT_MOUSEDEV $CONFIG_INPUT
if [ "$CONFIG_INPUT_MOUSEDEV" != "n" ]; then
int ' Horizontal screen resolution' CONFIG_INPUT_MOUSEDEV_SCREEN_X 1024
On Thu, 27 Jun 2002 00:46, Tom Rini wrote:
> On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> > 2. Move keyboard handling code to input subsystem
>
> I think that will work out the best. How's the attached look? It moves
> drivers/input/Config.in inside of drivers/char/Config.in and then fixes
> arches which had both. (Lightly tested from xconfig[1] for all arches
> which got changed).
I'm opposed to further junk going into drivers/char. It is already an
incomprehensible mess of unrelated code.
> > 3. Do wholesale backport of input subsystem from 2.5
>
> Not really an option (and 2.5 has this problem anyhow) since it's so
> invasive, once it's done.
Concur with the invasiveness angle.
Actually, I've got another idea, based on some stuff that I've been working on
for the ACPI "its not just power management" issue.
If you need to set something in drivers/input (per your original patch) that
depends on things that are set in drivers/char (or drivers/usb, anything that
comes later), then split the Config.in into two sections. One section
contains the normal Config.in user-selectable options, and a second
drivers/input/Config-post.in, that is sourced in at the end of
arch/foo/config.in and contains only automated Config.in dependancies (ie
define_bool) but no user selectable options.
Does this make sense? If not, I'll try for a patch that shows it later this
morning.
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Thu, Jun 27, 2002 at 06:58:04AM +1000, Brad Hards wrote:
> On Thu, 27 Jun 2002 00:46, Tom Rini wrote:
> > On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> > > 2. Move keyboard handling code to input subsystem
> >
> > I think that will work out the best. How's the attached look? It moves
> > drivers/input/Config.in inside of drivers/char/Config.in and then fixes
> > arches which had both. (Lightly tested from xconfig[1] for all arches
> > which got changed).
>
> I'm opposed to further junk going into drivers/char. It is already an
> incomprehensible mess of unrelated code.
drivers/char/Config.in isn't too bad right now. If you skip over the
horrific mess that is serial support, anyhow. Perhaps moving some of
the arch-specific questions out to arch/$(ARCH)/config.in
> Actually, I've got another idea, based on some stuff that I've been working on
> for the ACPI "its not just power management" issue.
>
> If you need to set something in drivers/input (per your original patch) that
> depends on things that are set in drivers/char (or drivers/usb, anything that
> comes later), then split the Config.in into two sections. One section
> contains the normal Config.in user-selectable options, and a second
> drivers/input/Config-post.in, that is sourced in at the end of
> arch/foo/config.in and contains only automated Config.in dependancies (ie
> define_bool) but no user selectable options.
>
> Does this make sense? If not, I'll try for a patch that shows it later this
> morning.
I don't think this makes sense for input however, unless we kill off
drivers/input/Config.in (and for sh/m68k/sparc64 just paste the lines
in) and merge it into drivers/char/Config.in (CONFIG_INPUT,
CONFIG_INPUT_{KEYB,MOUSE,EV}DEV) and drivers/char/joystick/Config.in
(CONFIG_INPUT_JOYSTICK). I wouldn't be opposed to doing that...
And for USB (CONFIG_INPUT'ed) joysticks we aren't any worse off, and
perhaps we could even move those into a USB menu.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, 27 Jun 2002 07:23, Tom Rini wrote:
> On Thu, Jun 27, 2002 at 06:58:04AM +1000, Brad Hards wrote:
> > On Thu, 27 Jun 2002 00:46, Tom Rini wrote:
> > > On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> > > > 2. Move keyboard handling code to input subsystem
> > >
> > > I think that will work out the best. How's the attached look? It
> > > moves drivers/input/Config.in inside of drivers/char/Config.in and then
> > > fixes arches which had both. (Lightly tested from xconfig[1] for all
> > > arches which got changed).
> >
> > I'm opposed to further junk going into drivers/char. It is already an
> > incomprehensible mess of unrelated code.
>
> drivers/char/Config.in isn't too bad right now. If you skip over the
> horrific mess that is serial support, anyhow. Perhaps moving some of
> the arch-specific questions out to arch/$(ARCH)/config.in
I meant from a user viewpoint. It is just a mish-mash of essentially unrelated
questions. I'd prefer to see options moved into menus that describe them.
Ideally about a screen length of options (for variable screen resolutions and
xconfig vs menuconfig :-)
So mice and joysticks are kind-of input things, so they belong with other
input config options.
Similarly, DRM and AGP are video options, so they belong together in a video
section (certainly not in a character device options section). Maybe with
other console options (although the concept of console is a bit strange in
the era of desktop unix) like framebuffer and VT.
Serial can bugger off by itself.
ftape is a mass storage thing, and belongs with other mass storage options
like block devices, ide and scsi.
i2c and watchdog cards are basically for system monitoring.
> > Actually, I've got another idea, based on some stuff that I've been
> > working on for the ACPI "its not just power management" issue.
> >
> > If you need to set something in drivers/input (per your original patch)
> > that depends on things that are set in drivers/char (or drivers/usb,
> > anything that comes later), then split the Config.in into two sections.
> > One section contains the normal Config.in user-selectable options, and a
> > second drivers/input/Config-post.in, that is sourced in at the end of
> > arch/foo/config.in and contains only automated Config.in dependancies (ie
> > define_bool) but no user selectable options.
> >
> > Does this make sense? If not, I'll try for a patch that shows it later
> > this morning.
>
> I don't think this makes sense for input however, unless we kill off
> drivers/input/Config.in (and for sh/m68k/sparc64 just paste the lines
> in) and merge it into drivers/char/Config.in (CONFIG_INPUT,
> CONFIG_INPUT_{KEYB,MOUSE,EV}DEV) and drivers/char/joystick/Config.in
> (CONFIG_INPUT_JOYSTICK). I wouldn't be opposed to doing that...
I think that I've explained it poorly. I'll patch.
> And for USB (CONFIG_INPUT'ed) joysticks we aren't any worse off, and
> perhaps we could even move those into a USB menu.
That is where most of the input stuff came from :-)
My main concern is that by 2.6, I don't want the current mess with Config
options. I want something that is logical and makes sense to people. Right
now, the only reliable way to get a build is to either check every menu (and
submenu, and subsubmenu), or to take a previously working config for that
machine, make oldconfig, and hope for the best.
That sucks.
We go to all this effort to write clean, beautiful code. Then we make it nigh
on impossible for non-gurus to get the most out of it.
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Thu, Jun 27, 2002 at 09:43:33AM +1000, Brad Hards wrote:
> On Thu, 27 Jun 2002 07:23, Tom Rini wrote:
> > On Thu, Jun 27, 2002 at 06:58:04AM +1000, Brad Hards wrote:
> > > On Thu, 27 Jun 2002 00:46, Tom Rini wrote:
> > > > On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> > > > > 2. Move keyboard handling code to input subsystem
> > > >
> > > > I think that will work out the best. How's the attached look? It
> > > > moves drivers/input/Config.in inside of drivers/char/Config.in and then
> > > > fixes arches which had both. (Lightly tested from xconfig[1] for all
> > > > arches which got changed).
> > >
> > > I'm opposed to further junk going into drivers/char. It is already an
> > > incomprehensible mess of unrelated code.
> >
> > drivers/char/Config.in isn't too bad right now. If you skip over the
> > horrific mess that is serial support, anyhow. Perhaps moving some of
> > the arch-specific questions out to arch/$(ARCH)/config.in
>
> I meant from a user viewpoint. It is just a mish-mash of essentially unrelated
> questions. I'd prefer to see options moved into menus that describe them.
> Ideally about a screen length of options (for variable screen resolutions and
> xconfig vs menuconfig :-)
It could use some sort of re-org I suppose. But not in 2.4 :)
> > > Actually, I've got another idea, based on some stuff that I've been
> > > working on for the ACPI "its not just power management" issue.
> > >
> > > If you need to set something in drivers/input (per your original patch)
> > > that depends on things that are set in drivers/char (or drivers/usb,
> > > anything that comes later), then split the Config.in into two sections.
> > > One section contains the normal Config.in user-selectable options, and a
> > > second drivers/input/Config-post.in, that is sourced in at the end of
> > > arch/foo/config.in and contains only automated Config.in dependancies (ie
> > > define_bool) but no user selectable options.
> > >
> > > Does this make sense? If not, I'll try for a patch that shows it later
> > > this morning.
> >
> > I don't think this makes sense for input however, unless we kill off
> > drivers/input/Config.in (and for sh/m68k/sparc64 just paste the lines
> > in) and merge it into drivers/char/Config.in (CONFIG_INPUT,
> > CONFIG_INPUT_{KEYB,MOUSE,EV}DEV) and drivers/char/joystick/Config.in
> > (CONFIG_INPUT_JOYSTICK). I wouldn't be opposed to doing that...
>
> I think that I've explained it poorly. I'll patch.
I'm not sure. :) It's a 6 question menu, keep in mind... (With 1 that
actually depends on something else, code-wise. Which is why if we
really want to try and clean up the logic and compile issues,
drivers/input/Config.in should probably die... (Or never be called
directly on arches which do get drivers/char/Config.in) And some of the
joystick stuff re-arranged..
> > And for USB (CONFIG_INPUT'ed) joysticks we aren't any worse off, and
> > perhaps we could even move those into a USB menu.
>
> That is where most of the input stuff came from :-)
heh.
> My main concern is that by 2.6, I don't want the current mess with Config
> options. I want something that is logical and makes sense to people. Right
> now, the only reliable way to get a build is to either check every menu (and
> submenu, and subsubmenu), or to take a previously working config for that
> machine, make oldconfig, and hope for the best.
Hopefully with 2.6 the input stuff won't suck as much.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/