maybe the evdev driver is causing my major mouse slow down problems during heavy system load.  my old installs never used evdev.

xorg.conf from rc1:

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

xorg.conf from alphas 1-7 and betas 1-3:

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Created attachment 174102 [details]
xorg.conf files

i am confirming this bug and i am certain that this problem is directly related to sax2 and what it sets my mouse up as (evdev).

using the default mouse settings for xorg, which is what i have been using through all of the betas and alphas completely fixes the major mouse slow down.

sure, it still lags a little under heavy load, but i can still move the mouse wherever i want to.  with evdev, the mouse barely moves.

Created attachment 174103 [details]
xorg.conf files

i am confirming this bug and i am certain that this problem is directly related to sax2 and what it sets my mouse up as (evdev).

using the default mouse settings for xorg, which is what i have been using through all of the betas and alphas completely fixes the major mouse slow down.

sure, it still lags a little under heavy load, but i can still move the mouse wherever i want to.  with evdev, the mouse barely moves.

Created attachment 174104 [details]
xorg.conf files

i am confirming this bug and i am certain that this problem is directly related to sax2 and what it sets my mouse up as (evdev).

using the default mouse settings for xorg, which is what i have been using through all of the betas and alphas completely fixes the major mouse slow down.

sure, it still lags a little under heavy load, but i can still move the mouse wherever i want to.  with evdev, the mouse barely moves.

504 gateway timeouts caused some duplicates, be gentle

sdasda

you can't compare the evdev driver with the old mouse driver. I had a
request to support mice with all buttons and features they may have and
the old mouse driver is useless for this task. According to this we
support evdev for devices we have tested. If it is slow or have other
problems it looks more like a evdev driver problem.

sax2 only sets the relevant parts of the evdev configuration which is
the number of buttons and the connection where to find the mouse

In both config files you attached you use the slow fbdev video driver. This could explain why also your mouse cursor gets slow on very high load. Please try again with a native driver ("nv"). Thanks.

well then in this case, suse or sax2 is setting my xorg.conf to use the "fbdev" driver.

which begs the question, why isn't suse or sax2 setting it to use the "nv" driver?

the config files i sent in are clean, i didn't adjust anything manually.

.

What's the output of "sax2 -r -p"?

i'm not at the box, but thru putty i get this:

Chip: 0  is -> EVGA Corporation GeForce 7800 GT 01:00:0 0x10de 0x0092 AGP fbdev

Yeah. For this card we use fbdev, since nv didn't work. But maybe this is meanwhile fixed. Check with "sax2 -r -m 0=nv".

Created attachment 174365 [details]
xorg.conf after using sax2 -r -m 0=nv

again, i moved the current xorg.conf out of the way before running this command.

results are attached.

So does this configuration work for you?

> So does this configuration work for you?

i won't know until i get home tonight.

> In both config files you attached you use the slow fbdev video driver. This
could explain why also your mouse cursor gets slow on very high load. Please
try again with a native driver ("nv"). Thanks.

keep in mind that i always install nvidia drivers, which switches everything from fbdev or nv to nvidia.  even when using nvidia the mouse is slow (under load) unless i switch the driver from "evdev" to "mouse".

when using "mouse", the mouse still lags a little during load, but i am able to move it all over the screen, including my second monitor.  when using "evdev", during the same amount of load i can barely get the mouse to nudge a few inches.

i can still try "nv" when i get home as well if you still want me to.

Yes, please test with nv driver.

Switching to nv driver for this card would still be an improvement, even if this does not fix the mouse slowlyness.

> So does this configuration work for you?

that was a mistake heh.  it didn't work.  and i forgot to set it to boot to runlevel 3 first.  oh well, i was able to mount the drive and switch it back to a working config.

keep in mind, i would normally just switch to vt1 and do my manual stuffs, but the default config i had loaded had that little keyboard blocker.

i will try to play with this more tonight and tomorrow night.

>> So does this configuration work for you?
>that was a mistake heh. it didn't work.
So you got a black screen, or what? 

i ended up with a black screen and the X mouse pointer on screen, and i got to see the bottom .25 inch of the kde splash screen.  that "nodeadkeys" problem (bug 327017) prevented me from using ctrl+alt+backspace to kill x or to switch over to tty1 to get to text mode to manually fix it.

