Seriously, guyz???
-
http://creative-destruction.me/2014/11/13/configure-your-gaming-mouse-on-linux/
Using gamer mice with Linux occasionally turns out to be problematic, because their high resolution combined with the default X server settings makes the mouse pointer incredibly fast to a point where it is unusable.
Seriously, Linux people? Your windowing system can't handle mouse DPIs in a sane fashion?
The basic desktop settings tools allow configuring the mouse pointer speed, but not much more. This is insufficient when using multiple devices (in this case, the built-in laptop trackpoint and an external mouse) that require different settings.
Seriously? You haven't figured this basic shit out yet?
The basic task is to examine the input devices known to the X server (for example by using xinput --list on the command line), determine the device ids from the listing, and then applying specific properties to known devices.
Seriously? There's no programmatic API for this shit? You need to use the a CLI command as an API?
The remaining question is how to automatically invoke the configuration script whenever a X input device is connected. If anybody knows how to get this done, please leave a comment.
Seriously? All this shit and you still don't even know how to make it work?
-
First of all, every proper game in the world lets you lower the sensitivity in-game.
Second of all, DPI switch buttons still work.It's a non-issue.
-
How legit is this website? the name kinda speaks for itself
- you can skip CLI commands with this setup , this will insure the mouse will never be too fast
- you can skip CLI commands with this setup , this will insure the mouse will never be too fast
-
Is that ... KDE configured to look like Unity?
What kind of heretic would do that?!?!
-
Then the article exists... why?
-
No fucking clue.
Let's also not forget that each Desktop Environment has something like this: http://docs.xfce.org/xfce/xfce4-settings/mouseHe's probably a "Oh look, I'm so cool because I use Arch Linux and do everything in CLI" idiot.
-
Is that ... KDE configured to look like Unity?What kind of heretic would do that?!?!
I am not sure I just gis a windows running in linux.
Seriously? All this shit and you still don't even know how to make it work?
if you feel like pointing the poor guy in th right direction, leave him a comment
UDEV - Run program on USB flash drive insert
I am trying to get a script to run whenever ANY USB flash drive (not just a specific one) is plugged in to the system and I have been pulling my hair out for about 2 weeks now on and off trying to ...
since when linux is for gaming anyhow?
-
SteamOS? AMD and Nvidia have been working with Valve to improve video card performance on Linux. Hopefully by next year it'll finally release.
-
SteamOS? AMD and Nvidia have been working with Valve to improve video card performance on Linux. Hopefully by next year it'll finally release.
lets resume this conversation in few years, so we can discuses actual improvements.
-
I'm pretty sure there's a
xinputswitch that allows you to change the sensitivity beyond what the GUI will let you. That said, I only used that once, ever, so I consider it a non-issue. The frequency at which you need to do it is about the same as on Windows; there's always that one wonky piece of hardware that's a pain on any OS after all.
-
I think this is not so much a 'gaming on linux' issue, as a 'gaming on windows, dual-booting linux on the same box' issue. Not that I've ever had a problem with it.
Ingame sensitivity switches are irrelevant, because it's the base UI that gets unusable.
-
Second of all, DPI switch buttons still work.
Ingame sensitivity switches are irrelevant, because it's the base UI that gets unusable.
No, DPI switching is a hardware function inside the mouse -- at least that's the way it is on my SideWinder X8.Seriously, Linux people? Your windowing system can't handle mouse DPIs in a sane fashion?
CLOSED WORKSFORME. I have used a SideWinder X8 on Linux (Mint/MATE) at its default 4000dpi setting and have not had one whit of trouble with "OMG, the mouse is unusably fast!". My parents have to use the DPI buttons to turn it down, though.
Besides, I'm sure that if you cranked up the mouse pointer speed settings in Windows all the way, you'd have the same problem that guy had -- it's a "the defaults are designed for $2 300dpi mice" problem, not "KDE/Gnome/... picked an insane default" problem. In fact, I recall having to turn the UI mouse speed down on Windows XP when I got my first gaming mouse, a MX518.
-
I think you missed my point.
The dpi button on a mouse lets you switch sensitivity without any system settings. That means that you can use highdpi in games and lowdpi outside of them. Which makes the blog's complaint kind of pointless.
I am fully aware that it works by hardware-side magic.@pleegwat probably referred to the mouse sensitivity slider most games have in their options menus. Which is a software-implemented per-game solution.
-
lets resume this conversation in few years
Heretic! Necroposting is not The Discourse Way! We should instead....
um....
Never talk again? That seems to be Discourse Approved
-
Ah. I was thinking @PleegWat was trying to say that the DPI buttons required per-game support, which is wrong, as you and I already know.
-
The dpi button on a mouse lets you switch sensitivity without any system settings.
of course changing those DPI settings on the mouse are not always easy on non-windows platforms. but once set you can use on linux without issue, and sometimes the mice are well enough designed that there are linux apps for setting all the button mappings and DPI switches without needing Windows or WINE
-
I didn't have any problems with mouse button mappings since... 2007-ish? I do remember some tinkering around in
/etc/xorg.confon Ubuntu 6.06 for one of those 15 button monstrosities one of my friends had, but somewhere around 7.x it all started to Just Work™.
-
never had much trouble with button mapping. the one i remember was the buttons were'nt mapped right in hardware (btn4 was labled btn5 on the mouse and vise versa) and i had to fiddle with Xorg to map btn 4 to btn999, btn5 to btn4 and btn999 to btn5
they apparently fixed that in the driver for windows rather than rewiring the mouse correctly...
-
they apparently fixed that in the driver for windows rather than rewiring the mouse correctly...
We'll fix it in
postsoftware!
-
I think someone else mentioned ingame DPI settings as an option? May have misread.
My own mice (both home and work) have DPI buttons, and they work fine under linux. Though I did need to do some education for the mode switch on my cyborg rat - the default linux driver detects more buttons than the windows one, and that mode switch was implemented on (IIRC) button 10-12, one of which is continually pressed...
-
I was about to chime in that I also use a high dpi mouse in Linux regularly and when I looked up the dpi on mine, I discovered that it's 8k. WTH? That's just ridiculous.
I have the opposite problem, though, that when the software for the mouse isn't loaded, its sensitivity settings seem to become something completely different from either what's set in the mouse's software or what's set in Windows. I adjust the sensitivity in Windows to where it already is, and the mouse behaves correctly.
Then again, Razer's software is clearly TRWTF. My mouse and all of its "extra" features work fine under Linux without the software.
-
Doesn't adjusting the sensitivity slider in Windows make the mouse move two pixels per tick and if you move it down, ignore ticks? It's almost as annoying as how mouse acceleration is on by default everywhere (Mac users can't even turn it off iirc).
-
The dpi button on a mouse lets you switch sensitivity without any system settings.
Yeah but that's clearly a "why should you have to?" kind of thing.
DPI is a "per" measure Dots-per-Inch. Therefore, it's super easy for software to translate that resolution to any speed.
I'm guessing the real problem here is that Linux mouses don't have to way of reporting their DPI to the host OS and/or the mouse makers don't bother making drivers for Linux, because the Linux kernel team has made things like "writing drivers" a wide-awake nightmare.
-
I'm guessing the real problem here is that Linux mouses don't have to way of reporting their DPI to the host OS
Not sure if that's a problem or not -- it's certainly fixable if it is, though.the mouse makers don't bother making drivers for Linux
Yeah. Most folks can't get drivers right for one OS, never mind 3-4! So, the 300dpi $2 mice and your RAT7 wind up sharing the same ol' stock HID driver on Linux -- it's no different than plugging your RAT7 into a Windows box that you can't install drivers on.because the Linux kernel team has made things like "writing drivers" a wide-awake nightmare.
Look in the mirror, blakey, because the Windows kernel team has done that, too -- or at least that is what I have been consistently told.
-
Not sure if that's a problem or not -- it's certainly fixable if it is, though.
Everything's fixable, the point is it's been decades and they haven't done it. All the Java crap we talk about is fixable, too. Hell, Lotus Notes is fixable-- it'd take a lot of effort because the hole they've dug is so deep, but it could be done.
Look in the mirror, blakey, because the Windows kernel team has done that, too -- or at least that is what I have been consistently told.
Somehow the Windows kernel lets your run drivers without incorporating them into the kernel itself. The problem with Linux is that the only reasonable way to write drivers is:
- Open source them, giving away any of your "secret sauce"
- Give up control of them to the Kernel team, where some idiot who probably doesn't even own the mouse in question "maintains" it
- But it'll break in 3 years anyway, and since the guy who "maintains" it doesn't give a shit, he'll just remove it outright instead of fixing it
(Or you can do what NVidia did and write a huge open-source wrapper to a proprietary driver, but that take a lot of effort that I'm guessing smaller hardware companies can't afford. Especially since the gaming market on Linux is so weak in the first place.)
-
Somehow the Windows kernel lets your run drivers without incorporating them into the kernel itself.
This is true on Linux, as well -- out-of-tree drivers are the norm while a driver is being initially written/stabilized, with the driver being brought in-tree once it is ready for general use.
1) Open source them, giving away any of your "secret sauce"
- Why would there be software "secret sauce" in a mouse driver?
- If you are dealing with a device full of secret sauce, wouldn't it be better to put the secret sauce in hardware/firmware, not in your @!)($!)$ driver? (I know, I know, that makes beancounters mad -- but it is better in the long run, since it opens you up to more markets.)
2) Give up control of them to the Kernel team, where some idiot who probably doesn't even own the mouse in question "maintains" it
Or, someone at your company can contribute patches to keep it up-to-date -- nothing stops hardware vendors from doing that, and some indeed do!
-
1) Why would there be software "secret sauce" in a mouse driver?
Because it's a gaming mouse.
2) If you are dealing with a device full of secret sauce, wouldn't it be better to put the secret sauce in hardware/firmware, not in your @!)($!)$ driver?
Most companies don't have tons of money to throw down a well. It's also possible the "secret sauce" is just a fix for something in firmware.
(I know, I know, that makes beancounters mad -- but it is better in the long run, since it opens you up to more markets.)
Right; but is there any evidence that selling gaming mouses to Linux users is a money-maker? Maybe, maybe when SteamOS is popular. Maybe. But now?
Is it worth the money of crafting the driver? Is it worth the headaches? Is it worth the expensive salary for someone who knows the Linux environment well enough? Does it add-up?
No; if Linux wanted hardware support, they'd change the equation by making driver development and distribution super-easy. They'd remove the requirements for drivers to be part of the kernel project (and therefore licensed GPL2). They'd fix the driver ABI so once written, the driver doesn't have to be rewritten for a decade or longer. They'd maybe even create a way for Linux to run Windows drivers, sure that's super-hard, but it would sure be a game changer.
Linux won't have good hardware support until they change the economic equation.
Or, someone at your company can contribute patches to keep it up-to-date -- nothing stops hardware vendors from doing that, and some indeed do!
Right but then you're paying a salary for it. That ain't cheap at all.
-
-
Because it's a gaming mouse.
BZZT -- the only protocol difference I'd expect between a fancy gaming mouse and a normal mouse is the request used to set up the DPI presets; things like macro buttons aren't an issue to handle in userland.
This really is a case like I mentioned where the secret sauce is in hardware -- read the USB HID class spec sometime, and think for a minute how much of the functionality of your RAT7, or my SideWinder X8, or any other gaming mouse you can think of requires commands above and beyond what HID defines.
It's also possible the "secret sauce" is just a fix for something in firmware.
Bugs suck, yes; but I don't get why a hack to workaround a firmware bug or chip erratum would be top secret stuff -- it's something that someone who wants to make a driver for your device will deal with in any case.Is it worth the money of crafting the driver? Is it worth the headaches? Is it worth the expensive salary for someone who knows the Linux environment well enough? Does it add-up?
If you can't tell there, I was speaking of hardware in general, not gaming mice.they'd change the equation by making driver development and distribution super-easy.
I'd say it's easier to write and distribute an out-of-tree Linux driver than it is a Windows driver -- it's certainly no harder than writing Windows drivers.They'd remove the requirements for drivers to be part of the kernel project
Did you even read what I said about out-of-tree drivers? Nobody will shoot at you for distributing your driver out of tree!They'd fix the driver ABI so once written, the driver doesn't have to be rewritten for a decade or longer.
If you aren't shipping a blob, this isn't a big deal: setting up your out-of-tree module to use DKMS means you can just push a source package out to users and it'll get recompiled against the kernel whenever needed.On the Windows side: there have been plenty of major driver-framework changes there too -- driver API/ABI stability in Windows isn't something I'd bet my company on, either!
And to top it off -- for the original topic (gaming mice), you don't need a kernel mode driver at all if all it does is send extra commands to the mouse to turn on/off specific stuff. This thing called libusb exists for a reason, you know...
-
BZZT -- the only protocol difference I'd expect between a fancy gaming mouse and a normal mouse is the request used to set up the DPI presets; things like macro buttons aren't an issue to handle in userland.
Not... force feedback? Perhaps a little LED screen on it showing your ammo counter? Maybe an integrated "mute" button which works hand-in-hand with a USB headset? Or like a tilt accelerometer that gives it a little 3D-ish panache? I can think of a thousand features a gaming mouse might have to set it apart.
If you think the only difference is the DPI and the amount of buttons... well, you're not a very creative person, we'll just leave it at that.
It's the OS's job to provide enough driver access to easily write drivers for not just plain yogurt hardware device, but for all possible hardware devices.
This really is a case like I mentioned where the secret sauce is in hardware -- read the USB HID class spec sometime, and think for a minute how much of the functionality of your RAT7, or my SideWinder X8, or any other gaming mouse you can think of requires commands above and beyond what HID defines.
I just listed a bunch of them. Although some of them might be covered by creative use of multiple HID interfaces for a single device, I've seen that done before.
If you can't tell there, I was speaking of hardware in general, not gaming mice.
That all applies to hardware-in-general as well, though. Unless the estimated payoff is greater than the effort, there's no point in any hardware maker creating a Linux driver.
Now you may argue that they're under-estimating the payoff, and that may be true, but it doesn't change the basic equation.
I'd say it's easier to write and distribute an out-of-tree Linux driver than it is a Windows driver -- it's certainly no harder than writing Windows drivers.
...
Did you even read what I said about out-of-tree drivers? Nobody will shoot at you for distributing your driver out of tree!
That's contrary to everything I've read about Linux driver development, but I'm certainly not an expert in the area.
On the Windows side: there have been plenty of major driver-framework changes there too -- driver API/ABI stability in Windows isn't something I'd bet my company on, either!
There's been two. Ever.
One when the consumer OS switched from Win32 to WinNT, and another when Windows Vista came out. (And Vista could still run the old-style Windows 2000 drivers, it just took a bit of "convincing".)
Unless you're going way back into ancient history and including DOS and Windows 3 drivers.
-
force feedback?
This can be done through standard HID requests -- it's certainly a common enough feature on other HID devices!
Perhaps a little LED screen on it showing your ammo counter?
Perhaps, although that makes me wonder why you're looking at your mouse to begin with...Maybe an integrated "mute" button which works hand-in-hand with a USB headset?
That doesn't even need to be a dedicated special function button -- and certainly doesn't need kernel support! Besides, wouldn't you want it to work for all headsets, not just your special fancy USB headset? (Call me old school, but I still get headsets with 3.5mm plugs on them, because they Just Work(tm), no matter what machine you're dealing with.)Or like a tilt accelerometer that gives it a little 3D-ish panache?
Now, an accelerometer in a mouse could be interesting...It's the OS's job to provide enough driver access to easily write drivers for not just plain yogurt hardware device, but for all possible hardware devices.
I was speaking to what could be supported by HID itself as a protocol.Now you may argue that they're under-estimating the payoff, and that may be true, but it doesn't change the basic equation.
My argument exactly -- the payoff for building a device (or, especially, designing a chip, since for most devices, drivers are at a chip level) that other people can write drivers for is that people will use it for more applications!That's contrary to everything I've read about Linux driver development, but I'm certainly not an expert in the area.
Not sure what you're reading -- but while in-tree has the advantages that it goes out to everybody who uses Linux, and you get more help from the kernel maintainers when it comes to fixing stuff, as I said -- the worst you'll get for sticking with out-of-tree is a 'aw, darnit...'There's been two. Ever.
One when the consumer OS switched from Win32 to WinNT, and another when Windows Vista came out. (And Vista could still run the old-style Windows 2000 drivers, it just took a bit of "convincing".)
True for the core API of 'how do I get a driver that does nothing into the kernel', but that's not what is generally meant by "Linux kernel ABI", and Windows device-type/subsystem-specific APIs are worked on on a fairly regular basis as well. See http://msdn.microsoft.com/en-us/library/windows/hardware/dn312125(v=vs.85).aspx for an example, as well as http://msdn.microsoft.com/en-us/library/windows/hardware/ff557454(v=vs.85).aspx.
-
Perhaps, although that makes me wonder why you're looking at your mouse to begin with...
That's not the point. The point is: I could easily see a mouse maker wanting that feature to set themselves apart. It doesn't matter if the feature is actually useful or desirable or not.
(Call me old school, but I still get headsets with 3.5mm plugs on them, because they Just Work(tm), no matter what machine you're dealing with.)
The ability to hot-swap a headset is worth using a USB one. I know some sound cards "support" it, but that's never worked very well for me. The real problem is a lot of software developers haven't gotten the memo from 1994 that hardware is hot-swappable yet.
It's also nice for my Let's Play videos that the USB sound channels are completely separate from the others, so I can easily record Skype and a video game into two different files simultaneously. I don't think I'd be able to make that work with a 3.5mm headset, at least not without some hackery.
Now, an accelerometer in a mouse could be interesting...
Right; now you're thinking. And I'd really hate to be the guy saying, "hey boss, this is a great feature, but it turns out the driver for it on Linux would cost $30,000 more than a stock driver." And if you like Linux, you should be having nightmares about that scenario. Nightmares!
True for the core API of 'how do I get a driver that does nothing into the kernel', but that's not what is generally meant by "Linux kernel ABI"
My understanding is that the Linux kernel ABI changes all the freakin' time for two reasons:
-
They don't plan ahead sufficiently to make all their needed changes all at once, and they don't see this as an issue since they only officially "support" drivers that are in the kernel and they can fix themselves, and
-
Linus doesn't want the ABI to be stable because that would lead to gasp proprietary drivers, and he somehow feels proprietary drivers would make Linux ... bad? ... somehow? I don't get it myself.
Anyway, if I'm wrong, correct me. But I've read a lot of articles about the driver situation in the Linux kernel, and I know the rapidly changing ABI is a point of contention.
-
-
For USB devices (which most input devices are nowadays), it is definitely possible to write a userspace driver. I've done so myself. You do need to start it as root so it can initialize the USB device and a uinput device so it can send input events back to the kernel, but once those are initialized you can drop to nobody.
-
Yeah actually now that I'm thinking about it, I think the last time I tried a Lunix (Ubuntu 11.something?), I had to use a userspace driver for my USB wifi network card.
-
For USB devices (which most input devices are nowadays), it is definitely possible to write a userspace driver. I've done so myself. You do need to start it as root so it can initialize the USB device and a uinput device so it can send input events back to the kernel, but once those are initialized you can drop to nobody.
Yeah, I linked libusb earlier in the thread.
My understanding is that the Linux kernel ABI changes all the freakin' time for two reasons:
Right, and most of those changes are specific to some subsystem dealing with a specific type of device. Windows is the same way: the core kernel APIs in Windows are much more stable than things dealing with specific device types.They don't plan ahead sufficiently to make all their needed changes all at once, and they don't see this as an issue since they only officially "support" drivers that are in the kernel and they can fix themselves, and
I'm sure there are plenty of cases where the Windows kernel team wish they had a time machine, because boy, we sure screwed up 3 years ago, and we'd love to fix it, but we'd have to release a new API version with the next release of Windows to do so. So, you either wind up basically batching changes into big packages with one big break per package, or dealing with lots of little changes with little breaks.2) Linus doesn't want the ABI to be stable because that would lead to gasp proprietary drivers, and he somehow feels proprietary drivers would make Linux ... bad? ... somehow? I don't get it myself.
It's called "this 3rd party driver is a piece of rubbish, but they won't fix it and we can't fix it". Considering how much damage a buggy driver can do...he has a point; Microsoft, OTOH, uses the strictures of the WHQL process as a defense against buggy rubbish drivers that crash people's systems -- they have the leverage to do that, though, whereas the Linux world doesn't.Anyway, if I'm wrong, correct me. But I've read a lot of articles about the driver situation in the Linux kernel, and I know the rapidly changing ABI is a point of contention.
It is; but at the same time, even for an out of tree driver -- it's not the case that you have to make code changes for every last ABI change under the sun.Yeah actually now that I'm thinking about it, I think the last time I tried a Lunix (Ubuntu 11.something?), I had to use a userspace driver for my USB wifi network card.
Windows actually has been moving towards this as well with UMDF. In general, ring0 code tends to blow up spectacularly when it does fail, so the less of it there is to blow up -- especially 3rd party ring0 code that has a nasty habit of doing naughty naughty things to the kernel -- the more reliable your OS will be.
-
It's called "this 3rd party driver is a piece of rubbish, but they won't fix it and we can't fix it". Considering how much damage a buggy driver can do...he has a point; Microsoft, OTOH, uses the strictures of the WHQL process as a defense against buggy rubbish drivers that crash people's systems -- they have the leverage to do that, though, whereas the Linux world doesn't.
How did / do drivers work in the Mac world?
-
How did / do drivers work in the Mac world?
Apple controls both sides of the ball in that case, so they can pretty much well test the living daylights out of their drivers, at least for important parts.
As to add-on USB doodads and such? Correct me if I'm wrong, but I think libusb works on OS X...
-
Windows actually has been moving towards this as well with UMDF. In general, ring0 code tends to blow up spectacularly when it does fail, so the less of it there is to blow up -- especially 3rd party ring0 code that has a nasty habit of doing naughty naughty things to the kernel -- the more reliable your OS will be.
The obvious solution is to not run the drivers inside the kernel, like Windows did in NT4, then didn't do for a long time for performance reasons, then did again in Vista. Not to put all the drivers in the kernel so you can "guarantee" correct code.
Anyway, regardless of what you think of Linus' driver philosophy, the practical result is the same: Linux has crappy driver support.
-
never had much trouble with button mapping
Fun fact: Same here, until least week. For some reason Windows 8 decided to switch the thumb buttons of my "new" mouse (not actually a new model, but I got a new one at work). Never happened to me on Linux, and I've been using Ubuntu since 7.xx.
BTW: Is there any way to re-map mouse buttons on Windows? I didn't find one and I'm tired of using the forward button to navigate back.
-
BTW: Is there any way to re-map mouse buttons on Windows? I didn't find one.
only way i've ever found it is to use the craptacular apps that the manufacturer puts out. never found a standard windows way to do it.
-
3) But it'll break in 3 years anyway, and since the guy who "maintains" it doesn't give a shit, he'll just remove it outright instead of fixing it
Since when do the linux kernel developers remove old drivers? They're still maintaining drivers for decade-old hardware that noone who doesn't live in a basement would ever use.
-
Since when do the linux kernel developers remove old drivers?
It doesn't matter what actually happens. Linux has shit hardware support. We know this because blakey told us.
-
It doesn't matter what actually happens. Linux has shit hardware support.
Because Linux sucks.
My current company produces hardware, including drivers and an SDK, for a number of operating systems including various Linuxes. Linux is always the biggest pain. Windows pretty much has universal back-compatibility, our current Windows drivers work on any version going all the way back to Win2000 I believe. And those who run Windows upgrade very very slowly, and Windows Updates never screws things up.
But Linux on the other hand, every minor update breaks it and we have to do modifications and additional testing across multiple kernel versions, platforms, and distributions. Because every minor change to the distro breaks something with the kernel interface.
I don't know how many emergency releases we've had to do because of things like a customer doing a simple yum update in CentOS/RHEL, causing the version to rev from 6.4 to 6.5 (to defuse the pedants, this is a scenario which has happened multiple times but with made-up details), and installing a new kernel which our drivers can't talk to yet. And while we're testing new drivers, their engineers are essentially blocked. All because some online guide says to do "yum update" before installing whatever.
-
But Linux on the other hand, every minor update breaks it and we have to do modifications and additional testing across multiple kernel versions, platforms, and distributions. Because every minor change to the distro breaks something with the kernel interface.
So you haven't put your stuff into the kernel to have the kernel devs do the work for you?
-
So you haven't put your stuff into the kernel to have the kernel devs do the work for you?
That probably wouldn't be legal. AS9000 certification, proprietary/classified protocols, U.S. Customs regulations and export laws, etc. edited to a TL;DR version
-
only way i've ever found it is to use the craptacular apps that the manufacturer puts out. never found a standard windows way to do it.
Why? Just why?
This is actually one of the reasons why I prefer Linux over Windows: The hardware support is still abysimal, but at least – once you found a piece of hardware that works fine on Linux – you don't have to install crappy software to actually use your hardware. You can use standard programs instead (whatever your DE and your distribution provide), which are actually going to work with the next version of your OS and don't fiddle with settings they shouldn't fiddle with.
-
Why? Just why?
Probably because Microsoft doesn't make a gaming mouse? Just a hunch. I wager they'd like to encourage people to use Xbox controllers for games.
I could see both sides of the argument. On the one hand, it's not really the OS's job to provide a config utility for stuff like this. On the other hand, providing a config utility in the OS would be pretty useful for the OS' users, and increase the usability-- since you know the third-party ones are all written by idiots.
-
I wager they'd like to encourage people to use Xbox controllers for games.
those actually work remarkably well, even in games that don't have controller support.
I was pleasantly surprised when i picked one up to start playing through the Halo series and it just kinda worked in all my other games, even the ones from as far back as 1999 (probably farther back than that, i just don't play those much these days)
-
Why? Just why?
dunno? i mean the buttons all work out of the box, it's mapping the custom actions to them that doesn't... i think that has something to do with windows not wanting to get in on the managing hardware profiles of other manufacturers. all the standard HID stiff (what's baked into the kernel/X11 in linux) works out of the box, but the fancy mouse specific settings don't (neither do they in Linux either so at least that's parity)
-
On the other hand, providing a config utility in the OS would be pretty useful for the OS' users, and increase the usability-- since you know the third-party ones are all written by idiots.
I think the main problem is that Microsoft wants to be attractive to hardware vendors, who actually think that their crappy driver software is adding value for their customers. I'm tired of useless mouse drivers which replicate existing settings dialogs just to put the vendor's logo into the dialog, constantly consume 5% of your CPU time, add toolbars to all of your browsers and manage to break both your AV software and your disc burning software in the process.
