Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
There's lots of stuff like constant/adaptive deceleration, velocity scaling, a whole transformation matrix and several acceleration profiles (check http://www.x.org/wiki/Development/Documentation/PointerAcceleration/ ), most of them are not available through any configuration GUI.
And yeah there needs to be a gui. People moving to linux for gaming wont want to edit text files or use the command line.
The people I play with say that is one of the top reasons they wont use linux.
Just one question. What happens when people switch to wayland?
For some people competitive playing is fun and requires proper configuration and hardware.
I'd say that it depends entirely on the Wayland compositor/displayserver abilities vs. the distros interface.
I just read that someone proposed to make a common library for input handling, based on Weston, that people could optionally use when creating a Wayland displayserver/compositor.
If you're asking in general:
The first few years, while Wayland compositors gains ground, you'll have a bunch of software using XWayland, which is one 'fullscreen' X-server instance per XWayland surface. So running a lot of software that has no Wayland support, will require more of your computer than an X-server (+ compositor) requires today. It should still result in 'perfect frames' and less inputlag than X-server has had (a lot of the changes done to X-server while preparing for XWayland, has afaik, removed a lot of roundtrips in the current, and upcomming version of X-server). Running only Wayland software though, should result in a more smooth user experience, and use less system resources. Check out videos on youtube with RPi running X-server, and Wayland.
Other than running some software in XWayland compatibility-mode, a little chaos, some failed Wayland compositor attempts and stuff like that, there shouldn't be that much difference, other than hopefully more efficiency, and 'perfect frames'.
I had a neat fix for this when there was no native steam. I would disable vsync in the game then tell kwin to use vertical sync. It got rid of all the screen tearing and the responsiveness was about the same as with having vsync off.
Native steam games don't seem to want to do that for me they just tear.
Im not good at programing otherwise id start working on a gui. QT interfaces are easy but I dont know how to make the interface actually do something.
for the 1:1 with 1600 dpi. everyone likes different sensitivity. I was pretty good with the default windows xp mouse settings and a 900 dpi mouse. I haven't found any info on the windows mouse acceleration and I wish I could mimic that in linux.
I use to not have to think about aiming at all and still have better accuracy than 95% of players but now im a total noob.
Ok looks like they will have a common input library. Wonder if its going to be like xorg where there is like 3 input libraries as stuff developes they keep old libraries around.
So this wasn’t even a sensitivity issue to start with. Very handy info anyways. I might make a GUI written in QT for tweaking mouse settings. Because, its 2014. Why are we still editing text files for a desktop environment?
Kone Pure can change profiles, DPI and sensitivity on the fly, it even can talk when chages it. Be sure to start "roccateventhandler" (user-side driver) first.
Mouse acceleration on X can be turned off completely, say, in xorg.conf:
Anyway, it'll be good if you make another GUI for Roccat.
I dont even have an xorg.conf so Im assuming that the mouse settings might be somewhere else?
It's not clear what you mean by "base sensitivity".
Pixel-to-pixel mapping CPI to screen, without acceleration? In this case laser Kone Pure's lowest is 800 CPI, and it can be dinamically (i.e. without replug) changed to 1600-3200-6400-8200 CPI both from Kone's GUI and from mouse itself (with "+" and "-" buttons on top).
Also Kone Pure has it's own "acceleration speeds" (from -5 to +5): say, on the same 800 DPI when you physically move the mouse at constant speed, cursor moves faster (at +5) or slowlier (at -5). These "acceleration speeds" also can be changed both from Kone's GUI or with mouse buttons.
Also games themselves may have settings for "sensitivity", "acceleration", etc. and only god knows what exactly they do.
Besides, X server has its own settings for "mouse acceleration". They can be configured with xinput tool, or in xorg.conf file, for a specific device (as in my example), or per group of devices, or per all devices, with different schemes and algorithms, etc, etc.
http://www.x.org/releases/X11R7.7/doc/man/man5/xorg.conf.5.xhtml
You don't have xorg.conf simply because X is normally smart enough to live without it, and users are happy with its default settings.
Roccat's mouses are nearly the only mouses that are well supported on linux, as far as I could see. It's strange that you have problems with Kone Pure...
UPD. Just to make it a bit more clear. "Mouse sensitivity" is a combination of CPI and "acceleration". Linux (X, actually) doesn't have any CPI of it's own, CPI is in mouse's sensor. But X does have a default acceleration profile, it can be checked with, say, xinput. Default profile can be changed to some other.
There's no GUI to manipulate X's main config xorg.conf and probably never will be, for various serious reasons. However, it's possible to make a script that detects X's current mouse settings and changes them with xinput, or xset, etc. It's also possible to write a GUI for such script.