Bugzilla Bug 251093

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 an attachment (id=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 an attachment (id=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] [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.

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 an attachment (id=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 an attachment (id=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. ***