DInput mouse - where to go from here?
frick at sc-networks.de
Thu Sep 27 01:04:30 CDT 2007
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 163 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070927/c1f0ad0a/attachment.pgp
More information about the wine-devel