| Summary: | x11-base/xorg-server-1.5.3 upgrade guide | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Francois Chenier <belgix_oz> |
| Component: | [OLD] Server | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dpblnt, frossie, gengor, hkbst, jrmalaq, kristian.niemi, pacho, rane, stefan, voidprayer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 251832 | ||
| Attachments: |
x11 upgrade guide v1
basic trackpoint-specific configuration to get scroll function x11 upgrade guide v2 xml-ified version of remi's guide |
||
|
Description
Francois Chenier
2008-12-16 00:39:17 UTC
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. *** |
