Client: ezquake (Linux)
I would welcome a solid answer to this question regarding "in_mouse" settings.

The console of the Linux client only mentions "in_mouse 0 (mouse off), in_mouse 1 (OS default), in_mouse 2 (direct input for uberleet performance)". But there is no mention of "in_mouse 3" (evdev).

On the other hand:
The windows client console offers:
in_mouse 0 (mouse off), in_mouse 1 (OS default), in_mouse 2 (direct input for uberleet performance) - AND: it even shows: in_mouse 3 (evdev), even though there is no evdev for Windows!?

There is a help description, however, (strangely only in the Windows client console) that for Linux users:
in_mouse 0 = mouse off, 1=DGA, 2=X mouse, 3=evdev.


I honestly think, this is a whole mess!
(the Windows client shouldn't talk of evdev and the Linux client definitely SHOULD instead)

And why is the order reversed?
in_mouse 2 in windows obviously means "direct input", while it is "in_mouse 1" in linux (dga) and NOT "in_mouse 2" (X mouse).



Now okay, all this was only a criticism regarding documentation.


My next question is more important to me:

I take it, in_mouse 1 in Linux means dga input, in_mouse 2 X mouse input...

What I observe, however, is that in BOTH cases mouse sensitivity is independent of my xset mouse speed settings!

Whether I use xset m 1 1 (to get unaccelerated speed) or xset m 100 1 (to get very high speed) or xset m 1/100 1 (to get a very slow mouse pointer movement), this is completely irrelevant inside the game! Whether I use in_mouse 1 or in_mouse 2 (and also: in_mouse 3, of course): I do not need to adjust my sensitivity (regardless of the xset settings).

The only difference between in_mouse 1 and in_mouse 2 that I notice:
with in_mouse 2 mouse speed is about twice as fast as with in_mouse 1.

So if both settings are independent of xset, doesn't that mean that I get dga input in both cases? And why the speed difference then between in_mouse 1 and 2?

(If I compare that to other games:
Without dga I really get different mouse pointer speed in a game if I change xset settings for the desktop).


Would be very interested in some good and well founded answer. Thanks.

sempron

if evdev has been compiled in

therefore 1 == dga, 2 == x, 3 == evdev

no idea immediately about your sensitivity issue though

btw if evdev has been compiled in then you should be able to see the 'in_evdevice' variable

Um, I definately felt acceleration on my mouse when playing with in_mouse 2. I'm not sure whether I felt it while playing with in_mouse 1 though - I sorta went straight for in_mouse 3. I did have some issues getting it to stick though - are you using in_restart to apply your value, or restarting the client? I've found in_restart is far more reliable (not to mention quicker). The latched values generally don't work that well for me in linux.

And I can see the help-text for in_mouse (that mentions linux settings) while in linux - maybe it's some setting that disables the comments on commands and/or variables from being shown?

Yes, I had also looked through the code and found this line.

I just wonder why the order is reversed in the windows code and why with the so-called X mouse my mouse speed is still independent of the xset settings...


Regards
sempron

3 comments:
Did you try different xset settings, did your mouse speed within the game change with in_mouse 2 or stay the same?

Hm, I have help texts enabled for the Linux console and get quite a lot of explanations for the various variables, but nothing about evdev for in_mouse - maybe this is due to the ezquake version I use...

By any chance, do you have the impression that mouse responsiveness is more lagged with in_mouse 3 as compared to 1 or 2 or to windows ezquake?


thanks
sempron


EDIT: Yes, I always use "in_restart" after a change...

- Not really, no. But I distinctly remember the acceleration on the mouse. Once I felt that I tried to change to evdev, and haven't looked back since.

- Possibly. I'm using 1.8.2 if that helps.

- Definately not. I can't play with any other setting anymore. It's smoother and more responsive than any other setting I've played with. I can't even play in Windows anymore

probably because a) the windows maintainers != linux maintainers, b) if someone just swapped the enum round to be the same then it could break everyone's configs :-) and c) DGA was considered 'normal' originally because the X input is so rubbish.

