As many of you know, Wine have number of serious problems when it comes down to games when using mouse. In fact big number of games suffer one or more of the following problems: 1. Mouse pointer escapes game window (for windowed programs) or confined to arbitrary rectangle (for full-screen) - bug 6971. 2. Mouse is being constantly re-centered (number of bugs). 3. Mouse lags, moves wrong direction or doesn't move at all (number of bugs). 4. Mouse is not smooth with high graphics/system load.
There are lots of reasons for these bugs: a) Wine does not grab pointer (doesn't lock it to one particular window). b) Wine's dinput still doing mouse warping while it should not c) Wine relies on an application to process messages so new input events could be received. d) Wine's x11drv is not fine grained - it has only one lock that everything uses, d3d and wgl included. e) The path from x11drv to dinput for input events is long with big overhead. f) X events come from Wine windows for the current process only not whole screen. g) Motion events Wine receives are absolute not relative.
Here is what me and others tried but failed: i) XEvIE - buggy, disabled by default, requires server round trip. ii) XInput - does not allow opening of keyboard or mouse devices. iii) Event Device (EvDev) - works perfectly, solves (a,b,c,d,e,f,g) but it's a client only solution (will not work on remote X, because it will try to open remote mouse, not local). iv) Virtualizing mouse pointer in x11drv - depends on (a) moves (b) from dinput into x11drv while same issues remain. v) Writing new X extension - last I've heard about this, it didn't get anywhere past initial proposals.
Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all?
As you see there are not much options available to solve mouse problems. However I personally do not want to turn this into another "child opengl saga". We ether solving it now, or putting a big red X on any game that's using dinput mouse, that's not already working.
The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_! Yes it's a limited fix it will work only for 99% of users who play games on their PC, and not remotely.
Vitaliy Margolen.
On Thursday September 27 2007 04:07, Vitaliy Margolen wrote:
The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_!
I strongly agree here with Vitaliy. Personally I think that using evdev for this purpose IS the "right way". Yes it will not work with remote X but Windows doesn't support this too (as far as I know at least). WINE purpose is to conform with Windows behavior. Therefore use of evdev will be correct. Even if above isn't true (I think it is) full support of remote X by dinput component isn't something useful for about 100% of users anyway. Of course everything above is just my opinion.
On Thu, Sep 27, 2007 at 04:48:23AM +0000, L. Rahyen wrote:
On Thursday September 27 2007 04:07, Vitaliy Margolen wrote:
The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_!
I strongly agree here with Vitaliy. Personally I think that using evdev for this purpose IS the "right way". Yes it will not work with remote X but Windows doesn't support this too (as far as I know at least). WINE purpose is to conform with Windows behavior. Therefore use of evdev will be correct. Even if above isn't true (I think it is) full support of remote X by dinput component isn't something useful for about 100% of users anyway. Of course everything above is just my opinion.
on the other hand what is the use of playing a game over a remote machine? or are there apps, that suffer from this too? i can only figure out two things:
- running a game server (unlikely one uses a direct X session - maybe only for games that need a client to configure the server)
- play multiplayer games on one machine exporting it to the network (i doubt many do this - excepcially with windows games; it is more likely the other way around: host a linux game to a buddy with a windows notebook)
one other concern i have is compatibility with other platforms. wine runs more or less fine at least on freebsd and osx - and others. so we keep the "old" code around, right?
in general i would like to point out, that we have already similar stuff going on with the joystick drivers. the /dev/js joystick was/is(?) not useable for serious sims, due to its dead zone coming from somewhere in the kernel. so the /dev/input option is there - linux only i asume - which works great.
so if the "evdev" path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance.
Am Donnerstag, 27. September 2007 08:04:30 schrieb Christoph Frick:
On Thu, Sep 27, 2007 at 04:48:23AM +0000, L. Rahyen wrote:
On Thursday September 27 2007 04:07, Vitaliy Margolen wrote:
The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_!
so if the "evdev" path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance.
You have my vote on an evdev dinput backend too, however, we get some problems which the X server used to solve for us:
1) Multiple Mice. If there are 2 mouse devices, the X server manages them and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse.
2) Different devices: An USB mouse creates a /dev/input/eventX node, but other devices, like my synaptics touchpad do not. In the worst case we need a driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, logitech, ...
3) Other OSes: This was mentioned already, but I wanted to add that the problem seems X11-only. MacOS reports relative mouse movements like Windows does, so a quartz driver will not have this issue. Perhaps the evdev reading should be implemented in winex11.drv?
I think as a first step, we should ask the X11 developers for their advice. Maybe we're missing some option here? I doubt it, but we should give it a try.
Stefan Dösinger wrote:
- Multiple Mice. If there are 2 mouse devices, the X server manages them and
combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse.
This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games <g>
- Different devices: An USB mouse creates a /dev/input/eventX node, but other
devices, like my synaptics touchpad do not. In the worst case we need a driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, logitech, ...
Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse - works properly in each case.
Vitaliy
Am Donnerstag, 27. September 2007 17:23:42 schrieb Vitaliy Margolen:
Stefan Dösinger wrote:
- Multiple Mice. If there are 2 mouse devices, the X server manages them
and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse.
This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games <g>
I do
That's the great thing about laptops, at least when playing Battlefield 1942. You can keep an aircraft controlled with one hand, but for serious fighting you need the real mouse. Imagine a LAN Party, running bf1942, some pizza next to you. With the thumb on the touchpad and the WASD keys, you can take off with a plane and steer to the battle, while the right hand is free to grab a glass or some pizza. Yes, it makes the keyboard and mouse oily and there's a risk to poor liquid over the laptop, but it works with the current dinput code :-)
Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse
- works properly in each case.
Should all mouse types create a event device node? Maybe I've done something wrong on my new laptop. On the old laptop, the touchpad had such a node, on the new one it doesn't.
On Thursday 27 September 2007, Vitaliy Margolen wrote:
Stefan Dösinger wrote:
- Multiple Mice. If there are 2 mouse devices, the X server manages them
and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse.
This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games <g>
Almost every laptop with externally connected USB mouse will behave like that.
Kuba
Vitaliy Margolen wine-devel@kievinfo.com writes:
Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all?
The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs.
Alexandre Julliard wrote:
Vitaliy Margolen wine-devel@kievinfo.com writes:
Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all?
The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs.
I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that.
I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need.
Vitaliy.
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Alexandre Julliard wrote:
Vitaliy Margolen wine-devel@kievinfo.com writes:
Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all?
The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs.
I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that.
I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need.
We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others.
The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs.
I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that.
I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need.
We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others.
--
I'd suggest we see if we can get someone from X.org involved in the discussion. While this wouldn't result in a fix today it would certainly let us get cooperation which is likely to result in a better fix. We might have to wait half a year for the full fix to get out there but we can always provide a short term work around and see if we can't run-time detect the improved correct way of doing it.
Chris
-
Alexandre Julliard -
Chris Morgan -
Christoph Frick -
Dmitry Timoshkov -
Kuba Ober -
L. Rahyen -
Stefan Dösinger -
Vitaliy Margolen