|
Bugzilla – Full Text Bug Listing |
| Summary: | broken evdev (configuration?) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | darren winter <sgt-d> |
| Component: | X.Org | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | ms |
| Version: | Alpha 5 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
xorg.conf after install (bad)
xorg log when using bad xorg.conf |
||
|
Description
darren winter
2007-08-08 13:07:22 UTC
Please attach xorg.conf created during installation, which didn't work for you most of the time and /var/log/Xorg.0.log when using this xorg.conf. Thanks. since nobody has acknowledged anything on this report yet... i have installed all of the odd numbered alphas, starting with #1... and now beta 1. in every instance, x failed to start after installation, and reboot. runlevel 5 has been reached, blah blah, text login. i have probably re-installed a total of 15 times and i always end up with the same thing. my brother and 3 of my friends, same thing. no X after install. we have to keep moving the borked xorg.conf out of the way and then copying xorg.conf.install to a new xorg.conf just to get it to work. i was on irc last night in the #suse channel and i had to offer this solution no less than 3 times to other users. the minor problem is that similar reports to this keep getting marked as "resolved in some bug #" but the cause of the problem hasn't been fixed. the major problem is that 10.3 final is less than 2 months away and the problem is still there. i will attach the files in just a second.... Created attachment 156955 [details]
xorg.conf after install (bad)
Created attachment 156956 [details]
xorg log when using bad xorg.conf
Speak english, boy! logs attached... Seems to be related to the "evdev" driver. Section "InputDevice" Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "20" Option "InputFashion" "Mouse" Option "Name" "Logitech USB Receiver" Option "Protocol" "event" Option "SendCoreEvents" "on" Option "Vendor" "Sysp" Option "ZAxisMapping" "4 5" EndSection (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules//input/evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (WW) Option "vendor" requires an integer value (II) evdev brain: Rescanning devices (1). (EE) PreInit returned NULL for "Mouse[1]" (WW) <default pointer>: No Device specified, looking for one... (II) <default pointer>: Setting Device option to "/dev/input/mice" (--) <default pointer>: Device: "/dev/input/mice" (==) <default pointer>: Protocol: "Auto" (**) Option "AlwaysCore" (**) <default pointer>: always reports core events (==) <default pointer>: Emulate3Buttons, Emulate3Timeout: 50 (**) <default pointer>: ZAxisMapping: buttons 4 and 5 (**) <default pointer>: Buttons: 9 (**) <default pointer>: Sensitivity: 1 (WW) No core pointer registered (II) XINPUT: Adding extended input device "<default pointer>" (type: MOUSE) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "Keyboard[0]" (type: KEYBOARD) (II) evdev brain: Rescanning devices (2). (--) <default pointer>: PnP-detected protocol: "ExplorerPS/2" (II) <default pointer>: ps2EnableDataReporting: succeeded No core pointer Fatal server error: failed to initialize core devices Seems to be a mouse, for which SaX2 uses by default the evdev driver, which obviously does not work. :-( For me this looks like a bug in configuration (SaX2). > Option "Vendor" "Sysp" > >(WW) Option "vendor" requires an integer value # man evdev Option "vendor" "integer" Specifies the vendor ID for the device you wish to use. This is either 0 (the default, matches anything), or the Vendor=<n> field in /proc/bus/input/devices for your device. This value should remain constant barring perhaps firmware updates to the device itself. Marcus, can you help investigating this issue. Most of the specified options for evdev driver look invalid to me ... *** This bug has been marked as a duplicate of bug 262317 *** interesting... myself and all of the people i know that have this problem are all running the logitech g5 gaming mouse.... ... and therefore are running the evdev instead of the mouse driver ... seems fixed in rc1 |