linux-kernel - Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore

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: <20091023085824.GA7199@core.coreip.homeip.net>
Date:	Fri, 23 Oct 2009 01:58:24 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Éric Piel <eric.piel@...mplin-utc.net>
Cc:	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not  work
	anymore

On Fri, Oct 23, 2009 at 10:08:41AM +0200, Éric Piel wrote:
> Op 22-10-09 20:19, Dmitry Torokhov schreef:
> > On Thu, Oct 22, 2009 at 07:48:47PM +0200, Éric Piel wrote:
> >> I don't think so: xorg 1.6.5, with xinput-evdev 2.2.5. They are both  
> >> latest or second latest stable versions.
> >>
> >> In the log I see this:
> >> (--) SynPS/2 Synaptics TouchPad: touchpad found
> >> (II) PS/2 Generic Mouse: Device reopened after 1 attempts.
> >> (EE) AT Translated Set 2 keyboard: device key_bitmask has changed
> >> (EE) AT Translated Set 2 keyboard: Device has changed - disabling.
> >>
> >> Quite a few people seem to have the same problem.
> > 
> > The bitmask should not be changing on it's own... Any chance you could
> > save contents or /proc/bus/input/devices before suspend and after resume
> > (when X decides to ditch the keyboard) and diff them?
> > 
> Hello,
> I've just tried this: before and after is exactly the same (attached is
> a copy of it).
> 

What about before X starts? Can you please boot into console, kill
hal and udev to make sure they don't mess up with the keymap and, after
doing

	echo -n rescan > /sys/bus/serio/devices/serio0/drvctl

which should completely reinitialize keyboard and compare
/proc/bus/input/devices again? If it is still the same then there must
be a silly bug in X's evdev... But regardless, X policy of comparing
keybit is stupid - they don't kill the device if I change keymap while
in X, why do they do that on resume? Or when I change the limits on
absolute axis... Oh well.

-- 
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/