Thanks this mate (http://lists.ibiblio.org/pipermail/sm-users/2008-November/001184.html) but if after upgrading xorg-server to 1.5.3 your keyboard or mouse does not work any more, just do this ... > All, > > If, after updating to xorg-server 1.5.3, you no longer have the use of > a standard keyboard or mouse (using the kbd or mouse drivers), you will > want to add the following to /etc/X11/xorg.conf: > > Section "ServerFlags" > Option "AllowEmptyInput" "false" > EndSection > > > Otherwise devices using the kbd and mouse drivers will be disabled. > Devices using other inputs (e.g. synaptics or evdev) will continue to > work fine (with or without the above). > > -sandalle Reproducible: Always Steps to Reproduce: 1.sudo emerge =x11-base/xorg-server-1.5.3 2.logoff 3.reboot (or restart X11) et voilà !!!
I confirm problem and solution thank you
Also confirming problem and fix. Thinkpad T61p Nvidia Fx 570M.
Well, that's not a bug per se. It's how Xorg now works if you have USE=hal. You have 3 possibilities : 1) rebuild xorg-server with USE=-hal 2) use the AutoAddDevices/AutoEnableDevices/AllowEmptyInput options in your xorg.conf 3) remove all input sections from your xorg.conf and properly set-up HAL Basically, I think we/I need to document this. Thanks
Bear in mind that setting AllowEmptyInput to false while using evdev-2.1 will cause xorg to crach while pressing ctrl+c: http://bugs.archlinux.org/task/12372
(In reply to comment #3) > Basically, I think we/I need to document this. I agree. Because of the severity of this issue (I had to reboot my kernel with nox option), just add a warning to this ebuild and close this bug. Regards
*** Bug 252480 has been marked as a duplicate of this bug. ***
*** Bug 252433 has been marked as a duplicate of this bug. ***
Here is what worked for me (no need to remove input sections from xorg.conf): in xorg.conf 1.change driver for Mouse from "mouse" to "evdev" 2.change driver for Keyboard from "kbd" to "evdev" i tried removing all input sections and having hald adding the devices for me automatically but the keyboard repeat rate was bonkers.
(In reply to comment #8) > Here is what worked for me (no need to remove input sections from xorg.conf): > in xorg.conf > 1.change driver for Mouse from "mouse" to "evdev" > 2.change driver for Keyboard from "kbd" to "evdev" That is what did the trick for me, but I also needed to add evdev to INPUT_DEVICES in make.conf Also, another thing to check if you are using hal is to make sure you are starting hald as a boot service. I think adding a URL to this bug report at least as a comment at the end of the xorg-server build would be useful.
I think we can only solve this 'bug' by an upgrade guide and a big red flashing warning at the end of emerge xorg-server.
reemerging x11-base/xorg-server-1.5.3-r3 with -hal does not do the trick for me. i can't switch to evdev for mouse:( #261989 control-c crashes X with evdev-2.2.0-r1
(In reply to comment #11) > reemerging x11-base/xorg-server-1.5.3-r3 with -hal does not do the trick for > me. > i can't switch to evdev for mouse:( #261989 > control-c crashes X with evdev-2.2.0-r1 Let's keep bugs on topic, please. Open a new bug. Thanks
Created attachment 186497 [details] x11 upgrade guide v1 Sigh, finally! A small upgrade guide. If anyone wants to pitch in ideas, comments, text, I'm all ears. Donnie, how do we proceed with the stabilization ? Thanks
I think that would be interesting add specific information about setting keymap with "hal way", as most of users will need to do it. In summary, I did the following: cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/ And modify: <merge key="input.xkb.layout" type="string">us</merge> as needed (in my case, "es") I think that this guide should also include information for solving bug 236983 , but we need, at first, to know what exact options will allow most of users recover past synaptics behavior (we can discuss it in related bug) Thanks! :-)
Created attachment 186659 [details] basic trackpoint-specific configuration to get scroll function Added a basic configuration for trackpoint devices found on IBM/Lenovo Thinkpad notebooks. It makes scrolling via the trackpoint+3rd button possible as it is intended for use. I couldn't find an existing template for that in /usr/share/hal/fdi/policy/10osvendor and looked that one up on the web. Apart from that the standard 10-x11-input.fdi file works, loading evdev for the trackpoint. Imo we should either add that information to the manual, or include it in the list of templates.
(In reply to comment #14) > I think that would be interesting add specific information about setting keymap > with "hal way", as most of users will need to do it. In summary, I did the > following: > cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/ > > And modify: > <merge key="input.xkb.layout" type="string">us</merge> > > as needed (in my case, "es") Right, it makes sense to have these instructions directly in the upgrade guide. > I think that this guide should also include information for solving bug 236983 > , but we need, at first, to know what exact options will allow most of users > recover past synaptics behavior (we can discuss it in related bug) Not yet, I'll only put 2.1.3 on the upgrade list, we can do >=2.2.1 later on. (In reply to comment #15) > Created an attachment (id=186659) [edit] > basic trackpoint-specific configuration to get scroll function > > Added a basic configuration for trackpoint devices found on IBM/Lenovo Thinkpad > notebooks. It makes scrolling via the trackpoint+3rd button possible as it is > intended for use. I couldn't find an existing template for that in > /usr/share/hal/fdi/policy/10osvendor and looked that one up on the web. Apart > from that the standard 10-x11-input.fdi file works, loading evdev for the > trackpoint. > > Imo we should either add that information to the manual, or include it in the > list of templates. I guess trackpoint users needed to do that before evdev came to light. I'm not sure it's worth patching the driver to include those options. I'll add a note about evdev's man page though. Thanks
Created attachment 186694 [details] x11 upgrade guide v2 Here's an updated version of the upgrade guide. I think we're good for stabilization. All the basics are nicely covered. Banzai!
Created attachment 186706 [details] xml-ified version of remi's guide I converted remi's guide to GuideXML so he can post it to desktop/X project space. Source is in the attachment. Online version is available for preview here: http://dev.gentoo.org/~rane/other/upgrading-to-xorg-1.5.xml
Brilliant, thanks a bunch Łukasz!
(In reply to comment #16 > > I think that this guide should also include information for solving bug 236983 > > , but we need, at first, to know what exact options will allow most of users > > recover past synaptics behavior (we can discuss it in related bug) > > Not yet, I'll only put 2.1.3 on the upgrade list, we can do >=2.2.1 later on. But, isn't it a x11-drivers/xf86-input-synaptics "problem"? (not a x11-drivers/xf86-input-evdev one) Best regards :-)
Just a note that the current guide lists > INPUT_DRIVER="evdev" which really should say > INPUT_DEVICES="evdev" instead. (Unless, of course, this has changed since the last stable Xorg release... but then I guess this should be documented as well.)
(In reply to comment #20) > But, isn't it a x11-drivers/xf86-input-synaptics "problem"? (not a > x11-drivers/xf86-input-evdev one) Indeed, and I've added links on how to configure the synaptics driver. If you want to contribute an official "synatpics HOWTO", I'm sure we can work it out :) (In reply to comment #21) > Just a note that the current guide lists > > INPUT_DRIVER="evdev" > which really should say > > INPUT_DEVICES="evdev" > instead. (Unless, of course, this has changed since the last stable Xorg > release... but then I guess this should be documented as well.) Thanks for catching this. Fixed in cvs. I consider this bug to be solved. If you have any more issues with the upgrade guide, please open new bug reports. Thanks
*** Bug 274087 has been marked as a duplicate of this bug. ***