|
Bugzilla – Full Text Bug Listing |
|
Description
Thomas Meindl
2007-04-07 20:45:52 UTC
Created attachment 129759 [details]
sax directory
Created attachment 129760 [details]
hwinfo --mouse
sax -p Chip: 0 is -> NVidia GeForce 7600 GS 03:00:0 0x10de 0x0392 AGP nv *** Bug 262318 has been marked as a duplicate of this bug. *** Created attachment 130843 [details]
forgot to attach sax.log
The evdev driver is used for your mouse. I have exactly the same
mouse with the same configuration running on my 10.2 machine
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
Stefan the log said:
(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
(**) Option "Device" "/dev/input/mice"
(==) <default pointer>: Emulate3Buttons, Emulate3Timeout: 50
(**) <default pointer>: ZAxisMapping: buttons 4 and 5
(**) <default pointer>: Buttons: 9
(WW) No core pointer registered
Thanks
Still waiting for the mouse... Do you need information from me or from Stefan? evdev fails gracefully with kernel 2.6.21-rc5. But I can remember that an self-written evdev configuration like the above was working in 10.2. Marcus, could you help here? See my comment #7. JFYI. Anything new about this topic? Using the evdev driver still fails in openSUSE 10.3 Alpha5 with 'No core pointer'. Will attach actual /var/log/Xorg.99.log Created attachment 146710 [details]
Xorg.99.log of openSUSE10.3 Alpha 5
*** Bug 288106 has been marked as a duplicate of this bug. *** *** Bug 288106 has been marked as a duplicate of this bug. *** Same bug bit me I have the same problem with openSUSE 10.3 alpha5+ ( had it in alpha 5 too). mouse: wireless MX laser 1000. problem evdev, protocol event solution change out evdev for mouse and comment out protocol event. >solution change out evdev for mouse and comment out protocol event.
Not really a solution, 'cause it will render special buttons (e.g. Tilt-Wheel) useless - and evdev was already working with G5.
Agreed, any bug that results in the installation to not complete should be marked as a show stopper anyways. Because of it when Sax2 refused to launch, and the second stage of installation won't complete. I agree. This is really annoying. My comment/solution was a workaround until a fix comes along. I recommend moving this to critical or even a blocker, as anyone with a logitech mouse that uses this driver will not be able to load xorg unless they use the work around Agreed, changed status to blocker. That seems to do the trick on openSUSE 10.3Beta1 with my G5 mouse: >> Inserted the following TWO sections into /etc/X11/xorg.conf : Section "InputDevice" Driver "mouse" Identifier "Mouse[1]" Option "Buttons" "7" Option "Device" "/dev/input/mice" Option "Name" "ExplorerPS/2 on USB" Option "Protocol" "ExplorerPS/2" Option "Vendor" "USB-Mouse" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Logitech G5" Driver "evdev" Option "AlwaysCore" Option "Name" "Logitech USB Gaming Mouse" #the following Option seems not necessary (don't know whether it would work): #Option "Device" "/dev/input//dev/input/by-id/usb-Logitech_USB_Gaming_Mouse-event-mouse" Option "ZAxisMapping" "4 5 6 7" Option "Emulate3Buttons" "false" EndSection >> And then the following into the Section "ServerLayout" : Section "ServerLayout" ... InputDevice "Mouse[1]" "CorePointer" InputDevice "Logitech G5" ... EndSection Now the X-Server fires up and the program xev shows me that also the so-called Tilt-Wheel, that means Button 7 and 8 (or so), does work. Recommend testing. Should it be working it should also be tested with with games (like Quake4), because there were problems with evdev in the past. I really, really hope this works, kind regards, Tom *** Bug 298398 has been marked as a duplicate of this bug. *** Find also some details in Bug #298398 (duplicate). Obviously I need to check if the evdev driver still works at all. Reassigning to Matthias again. Marcus, two questions:
1st) I thought evdev should be used for special mice only (thus the "Name" tag, which restricts the use for only this device). But there is no secondary mouse device indicated in the sax.log of attachment #130843 [details], and there should be one using the mouse driver and /dev/input/mice as input.
2nd) The mouse configuration sax uses:
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
specifies a "Vendor", and wrongly so according to the manpage:
Option "vendor" "integer"
Specifies the vendor ID for the device you wish to use.
This is either 0 (the default, matches anything), or the Ven‐
dor=<n> field in /proc/bus/input/devices for your device.
This value should remain constant barring perhaps firmware
updates to the device itself.
Could you check whether this is a bug in sax, or a misspecification only? Or an left-over from previous configuration code, because this field wasn't tested so far (it has already been described by the manpage on 10.2)? Also "Protocol" and "InputFashion" should probably not be set for evdev devices, because they are unknown. This could clash with future driver options.
The man page reads to me that "vendor"/"product" ids can be used for device identification, but "Name" only is the preferred one - except if you want to specify a specific port, in that case it would be "Phys".
Lowering severity. This is not blocker, but annoying nevertheless. I think the only way this should drop from a blocker to critical is if by default evdev is never set. In my case, x will never load unless I edit xorg I'm not sure how this could NOT be marked as a blocker. These mice are a common piece of hardware (probably one of the best selling mice) and as such a issue that blocks people from using them IMHO is a show stopper as it effects basic I/O functionality. This issue is not a leftover from a previous configuration as it's easily reproduced on a fresh clean install. i don't care how it's marked, as long as it is fixed in beta 2 so we can make sure it doesn't still exist when 10.3 goes gold. why the hell is bugzilla so buggy lately? took me an hour to login :P~ I just attached this mouse to my laptop, and the Xserver crashed immedeately: Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80d5481] 1: [0xffffe420] 2: /usr/bin/Xorg [0x80fbd4e] 3: /usr/bin/Xorg [0x80fc76a] 4: /usr/bin/Xorg(xf86_reload_cursors+0xbd) [0x80fc43d] 5: /usr/lib/xorg/modules//drivers/intel_drv.so [0xb7b7bcd2] 6: /usr/bin/Xorg(xf86CrtcSetMode+0x279) [0x80fa7c9] 7: /usr/lib/xorg/modules//drivers/intel_drv.so [0xb7b783be] 8: /usr/bin/Xorg(xf86ProbeOutputModes+0x18e) [0x80f968e] 9: /usr/bin/Xorg [0x80ff191] 10: /usr/bin/Xorg(RRGetInfo+0x89) [0x816d839] 11: /usr/bin/Xorg(ProcRRGetScreenResources+0x7b) [0x817191b] 12: /usr/bin/Xorg [0x816aed5] 13: /usr/bin/Xorg [0x81548ce] 14: /usr/bin/Xorg(Dispatch+0x1af) [0x808ef5f] 15: /usr/bin/Xorg(main+0x47e) [0x8076a4e] 16: /lib/libc.so.6(__libc_start_main+0xe0) [0xb7cf5fe0] 17: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e1) [0x8075dd1] This could even be intel driver related, as it has proven to be a bit unstable lately. But this is an additional / other topic. Please don't change the Severity. These flags are meant for us developers. The system works, just configuration doesn't, and only on a few mice. This will *not* block shipping. Hm. Works here with sax2 version 8.1 - SVN Release 1.49 2003/03/17 (sax2-8.1-206.rpm). sax2 -r creates a wonderful configuration (well, actually the mouse part is still broken, but evdev still detects the mouse), and all 17 buttons are working. Ah, I see. The mouse I have is a "Logitech USB Receiver", while yours is a "Logitech USB Gaming Mouse". Marcus, cdb/Pointers shows "Logitech:USB Gaming Mouse" as the only one using evdev. Additionally, I found three profiles specifying evdev, logitech-Gaming, logitech-MediaPlay, and logitech-mxlaser. logitech-Gaming and logitech-MediaPlay show the same Name "Logitech USB Receiver". Apparently, profiles are selected by vendor and device ID (maps/Input.map). In that case it would certainly be better to use vendor/product in the driver config as well. Will change that. Created attachment 158213 [details]
Fix for sax2 evdev profiles
This patch should fix the issue.
You can apply it in an already installed system (patch -p0 when residing in / as root), and do a "sax2 -r" in order to test.
The mouse configuration still states (wrongly) Option "Buttons" "10", but the evdev driver apparently doesn't care about that one either. Even the standard mouse driver is now capable of announcing the correct number of buttons...
Can you two please test this patch?
Marcus, please apply to sax if tested positively. Please don't close this bug report, as there are still two issues for me to fix here: - Xserver shouldn't bail out if Corepointer doesn't work, but continue (AllowOpenMouseFail) - Xserver shouldn't crash when attaching additional mice > - Xserver shouldn't bail out if Corepointer doesn't work, but continue
> (AllowOpenMouseFail)
> - Xserver shouldn't crash when attaching additional mice
IMHO we should open a seperate bugreport for these issues. Otherwise this bugreport won't be closed soon.
Agreed, as soon as this one is verified and sax2 is patched. Applied the patch to the OpenSuse103beta1 and it works for me:
init 3
sax2 -m 0=nidia // still needed to define the nvidia driver
//(don't know whether this is worth a bugreport)
SaX2 starts up correctly and shows me the mouse with the name 0x046d (I suppose this is taken from the "Vendor" field of xorg.conf). All Buttons work, number 6 and 7 (i.e Tilt-Wheel) are shown as a wheel movement in the picture of the mouse, which is a mere cosmetically problem.
Sax2 works also flawlessly in init 5 with an X-server running. It's up an running again, thank you all a lot!
Btw. The manual selection in the mouse-menu Logitech-->USB Gaming Mouse writes the wrong old setting with "Vendor" as a string. Reassigning to Marcus. Matthias, please don't forget about comments #44/45. (In reply to comment #48 from Thomas Meindl) > Btw. The manual selection in the mouse-menu Logitech-->USB Gaming Mouse writes > the wrong old setting with "Vendor" as a string. I guess with the current design of sax there is not much we can do about that. I assume that we won't hit this path very often (who does configure the mouse by hand?). (In reply to comment #45 from Stefan Dirsch) > IMHO we should open a seperate bugreport for these issues. Otherwise this > bugreport won't be closed soon. Done. Bug #302116 Marcus, close this one when the patch is applied. fixed data record for manual selection what the hell??? this bug still exists in beta 2! is this bug going to persist through the 10.3 final release? i am officially requesting that this is changed back to BLOCKER until it is FIXED. The patch wasn't integrated into beta2, as far as I can see. You can apply the patch of comment #43 as a temporary solution. sax2 fails due logitech usb gaming mouse <---that's the issue, how can something be marked as resolved when it still doesn't work? is the patch integrated in to the upcoming beta 3? i have tested every release so far, all 7 alphas and both betas. if this patch isn't going to make it in to beta 3 then i am going to skip b3 completely. imo, beta 3 should not be released at all unless this is fixed, because after that it's on to rc1 and then final... and the last thing anyone wants is for beginners to get stuck in full screen text mode. I think the fix got in by Marcus just after code freeze for beta 2. But you can try to install all sax2*.rpm from factory to test that. ok, thanks. beta 3 is coming in 2 days, i will see if it is fixed in that release. You won't like this to hear, but either the fix didn't get in or it was changed in some sort of way, because it doesn't work in beta3 - unless I apply the patch. According to the sax2 changelog it has been fixed: ------------------------------------------------------------------- Tue Aug 21 10:12:22 CEST 2007 - ms@suse.de [...] - fixed data record for USB gaming mouse (#262317) ... but the patch (see comment #43) has not been applied. :-( Need to reopen this one. Ya the bug is still there but even after applying the patch sax still refuses to launch unless a sax -r is done. Unfortunately this results in a xorg.conf that limits my setting of resolution to 1280x1024 in sax even though I was previously able to set it to my preferred 1600x1200 before. Can we please get a new sax2-ident package up on the updates until this issue is resolved? (In reply to comment #62 from Dean Hilkewich) > but even after applying the patch sax still refuses to launch unless a > sax -r is done. Unfortunately this results in a xorg.conf > that limits my setting of resolution to 1280x1024 in sax even though I was > previously able to set it to my preferred 1600x1200 before. This issue looks unrelated. Might be a driver regression and needs to be reported seperately. Well, if I hook up another mouse then Sax correctly gives me the 1600x1200 option and does not limit me to 1280x1024. Let me clearify that a bit. If I install 10.3 B 3 while using another mouse (Logitech MX-510) then I have full 1600x1200 resolution so it is related somehow. One last thing, this issue replicable with both the nv and nvidia driver. I would need to see this 1280x1024 xorg.conf. Very well I will get you xorg.confs of an install with the MX510 and the G5 mouse. Just give me a few hours beta 3: no change. after months of reporting this problem, it obviously is not going to be fixed before 10.3 goes final. so, anyone with a logitech g5 mouse, don't expect any kind of gui after installing suse. - the manual selection of the mouse data in the CDB has been fixed It was an issue related to this bug but not the main problem - but the X driver problem seems to be still present. Comment #51 points to the real problem *** This bug has been marked as a duplicate of bug 302116 *** (In reply to comment #71 from Marcus Schaefer) > - the manual selection of the mouse data in the CDB has been fixed > It was an issue related to this bug but not the main problem I do not understand this. I only can see that Matthias' patch (comment #43) has not been applied. Maybe because it's not required. I don't know. > - but the X driver problem seems to be still present. Comment #51 > points to the real problem > > *** This bug has been marked as a duplicate of bug 302116 *** Unfortunately this won't help us, since Matthias is on vacation until Wed 2007-09-26. Therefore I suggest to no longer use the evdev driver for these mice for openSUSE 10.3. How likely is that #302116 is fixed the days after Matthias returns? Because then I would prefer an online update for the real issue instead of a work around now. After all the GM is 27th - so if we have a fix on let's say 29th it would be ok, no? I admit I miss a good picture of the remaining impact. Ahem sorry but evdev support was a _requested_ feature by many people and you want to me to disable it just because X is broken again ? I thought we would have at least a minimum of interest in making things better so why not ask Egbert or the Xorg community for help or at least try to fix evdev instead of creating a blocker bug for sax2 Thanks I agree. We should track the real issue only - meaning DUPLICATE again and severity up 302116 if it's really that much of a problem. Bug #302116 is about Xserver not starting if the corepointer (in this case evdev) fails. Fixing this issue would mean in this case that the Xserver starts with no working mouse at all. Only keyboard input support. This would be even worse than using the usual mouse driver for these 3 (in words three!) mice. According to comment #62 applying the patch fixes the issue, but introduces a new one (maximal resolution 1280x1024) which is not understood yet (xorg.conf is still missing). Marcus still didn not explain, why he thinks the patch is not necessary. (In reply to comment #69 from Dean Hilkewich) > Very well I will get you xorg.confs of an install with the MX510 and the G5 > mouse. Just give me a few hours. Dean, please provide them ASAP. (In reply to comment #62 from Dean Hilkewich) > Ya the bug is still there but even after applying the patch sax still refuses > to launch unless a sax -r is done. Unfortunately this results in a xorg.conf > that limits my setting of resolution to 1280x1024 in sax even though I was > previously able to set it to my preferred 1600x1200 before. This one I need as well. Created attachment 162855 [details]
xorg.conf during install with logitech g5
i have submitted my xorg.conf's before, to no avail.
here is the most recent, from beta 3.
Can't find the other requested xorg.conf files. :-( Would it help is we took up a collection and mailed you a logitech mouse? It would already help to see the xorg.conf files I've been offered before. *** Bug 308956 has been marked as a duplicate of this bug. *** so, how's this one looking for rc1? :p Well, it depends on Dean. I'm still waiting for his offered xorg.conf files. :-( They should defiantly fix this by RC1. It is a pretty important bug. What about providing the required feedback instead of complaining that the bug is still not fixed? how about fixing it instead of claiming that it's fixed - only to find out that it's not - and then asking for more logs? i know i've provided my share of bugs. this has been on the books for months now, and we've all said this would end up as a huge problem for everyone. now here we are on the verge of final release and we are being asked for more logs. i've been reporting (and supplying logs) since alpha 1, both here and on irc. none of this should be a shock. my share of logs* everyone is trying to help this one get fixed. it was supposed to be fixed in b2, then again in b3,,, i'm not even going to try rc1 because i am pretty sure it can't be roslved by then... BUT... i will GLADLY try rc1 and test the hell out of it if you think it will be. sign me up! i just would like to see everyone have a decent installation experience, that's all... and i know a lot of people with these mice. I would defiantly recommend you fix this by RC1. The whole world has Logitech Mice. I don't think it's fixed yet. With the config files I mean the one I requested in comment #77. These would show me - the difference between G5 (broken) and MX510 (working) configurations - the difference for G5 configurations when the patch is applied *and* why then the maximum resolution is limited to 1280x1024, which does not make any sense to me at all. It was my hope that Dean could provides these informations to save my time for different bugs, but I was proven wrong. :-( ok, this is not blocking the release. I'm currently trying hard to reproduce this issue. The mouse I'm using:
#################
#
# Logitech
# MediaPlay
# Cordless Mouse
#
##################
# hwinfo --mouse
47: USB 00.0: 10503 USB Mouse
[Created at usb.122]
UDI: /org/freedesktop/Hal/devices/usb_device_46d_c50e_noserial_if0
Unique ID: UfPf.r+G0OqTk0u7
Parent ID: 2XnU.+3dax8OvtgB
SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0
SysFS BusID: 5-1:1.0
Hardware Class: mouse
Model: "Logitech USB Receiver"
Hotplug: USB
Vendor: usb 0x046d "Logitech Inc."
Device: usb 0xc50e "USB Receiver"
Revision: "25.00"
Compatible to: int 0x0210 0x0028
Driver: "usbhid"
Driver Modules: "usbhid"
Device File: /dev/input/mice (/dev/input/mouse0)
Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event2, /dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1:1.0-event-mouse, /dev/input/by-id/usb-Logitech_USB_Receiver-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1:1.0-mouse
Device Number: char 13:63 (char 13:32)
Speed: 1.5 Mbps
Module Alias: "usb:v046DpC50Ed2500dc00dsc00dp00ic03isc01ip02"
Driver Info #0:
Buttons: 8
Wheels: 2
XFree86 Protocol: explorerps/2
GPM Protocol: exps2
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #43 (Hub)
Created attachment 163191 [details]
xorg.conf created during installation (works)
Created attachment 163192 [details]
xorg.conf created with "sax2 -r" (works)
Created attachment 163193 [details]
xorg.conf created with "sax2 -r" and evdev profiles patch in place (works)
I just tried the input-section from your Xorg.conf form comment 93 and it kills my XServer so hard, that if I switch to console 7 via Alt-Ctrl-F7 it shows a black screen with a blinking cursor - then switching back to any other console doesn't work any more (NVIDIA and nv driver). I believe that you've got a newer revision of the Logitech G5 mouse (according c. 92). Newer G5s have an extra button on the side (so there are two side-buttons now). With the patch I can use sax2 and the Xserver without any problem (whereas I cannot say something about resolutions above 1280x1024 because this is the max. resolution of a single screen of my Twinview setup). My 2 years old one-side-button-G5: 42: USB 00.0: 10503 USB Mouse [Created at usb.122] UDI: /org/freedesktop/Hal/devices/usb_device_46d_c041_noserial_if0 Unique ID: 7bWa.xCkw_U0ZPy7 Parent ID: pBe4.eStfeOR6kQD SysFS ID: /devices/pci0000:00/0000:00:0b.0/usb2/2-3/2-3:1.0 SysFS BusID: 2-3:1.0 Hardware Class: mouse Model: "Logitech USB Gaming Mouse" Hotplug: USB Vendor: usb 0x046d "Logitech Inc." Device: usb 0xc041 "USB Gaming Mouse" Revision: "46.02" Compatible to: int 0x0210 0x0028 Driver: "usbhid" Driver Modules: "usbhid" Device File: /dev/input/mice (/dev/input/mouse0) Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event1, /dev/inpu t/by-id/usb-Logitech_USB_Gaming_Mouse-event-mouse, /dev/input/by-path/pci-0000:0 0:0b.0-usb-0:3:1.0-event-mouse, /dev/input/by-id/usb-Logitech_USB_Gaming_Mouse-m ouse, /dev/input/by-path/pci-0000:00:0b.0-usb-0:3:1.0-mouse Device Number: char 13:63 (char 13:32) Speed: 12 Mbps Module Alias: "usb:v046DpC041d4602dc00dsc00dp00ic03isc01ip02" Driver Info #0: Buttons: 8 Wheels: 2 XFree86 Protocol: explorerps/2 GPM Protocol: exps2 Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #41 (Hub) No real difference WRT to evdev driver configuration between xorg.conf of installation and reconfiguration with sax2 afterwards with and without the patch. @@ -73,11 +73,9 @@ Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "10" - Option "InputFashion" "Mouse" - Option "Name" "Logitech USB Receiver" - Option "Protocol" "event" + Option "Product" "0xc50e" Option "SendCoreEvents" "on" - Option "Vendor" "Sysp" + Option "Vendor" "0x046d" Option "ZAxisMapping" "4 5" EndSection This is the only mouse specific difference between the configurations. (WW) Option "vendor" requires an integer value Since there is neither a "InputFashion" nor a "Protocol" option in evdev driver - but a "Name" option and "Vendor" option needs to be set correctly - I'll generate a new patch for SaX2. Created attachment 163200 [details]
sax2-logitech-profile.diff
update for sax2 evdev profile patch
> I just tried the input-section from your Xorg.conf from comment 93 and it > kills my XServer so hard, that if I switch to console 7 via Alt-Ctrl-F7 it > shows a black screen with a blinking cursor - then switching back to any > other console doesn't work any more (NVIDIA and nv driver). > I believe that you've got a newer revision of the Logitech G5 mouse > (according c. 92). Newer G5s have an extra button on the side (so there are > two side-buttons now). Yes, could be. The mouse has two blue side buttons on the left side with cursor up/down on them. Yours seems to have 20 buttons whereas mine has "only" 10 according to the created config file. > With the patch I can use sax2 and the Xserver without any problem (whereas I > cannot say something about resolutions above 1280x1024 because this is the > max. resolution of a single screen of my Twinview setup). Could you try the new patch of comment #98, although I don't think it won't change anything? Thomas, Julian, Darren, Stephen, Dean. Could we agree, that anybody who is still interested into getting this fixed, to give the updated patch of comment #98 a try and provide feedback ASAP? The patch can be applied as root by running cd /; patch -p0 < <patchfile_with_full_path> Afterwards run "sax2 -r". Attach /var/log/SaX.log. I really want to see this fixed. Sadly, I can't look at it until late this evening (MST). Still a student and have a major calc 2 test today. I will try though when I get back home. I wish I could do it during work, but I'm not really allowed to. Plus I'm the only tester on the team testing opensuse 10.3 (XEN). Try/hoping to get a good XEN release in 10.3 Created attachment 163231 [details]
SaX.log file
I applied the patch to the original profile files. Again sax2 (or xorg) couldn't start up.
(In reply to comment #99 from Stefan Dirsch) > Yes, could be. The mouse has two blue side buttons on the left side with > cursor up/down on them. Yours seems to have 20 buttons whereas mine > has "only" 10 according to the created config file. Thomas, you have a completely different mouse. Yours is a Vendor: usb 0x046d "Logitech Inc." Device: usb 0xc041 "USB Gaming Mouse" Mine is a Vendor: usb 0x046d "Logitech Inc." Device: usb 0xc50e "USB Receiver" Different profiles are used for these. 0x046d : 0xc041 : logitech-Gaming 0x046d : 0xc50e : logitech-MediaPlay --- logitech-Gaming 2007-09-11 07:29:32.000000000 +0200 +++ logitech-MediaPlay 2007-09-11 07:30:10.000000000 +0200 @@ -6,6 +6,6 @@ InputDevice -> [X] -> Option -> Name = Logitech USB Receiver InputDevice -> [X] -> Option -> SendCoreEvents = on InputDevice -> [X] -> Option -> ZAxisMapping = 4 5 -InputDevice -> [X] -> Option -> Buttons = 20 +InputDevice -> [X] -> Option -> Buttons = 10 InputDevice -> [X] -> Option -> Vendor = 0x046d -InputDevice -> [X] -> Option -> Product = 0xc041 +InputDevice -> [X] -> Option -> Product = 0xc50e (In reply to comment #103 from Thomas Meindl) > Created an attachment (id=163231) [details] > SaX.log file > > I applied the patch to the original profile files. Again sax2 (or xorg) > couldn't start up. Obviously the evdev driver does not work together with this mouse (Gaming: 0x046d:0xc041). :-( (II) evdev brain: Rescanning devices (1). (EE) PreInit returned NULL for "Mouse[1]" ==> it doesn't make sense to enable evdev for this mouse. It looks different for me (MediaPlay: 0x046d:0xc50e): (II) evdev brain: Rescanning devices (1). (**) Option "SendCoreEvents" "on" (**) Mouse[1]-usb-0000:00:1d.0-1/input0: always reports core events (**) Option "CorePointer" (**) Mouse[1]-usb-0000:00:1d.0-1/input0: Core Pointer (II) Mouse[1]-usb-0000:00:1d.0-1/input0: Found 4 relative axes. (II) Mouse[1]-usb-0000:00:1d.0-1/input0: Configuring as pointer. (**) Mouse[1]-usb-0000:00:1d.0-1/input0: HWHEELRelativeAxisButtons: 6 7. (**) Mouse[1]-usb-0000:00:1d.0-1/input0: WHEELRelativeAxisButtons: 4 5. (II) Mouse[1]-usb-0000:00:1d.0-1/input0: Found 16 mouse buttons (**) Mouse[1]-usb-0000:00:1d.0-1/input0: Configuring 4 relative axes. (II) Mouse[1]-usb-0000:00:1d.0-1/input0: Configured 20 mouse buttons Stephen, it's sufficient to give me feedback tomorrow. :-) In reply of comment 105: But with patch number 1 I get evdev working (and working stable): (II) evdev brain: Rescanning devices (1). (**) Option "SendCoreEvents" "on" (**) Mouse[1]-usb-0000:00:0b.0-3/input0: always reports core events (**) Option "CorePointer" (**) Mouse[1]-usb-0000:00:0b.0-3/input0: Core Pointer (II) Mouse[1]-usb-0000:00:0b.0-3/input0: Found 4 relative axes. (II) Mouse[1]-usb-0000:00:0b.0-3/input0: Configuring as pointer. (**) Mouse[1]-usb-0000:00:0b.0-3/input0: HWHEELRelativeAxisButtons: 6 7. (**) Mouse[1]-usb-0000:00:0b.0-3/input0: WHEELRelativeAxisButtons: 4 5. (II) Mouse[1]-usb-0000:00:0b.0-3/input0: Found 16 mouse buttons (**) Mouse[1]-usb-0000:00:0b.0-3/input0: Configuring 4 relative axes. (II) Mouse[1]-usb-0000:00:0b.0-3/input0: Configured 20 mouse buttons (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 (**) Option "Device" "/dev/input/mice" (==) <default pointer>: Emulate3Buttons, Emulate3Timeout: 50 (**) <default pointer>: ZAxisMapping: buttons 4 and 5 (**) <default pointer>: Buttons: 9 (**) <default pointer>: Sensitivity: 1 (II) XINPUT: Adding extended input device "<default pointer>" (type: MOUSE) (II) XINPUT: Adding extended input device "Mouse[1]-usb-0000:00:0b.0-3/input0" (type: MOUSE) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "Keyboard[0]" (type: KEYBOARD) Ouch! My updated patch was completely bogus. Better do no set Option "Name". But without any patch evdev does not work. Is this correct, Thomas? Correct, only when the original patch is applied my old G5 works with evdev and sax2 /xorg starts reliable. Thanks. So Julian, Darren, Stephen, Dean, please use the patch of comment #43 and not my broken one of comment #98. Besides from that the instructions remain the same as in comment #100. stefan, thank you. i will test this as soon as i get home tonight! Created attachment 163398 [details] sax logs & xorg confs > #48 - patch -p0 when residing in / as root > attachment: bug-262317_sax2-logitech-profile.diff meh-rd42:/ # patch -p0 < bug-262317_sax2-logitech-profile.diff patching file /usr/share/sax/profile/logitech-Gaming patching file /usr/share/sax/profile/logitech-MediaPlay patching file /usr/share/sax/profile/logitech-mxlaser > #100 Afterwards run "sax2 -r". Attach /var/log/SaX.log. meh-rd42:/ # sax2 -r SaX: initializing please wait... SaX: your current configuration will not be read in SaX: access to your display has been granted SPP: prepare device [0] profile: NoModelines SPP: prepare device [1] profile: logitech-Gaming SPP: prepare device [0] profile: microsoft-natural SPP: including prepared profile(s)... SaX: startup SaX: X-Server: :0.0 -> grant SaX: using cache data... popups... title: message invalid color/resolution combination. the selected resolution and/or color settings are not supported by the graphics cards framebuffer. title: message 3d accelleration not supported sax2 cannot offer activation of the 3d subsystem because your graphics card/driver doesn't support 3d. results... when sax2 came up, i clicked test - no test occurred, sax2 window disappeared -> sax1.log i ran it again and clicked save this time, the window went away -> sax2.log in any case, when i restarted x, my monitor started flipping diagonally at about 10,000 mph. i had to kill it and login again to get it to stop. i rebooted, same thing. i had to restart x and login to get it to stop. additionally, for some stupid reason. /boot/grub/menu.lst on my main title vga-0x31a was changed by sax2 to vga=0x0. so when i was booting up my text was like 10 inches tall. does the mouse work? it always has AFTER i have gotten back in to X and/OR been able to run sax2 -r. so, this time, with the patch the mouse worked... but it also worked when i ran sax2 -r back in beta 1 and beta 2 with the same exact results as i had tonight - but in both of those cases i never patched anything. and if you look at these new logs, i'm not sure the end of the logs look like any kind of real success, maybe i'm wrong though. xorg.sax was the config AFTER i ran sax2 -r - like i said, it doesn't appear to be working, so maybe this file is unchanged by it... and when compared to my real xorg.conf = identical. anyway, these are my results with the patch on suse 10.3 beta 3 64-bit and the logitech g5 version 1 (one side button). hope this helps! Created attachment 163401 [details]
Xorgs.G5_and_MX510.
I'm sorry Stephan, had a family emergency and was rushed away for a few days. Here are the requested files. The other thing I notice after the patch is applied sax refuses to make any changes the the xorg.conf.
confirming... i'm seeing the same thing. sax2 does not test or close properly, it makes no changes to the xorg.conf file whatsoever - but it also modified by /boot/grub/menu.lst file from vga=0x31a to vga=0x0 - so when i rebooted my text was HUGE. Darren, you created your xorg.conf with nvidia-xconfig. AFAIK sax2 doesn't touch any xorg.conf files, which couldn't be read in successfully - which happened in this case. The vga setting change in menu.lst seems to be a side effect (might be a bug in SaX2, which needs to be reported seperately). All in all your results are completely unrelated to the original evdev mouse driver problem. Since your original xorg.conf has not been changed by SaX2 the normal mouse driver specified in this file is running and works as expected. I suggest to rename xorg.conf and test again. I'm sorry. Dean, you own the same mouse as Thomas and said that adding the patch fixes the configuration. The configuration files you sent confirm this. The limitation in the resolution looks completely unrelated to me. So I don't want to handle it in this bugreport. (In reply to comment #116 from Stefan Dirsch) > I suggest to rename xorg.conf and test again. I'm sorry. But since you also own the same mouse as Thomas and Dean I expect to see the same results. Now let's wait for feedback by Stephen and Julian, since I don't know which mice they own. no problem. i can re-test this tonight when i get home. Stefan Dirsch, Thomas says that he cannot confirm the issue. "With the patch I can use sax2 and the Xserver without any problem (whereas I cannot say something about resolutions above 1280x1024 because this is the max. resolution of a single screen of my Twinview setup)." Like I say, until the patch is applied and then reconfigured using sax -r, the xorg is correct with the metamodes. With the MX510 you can change the xorg easily with sax and you do not have metamode issues. It's only after the patch is applied and a sax -r is done that the xorg then becomes unwritable/unupdateable with the wrong metamodes. If instead of running the patch I just use the old mouse config pre evdev: Section "InputDevice" Driver "mouse" Identifier "Mouse[1]" Option "Buttons" "12" Option "Device" "/dev/input/mice" Option "Name" "Logitech USB Gaming Mouse" Option "Protocol" "explorerps/2" Option "Vendor" "Sysp" Option "ZAxisMapping" "4 5" EndSection Then sax remains fully configurable and metamodes are correct. sax becomes totally useless after the patch is applied where as without it it functions properly if the old style mouse confiq is used. So once again.... patch=sax incorrect metamodes and the resulting xorg.conf never gets written after sax -r is done. no patch but old mouse config is edited in xorg, sax remains fully and properly functional The bug only appears after the patch is applied and a sax -r is done. I cannot reproduce this problem with my MediaPlay mouse. With the patch applied SaX2 changes the xorg.conf as often as it is required each time I run SaX2. So we have a conflict here. - we need the patch for the Logitech Gaming mouse. Otherwise no correct configuration can be written, which results in a non-working Xserver. - but with the patch applied changes of xorg.conf are no longer possible How should we resolve this conflict? Since we cannot reproduce this problem due to lacking hardware I suggest to disable evdev driver for this mouse. The patch should be applied nevertheless. There's nothing wrong with it. Marcus, could you please take care of this? The patch is the one of comment #43. The mouse, which no longer should be configured to use evdev is 0x046d : 0xc041 : logitech-Gaming done what the?!? i thought there were valid arguments here to keep evdev... > #48 - evdev fails gracefully with kernel 2.6.21-rc5. but i can remember that an self-written evdev configuration like the above was working in 10.2. > #23 - solution change out evdev for mouse and comment out protocol event. not really a solution, 'cause it will render special buttons (e.g. tilt-wheel) useless - and evdev was already working with g5. > #74 - ahem sorry but evdev support was a _requested_ feature by many people and you want to me to disable it just because x is broken again? i thought we would have at least a minimum of interest in making things better so why not ask egbert or the xorg community for help or at least try to fix evdev instead of creating a blocker bug for sax2. removing evdev isn't fixing the problem at all - this is avoiding the real problem completely. i still plan on testing this patch tonight when i get home. resolved? hardly. I'm sorry, but we don't have any other choice at the moment. I suggest to send us such a mouse so we can improve the situation for the next openSUSE release. Stephan, is it possible that this issue with sax2 becoming unusable after the patch is applied only effects 10.3 x64 sax2? Are you attempting to replicate the issue in 32 or 64 ? It seems the person that can replicate this issue is running pretty much the same setup darren winter both are using 64-bit. I've tested on a x64 system. OK, just wanted to verify that. *** Bug 309925 has been marked as a duplicate of this bug. *** In reply of comment #119 : Dean, can you please open a new bug report for your screen-resolution related problem, - if there isn't one already. This report is getting really long :) In reply of comment #124 : Darren, I agree with you that this issue isn't really solved, but as there isn't almost any time left to the release of 10.3, we should reopen this bug later, when the resolution problem is solved. In reply of comment #126 : I use the x86_64 version too, if this helps you. I would suggest, that every one whose monitor is capable of the higher resolutions than 1280x1024 tests the patch with sax to gather information ASAP. On a later date, it will be harder to test, because the latest settings for G5 with ID 0x046d:0xc041 won't produce the issue. Thanks everybody so far, for your time and your patient :) Maybe instead of closing this bug, we reassign it to opensuse 11.0? This way no one thinks that this is fixed? I just seems weird to make something resolve this way. It would be cool to have an option such as delayed I'll still plan on testing the patch tonight. I'm also running x86_64, because of XEN testing as well (In reply to comment #130 from Thomas Meindl) > In reply of comment #119 : Dean, can you please open a new bug report for > your screen-resolution related problem, - if there isn't one already. This > report is getting really long :) If I did understand Dean correctly, sax2 refuses to rewrite the xorg.conf with the patch in place in general - unrelated to the resolution. Yes, this should be handled in a different bugreport. > In reply of comment #124 : Darren, I agree with you that this issue isn't > really solved, but as there isn't almost any time left to the release of > 10.3, we should reopen this bug later, when the resolution problem is solved. I prefer to not reopen this bugreport. Instead open a new one with the conclusion we got from this one and add a reference from the new one to this one. > I would suggest, that every one whose monitor is capable of the higher > resolutions than 1280x1024 tests the patch with sax to gather information > ASAP. On a later date, it will be harder to test, because the latest > settings for G5 with ID 0x046d:0xc041 won't produce the issue. As said before I don't think it's related to a different resolution at all. And it's not that hard to add "0x046d : 0xc041 : logitech-Gaming" to /usr/share/sax/sysp/maps/Input.map. :-) "If I did understand Dean correctly, sax2 refuses to rewrite the xorg.conf with the patch in place in general - unrelated to the resolution. Yes, this should be handled in a different bugreport." Ok I'm not sure how you can determine that this is not directly a result of the patch as pre-patch sax2 saves and configures xorg.conf properly. After applying the patch sax2 no longer saves the xorg file but seems to use a "default or generic" metamodes (where it gets these modes I don't have any idea). After the patch is applied and a sax2 -r is done you cannot see nor adjust any xorg.conf settings using sax2. Using sax2 create a new xorg.conf then results in no updated xorg.conf being written (file date and time stays the same). Even then swapping the G5 for the MX510 does not cure the issue afterwards. Even installing the nvidia drivers and then using the sax2 -m 0=nvidia results in no changes being applied to the xorg.conf. With patch = cannot update xorg.conf without patch = can update xorg.conf Only 1 thing has changed between the setups and that's the patch. Is the patch exposing a new bug? After the patch sax2 does not seem to save the xog.conf. How would I create a new bug that is a direct result of the patch? Title it..."Patch to fix evdev breaks sax2?" Dean, I agree with the title for the seperate bugreport. But we might need this mouse to reproduce it ... Created attachment 163745 [details] default suse xorg - after running sax2 so... i ran sax2 again, after the patch. before running it i move the original xorg.conf file from my suse installation (before any nvidia stuff was added). when sax2 was done, the test never ran, so i launched sax2 again, this time skipping the test and just telling it to save my settings. it did not make a single change to my xorg.conf. so, i started over without an xorg.conf file in place. test button did nothing but close sax2. clicking save button closes sax2 but an xorg.conf file is never written. so, i'm back on my nvidia xorg.conf for now. finally, even though sax2 hates my xorg.conf (does nothing for it), it sure seems to love playing with my /boot/grub/menu.lst file: Bug 310115 - sax2 modifies grub's menu.lst - why is sax2 modifying a boot loader?! https://bugzilla.novell.com/show_bug.cgi?id=310115 Created attachment 163746 [details]
sax2 log
oh yeah, when i temporarily removed xorg.conf and ran sax2 -r, this is what happened.... see attached log, plus command line output:
meh-rd42:/etc/X11 # sax2 -r
SaX: initializing please wait...
SaX: access to your display has been granted
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
SPP: prepare device [0] profile: NoModelines
SPP: prepare device [1] profile: logitech-Gaming
SPP: prepare device [0] profile: microsoft-natural
SPP: including prepared profile(s)...
SaX: startup
SaX: X-Server: :0.0 -> grant
SaX: using cache data...
> Bug 310115 - sax2 modifies grub's menu.lst - why is sax2 modifying a boot
> loader?!
Thanks. I commented on this bug now.
Dean, once you opened a bugreport for ""Patch to fix evdev breaks sax2?", please don't forget to put me into Cc. Thanks. Darren, WRT comment #138. Please open a separate bugreport for this as well. Maybe these are only warnings during start, but there are more lines in SaX.log I don't understand. Put me into Cc of this bugreport. Thanks. that's strange, when I was running one of my PV domUs today I ran into the same thing with sax2. When I hit test it exited out. Point being that might be a sax2 problem that has nothing to do with this. Burning beta 3 right now then don't hijack random bugs? (In reply to comment #142 from Stephan Kulow) > then don't hijack random bugs? Please ignore this comment. Probably he missed the context of the discussion here. Please see bug 310305 as to why this patch breaks sax. This should be reopened. *** Bug 310305 has been marked as a duplicate of this bug. *** see bug 310305 why this patch breaks sax (In reply to comment #145 from Dean Hilkewich) > *** Bug 310305 has been marked as a duplicate of this bug. *** Instead I reopened Bug #310305. i just wanted to follow up on this bug... i installed rc1 last night and after the installation, runlevel 5 worked. granted, it's not with evdev, so this was the "workaround" in action. at least end users won't be stuck at a text based login this way. I didn't see this fixed/worked around in RC1. Sorry I haven't had a chance to get anything done on this. the XEN stuff has killed my time. working on bug #300496 Stefan knows what's going on there. As far as I can see there's no workaround in my xorg.conf . Instead there is a nice evdev configuration for the mouse, which works. :-) I just tried RC1 last night too. The Live Medium did not have a problem. But, the installer did not like it still. Is this going to be resolved by the next release? @stephen comment #122 mentions disabling evdev for the logitech g5 gaming mouse (v1) which was causing the problem. i'm not sure what changed, but x is working after installation. @julian... what happens? no x? @thomas... my xorg.conf also shows evdev, what in the world?!? Section "InputDevice" Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "20" Option "InputFashion" "Mouse" Option "Name" "Logitech USB Gaming Mouse" Option "Protocol" "event" Option "SendCoreEvents" "on" Option "Vendor" "Sysp" Option "ZAxisMapping" "4 5" EndSection hmm, maybe evdev is causing my major mouse slow down problems during heavy system load - bug 327517. my old installs ever used evdev: Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection bug 327517 - quick follow up, changing to driver "mouse" fixed my major mouse lagging problem I finally have some info on my mouse. Bus 002 Device 006: ID 046d:c50e Logitech, Inc. MX-1000 Cordless Mouse Receiver still the same issue. I'd like to reopen this bug for openSUSE 11.0. I bought a new Logitech VX Nano notebook mouse yesterday and found out, that I have to use the evdev driver to be able to use all the buttons this mouse provides. First, I tried this on openSUSE 10.3, but after I configured xorg.conf to use evdev for this mouse, Xorg failed to start, like other users in this thread reported. Next I tried on openSUSE 11.0 and Xorg did start at least, but the mouse wasn't working. I found out, that I configured the wrong device path. I used 'cat /proc/bus/input/devices' to find out the correct event the mouse is currently mapped to (in my case this is currently event3). It is working now, here's my xorg.conf Section: Section "InputDevice" Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "9" Option "Device" "/dev/input/event3" Option "Name" "Logitech USB Receiver" Option "Protocol" "auto" Option "HWHEELRelativeAxisButtons" "7 6" EndSection Because, the WHEEL buttons are somehow switched by default on this model (is this a evdev bug or a hardware bug?), I need to remap the horizontal scroll buttons using the last line in the above config. While trying to find out how I remap those things I read the following in 'man evdev': Option "Device" "string" Specifies the device note through which the device can be accessed. At this time ONLY /dev/input/event<N>, where <N> is an integer, are matched against this this field. This option uses globbing. Please note that use of this option is strongly discouraged. So if using the device path is strongly discouraged, I tried the following setup: Section "InputDevice" Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "9" Option "Name" "Logitech USB Receiver" Option "Vendor" "046d" Option "Product" "c521" Option "Protocol" "auto" Option "HWHEELRelativeAxisButtons" "7 6" EndSection This should select the device by VendorID and ProductID. But trying to restart Xorg with this setup fails. I did some further testing and it seems, that if the "Device" option is missing and you are using the evdev driver, Xorg fails to start (although this option is strongly discouraged in the manual)! Anyway, the first setup seems to work. The only problem might be, that the mouse will not always be mapped to event3, so it might be, that after reboot or if you plug in the USB receiver to another USB port, the mouse may not work and you have to edit xorg.conf to fit the current device path. I'll do some further testing on this. Is there a chance that evdev will be enabled by default for openSUSE 11.0? I did not read all posts in this (long) bug thread, but as far as I understood, evdev was disabled on openSUSE 10.3 due to this bug? > I'd like to reopen this bug for openSUSE 11.0. I bought a new Logitech VX
> Nano notebook mouse yesterday and found out, that I have to use the evdev
> driver to be able to use all the buttons this mouse provides.
Please open a seperate bugreport for this as enhancement? Thanks.
OK, I created a new bug 380734 for this issue on openSUSE 11.0. |