Re: [bk patches] Long delayed input update

[Vojtech Pavlik <vojtech@suse.cz>]

On Mon, Jan 03, 2005 at 09:54:33PM -0800, Linus Torvalds wrote:

> I pulled and immediately unpulled again.
> 
> Vojtech, stuff like this is unacceptable:
> 
> 	PS/2 driver library (SERIO_LIBPS2) [N/m/y/?] (NEW) ?
> 
> 	Say Y here if you are using a driver for device connected
> 	to a PS/2 port, such as PS/2 mouse or standard AT keyboard.
> 
> Stop messing with peoples minds. The default config should contain
> keyboard and mouse support, and unless the user asks for "Embedded" or the
> year 2010 comes along and you can't find computers with non-USB keyboards
> anyway, that's how it's going to remain.

What machine this was on? Kernel config won't allow you to unselect that
option if AT Keyboard is selected, and that's always selected when
CONFIG_PC is.

> We had this _idiocy_ early in 2.5.x, and it caused untold silly problems. 
> We fixed it. We're not going to re-do that mistake.
> Please re-do your BK tree without this

I tested it then, and now again. And I can't get the prompt you're
getting.

	$ bk clone linus test
	$ cd test
	$ bk -r get
	$ make defconfig
	$ bk pull ../input
	$ make oldconfig

doesn't ask ANY questions.

I can imagine that option being asked about on a Mac, but there it might
make sense, or at least cause no harm if you enable it, even if it's
not needed.

> Also, considering that every
> _single_ time we've messed with the legacy keyboard/mouse controller there
> have been compatibility problems, I want to know what the advantages are.  

The changes to the keyboard/mouse controller code (i8042.c) are added
powermanagement callbacks, which are very much needed, and added ACPI
probing, which, although not strictly needed, is a less intrusive way of
detecting whether a kbd/mouse controller is present.

Regarding libps2, that doesn't touch the controller code itself, only
the mouse and keyboard drivers. It's a refactoring of the code,
eliminating a bunch of duplicate code which had a tendency of diverging
and that was causing problems. It shouldn't change any functionality per
se.

> Does the work actually _fix_ anything,

The refactoring itself didn't fix any problems, and it wasn't intended
to, but it uncovered some bugs that when fixed, made real problems go
away, like the ACK timeouts in RESET_BAT code path.

> and has it in any way been tested on the millions of different
> versions of kbd controller clones out there?

Does a few months in Andrew's tree count?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR