After upgrading to xorg 1.6 during a routine system update on on an ~amd64 system the keyboard (PS/2) and mouse (usb) ceased to operate. The xorg 1.6 upgrade guide does not provide any documentation on how to configure HAL based input, and the 1.5 guide barely mentions it. I feel a switch to HAL as the default input menthod to be the likely explanation for input configurations suddenly ceasing to work. There are keyboard options (such as which key is the compose key), and mouse options (such as how to map extra buttons) that I want to keep, but now I have no idea how to configure them due to insufficient upgrade documentation. Reproducible: Always Steps to Reproduce: Expected Results: An upgrade guide that either documents or links to documentation required to use the new configuration methods.
Further investigation while SSHed in to it... (II) LoadModule: "evdev" (II) Loading /usr/lib64/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.5.3, module version = 2.2.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (EE) module ABI major version (2) doesn't match the server's version (4) (II) UnloadModule: "evdev" (II) Unloading /usr/lib64/xorg/modules/input//evdev_drv.so (EE) Failed to load module "evdev" (module requirement mismatch, 0) (EE) No input driver matching `evdev' (EE) config/hal: NewInputDeviceRequest failed (15) (II) config/hal: Adding input device AT Translated Set 2 keyboard (II) LoadModule: "evdev" (II) Loading /usr/lib64/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.5.3, module version = 2.2.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (EE) module ABI major version (2) doesn't match the server's version (4) (II) UnloadModule: "evdev" (II) Unloading /usr/lib64/xorg/modules/input//evdev_drv.so (EE) Failed to load module "evdev" (module requirement mismatch, 0) (EE) No input driver matching `evdev' (EE) config/hal: NewInputDeviceRequest failed (15) (II) config/hal: Adding input device Microsoft Microsoft IntelliMouse? Optical (II) LoadModule: "evdev" (II) Loading /usr/lib64/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.5.3, module version = 2.2.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (EE) module ABI major version (2) doesn't match the server's version (4) (II) UnloadModule: "evdev" (II) Unloading /usr/lib64/xorg/modules/input//evdev_drv.so (EE) Failed to load module "evdev" (module requirement mismatch, 0)
Not our problem; reassigning.
You need to rebuild your drivers like the ebuild suggests. No HAL code has changed with 1.6, all the relevant sections from the 1.5 guide still apply. I agree, though, our overall X guides could be better but that issue is already handled in another bug. Thanks
Which other bug. Could you please close this bug in the same way that the other (In reply to comment #3) > You need to rebuild your drivers like the ebuild suggests. I never did figure out how to get paludis to notify me properly, -usually- it isn't an issue. > I agree, though, our overall X guides could be better but that issue is already > handled in another bug. Which other bug? Why wasn't this closed against it? (That way anyone who finds this and not the other bug can reach it)
(In reply to comment #4) > I never did figure out how to get paludis to notify me properly, -usually- it > isn't an issue. You should get in touch with paludis people to see if this is a bug or not. ewarn/elog messages are _very_ important and ignoring them shouldn't be an option. > Which other bug? Why wasn't this closed against it? (That way anyone who finds > this and not the other bug can reach it) There are several open bugs, this is a much broader subject. And I didn't close this bug against any of them since your core issue was the missing rebuild, not a documentation problem. Thanks
This is a documentation issue, the issue I ran in to -should- be listed in the upgrade guide as it is one issue that could occur. It's not difficult to miss something like that among all the other warnings that pop up. It's also more of a dependency checking issue, but that's another bug too. Where paludis puts important logs is an issue, when you do paludis -i world to upgrade everything the comments can scroll off of screen's buffer, manually redirecting logs to a file would just make for something too large to skim through. Could you please update the documentation to list that as one of the things to check for, since it is an upgrade issue? (In reply to comment #5) > (In reply to comment #4) > > I never did figure out how to get paludis to notify me properly, -usually- it > > isn't an issue. > > You should get in touch with paludis people to see if this is a bug or not. > ewarn/elog messages are _very_ important and ignoring them shouldn't be an > option. > > > Which other bug? Why wasn't this closed against it? (That way anyone who finds > > this and not the other bug can reach it) > > There are several open bugs, this is a much broader subject. And I didn't close > this bug against any of them since your core issue was the missing rebuild, not > a documentation problem. > > Thanks >
(In reply to comment #6) > This is a documentation issue, the issue I ran in to -should- be listed in the > upgrade guide as it is one issue that could occur. It's not difficult to miss > something like that among all the other warnings that pop up. This doesn't belong in a version-specific guide since _all_ versions of X break the module ABI. The ebuild already gives you the exact command to rebuild your drivers. The upgrade guide is about specific changes from the last releases. So no, that won't change. Sorry. > It's also more > of a dependency checking issue, but that's another bug too. There's no dependency bug either. A given version of an X driver can work against various versions of the X server. Drivers just have to be rebuilt to use the new X server API/ABI. > Where paludis puts important logs is an issue, when you do paludis -i world to > upgrade everything the comments can scroll off of screen's buffer, manually > redirecting logs to a file would just make for something too large to skim > through. Portage keeps an internal log of elog/ewarn messages and redisplays them at the end of an emerge phase. I'm not trying to blame you here, but I'm not going to change my ebuilds because paludis has some weird behavior. That's either up to you or paludis devs to fix. :) Thanks
> > > It's also more > > of a dependency checking issue, but that's another bug too. > > There's no dependency bug either. A given version of an X driver can work > against various versions of the X server. Drivers just have to be rebuilt to > use the new X server API/ABI. > > > Where paludis puts important logs is an issue, when you do paludis -i world to > > upgrade everything the comments can scroll off of screen's buffer, manually > > redirecting logs to a file would just make for something too large to skim > > through. > > Portage keeps an internal log of elog/ewarn messages and redisplays them at the > end of an emerge phase. So does paludis, however I already stated why I missed it, and that's beside the point. There is still one open issue, the guide. > (In reply to comment #6) > > This is a documentation issue, the issue I ran in to -should- be listed in the > > upgrade guide as it is one issue that could occur. It's not difficult to miss > > something like that among all the other warnings that pop up. > > This doesn't belong in a version-specific guide since _all_ versions of X break > the module ABI. The ebuild already gives you the exact command to rebuild your > drivers. The upgrade guide is about specific changes from the last releases. > > So no, that won't change. Sorry. It should change, it is a -known- bug with known workarounds that is NOT documented in the upgrade documentation. Therefore the upgrade documentation is not complete. If the error spans multiple versions then the solution is to have a version independent list of such potential issues and link to it in the list of problems. Listing the solution to this issue in an area where it -can- be missed, which can cause a computer to come up in such a way that an average user would be unable to recover it is not good enough. Please consider documenting this issue in the upgrade guides so that at least if it does happen, the chance of an annoying bug being filed about a known issue is much reduced. Thank you