ubuntu gutsy, options usbhid mousepoll=2, evdev for both xorg and ezquake - no problems :-)

I just discovered something interesting:

If in the input section of my xorg.conf I use an option "Sensitivity" and set it to some value like "3" it overrides my xset setting in my .xinitrc.

BUT:
Such an option "Sensitivity" "3" not only makes the mouse three times faster with in_mouse 2 (X mouse), but ALSO with in_mouse 1!?

That's why in the meantime I wonder if in_mouse 1 really provides DGA input. Shouldn't _direct input_ mouse speed be "unimpressed" by any X setting regarding speed?

Only in_mouse 3 (evdev input) shows no difference (as you would expect it with DGA input): The above example of "Sensitivity" "3" doesn't change mouse sensitivity at all with in_mouse 3, while (as I just said) both in_mouse 1 and in_mouse 2 clearly depend on X sensitivity settings...


sempron

I've never gotten this new mouse settings to work.

My question is: why did ezquake developers have to make it so much harder?

Why didn't you add all these new options, but made the default settings identical to the old ezquakes, for backwards compatibility?

It is really why I can't upgrade to the new ezquake. Because my old config the mouse is totally wrong.

in_restart was done by one man - me, at least secondary sexual characters say so, both in linux and windows, so it not a) case but c) and b). But it PAIN, think about, linux does't have direct-x and windows does't have evdev or DGA, so in_restart is really OS dependant, so I selected some backward compatible setting, as I recall or something what cause as less as possibile problems.
Also, I did't really checked how in_restart works in NON GL builds (both windows or linux), I simply ignore soft.

heh, dunno, i tryed make it backward compatible and hope it so, however I mostly tested evedev mouse with fps independant physics because found other mouses types just unplayable even before I added in_restart.

I slowly get accustomed to ezquake in Linux - and more and more I can say that playing with it is quite okay (not quite as nicely as with ezquake for windows, but it comes close) - of all the clients tested by me I always end up with ezquake again, because it is the one that I like the best, in spite of all the flaws I described before.

I still think that both in_mouse 2 AND in_mouse 1 cannot be pure DGA, because mouse sensitivity (in-game) depends on X settings (either xset settings or xorg.conf settings). I am under the impression that even in_mouse 1 shows mouse acceleration! (something that I highly dislike). - In Windows XP, however, in_mouse 2 (which is direct input) is clearly independent of desktop mouse speed settings!

Well, I suppose, DGA or direct input should be completely independent of any desktop mouse settings (bypass them). Correct?

Just curious:
Wouldn't this mean that a sensitivity of (for instance) 7.5 in Windows XP with direct input should feel the same as a sensitivity setting of 7.5 in Linux? (using the same software (ezquake) and the same mouse)?


sempron

true.


dunno about DGA, but direct input in windows actually depends of drivers, at least with my logitech mouse and setpoint (that how mouse drivers called by logitech) installed.
Also, I can only repeat my self, EVDEV most(or only!) smooth mouse in linux, at least with in_mmt 1 and fps independant physics, same smooth as in windows.


Nothing to comment, too "brave" assumption.

Make sure to increase your mouse polling rate to 500Hz. Ezquake under Linux with > 500fps, 500Hz and evdev is extremely smooth. Without the tiny fps drops you get under Windows XP. If you have any further questions just join #linux.qw. We'll help you out

and yes, 500 hz is MUST HAVE.

I am quite convinced, nobody is able to distinguish 500 hertz polling rate from 250 hertz polling rate! Of course, just 125 hertz is a different story (mouse movement, indeed, appears less smooth) - but seeing a difference between 250 and 500? No way - looks like pure placebo to me.

Anyway, I DO use 500 hertz polling rate (in Linux, via: modprobe usbhid mousepoll=2) (though everything is already perfect with 250 Hertz in Windows XP!), I still experience a slight mouse lag when using ezquake in Linux. And I still do not know whether it is some kind of video lag or whether it is input lag or whatever...

Is it, however, no sound lag, because it does not only happen when using ALSA, but also with opensound.

