[Bug 39891] New: In Split/Second all Wireless XBox 360 controllers are mapped to the Joystick 3 entry instead of js0->Joystick 0, js1->Joystick 1, etc
https://bugs.winehq.org/show_bug.cgi?id=39891
Bug ID: 39891 Summary: In Split/Second all Wireless XBox 360 controllers are mapped to the Joystick 3 entry instead of js0->Joystick 0, js1->Joystick 1, etc Product: Wine Version: 1.9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: gamingpakker+wine@gmail.com Distribution: ---
With the Wireless XBox 360 receiver xpad reserves 4 controllers and properly assigns each controller to an increasing jsX and eventX. In Split/Second (https://appdb.winehq.org/objectManager.php?sClass=application&iId=11532) the game shows an entry for each one as well with the label Joystick 0 through 3 in the controls menu but the input of each of the wireless controllers ends up mapped to the Joystick 3 entry instead of having the first controller mapped to Joystick 0, the second to Joystick 1, etc.
No DLL overrides etc used. Steam installation of the game is used. This issue was also present in 1.8 and at least in the last few 1.7 versions (53, 54, 55). I don't know if this is a regression or something that was always broken. Using WINE-Staging primarily.
https://bugs.winehq.org/show_bug.cgi?id=39891
Omar gamingpakker+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #1 from Bruno Jesus 00cpxxx@gmail.com --- Please attach a +dinput,+winmm log. See http://wiki.winehq.org/FAQ#get_log (10.1 and 10.2).
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #2 from Omar gamingpakker+wine@gmail.com --- Created attachment 53284 --> https://bugs.winehq.org/attachment.cgi?id=53284 Output of Split/Second with +dinput,+winmm
Output of: WINEDEBUG=+dinput,+winmm wine SplitSecond.exe > /tmp/wine_dinput_winmm_debug.txt 2>&1
2 xbox controllers were physically present during this test (js0/event20 and js1/event21). Controls for either one can only be assigned in the entry for Joystick 3. Used both controllers to assign something before closing the game again.
https://bugs.winehq.org/show_bug.cgi?id=39891
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.dljunk@gmail.com, | |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=39891
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com --- This bug is hard to check due to the hardware requirements. After looking for more information I found this page http://www.rojtberg.net/1049/state-of-the-xpad-xbox-controller-driver/
It looks like a bunch of driver fixes should be in Linux 4.6. Maybe it is worth trying a newer kernel. With some luck the problem may not be in Wine.
Specially because the ghost entries will no longer be present, so if there is only one joystick there should be only one event/js entry connected.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #4 from Omar gamingpakker+wine@gmail.com --- My system is currently running 4.6.4 so I'll give it a go when I get back home later this week.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #5 from Omar gamingpakker+wine@gmail.com --- I've just tested things on 4.6.4 but sadly things are not OK yet.
Linux no longer populates all jsX/eventX entries unless the controllers are physically present but if there are more than 2 controllers present, the game will still map all controllers to the last entry (so with 2 controllers that is the menu entry 'Joystick 1').
But even with only a single controller present, it's not working properly. While you can actually assign buttons and play the game itself when there is only 1 controller physically present, it does not allow you to use the controller in the menus itself. (also on windows the controllers don't need manual mapping and are pre-populated with the proper buttons)
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #6 from Bruno Jesus 00cpxxx@gmail.com --- If you run "wine control" and test inside the control panel applet everything is fine? I mean each controller responds on the correct selected place?
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #7 from Omar gamingpakker+wine@gmail.com --- Yes. Both controllers map to their own entries (one entry for 'event' and for 'js') inside wine control.
I had also tried disabling one set of entries in wine control but that did not change behaviour.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #8 from Omar gamingpakker+wine@gmail.com --- I checked in Windows again and I suddenly realized that on Windows the menu entries for the controllers are actually named differently; Joypad instead of Joystick.
Based on this hereby a short list aggregating the differences in behaviour I see between Windows and Wine.
On Windows: - The controllers get entries labeled Joypad 0..3 - Each controller maps to the proper menu entry - The controller buttons/controls are mapped by default - The controllers function normally in the game menus (e.g. skipping intro logo's, pressing start, navigating, etc)
On WINE: - The controllers get entries labeled Joystick 0..3 - Each controller is mapped to the last Joystick menu entry - The controller buttons/controls require manual mapping/assignment - The controllers can not be used in the game menus
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #9 from Bruno Jesus 00cpxxx@gmail.com --- Looks like you are not alone, Windows users also complain about some problems like joystick not detected, not mapped or not working in menus, one controller mapped to second player instead of first:
https://steamcommunity.com/app/297860/discussions/0/613937943131979340/ http://www.gamefaqs.com/boards/958776-split-second/54852078 http://www.gamefaqs.com/boards/958776-split-second/54899976 http://www.gamefaqs.com/boards/958776-split-second/54876751
Some people say it works fine out of the box, it is difficult to tell what is wrong in this situation.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- I just tested the game with 2 different joysticks and it is completely messed up. It does not recognize half of the controller buttons saying that I'm pressing repeated buttons during the controller config. I'll do further tests when I have more time.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Bruno Jesus from comment #10)
I just tested the game with 2 different joysticks and it is completely messed up. It does not recognize half of the controller buttons saying that I'm pressing repeated buttons during the controller config. I'll do further tests when I have more time.
Ok, my first problem is that my PS2 gamepad to USB converter is malfunctioning, so it can no longer be trusted. My other simpler 8 button USB gamepad works fine in the races, not in the menus. I'm quite surprised to see that the game actually runs in my onboard intel graphics computer, 10fps but works.
https://bugs.winehq.org/show_bug.cgi?id=39891
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #12 from Bruno Jesus 00cpxxx@gmail.com --- Ok, experiments so far:
1 Generic USB Joystick with 8 buttons - Menu does not work, in-game work, needs manual button assignment
1 wired Xbox 360 controller - works out of the box in the menus and game, no assignment needed
Why the Xbox controller works in the menus? No idea, maybe it has to do with the fact that it is automatically recognized and configured so the game is sure what button is each operation
Then I attached the Xbox 360 wireless receiver (disassembled from a red bricked xbox, thanks internet for the tutorials), then I can see the main problem you talk about every control input going to the last controller.
At first I thought it was because every joystick have the same name in Wine, so I changed the code so they got different names, but that didn't help. The game is clearly polling all joysticks all the time, including during the button assignment screen.
I need to learn how to sync a wireless controller to the receiver in Linux so I can test if it works in the menu for me. Did you test with a wired xbox controller?
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #13 from Omar gamingpakker+wine@gmail.com --- I have not tested with a wired 360 controller as I do not have one. I'm asking around right now if I can find someone that has one.
What you describe with the wired 360 controller is the proper behaviour. That is how the game has always functioned for me on Windows with the wireless 360 controller as well. Iirc non-Xbox controllers show the same behaviour as your generic USB Joystick on Windows as well. I'll double check with a generic joystick as well, I should still have one laying around somewhere.
This does sound like there may be a discrepancy between how the wired vs wireless xbox controllers are eventually handled within WINE?
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #14 from Omar gamingpakker+wine@gmail.com --- Found the Joystick and aside from it being shitty as hell, it did not work in the menus and required manual assignment.
Also, it may be that if there really is a discrepancy for the wireless controllers that that may be why some other games do not seem to work with it either. I just tested with RWBY Grimm Eclipse as well: - On Windows the 360 controller works fine and can be used, other controllers do not work at all (unless the register as 360 controllers afaik (e.g. PS4 controller using InputMapper)). - On WINE the wireless controller doesn't work at all Based on that it's almost as if the wireless controller is not being detected/handled as an actual Xbox 360 controller in WINE.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com --- Are you using the (js) or (event) joystick? I'm using the event one, please go to control panel and disable the (js) and give a new try with the wired controller if possible.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #16 from Omar gamingpakker+wine@gmail.com --- As I mentioned previously I had already tried to disable the 'js' entries as well as the 'event' entries in WINE. There was no change.
I asked around but sadly the people I asked that had 360 controllers all had the wireless version.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #17 from Bruno Jesus 00cpxxx@gmail.com --- One more possible difference, I'm using the xpad driver. There is also other driver called xboxdrv. Which one are you using?
# lsmod | grep -i xpad xpad 16970 0 ff_memless 12675 1 xpad usbcore 154038 8 xpad,uvcvideo,ums_realtek,usb_storage,hid_sony,ehci_hcd,ehci_pci,usbhid
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #18 from Omar gamingpakker+wine@gmail.com --- xpad
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #19 from Omar gamingpakker+wine@gmail.com --- Since you mentioned xboxdrv, I've been experimenting with the xboxdrv driver today. I was able to get some different behaviour by using this driver. Below are the results of that. I've also tested this driver with the 'js' version of the controller disabled in WINE, there was no change in behaviour.
1) Running xboxdrv without any arguments made the controller show up as 'Joypad' in Split/Second instead of 'Joystick', however it doesn't work in the menus and still needs manual assignment. Several buttons don't work/register at all in the game (triggers, shoulder buttons, etc).
2) Running xboxdrv with the --mimic-xpad argument makes Split/Second work with the controller; it works in the menus, no manual assignment is required and it is listed as a 'Joypad' instead of 'Joystick'. (NOTE: if you edit the right trigger assignment, it will not match the label that was originally assigned; the automatic assignment is 'Axis Z Neg' but if you manually assign it, it becomes 'Right Axis Z Pos'. I did not notice any driving behaviour changes in-game)
3) Regardless of whether I disable the 'next-controller' flag in /etc/default/xboxdrv or not, it creates 2 controller entries in-game. The single physical controller maps to the second entry. (does xboxdrv map the receiver??? I have no clue where the first entry is coming from.)
I get the impression that: - xpad does not present the wireless xbox360 controllers in a way that makes WINE handle it like an xbox360 controller. - xboxdrv can be forced to make the wireless xbox360 controller be presented to the system as a wired one by using --mimic-xpad and as a result seems to work for Split/Second singleplayer, which doesn't care about the controller index. - xboxdrv breaks games that rely on index 0 being used for the controller or games that allow local multiplayer.
I'm still not sure whether the problem is with the drivers not handling the controllers properly or that WINE isn't properly handling how the wireless controllers are presented by the drivers.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #20 from Bruno Jesus 00cpxxx@gmail.com --- In all my attempts the game always label everything as Joypads, which is very weird because wine always reports the controllers as joysticks (fixed in the source code). It is interesting that it worked with xboxdrv. So far I have found 2 problems:
- The game cannot cope with joysticks with the same name, which is the case in Wine if you attach 2 identical controllers. The game will not start a second device with the same name.
- The game cannot cope with more than 4 controllers, it will quit enumerating and result in the "all controllers mapped to joystick 3" issue. Still unsure if this is a wine or game bug.
As far as I remember Windows always add a number at the end of joystick name to differentiate identical controllers, but I'm not sure.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #21 from Omar gamingpakker+wine@gmail.com --- I've checked in Windows (dxdiag) and it seems that it does not assign unique names. Both controllers show up as 'Controller (Xbox 360 Wireless Receiver for Windows)', however, it does assign a unique controller ID (in my case 0 and 1 respectively).
For me I think the mapping to the last entry was because the controllers were all duplicates; I've not used more than 4 controllers (I have only 2 physically available to me and the receiver doesn't handle more)
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #22 from Omar gamingpakker+wine@gmail.com --- Created attachment 55353 --> https://bugs.winehq.org/attachment.cgi?id=55353 Windows DxDiag DirectInput section
Hereby what DxDiag registers in the DirectInput section on Windows.
The hardware location for the controllers on Windows are: - XBOX_360_DEVICE_00:00 - XBOX_360_DEVICE_00:02 Where XBOX_360_DEVICE_00 is the Wireless Receiver with hardware location Port_#0002.Hub_#0002.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #23 from Omar gamingpakker+wine@gmail.com --- Created attachment 55356 --> https://bugs.winehq.org/attachment.cgi?id=55356 WINE DxDiag DirectInput section
I just checked with DxDiag in WINE as well and it looks like naming should be fine (name is the same for each, just like on Windows, increasing Controller ID just like on Windows as well).
What I do notice is that the controllers have the Product ID of the receiver instead of the Product ID of the controller. (0x0719 instead of 0x02A1)
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #24 from Omar gamingpakker+wine@gmail.com --- I think that may actually be it.. If you run xboxdrv with --mimic-xpad it sets the Product ID to 0x028E which is the ID for the wired controller.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #25 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Omar from comment #24)
I think that may actually be it.. If you run xboxdrv with --mimic-xpad it sets the Product ID to 0x028E which is the ID for the wired controller.
The game could have a hard-code check for the wired controller pid so it auto-configures it.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #26 from Omar gamingpakker+wine@gmail.com --- If that is the case it must also have check on 0x02A1 in addition to 0x028E, otherwise it wouldn't work with the wireless controller on Windows either.
I think that the main problem here is that the wireless xbox controllers are presented to the system using the ID of the receiver and not with the ID of the controller itself. In which case this is probably a bug in the driver as afaik WINE takes the ID information it receives from the evdev API.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #27 from Omar gamingpakker+wine@gmail.com --- Ok this is what I've found about the hierarchy of the wireless receiver/controller between Windows and Linux.
Windows: TL/DR; Both the receiver and controllers are unique devices. - Receiver -- Separate device, attached to a USB port, hub-style device ('Xbox 360 peripheral') -- Product ID 0x0719 - Controllers (x4) -- Separate device, attached to the receiver, game controller -- Product ID 0x02A1
Linux: TL/DR; The receiver and controllers are the same device (receiver = 4 controllers). - Receiver -- Attached to a USB port, seen as 4 game controllers. -- Product ID 0x0719. - Controller (4x) -- Not handled as a separate device. -- Should have Product ID = 0x02A1. -- In the system tree the controllers are located underneath the receiver: /sys/bus/usb/devices/[receiver usb]/[receiver-usb]:[controller]
I'm fairly certain that we can now classify this as a driver issue. I probably need to report this bug with the xpad kernel driver. If after that there are still issues with the wireless controller in WINE we'll just have to look at that when it happens.
For the record, is there a way to spoof the product ID (either in Linux or WINE) so I could test this?
https://bugs.winehq.org/show_bug.cgi?id=39891
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #28 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 55359 --> https://bugs.winehq.org/attachment.cgi?id=55359 Fake PID/VID patch
(In reply to Omar from comment #27)
For the record, is there a way to spoof the product ID (either in Linux or WINE) so I could test this?
If you able to compile Wine than it is easy. Take a look at the attached patch for the (event) joystick.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #29 from Omar gamingpakker+wine@gmail.com --- Ok I've compiled wine-staging 1.9.16 with the product ID for the wireless controller (0x02a1). As a result the controller is handled properly by Split/Second.
Other things I noticed to keep in mind: 1) The presence of the 'js' entry causes a generic joystick to be added as well with no mappings defined. 2) If the 'js' entry of the controller isn't disabled in WINE it will process that entry instead of the 'event' entry of the same controller ('js' seems to take precedence over 'event').
I don't know if nr. 2 is something caused by the game does or by WINE. However, since it is easily solved by just disabling the 'js' entry in wine control, I'm not sure it warrants spending time on to figure that out.
To summarize the cause of this issue: 1) Linux driver exposes the wrong Product ID for the wireless 360 controllers. 2) WINE just takes over the ID presented by the driver. 3) Game gets an ID it doesn't know thus does not allow controller use in menus and does not auto-assign it for you.
Possible fixes I see available to solve this: 1) Get the Linux drivers to set the correct Product ID. 2) As long as 1 is not done, patch WINE to replace the Product ID of Microsoft joysticks that have ID=0x0719 with ID=0x02a1.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Omar from comment #29)
Other things I noticed to keep in mind:
- The presence of the 'js' entry causes a generic joystick to be added as
well with no mappings defined.
That is a bug in Wine, I have sent a patch: http://source.winehq.org/patches/data/125574
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #31 from Omar gamingpakker+wine@gmail.com --- Recompiled again including that patch to try it out. With the patch it now exposes vendor id and product id for the 'js' entry. As such I expanded the spoofing so it applies to the 'js' code as well (joystick_linux.c). With the spoofing both the 'js' and 'event' entries are now working properly.
This still leaves issue 2:
If the 'js' entry of the controller isn't disabled in WINE it will process that entry instead of the 'event' entry of the same controller ('js' seems to take precedence over 'event').
But as I said before, that can easily be solved by just disabling the 'js' entry in wine control.
I don't know anything at all about joystick handling in WINE but I do feel like with the VIDPID patch it may be possible to just disable 'js' entries by default? If the 'js' entry matches the name, vid, pid and controller ID of an 'event' entry it could be disabled by default, right?
https://bugs.winehq.org/show_bug.cgi?id=39891
Omar Pakker gamingpakker+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #32 from Omar Pakker gamingpakker+wine@gmail.com --- I thought I'd update this with links to the upstream reports.
First report was on kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=153131 No reply for 3 months.
Decided to make another report on the Xpad GitHub. https://github.com/paroj/xpad/issues/54 This was picked up really fast (as in, within 24 hours or so!). There is currently a branch available (x360w_id) that sets the PID for the wireless controllers to 0x02A1.
I'm also setting this bug to resolved/notourbug now since the issue is not a problem within WINE and has been picked up with the driver devs.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #33 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Omar Pakker from comment #32)
... I'm also setting this bug to resolved/notourbug now since the issue is not a problem within WINE and has been picked up with the driver devs.
I'm not against that but the newer kernel with the correct user driver is enough to solve the original issue about joysticks being mapped to the same slot?
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #34 from Omar Pakker gamingpakker+wine@gmail.com --- (In reply to Bruno Jesus from comment #33)
(In reply to Omar Pakker from comment #32)
... I'm also setting this bug to resolved/notourbug now since the issue is not a problem within WINE and has been picked up with the driver devs.
I'm not against that but the newer kernel with the correct user driver is enough to solve the original issue about joysticks being mapped to the same slot?
That was an earlier problem with the driver that got fixed. See: https://bugs.winehq.org/show_bug.cgi?id=39891#c5
The title of this bug is maybe not entirely accurate anymore. Maybe it should've originally been split into a new one from that point onward into a new one titled something along the lines of 'Wireless 360 Controller is not usable in the menu and not automatically mapped'.
https://bugs.winehq.org/show_bug.cgi?id=39891
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|In Split/Second all |In Split/Second wireless |Wireless XBox 360 |Xbox 360 controller is not |controllers are mapped to |usable in the menu and not |the Joystick 3 entry |automatically mapped |instead of js0->Joystick 0, |(driver reports wrong PID) |js1->Joystick 1, etc |
https://bugs.winehq.org/show_bug.cgi?id=39891
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #35 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=39891
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #36 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
https://bugs.winehq.org/show_bug.cgi?id=39891
--- Comment #37 from Omar Pakker wine@opakker.nl --- I didn't realize there was really a difference between 'RESOLVED' and 'CLOSED' tbh haha. The best I can guess is it'd normally stay on RESOLVED until someone else verifies it then CLOSED? Though that leaves a bit of a weird situation for 'NOTOURBUG' cases imo.
Anyway, if CLOSED (+ NOTOURBUG) is for when it's fixed upstream, I think your change to CLOSED was actually good. As far as I'm aware it has been included in the upstream/kernel xpad driver for a while now. Commit b6fc513.
With a quick search, said commit should have been included since the following releases: - 4.10 (the stable branch at the time) - 4.9.5 (longterm branch) - 4.4.44 (longterm branch)
https://bugs.winehq.org/show_bug.cgi?id=39891
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Status|RESOLVED |CLOSED
--- Comment #38 from Zebediah Figura z.figura12@gmail.com --- (In reply to Omar Pakker from comment #37)
I didn't realize there was really a difference between 'RESOLVED' and 'CLOSED' tbh haha. The best I can guess is it'd normally stay on RESOLVED until someone else verifies it then CLOSED? Though that leaves a bit of a weird situation for 'NOTOURBUG' cases imo.
Essentially, RESOLVED NOTOURBUG signifies that the bug exists upstream, but hasn't been fixed yet. CLOSED NOTOURBUG signifies that the bug has been fixed upstream and that that fix has been released. In a somewhat similar manner, RESOLVED FIXED means that the bug has been fixed in Wine but that the fix hasn't been released yet; such bugs are closed when a release is made. Other status (INVALID, ABANDONED, DUPLICATE) can be closed at any point; there's no distinction made there.
Anyway, if CLOSED (+ NOTOURBUG) is for when it's fixed upstream, I think your change to CLOSED was actually good. As far as I'm aware it has been included in the upstream/kernel xpad driver for a while now. Commit b6fc513.
Closing for real, then.
-
wine-bugs＠winehq.org