Hi,
It took me about an hour to find out why my keyboard didn't work in 2.5.45.
Well... after all it seemed that I need to enable 4 ! options inside the
input configuration, just to get my default, nothing special PS/2 keyboard up
and running. Oh, and I didn't even have my not so fancy boring default PS/2
mouse configured then. Guys, being able to configure everything is nice, but
with the 2.5 kernel, things are definitely getting out of control IMHO.
Jos
> It took me about an hour to find out why my keyboard didn't work in 2.5.45.
> Well... after all it seemed that I need to enable 4 ! options inside the
> input configuration, just to get my default, nothing special PS/2 keyboard up
> and running. Oh, and I didn't even have my not so fancy boring default PS/2
> mouse configured then. Guys, being able to configure everything is nice, but
> with the 2.5 kernel, things are definitely getting out of control IMHO.
don't blame your inability to understand the consequences of copying a .config
across ~50 kernel releases on others thank you.
--
tomas szepe <[email protected]>
On Sunday 03 November 2002 17:05, Tomas Szepe wrote:
> > It took me about an hour to find out why my keyboard didn't work in
> > 2.5.45. Well... after all it seemed that I need to enable 4 ! options
> > inside the input configuration, just to get my default, nothing special
> > PS/2 keyboard up and running. Oh, and I didn't even have my not so fancy
> > boring default PS/2 mouse configured then. Guys, being able to configure
> > everything is nice, but with the 2.5 kernel, things are definitely
> > getting out of control IMHO.
>
> don't blame your inability to understand the consequences of copying a
> .config across ~50 kernel releases on others thank you.
I wont, as long as you don blame someone who -to prevent buggy config files-
downloaded a fresh 2.5.45 kernel, patched it with the bk-1 update and ran
make menuconfig after that, of copying .config files.
Jos
Jos Hulzink wrote:
>It took me about an hour to find out why my keyboard didn't work in 2.5.45.
>Well... after all it seemed that I need to enable 4 ! options inside the
>input configuration, just to get my default, nothing special PS/2 keyboard up
>and running. Oh, and I didn't even have my not so fancy boring default PS/2
>mouse configured then. Guys, being able to configure everything is nice, but
>with the 2.5 kernel, things are definitely getting out of control IMHO.
>
>
This is potentially becoming a FAQ... I ran into this too, as did
several people in the office. People who compile custom kernels seem to
run into this when they first jump into 2.5.x. AT Keyboard support is
definitely buried :/
Unfortunately I don't have any concrete suggestions for Vojtech (input
subsystem maintainer), just a request that it becomes easier and more
obvious how to configure the keyboard and mouse that is found on > 90%
of all Linux users computers [IMO]...
Jeff
On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> Jos Hulzink wrote:
>
> >It took me about an hour to find out why my keyboard didn't work in 2.5.45.
> >Well... after all it seemed that I need to enable 4 ! options inside the
> >input configuration, just to get my default, nothing special PS/2 keyboard up
> >and running. Oh, and I didn't even have my not so fancy boring default PS/2
> >mouse configured then. Guys, being able to configure everything is nice, but
> >with the 2.5 kernel, things are definitely getting out of control IMHO.
> >
> >
>
> This is potentially becoming a FAQ... I ran into this too, as did
> several people in the office. People who compile custom kernels seem to
> run into this when they first jump into 2.5.x. AT Keyboard support is
> definitely buried :/
>
> Unfortunately I don't have any concrete suggestions for Vojtech (input
> subsystem maintainer), just a request that it becomes easier and more
> obvious how to configure the keyboard and mouse that is found on > 90%
> of all Linux users computers [IMO]...
Too bad you don't have any suggestions. I completely agree this should
be simplified, while I wouldn't be happy to lose the possibility of not
compiling AT keyboard support in.
--
Vojtech Pavlik
SuSE Labs
Dear diary, on Sun, Nov 03, 2002 at 08:07:05PM CET, I got a letter,
where Vojtech Pavlik <[email protected]> told me, that...
> On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> > Jos Hulzink wrote:
> >
> > >It took me about an hour to find out why my keyboard didn't work in 2.5.45.
> > >Well... after all it seemed that I need to enable 4 ! options inside the
> > >input configuration, just to get my default, nothing special PS/2 keyboard up
> > >and running. Oh, and I didn't even have my not so fancy boring default PS/2
> > >mouse configured then. Guys, being able to configure everything is nice, but
> > >with the 2.5 kernel, things are definitely getting out of control IMHO.
> > >
> > >
> >
> > This is potentially becoming a FAQ... I ran into this too, as did
> > several people in the office. People who compile custom kernels seem to
> > run into this when they first jump into 2.5.x. AT Keyboard support is
> > definitely buried :/
> >
> > Unfortunately I don't have any concrete suggestions for Vojtech (input
> > subsystem maintainer), just a request that it becomes easier and more
> > obvious how to configure the keyboard and mouse that is found on > 90%
> > of all Linux users computers [IMO]...
>
> Too bad you don't have any suggestions. I completely agree this should
> be simplified, while I wouldn't be happy to lose the possibility of not
> compiling AT keyboard support in.
Well, why can't it be enabled by default? Other options are as well, and it's
IMHO sane to enable keyboard and mice support by default. It should clear up
the initial confusion as well.
I think that these options should be enabled by default:
[Userland interfaces]
Mouse interface
Legacy /dev/psaux (?)
(I suggest to make this non-default in 2.7, but maybe
we want shorter transition period?)
[Input I/O drivers]
Serial i/o support
i8042
Serial port line discipline
[Input device drivers]
Keyboards
AT keyboard support
Mice
Serial mouse (?)
(..or maybe not, this is really not so common as PS/2
lately)
PS/2 mouse
I think that those are absolute minimum and if anyone will want to have any of
these explicitly off, he's more likely to know where to turn it off, rather
than vice versa.
--
Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
-- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
On Sunday 03 November 2002 20:07, Vojtech Pavlik wrote:
> On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> > Unfortunately I don't have any concrete suggestions for Vojtech (input
> > subsystem maintainer), just a request that it becomes easier and more
> > obvious how to configure the keyboard and mouse that is found on > 90%
> > of all Linux users computers [IMO]...
>
> Too bad you don't have any suggestions. I completely agree this should
> be simplified, while I wouldn't be happy to lose the possibility of not
> compiling AT keyboard support in.
Something I have been thinking about for a while is a quick-config option
(that sets some defaults that hold for 90% of the systems), or an expert mode
that shows extra options. Though I understand that this is hard to do, and
much hardware differs, I think it can be done for some basics like keyboard,
mouse, USB and stuff.
Yes, this will cause your kernel to be bigger than optimal, for some drivers
will be compiled in that are not used on your system. But if you want you can
optimize things away after clicking <set defaults for standard IBM PC>.
If this idea is not blown away immediately, I'm willing to work this idea out
a little, though I can understand that people call me an idiot...
Jos
On Sunday 03 November 2002 21:13, Vojtech Pavlik wrote:
>
> All the needed options ARE enabled by default. (check arch/i386/defconfig)
Now all you need is the users to know "make defconfig". I compile kernels since 1.2.13, but I didn't know the option till today. Sure, my fault, but I'm sure I'm not the only one.
Detail: IMHO the USB keyboard and mouse support should be on, and DRI should be enabled for all video cards, but that is a minor issue...
Jos
Then perhaps the internal speaker could be moved...
Regards, Dean.
On Sun, 3 Nov 2002 20:07:05 +0100 Vojtech Pavlik <[email protected]> wrote:
On Sun, Nov 03, 2002 at 08:37:34PM +0100, Petr Baudis wrote:
> Dear diary, on Sun, Nov 03, 2002 at 08:07:05PM CET, I got a letter,
> where Vojtech Pavlik <[email protected]> told me, that...
> > On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> > > Jos Hulzink wrote:
> > >
> > > >It took me about an hour to find out why my keyboard didn't work in 2.5.45.
> > > >Well... after all it seemed that I need to enable 4 ! options inside the
> > > >input configuration, just to get my default, nothing special PS/2 keyboard up
> > > >and running. Oh, and I didn't even have my not so fancy boring default PS/2
> > > >mouse configured then. Guys, being able to configure everything is nice, but
> > > >with the 2.5 kernel, things are definitely getting out of control IMHO.
> > > >
> > > >
> > >
> > > This is potentially becoming a FAQ... I ran into this too, as did
> > > several people in the office. People who compile custom kernels seem to
> > > run into this when they first jump into 2.5.x. AT Keyboard support is
> > > definitely buried :/
> > >
> > > Unfortunately I don't have any concrete suggestions for Vojtech (input
> > > subsystem maintainer), just a request that it becomes easier and more
> > > obvious how to configure the keyboard and mouse that is found on > 90%
> > > of all Linux users computers [IMO]...
> >
> > Too bad you don't have any suggestions. I completely agree this should
> > be simplified, while I wouldn't be happy to lose the possibility of not
> > compiling AT keyboard support in.
>
> Well, why can't it be enabled by default? Other options are as well, and it's
> IMHO sane to enable keyboard and mice support by default. It should clear up
> the initial confusion as well.
All the needed options ARE enabled by default. (check arch/i386/defconfig)
> I think that those are absolute minimum and if anyone will want to have any of
> these explicitly off, he's more likely to know where to turn it off, rather
> than vice versa.
--
Vojtech Pavlik
SuSE Labs
On Sun, 3 Nov 2002 20:07:05 +0100
Vojtech Pavlik <[email protected]> wrote:
>
> Too bad you don't have any suggestions. I completely agree this should
> be simplified, while I wouldn't be happy to lose the possibility of not
> compiling AT keyboard support in.
What about:
<*> serial i/o (mouse, keyboard...) support"
<*> PC PS/2 and keyboard controller (i8042)
<*> PS/2 mouse support
<*> Typical (AT) keyboard support
<*> Serial port (COM) <something> support
<*> Serial port (COM) mouse support
[*] Advanced keyboard support
<*> Other keyboards here
<*> [the other Things]
Yes, it confuses people who only wants a mouse working.
Still i think it's better than selecting the driver controller
and after that selecting the device controller (if i'm understanding
the current menu ;) BTW, we'll never be able to put a <*> Mouse support
so i think that this is the best way.
Also, the current menu has some things that i dislike ;)
- Please, don't use names such "i8042 ". Most of the people
(even people in this list i guess) didn't know what
a i8042 controller is until they had to configure that ;)
"Help" is the right place for explainig that i guess ;)
- Replace "mice" by "mouse support" or something. English isn't the only
language in the earth. Many people think that the plural
of "mouse" is "mouses" ;)
- In the current menu, you can disable the i8042 thing and you still can see
the [*] Keyboard entry alone.
and another (crap) suggestion could be to put the pc speaker support under a /proc/something
and remove the menu entry ;)
Vojtech Pavlik wrote:
> Too bad you don't have any suggestions. I completely agree this should
> be simplified, while I wouldn't be happy to lose the possibility of not
> compiling AT keyboard support in.
Why not set the default option for AT Keyboard support on i386 platforms to
"Y"?
Cheers,
Nicholas
Jos Hulzink wrote:
> Hi,
>
> It took me about an hour to find out why my keyboard didn't work in
> 2.5.45. Well... after all it seemed that I need to enable 4 ! options
> inside the input configuration, just to get my default, nothing special
> PS/2 keyboard up and running. Oh, and I didn't even have my not so fancy
> boring default PS/2 mouse configured then. Guys, being able to configure
> everything is nice, but with the 2.5 kernel, things are definitely getting
> out of control IMHO.
>
Stop whining, 2.5 kernels are development kernels -> not *expected* to work
%100!
Cheers,
Nicholas
On Sun, 03 Nov 2002 15:38:21 -0500
Nicholas Wourms <[email protected]> wrote:
> Stop whining, 2.5 kernels are development kernels -> not *expected* to work
> %100!
But they are expected to be configured not so hardly
On Sunday 03 November 2002 21:38, Nicholas Wourms wrote:
> Stop whining, 2.5 kernels are development kernels -> not *expected* to
> work %100!
Correct me if I'm wrong, but we're here to work out the problems. That's
one of the major meanings of "development", in my experience.
I was bitten too: I loaded my 2.4.19 configuration and looked through most
options, but I overlooked this keyboard/mouse thing. I think it's not
turned on by default if you load an existing configuration, which is
probably not what we want.
--
Ciao,
Flavio Stanchina
Trento - Italy
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty. Beauty is not love.
Love is not music. Music is the best.
-- Frank Zappa
Flavio Stanchina wrote:
> On Sunday 03 November 2002 21:38, Nicholas Wourms wrote:
>
>
>>Stop whining, 2.5 kernels are development kernels -> not *expected* to
>>work %100!
>
>
> Correct me if I'm wrong, but we're here to work out the problems. That's
> one of the major meanings of "development", in my experience.
>
> I was bitten too: I loaded my 2.4.19 configuration and looked through most
> options, but I overlooked this keyboard/mouse thing. I think it's not
> turned on by default if you load an existing configuration, which is
> probably not what we want.
>
This is true, but if you are going to make a report, make a
report, don't advocate changing something which works for
most as it stands. From the subject, one got the idea that
people wanted to do some willy-nilly rearranging of the
configure options. The real issue here is that you really
should *not* be copying 2.4 .config's over to a 2.5 tree.
That way you'll be forced to go through all the options and
get the proper "default" options for your platform enabled
automatically.
Cheers,
Nicholas
On Sunday 03 November 2002 22:22, Nicholas Wourms wrote:
> This is true, but if you are going to make a report, make a
> report, don't advocate changing something which works for
> most as it stands. From the subject, [...]
I agree, the subject is misleading.
> [...] The real issue here is that you really
> should *not* be copying 2.4 .config's over to a 2.5 tree.
Why souldn't I be able to do that? I was hoping that options missing from
the loaded config would be set to the default value, which in the case of
standard AT keyboard and PS/2 mouse is "yes, of course I want that".
> That way you'll be forced to go through all the options and
> get the proper "default" options for your platform enabled
> automatically.
How long will it take to go through all the options, your old config file
at hand, and check that everything you need is there? How easy would it be
to make a mistake?
--
Ciao,
Flavio Stanchina
Trento - Italy
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty. Beauty is not love.
Love is not music. Music is the best.
-- Frank Zappa
On Sunday 03 November 2002 03:39 pm, Jos Hulzink wrote:
> On Sunday 03 November 2002 20:07, Vojtech Pavlik wrote:
> > On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> > > Unfortunately I don't have any concrete suggestions for Vojtech (input
> > > subsystem maintainer), just a request that it becomes easier and more
> > > obvious how to configure the keyboard and mouse that is found on > 90%
> > > of all Linux users computers [IMO]...
> >
> > Too bad you don't have any suggestions. I completely agree this should
> > be simplified, while I wouldn't be happy to lose the possibility of not
> > compiling AT keyboard support in.
>
> Something I have been thinking about for a while is a quick-config option
> (that sets some defaults that hold for 90% of the systems), or an expert
> mode that shows extra options. Though I understand that this is hard to do,
> and much hardware differs, I think it can be done for some basics like
> keyboard, mouse, USB and stuff.
I like this idea!
> Yes, this will cause your kernel to be bigger than optimal, for some
> drivers will be compiled in that are not used on your system. But if you
> want you can optimize things away after clicking <set defaults for standard
> IBM PC>.
How about running the "quick config", which I can then use a base to
customize?
> If this idea is not blown away immediately, I'm willing to work this idea
> out a little, though I can understand that people call me an idiot...
Not at all!
-Nick
On Sun, Nov 03, 2002 at 08:07:05PM +0100, Vojtech Pavlik wrote:
> > Unfortunately I don't have any concrete suggestions for Vojtech (input
> > subsystem maintainer), just a request that it becomes easier and more
> > obvious how to configure the keyboard and mouse that is found on > 90%
> > of all Linux users computers [IMO]...
>
> Too bad you don't have any suggestions. I completely agree this should
> be simplified, while I wouldn't be happy to lose the possibility of not
> compiling AT keyboard support in.
Last month or so I suggested adding a hint for Appletalk, and I see
that it is there now:
config LLC
tristate "ANSI/IEEE 802.2 Data link layer protocol (IPX, Appletalk)"
Such parenthetical remarks will no doubt help a little.
You might try
--- Kconfig~ Thu Oct 31 14:15:06 2002
+++ Kconfig Sun Nov 3 22:51:45 2002
@@ -5,7 +5,7 @@
menu "Input device support"
config INPUT
- tristate
+ tristate "Input devices (needed for mouse, keyboard, ...)"
default y
---help---
Say Y here if you have any input device (mouse, keyboard, tablet,
and
--- Kconfig~ Thu Oct 31 14:15:06 2002
+++ Kconfig Sun Nov 3 22:54:28 2002
@@ -2,7 +2,7 @@
# Input core configuration
#
config SERIO
- tristate "Serial i/o support"
+ tristate "Serial i/o support (needed for keyboard and mouse)"
---help---
Say Yes here if you have any input device that uses serial I/O to
communicate with the system. This includes the
(and maybe also sth under keyboard, to tell people that what they have
is called an AT keyboard).
Andries
On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> This is potentially becoming a FAQ... I ran into this too, as did
> several people in the office. People who compile custom kernels seem to
> run into this when they first jump into 2.5.x. AT Keyboard support is
> definitely buried :/
Documentation isn't enough. It _has_ to be made simpler.
Its obvious that this is the #1 stumbling block to a 2.5 virgin right now.
I fell over it myself when I merged it, as did Linus I believe.
It's just not obvious enough.
Having it documented obviously isn't enough too. I covered this in
the document[*] I wrote last week, which got ~3000 direct hits, ~7000
or so on Linux-today, and god knows how many elsewhere.
(Either that, or my description of the problem sucked).
Dave
[*] http://www.codemonkey.org.uk/post-halloween-2.5.txt
--
| Dave Jones. http://www.codemonkey.org.uk
On Sun, Nov 03, 2002 at 04:22:48PM -0500, Nicholas Wourms wrote:
> Flavio Stanchina wrote:
> >On Sunday 03 November 2002 21:38, Nicholas Wourms wrote:
> >
> >
> >>Stop whining, 2.5 kernels are development kernels -> not *expected* to
> >>work %100!
> >
> >
> >Correct me if I'm wrong, but we're here to work out the problems. That's
> >one of the major meanings of "development", in my experience.
> >
> >I was bitten too: I loaded my 2.4.19 configuration and looked through most
> >options, but I overlooked this keyboard/mouse thing. I think it's not
> >turned on by default if you load an existing configuration, which is
> >probably not what we want.
> >
>
> This is true, but if you are going to make a report, make a
> report, don't advocate changing something which works for
> most as it stands. From the subject, one got the idea that
> people wanted to do some willy-nilly rearranging of the
> configure options. The real issue here is that you really
> should *not* be copying 2.4 .config's over to a 2.5 tree.
> That way you'll be forced to go through all the options and
> get the proper "default" options for your platform enabled
> automatically.
So here goes the suggestion:
The config gets a version-Tag.
Changes before the second dot in the version print a warning that you
should not copy configs between major-versions. (Maybe it is better to
default to exit with the warning and an option to override the exit.)
Only configs without a version-Tag are tricky. Maybe there is a good(tm)
config-option that can be used to guess if the config is from the
current major-version (=2.5). All other configs are "old(tm)".
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Dear diary, on Sun, Nov 03, 2002 at 09:13:08PM CET, I got a letter,
where Vojtech Pavlik <[email protected]> told me, that...
> On Sun, Nov 03, 2002 at 08:37:34PM +0100, Petr Baudis wrote:
> > Dear diary, on Sun, Nov 03, 2002 at 08:07:05PM CET, I got a letter,
> > where Vojtech Pavlik <[email protected]> told me, that...
> > > Too bad you don't have any suggestions. I completely agree this should
> > > be simplified, while I wouldn't be happy to lose the possibility of not
> > > compiling AT keyboard support in.
> >
> > Well, why can't it be enabled by default? Other options are as well, and it's
> > IMHO sane to enable keyboard and mice support by default. It should clear up
> > the initial confusion as well.
>
> All the needed options ARE enabled by default. (check arch/i386/defconfig)
Yes, but if this will be in the Kconfig as well (I mean adding "default y"
lines, I can make a patch, if there's a desire), it will be offered as default
even when doing make oldconfig, which is what most of the people is going to do
(not make defconfig, most of people doesn't even know it exists and the rest
probably wants to configure 2.5 based on their 2.4 configuration anyway).
--
Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
-- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 4 Nov 2002 08:59, Dave Jones wrote:
> On Sun, Nov 03, 2002 at 12:52:48PM -0500, Jeff Garzik wrote:
> > This is potentially becoming a FAQ... I ran into this too, as did
> > several people in the office. People who compile custom kernels seem to
> > run into this when they first jump into 2.5.x. AT Keyboard support is
> > definitely buried :/
>
> Documentation isn't enough. It _has_ to be made simpler.
> Its obvious that this is the #1 stumbling block to a 2.5 virgin right now.
> I fell over it myself when I merged it, as did Linus I believe.
> It's just not obvious enough.
This is a general merging issue. I personally didn't get affected (because USB
only is good), but it was a big problem for 2.4.19-pre10, when HID input
support became optional (so you can have HID for an embedded USB UPS server,
without getting bloat).
The idea of using a kernel revisioning system is good, but things change
between any two kernels (2.4.19-pre9 and 2.4.19-pre10 in this case).
Suggest that the kernel .config should be revisioned, and if the version
doesn't match, make $BUILDTARGET (eg bzImage, vmlinux, modules, whatever)
should not run. make install and make modules_install shouldn't run either.
Instead, if the version differences are minor (definition TBA), then make
[|x|menu|old|m]config should copy the old .config to an alternative name (eg.
.config-previous) and then for each option, we should pull from
.config-previous, then def-config (if no entry in .config-previous), which
we'd then have as a default. and allow the user to override.
Also note that this will NOT solve the problem described. When you move
functionality into an existing section, which is turned off, you have to
check every option. Consider the impact of creating a "make kernel boot"
option three levels down in the AX.25 code. 99% of kernel builders wouidn't
see it. Generally you only get this level of breakage in unstable series, so
people need to rebuild their config from scratch anyway. Also, the intent of
some options changes (consider those that no longer need any SCSI, because
their IDE CD-RW device is now native)
Fundamentally, if you don't know how to build the configuration, this is a
good time to learn, even if only by trial and error.
Brad
- --
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9xaCaW6pHgIdAuOMRAiGlAJ9bHWOxXDameBdHyKhFQLfuImUmGgCgop2w
NE66gEzpN4hNzPAoR4uMTcg=
=jxzW
-----END PGP SIGNATURE-----
Hello,
this patch (against 2.5.45) introduces sane defaults for the input layer
configuration. The most common options default to yes now, so that with simply
accepting defaults provided by make oldconfig, the 2.4 configuration can be
converted to 2.5 configuration while preserving the basic keyboard, mouse and
serial port support. This should prevent most users confusion when configuring
their first 2.5 kernel. Please apply.
drivers/input/Kconfig | 2 ++
drivers/input/keyboard/Kconfig | 2 ++
drivers/input/mouse/Kconfig | 2 ++
drivers/input/serio/Kconfig | 3 +++
4 files changed, 9 insertions(+)
Kind regards,
Petr Baudis
diff -ru linux/drivers/input/Kconfig linux+pasky/drivers/input/Kconfig
--- linux/drivers/input/Kconfig Fri Nov 1 22:21:33 2002
+++ linux+pasky/drivers/input/Kconfig Sun Nov 3 23:21:35 2002
@@ -28,6 +28,7 @@
config INPUT_MOUSEDEV
tristate "Mouse interface"
+ default y
depends on INPUT
---help---
Say Y here if you want your mouse to be accessible as char devices
@@ -45,6 +46,7 @@
config INPUT_MOUSEDEV_PSAUX
bool "Provide legacy /dev/psaux device"
+ default y
depends on INPUT_MOUSEDEV
config INPUT_MOUSEDEV_SCREEN_X
diff -ru linux/drivers/input/keyboard/Kconfig linux+pasky/drivers/input/keyboard/Kconfig
--- linux/drivers/input/keyboard/Kconfig Fri Nov 1 22:21:34 2002
+++ linux+pasky/drivers/input/keyboard/Kconfig Sun Nov 3 23:24:40 2002
@@ -3,6 +3,7 @@
#
config INPUT_KEYBOARD
bool "Keyboards"
+ default y
depends on INPUT
help
Say Y here, and a list of supported keyboards will be displayed.
@@ -12,6 +13,7 @@
config KEYBOARD_ATKBD
tristate "AT keyboard support"
+ default y
depends on INPUT && INPUT_KEYBOARD && SERIO
---help---
Say Y here if you want to use the standard AT keyboard. Usually
diff -ru linux/drivers/input/mouse/Kconfig linux+pasky/drivers/input/mouse/Kconfig
--- linux/drivers/input/mouse/Kconfig Fri Nov 1 22:21:34 2002
+++ linux+pasky/drivers/input/mouse/Kconfig Sun Nov 3 23:22:27 2002
@@ -3,6 +3,7 @@
#
config INPUT_MOUSE
bool "Mice"
+ default y
depends on INPUT
help
Say Y here, and a list of supported mice will be displayed.
@@ -12,6 +13,7 @@
config MOUSE_PS2
tristate "PS/2 mouse"
+ default y
depends on INPUT && INPUT_MOUSE && SERIO
---help---
Say Y here if you have a PS/2 mouse connected to your system. This
diff -ru linux/drivers/input/serio/Kconfig linux+pasky/drivers/input/serio/Kconfig
--- linux/drivers/input/serio/Kconfig Fri Nov 1 22:21:34 2002
+++ linux+pasky/drivers/input/serio/Kconfig Sun Nov 3 23:22:58 2002
@@ -3,6 +3,7 @@
#
config SERIO
tristate "Serial i/o support"
+ default y
---help---
Say Yes here if you have any input device that uses serial I/O to
communicate with the system. This includes the
@@ -19,6 +20,7 @@
config SERIO_I8042
tristate "i8042 PC Keyboard controller"
+ default y
depends on SERIO
---help---
i8042 is the chip over which the standard AT keyboard and PS/2
@@ -34,6 +36,7 @@
config SERIO_SERPORT
tristate "Serial port line discipline"
+ default y
depends on SERIO
---help---
Say Y here if you plan to use an input device (mouse, joystick,
Dave Jones wrote:
> Having it documented obviously isn't enough too.
Maybe we need some heuristics for "upgrading" old .config files in
the event of a "make oldconfig". They could be of the form of rules
like this:
CONFIG_obsolete1 && CONFIG_obsolete2 -> CONFIG_new1=y, CONFIG_new2=y
(In a separate file, and entries would be aged. Maybe config tools
could even walk users through this interactively, or flag settings
obtained this way specially, e.g. with a similing wizard icon ;-)
Maybe even add some descriptive text after the rule.)
This still doesn't help for hard to find or obscurely named options,
but at least people upgrading wouldn't be bitten every time something
is renamed or restructured.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Matthias Schniedermeyer wrote:
> The config gets a version-Tag.
This would only be helpful if you also had a description of what the
user is expected to change. (And once you have this, you might as
well automate the process a little more, as I've just described in
another posting.)
Just telling the user that there might be problems isn't very helpful,
in particular since most such version conflicts would be false alarms,
e.g. name changes of some obscure controller I don't have anyway. I
think most people are aware of the fact that "make oldconfig" may
produce nonsense, but it's still annoying if it does.
Another easy extension to consider: after "make oldconfig", print
the options that were found in .config, but which don't exist anymore.
I've actually proposed this already two years ago, see also
http://marc.theaimsgroup.com/?l=linux-kernel&m=97298980521513&w=2
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Sun, 3 Nov 2002, Jos Hulzink wrote:
| On Sunday 03 November 2002 21:13, Vojtech Pavlik wrote:
| >
| > All the needed options ARE enabled by default. (check arch/i386/defconfig)
|
| Now all you need is the users to know "make defconfig". I compile kernels since 1.2.13, but I didn't know the option till today. Sure, my fault, but I'm sure I'm not the only one.
|
| Detail: IMHO the USB keyboard and mouse support should be on, and DRI should be enabled for all video cards, but that is a minor issue...
so while some people are attempting to "fix" this with
defconfig or mostlikelyconfig, I'd like to remind people
of the post-halloween doc from Dave Jones. He addresses
this stuff in there. Does it possibly need even more
emphasis there? and stronger hints for people to at
least browse it before using 2.5.x for the first time?
--
~Randy
On Mon, Nov 04, 2002 at 11:43:18AM +0900, Miles Bader wrote:
> Keep in mind that All the World's Not a PC. No doubt those options are
> enabled on the majority of kernels, by number, but linux supports many,
> many types of systems, and I'll bet on fair number of them, it doesn't
> make much sense to enable psaux mouse support!
> So ... instead of saying `default y' for these options, how about saying
> `default IM_ON_A_PC' where IM_ON_A_PC is defined somehow. How, I don't
> know; it could be a separate config question in a very obvious place,
> perhaps itself having `default X86'.
> Perhaps this should really be two flags, one IM_ON_A_PC meaning `typical
> i386 pc with legacy devices', and the other, more general, being
> something like IM_ON_A_WORKSTATION. Then wierd things like psaux would
> say `default IM_ON_A_PC', but more general things like keyboards would
> say `default IM_ON_A_WORKSTATION'.
> [Yeah, those names are sucky, I know...]
> Thanks,
> -Miles
How about a PC subarch and turning them on by default for it?
Bill
Petr Baudis <[email protected]> writes:
> > Too bad you don't have any suggestions. I completely agree this should
> > be simplified, while I wouldn't be happy to lose the possibility of not
> > compiling AT keyboard support in.
>
> Well, why can't it be enabled by default? Other options are as well, and it's
> IMHO sane to enable keyboard and mice support by default. It should clear up
> the initial confusion as well.
Keep in mind that All the World's Not a PC. No doubt those options are
enabled on the majority of kernels, by number, but linux supports many,
many types of systems, and I'll bet on fair number of them, it doesn't
make much sense to enable psaux mouse support!
So ... instead of saying `default y' for these options, how about saying
`default IM_ON_A_PC' where IM_ON_A_PC is defined somehow. How, I don't
know; it could be a separate config question in a very obvious place,
perhaps itself having `default X86'.
Perhaps this should really be two flags, one IM_ON_A_PC meaning `typical
i386 pc with legacy devices', and the other, more general, being
something like IM_ON_A_WORKSTATION. Then wierd things like psaux would
say `default IM_ON_A_PC', but more general things like keyboards would
say `default IM_ON_A_WORKSTATION'.
[Yeah, those names are sucky, I know...]
Thanks,
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
Hello All , The tools everyone has been discussing & thinking
about out loud are nice items to have .
But has -anyone- thought of documenting the new structure &
placing the url/referance into the 'README' ? Please ?
Tia , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+