For whatever reason, using ezquake in Windows XP (with otherwise identical settings) is still better and more fun/more successful. It just feels like there is no delay whatsoever as compared to the tiny bit of lag experience when playing under Linux.
But it cannot be my system: On the same computer and with the same Linux other games (like aprq2 for Quake2) run very, very well (smooth, fast, without any feeling of input/video latency)...

So to summarize:
ezquake is playable under Linux and I got accustomed quite well to it, but playing quake2 or playing (ezquake...) under Windows is still a better and more lag-free experience...


sempron

Maybe it's because KovaaK and I both use very high FPS caps higher than 500 and high refresh rates (160hz for him, 125hz for me) but I know we both can distinguish 500hz from 1000hz, and the same goes for 250->500hz.

Why not? You still can use -mevdev on the command line, and change it 'on-the-fly' if you need, with the in_ev* variables. For me the in_restart command is being very useful (thanks qqshka!), because sometimes my Debian box sets the mice to /dev/input/event1 and sometimes to /dev/input/event2, I don't know why. Even if I have some of the two set with -mevdev I can change it inside the client. Maybe you forgot to set in_mouse 3?

I use a separated xorg.conf to play quake, with every line regarding the mice commented. We don't need it because the mice is accessed directly through the client.

As it says in the new 1.8.2 client when you type the various in_* commands you need to type the following from the console

sudo chmod 644 /dev/input/event*

then after you load the client type in_evdevlist and it should list all the events.

Really interested in hearing what settings people are using.

currently I am using
ubuntu 7.1 - gives me some problems but for the most part its ok.

Logitech G1
500hz mouse
in_mouse 3 (which is evdev)
sens 4
Using the real time clock running at 1024

Here it goes:

Debian 4.0 (aka "Etch" - everything is default, xorg/kernel etc

Logitech mx518
500hz mouse
in_mouse 3 (evdev)
sens 3.2
I don't use -rtctimer because for some strange reason I can't get stable fps when using it
1152x864@108 / cl_maxfps 540 (got this modeline here: http://koala.ilog.fr/cgi-bin/nph-colas-modelines)
"xset m 0 0" on my init script to remove accel

With -rtctimer the FPS isn't correct here when I connect to localhost. The same happens to you?

I don't notice any problems with frame rate, only problem I notice is the mouse response doesn't feel as good as my old svga setup I had been using.

Perhaps recompile your kernel and change the kernel scheduling to 1000hz

Using the following code from below might also help get your frame rate stable originally posted here

i wonder where Strider is these days

I've already tried to do this, with no success. It's weird because with -rtctimer the fps is correct online, playing on some internet server, but it's wrong on localhost.


This probably doesn't have anything to do with FPS, but with the mice. I was using the same thing but did it in a different manner:

renice -20 `pgrep events/0`
#run qw here
renice -5 `pgrep events/0`

This does the same thing: give highest priority (-20) to the mice's process (events/0), run qw, then return to the normal priority (-5). But I don't like to use such things anymore, too much tweaks sometimes make things worse.

This sounds very interesting. So I am not alone noticing some kind of mouse lag when playing ezquake in Linux? Or do you do it because of that DGA mouse stuttering? (not sure what is meant by that, though)

Does it improve mouse responsiveness for you?
I cannot say anything yet because I just started testing it a bit. Not sure if it improves something or whether it is mere fancy.


sempron


@sfinx
Yes, just using pgrep makes it even simpler, good idea!

I notice if I use the svga client I can get way more directs off when compared to 2.6 kernel xwindows using dga or evdev mouse.

30 directs vs 11 directs

Hm, this is not the answer to my question. ;-)

I am more interested in the impact of the "renice" trick on mouse lag. Do you notice any effect? I have been testing it out now for some time, but I am not convinced, it changes anything.

What do you mean by "directs"? Not sure, I understand, do you mean "direct hits"?


thanks again, sempron

It makes the mouse feel smoother

but doesn't solve my problem.

By directs I am talking direct rocket hits.