udev create a symlink to my mouse and /dev/input/js0
Of course then, game like etqw mistake js0 for a joystick and try use it with unexpected result from a mouse :P
No joystick is plug in that computer.
The mouse is usb :
This is a new mouse, so i'm not sure about other udev versions, but i've tried the 171-r2 & 171-r5
Just by its presence the /dev/input/js0 show a problem as i have 0 joystick, but xorg also see the mouse/joystick
[ 90339.278] (II) config/udev: Adding input device Microsoft Microsoft® SideWinder™ X3 Mouse (/dev/input/js0)
Steps to Reproduce:
1. plug the mouse
2. run etqw
3. mistake a joystick presence with the mouse
4. Easy workaround (until next udev start or plugin/out the mouse) -> rm /dev/input/js0
emerge --info udev
Portage 184.108.40.206 (default/linux/x86/10.0/desktop, gcc-4.4.3, glibc-2.12.2-r0, 220.127.116.11 i686)
System uname: Linux-18.104.22.168-i686-Intel-R-_Core-TM-_i7_CPU_950_@_3.07GHz-with-gentoo-2.1
Timestamp of tree: Thu, 29 Dec 2011 21:30:01 +0000
distcc 3.1 i686-pc-linux-gnu [enabled]
dev-lang/python: 2.7.2-r3, 3.2.2
sys-devel/autoconf: 2.13, 2.68
sys-devel/automake: 1.10.3, 1.11.1-r1
sys-kernel/linux-headers: 2.6.38 (virtual/os-headers)
Repositories: gentoo x-portage
CFLAGS="-march=core2 -O2 -pipe -mfpmath=sse"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=core2 -O2 -pipe -mfpmath=sse"
EMERGE_DEFAULT_OPTS="--buildpkg --autounmask=n --jobs=4 --keep-going --quiet-build=n --accept-properties=-interactive"
FEATURES="assume-digests binpkg-logs buildpkg distcc distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org ftp://mirror.ovh.net/gentoo-distfiles http://gentoo.mirror.sdv.fr/ http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
sys-fs/udev-171-r5 was built with the following:
USE="acl extras gudev hwdb keymap rule_generator -action_modeswitch -build -debug -edd -floppy -introspection (-selinux) -test"
Do you have this problem with >=sys-fs/udev-197-r2? If you do, reopen the bug. Thanks!
I won't go past 171 udev version, that is still in tree.
So i cannot test with 197-r2
I suppose this one will never get fix.
(In reply to comment #2)
> I won't go past 171 udev version, that is still in tree.
> So i cannot test with 197-r2
Bug 452556 -> The problems that blocked stabilization have been solved. Separate /usr is still supported. If you use uclibc, you can use 197-r3 and uclibc head and it is supported too. There is no reason to stick to 171 or switching to eudev other than a lot of FUD and the only thing they provide:
Support for older kernels than 2.6.39. If you use higher kernel, nothing is stopping you from upgrading for test.
> I suppose this one will never get fix.
You are right if you are sticking with 171 which will be removed after bug 452556 has been done. We don't have your hardware and setup to test the new version. If you don't plan on still testing it after reading this comment, you can change the status as RESOLVED, CANTFIX (or I'll do it after, depending on your reply here)
It's ok don't worry, but i prefer stick to udev-171 and live with that bug.
And your solve isn't one anyway, just another test to see if upstream has fix that.
(In reply to comment #4)
> It's ok don't worry, but i prefer stick to udev-171 and live with that bug.
> And your solve isn't one anyway, just another test to see if upstream has
> fix that.
To track the changes between 171 and 197 regarding the code involved with your problem would be a task requiring hours for someone not knowing the code inside out. So it's not unreasonable to ask an user to test the current at all, heck, if you had filed this to upstream bugtracking system, they would have asked you the same!
197-r3 is stable now on amd64, and soon as rest of the arch's are done, 171 will be gone.
(In reply to comment #5)
> To track the changes between 171 and 197 regarding the code involved with
> your problem would be a task requiring hours for someone not knowing the
> code inside out. So it's not unreasonable to ask an user to test the current
> at all, heck, if you had filed this to upstream bugtracking system, they
> would have asked you the same!
I never said it was unreasonable, just that for me, it's not an option.
And i know upstream would have force me to upgrade, but i didn't report this one upstream, but within my distro, as this version is still support by it.
You can at least grant me that by the time when i report this one, this was the case, even you are showing me it won't go long, and i was sure upstream have already drop support for that version.
Mr Suominen, you seems to make a mountain out of nothing, for a bug that i could easy workaround, and that i have agree & set cantfix myself, and already state you don't have to worry about it.
If by my french->english translate, i have upset you in some way, i'm sorry. It wasn't done for that. It was just a bug report for a minor annoyance.
If i upgrade udev, i will report its status (still bug or fix) with that newer version.
(In reply to comment #6)
> one upstream, but within my distro, as this version is still support by it.
Sorry, but it's not supported anymore.
> If i upgrade udev, i will report its status (still bug or fix) with that
> newer version.