linux-kernel - Re: [git pull] Input updates for 2.6.34-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100804062021.GA25742@core.coreip.homeip.net>
Date:	Tue, 3 Aug 2010 23:20:22 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, Bastien Nocera <hadess@...ess.net>,
	Anisse Astier <anisse@...ier.eu>
Subject: Re: [git pull] Input updates for 2.6.34-rc6

On Fri, May 14, 2010 at 08:16:34AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 14 May 2010, Matthew Garrett wrote:
> >
> > I've done some experimentation under qemu. On ACPI systems, Windows will 
> > *only* touch the keyboard controller if there's a device with an 
> > appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> > Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> > their keyboard probing is also somewhat different to ours, but that's 
> > probably another story.
> 
> Well, I'd hate to lose the keyboard hotplug capability, but at the same 
> time, it _is_ 2010, and while I have personally used it historically, I 
> don't really foresee ever using it again.
> 
> So we _could_ decide to just try it, and see if anybody screams. If nobody 
> does, that would be a very simple solution to the problem.
> 

OK, time to ressurect the topic ;)

There is another report (from Anisse - CCed) - MSI AE2220 stops for 10
seconds when we try to see if "AUX DISABLE" command took effect (it
doesn't). While we should reduce the time we wait and retry to something
more reasonable it woudl not fix this issue completely.

The box does not have any PS/2 ports but in this case BIOS writers _did_
some crack and put PS/2 devices in DSDT. While the devices are most
likely not active and thus Matthew's patch would help Anisse I do hate
to loose the option of plugging PS/2 mouse/keyboard after boot and
having chance of them working. I would still like to add a few blacklist
entries instead.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/