I'm not really sure where the problem lies at (I'm not a developer). My problem is as follows: I have a buggy Logitech BT Mini-receiver, from time to time it likes to stop responding. I found that a quick fix for this is to unplug it, and plug it back in. If I'm using the kbd and mouse drivers with xorg this works fine. However if I use evdev, which I am trying to because I have an MX1000 and all 12 buttons are only recognized with evdev, It won't be re-recognized. I then have to exit X, make sure that it detects the proper event and replug it in. I thought that this was merely because it changes the event, it seems to go back and for between event2 and event3, when plugging and unplugging. I have tried changing the device to /dev/input/mice with my driver as evdev all buttons on the mouse continue to work properly like this, however, the bug still exists. Untested: Supposedly creating static udev rules will allow me to plug and unplug the device without it changing events. I'm going to try this but to improve quality this shouldn't have to be done. sofware versions: sys-kernel/gentoo-sources 2.6.15-r1 x11-drivers/xf86-input-evdev-1.0.0.5 virtual/x11-7.0-r1 x11-base/xorg-x11-7.0-r1 sys-fs/udev-087 Note: bug exists outside of my malfunctioning hardware, It just makes things more painful for me, because it forces me to unplug my hardware intermittently.
This sounds like yet another issue with the evdev driver to me (or possibly a useful enhancement). Please have a look around https://bugs.freedesktop.org for a similar issue, and file a new bug there if you can't find it. We'll see what they say about it. Meanwhile, you should probably try the static udev rule. It's possible this is something that should be fixed on the udev side of things.
> It's possible this is > something that should be fixed on the udev side of things. > that's what I was trying to figure out. who's problem this actually is. I'm sure it's upstream but I'm not sure which project. I'll check at freedesktop first.
The new evdev driver has been completely re-written and sounds like it might solve your problems. xf86-input-evdev 1.1.1 supposedly works with xorg-server 1.0.2, so if you want to give it a spin you'll have to edit the ebuild to drop the requirement on the newer server. If it does work, let me know and I'll drop the requirement in the tree.
>. If it does work, let me know and I'll > drop the requirement in the tree. > I'd love to help... but... I've never edited an ebuild in my life, and I don't know how to unmask a ~M package. Never neaded to... If you could tell me exactly what to do I'll test it, (or point me in the direction of a resources I can look at to figure this out.) I apologize for my ignorance, but am willing to help and learn.
Here's the overkill version: http://dev.gentoo.org/~plasmaroo/devmanual/ For what you need to do (as root in a terminal): 1) Unmask xf86-input-evdev-1.1.1. "echo =x11-drivers/xf86-input-evdev-1.1.1 >> /etc/portage/package.unmask" should do it. 2) Modify the ebuild. 2.a)Navigate to the category (by default it should sit at /usr/portage/x11-drivers/xf86-input-evdev - replace /usr/portage with $PORTDIR from make.conf if you've changed it). 2.b)Edit the ebuild xf86-input-evdev-1.1.1.ebuild with your editor of choice. There will be the following line: RDEPEND=">=x11-base/xorg-server-1.0.99" Change drop the version dependency so it reads: RDEPEND="x11-base/xorg-server" 3) You'll have to regenerate the package manifest so portage doesn't complain. While in the same directory, issue the command: "ebuild xf86-input-evdev-1.1.1.ebuild manifest". Now you can update the driver by "emerge -u xf86-input-evdev". If things die a horrible death, just remove the line from /etc/portage/package.unmask and downgrade the driver. The changes you made to the ebuild will only stay until the next time you sync. If you want them to be more permanent, read up on overlays :) forums.gentoo.org is another good resource.
thx for the quick walkthrough. I'll read the dev thing later too. unfortunately X wouldn't launch. here's the what I assume is the only relevant info for the xorg.0.log (II) evdev brain: Rescanning devices (1). (**) Option "CorePointer" (**) Mouse0-usb-0000:00:02.0-4.3/input0: Core Pointer (II) Mouse0-usb-0000:00:02.0-4.3/input0: Found 1 absolute axes. (II) Mouse0-usb-0000:00:02.0-4.3/input0: Configuring as pointer. (**) Mouse0-usb-0000:00:02.0-4.3/input0: Configuring in Absolute mode. (**) Mouse0-usb-0000:00:02.0-4.3/input0: AbsoluteScreen: -1. *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Backtrace: 0: /usr/bin/X(xf86SigHandler+0x9e) [0x80ba93e] then It dies. I've downgraded for the time being.
Alright, well, I still have a feeling the new driver will fix your problems. If you'd like, you'll need the masked xorg-server, mesa, and whatever drivers you use. If you want to wait for 7.1 to be officially released, we'll just leave this bug for now.
Created attachment 85524 [details] Xorg.0.log from alpha release I decided to try the new evdev driver (and X server blah blah). I'm attaching the xorg.log It crashed. It has backtraces and such not sure if they are useful. or if you can tell me what's going on...
I think XInputHotplug is the solution to this problem. https://bugs.freedesktop.org/show_bug.cgi?id=971 is the related bug for this. anyway these patches could make there way into portage? how would I get them applied?
We won't put the patches in until their actually applied upstream, which may happen soon if they're putting it in for 7.2. If you'd like to apply them yourself, you'll have to add the respective patches to the PATCHES variables of the proper ebuilds. Take a look at the xorg-server ebuild to see how this is done. Also, I just unmasked 7.1 - give it a try, there might have been some bugs fixed.
> Also, I just unmasked 7.1 - give it a try, there might have been some bugs > fixed. > I noticed that after I posted here, and had to file another bug http://bugs.gentoo.org/show_bug.cgi?id=135456 evdev receives same breakage I got when I tested it on alpha.
