Dear sir/miss, I found a problem regarding wine. Linux detects my gamepad fine, but wine doesn't find my gamepad. This problem lies in the fact that wine checks /dev/js0 while the device is located in /dev/input/js0. To solve it I would suggest to let the ebuild make a symlink from /dev/input/js0 to /dev/js0 This problem occurs with all wine versions of wine as far as I am aware.
*** Bug 130262 has been marked as a duplicate of this bug. ***
You need a custom udev rule to make such symlink, not exactly what wine ebuild should be doing, IMHO... Better ask upstream to fix wine to search for js? devices in /dev/input.
wine should check both /dev/input/js and /dev/js
Created attachment 84840 [details, diff] wine-joy.patch try this patch please
You could easily maintain compatibility with Wine and any other application using joysticks simply by adding some symlinks in /dev. That's what my system has, and it's using udev. /me says its a Gentoo bug.
btw. The solution is not to modify your Wine ebuild, it is to fix the system (udev configuration or population of /dev) to create a link /dev/js0 -> input/js0. This is standard on other systems, and it's why joysticks work with Wine on other systems. bash-3.00$ ls -l /dev/js0 lrwxrwxrwx 1 root root 9 2005-11-23 06:15 /dev/js0 -> input/js0
Heh, that could be a solutions aswell, anyways I don't mind because creating a symlink solves the problem, but for users not aware of this, it might be a good idea to either patch wine or add a default udev rule.
before you pointlessly blame Gentoo, why dont you read the udev source the default rule files for pretty much all distros generate only /dev/input/js#
Ehh...guys, it doesn't matter how this bug gets fixed, as long as it gets fixed. Well...that is at leas, my humble opinion.
> before you pointlessly blame Gentoo, why dont you read the udev source The point is: 1) /dev/js* used to exist. Applications used it (eg. Wine). Maintain it for backward compatibility. 2) Other distributions do maintain compatibility. It's just a matter of adding a symlink in one place. Why change many apps when you can make a single change to fix them all? 3) You'll never achieve compatability with older source or binary packages without a symlink. If your patch is accepted into Wine, Gentoo will still be broken for the above reasons.
sure, binary-only apps will remain broken and users will have to use the compat rules in those cases, there's no way around it ... but that's no reason to force the same old behavior forever source packages we can fix easily
Well Spanky, IMHO Mike put good point there, and I agree with him, older/other apps might also use /dev/js0 instead of /dev/input/js0 so I think adding a symlink would be the best solution indeed.
> binary-only apps will remain broken and users will have to use the compat > rules in those cases, there's no way around it Yes, there is a way around it... add a symlink. Why not?
you misread my statement .. i said there's no way around needing compat symlinks for binary-only packages Linux distros could go back to the old /dev style of having thousands of device nodes right in the root of /dev but where's the fun in that
I think this can be considered solved, as the patch was added to wines CVS. More info: http://www.winehq.org/pipermail/wine-cvs/2006-April/thread.html
Well, like I said, it's only "fixed" for Wine. Have fun fixing again and again.
well that's what we enjoy doing, it keeps us busy
> well that's what we enjoy doing, it keeps us busy Well, I hope you're learning something by wasting your time, my time and your users time, because I'm certainly not.
then, as noted on the mailing list, why dont we both stop wasting each others time by posting pointless followups such as this one i'm posting right now