anyway, i've been thinking about this a lot this morning.  i don't need to see if sax2 is working correctly or not, i know that it is writing an xorg.conf file that should work.  my problem is specific to the mouse and, for sake of time (10.3 final is only 9 days from now), i would like to focus on manually adjusting xorg.conf instead of using sax2 to generate new config files each time.

every time i attach my xorg.conf files i am doing it the way you have been asking (using sax2), and it has been defaulting to fbdev which you have pointed out is slower.  i never use sax2's defaults, and i have never used fbdev - so that is not what is causing my problem.  in my opinion this mouse lag (in my case) is not related  fbdev (since i never use it) and it probably isn't "nv" although i can easily switch to that to test it if needed (tonight), and i know it isn't "nvidia" which is all i ever use.

what i am trying to say (and debug) is that when i use the "evdev" mouse driver with "nvidia" (and possibly "nv"), the mouse is almost impossible to move during heavy load...  i litteraly can barely move it in a 1" or 2" radius, at the very mose.  when i switch the mouse driver from "evdev" to "mouse", there is still some mouse lag during heavy load, but it is at least sufferable, i can still do things and i can freely move the mouse all over the screen even though it is a little jerky.

so, everything aside from sax2, here is what i have been playing with...

this is what i am using currently in 10.3 rc1, and it seems "ok":

Section "InputDevice"
    Driver     "mouse"
    Identifier "Mouse[1]"
    Option     "Protocol" "explorerps/2"
    Option     "Device"   "/dev/input/mice"
EndSection

this is what i was using in 10.3 alphas 1-7 and betas 1-3 and would probably work the same in rc1:

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

this is what was setup after a fresh installation of rc1 and it is laggy as hell during heavy system load:

Section "InputDevice"
    Identifier     "Mouse[1]"
    Driver         "evdev"
    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

Ok. So nv driver still does not support this card properly. This is all I wanted to know. Thanks for the feedback.

i will confirm 100% if "nv" is working/not working for my video card tonight.

but that's not why i'm here :p~

@stefan...  quick follow up.  after a clean install of rc1, the graphical portion of x works fine.  graphics are fine during install and fine after i get in to kde for the first time.  again, this is all with "fbdev" i am pretty sure.  i will re-check the "sax2 -r -m 0=nv" command one more time tonight for you.

Thanks. Yes, testing other video drivers is not the issue here. :-)

@stefan "sax2 -r -m 0=nv" does not work for my card.  i rebooted to runlevel 3 and ran this 3 different times and got the same result each time.  i moved my xorg.conf out of the way each time - a new one was not created.

basically, during the execution of this command it attempts to go in to test mode.  during the test i see the X mouse cursor and instead of seeing the full screen graphical test, the graphics are all compressed and garbled at the top of the screen, roughly .5 inches wide.  i am unable to complete the test, so it doesn't generate a valid xorg.conf.  i can look for and attach sax2 logs if needed.

Thanks. No need for further testing the nv driver. Obviously it still does not support this card. :-(

ok, cool.  so...  back to the topic of this bug report...  what, if anything, will be changed in 10.3 final that will prevent "evdev" users from having major mouse slow downs during medium to heavy system load?

I don't expect a fix to be available for 10.3. I meanwhile switched to evdev driver, but this is a Logitech MX310 model and up to now I couldn't reproduce this problem. :-(

Workaround for 10.3 is to switch back to normal mouse driver with SaX2. Hope this is meanwhile possible also for you, isn't it? Or do you still suffer from the other SaX2 bugs, which prevented SaX2 from rewriting the xorg.conf?

my setup is a little too exotic i guess for now, so i will have to avoid sax2.  the current issues between sax2 and my hardware shouldn't pose any major problems for me, or anyone else really, because after a clean install of suse we are getting in to graphical mode - and that was the single biggest problem for new users.  the rest is gravy :)

so, since this issue can be corrected by me manually switching from "evdev" to "mouse"...  should this bug remain open so it can be revisited later?  if not, feel free to close it.  your call.

Ok. Let's close it as later.

I'm now using the evdev driver as mouse driver on all machines I'm currently working and didn't see such an issue up to now. I'm afraid I can't help here.
Closing the bugreport therefore. 

If it's an option for you to send your mouse model to us (Nuremberg, Germany) for some time we could try to reproduce and possibly fix the issue though.