medusalix / xow Goto Github PK

View Code? Open in Web Editor NEW

1.4K 1.4K 97.0 1.16 MB

Linux driver for the Xbox One wireless dongle

Home Page: https://medusalix.github.io/xow

License: GNU General Public License v2.0

Makefile 1.30% C++ 97.05% Shell 1.66%

dongle linux usb user-mode wireless xbox xbox-one

xow's People

Contributors

Stargazers

Watchers

Forkers

jbwyatt4archive iamsingularity forksbot ezhangle liyucode nschimme fr34k8 tauakiou nightfeather dummyx p0kr totalcaesar659 dereckhall alexanderjarendt kakra 3wille ncnynl avatar4ik3 sarthak96 kapsh rubencarneiro nmmsantos atcq 5l1v3r1 mfkiwl leossok simma101 sofakng drtexx juliolimareis transcengopher orbekk ramongallud nullobsi anonymous0011 stianeklund rehar tinyretrowarehouse sl903dj hazarth arthurus zhaouvorg aleasto j-dawe fauli1221 cwashington91 evelikov terrorizer1980 jan200101 wavemaker-labs mathewdeyo prakhar64 sevenautumns pugavkomm nyvanga nick-prat originlegend stingwork fhavrlent zakk4223 lnrsoft neonoxd kh0nsu kowalski2019 eriobis webodan drowfx agentmith blakenator guero777 mspaulding06 jarednthomas eivindbergem babyaries murvudd frankfanslc flieswithwind cocorobotics alexanderwb versaloon gmh5225 florke64-forks richama2 gg-big-org senonide weizx208 delabrcd konstantindjairo debexxe jardon lunacodedemon leonfg teoguoen kgpgit

xow's Issues

Simple logo and web page for the project

Hello,

First of all, thank you very much for the impressive work! Working as a charm for me on Fedora 31 : )

I want to propose a simple logo and web page for the project.

For the logo I thought about referencing both the physical dongle shape and imagery and also the command to run xow on ther terminal.

For the web page I thought about just going simple and effective.

The font is Roboto Mono and is under an Apache 2.0 license.

Here are some ideas:

Xbox Elite Controller 2

Looks like it does not work.

If I run # xow I get the following output:

2020-02-03 01:41:18 INFO  - Dongle plugged in
2020-02-03 01:41:18 INFO  - Chip address: 6c:5d:3a:00:2c:75
2020-02-03 01:41:18 INFO  - Dongle initialized
2020-02-03 01:41:22 INFO  - Pairing initiated
2020-02-03 01:41:22 INFO  - Pairing initiated
2020-02-03 01:41:23 INFO  - Pairing initiated
2020-02-03 01:41:23 INFO  - Pairing initiated

The light blinks, but when I attempt to pair the controller, nothing happens.

OS: Manjaro 5.4.16-1

Support for different version of the dongle

I am currently on Arch Linux and i tried both xow packages from the AUR and also directly compiled and installed from github.
Pairing works in a VM and in Windows directly but never saw a successful connection on Arch (Even tried another adapter + controller combo).

Slim Adapter + 1708.
How can i debug this problem?

2020-02-15 19:06:45 INFO - xow v0.3-15-g8ee82a4 ©Severin v. W.
2020-02-15 19:06:46 INFO - Dongle plugged in
2020-02-15 19:06:46 DEBUG - Firmware already loaded
2020-02-15 19:06:46 DEBUG - Chip version: 7632
2020-02-15 19:06:46 INFO - Chip address: 6c:5d:3a:00:d1:ca
2020-02-15 19:06:46 INFO - Dongle initialized
2020-02-15 19:06:50 INFO - Pairing initiated
2020-02-15 19:06:50 INFO - Pairing initiated

Startup issues with the old dongle

Did more testing now, as promised. I am not quite sure what the reason is, but sometimes it happens that xow fails on startup (exit status=255), but if I re-start it later then it works:

desktop@steamos:~$ sudo systemctl status xow -l
● xow.service - Xbox One Wireless Dongle Driver
   Loaded: loaded (/etc/systemd/user/xow.service; enabled)
   Active: failed (Result: exit-code) since Mi 2019-12-25 20:57:42 CET; 36s ago
  Process: 646 ExecStart=/usr/local/bin/xow (code=exited, status=255)
 Main PID: 646 (code=exited, status=255)

Dez 25 20:57:42 steamos systemd[1]: Starting Xbox One Wireless Dongle Driver...
Dez 25 20:57:42 steamos systemd[1]: Started Xbox One Wireless Dongle Driver.
Dez 25 20:57:42 steamos xow[646]: INFO  - xow  ©Severin v. W.
Dez 25 20:57:42 steamos xow[646]: ERROR - Error opening device: LIBUSB_ERROR_NO_DEVICE
Dez 25 20:57:42 steamos systemd[1]: xow.service: main process exited, code=exited, status=255/n/a
Dez 25 20:57:42 steamos systemd[1]: Unit xow.service entered failed state.

desktop@steamos:~$ sudo systemctl stop xow 
desktop@steamos:~$ sudo systemctl start xow 
desktop@steamos:~$ sudo systemctl status xow -l
● xow.service - Xbox One Wireless Dongle Driver
   Loaded: loaded (/etc/systemd/user/xow.service; enabled)
   Active: active (running) since Mi 2019-12-25 20:58:22 CET; 2s ago
 Main PID: 1693 (xow)
   CGroup: /system.slice/xow.service
           └─1693 /usr/local/bin/xow

Dez 25 20:58:22 steamos systemd[1]: Started Xbox One Wireless Dongle Driver.
Dez 25 20:58:22 steamos xow[1693]: INFO  - xow  ©Severin v. W.
Dez 25 20:58:22 steamos xow[1693]: INFO  - Dongle plugged in
Dez 25 20:58:22 steamos xow[1693]: INFO  - Chip address: 62:45:b4:fa:b0:d2
Dez 25 20:58:22 steamos xow[1693]: INFO  - Dongle initialized

So far this only happened with the old bulky dongle (and not always), but until now never with the new small one.

Model 1537 not connecting

I'm using Ubuntu LTS 18.04 and Xbox one controller 1537 and compiled xov from github. The controller was paired on a Windows 10 machine successfully to the same dongle.
When I try to connect my controller in Linux it doesn't work. The controller is associated multiple times with a new ID.

Is there a way to debug this or is there a simple fix?

2020-03-21 16:35:00 INFO - xow v0.4 ©Severin v. W.
2020-03-21 16:35:00 DEBUG - Opening device...
2020-03-21 16:35:00 INFO - Dongle plugged in
2020-03-21 16:35:00 DEBUG - Firmware already loaded, resetting...
2020-03-21 16:35:00 DEBUG - Firmware loaded
2020-03-21 16:35:00 DEBUG - ASIC version: 7632
2020-03-21 16:35:00 DEBUG - Chip id: 7613
2020-03-21 16:35:00 INFO - Wireless address: 6c:5d:3a:01:dc:dd
2020-03-21 16:35:00 INFO - Dongle initialized
2020-03-21 16:35:10 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:10 INFO - Controller '1' connected
2020-03-21 16:35:15 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:15 INFO - Controller '2' connected
2020-03-21 16:35:20 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:20 INFO - Controller '3' connected
2020-03-21 16:35:25 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:25 INFO - Controller '4' connected
2020-03-21 16:35:30 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:30 INFO - Controller '5' connected
2020-03-21 16:35:34 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:34 INFO - Controller '6' connected
2020-03-21 16:35:39 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:39 INFO - Controller '7' connected
2020-03-21 16:35:44 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:44 INFO - Controller '8' connected
2020-03-21 16:35:49 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:49 INFO - Controller '9' connected
2020-03-21 16:35:54 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:54 INFO - Controller '10' connected
2020-03-21 16:35:59 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:35:59 INFO - Controller '11' connected
2020-03-21 16:36:04 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:04 INFO - Controller '12' connected
2020-03-21 16:36:09 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:09 INFO - Controller '13' connected
2020-03-21 16:36:14 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:14 INFO - Controller '14' connected
2020-03-21 16:36:19 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:19 INFO - Controller '15' connected
2020-03-21 16:36:23 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:23 INFO - Controller '16' connected
2020-03-21 16:36:28 DEBUG - Client associating: 7e:ed:85:de:de:c0
2020-03-21 16:36:28 ERROR - All WCIDs are taken
2020-03-21 16:36:28 ERROR - Failed to associate client

Controller keeps disconnecting and then reconnecting

I'm having an issue where at seemly random points, the Xbox symbol will flash for a few seconds (indicating that the controller is disconnected) and then go solid again (indicating that it has reconnected. At first, I thought the batteries were dying, but I switched them out and checked their charge, so that wasn't the issue. I've only had this happen in the Witcher 3, but that's the only game I've tested it on. Another thing that might be important, when I'm holding down the left stick to run, it keeps running while it's disconnected, and then I have control again when it reconnects.

Controllers losing connection for a couple of seconds

Operating system: Raspbian Buster
Kernel version: 4.19.75
Controller model: 1708
Dongle variant: slim
xow version: v0.3-10-gf06f669

With my last update of the driver (latest commit: f06f669) all 4 of my controllers started randomly losing connection for a couple of seconds at a time.
After checking out the previous commit (4edcee5) and reinstalling xow the issue is no longer present and controllers maintain a stable connection.

I've attached xow debug logs from two sessions: one before downgrading (xow-v0.3-10-gf06f669.log) the driver and one after doing so (xow-v0.3-9-g4edcee5.log).

Let me know if there's anything I can do on my side to help with debugging this problem. Also, thank you for all the great work on this project!

xow-v0.3-9-g4edcee5.log
xow-v0.3-10-gf06f669.log

Segmentation fault when exiting xow (ctrl+c)

I noticed every time I close xow with CTRL+C (when running from cli) there is a segfault:

ddragic:pts/1:xow $ ./xow 
2020-04-11 14:03:28 INFO  - xow v0.4-9-g7675112 ©Severin v. W.
2020-04-11 14:03:30 DEBUG - Opening device...
2020-04-11 14:03:30 INFO  - Dongle plugged in
2020-04-11 14:03:30 DEBUG - Firmware loaded
2020-04-11 14:03:31 DEBUG - ASIC version: 7632
2020-04-11 14:03:31 DEBUG - MAC version: 7662
2020-04-11 14:03:31 DEBUG - Chip id: 7613
2020-04-11 14:03:31 INFO  - Wireless address: 62:45:b5:01:9a:09
2020-04-11 14:03:31 INFO  - Dongle initialized
2020-04-11 14:03:34 DEBUG - Client associating: 7e:ed:8c:1c:8f:74
2020-04-11 14:03:34 INFO  - Controller '1' connected
2020-04-11 14:03:34 INFO  - Product ID: 02ea
2020-04-11 14:03:34 DEBUG - Firmware version: 3.1.1221.0
2020-04-11 14:03:34 DEBUG - Hardware version: 1284.1.1.1
2020-04-11 14:03:35 INFO  - Serial number: 03600079292806
2020-04-11 14:03:38 DEBUG - Battery type: 1, level: 2
2020-04-11 14:03:58 DEBUG - Battery type: 1, level: 2
^C2020-04-11 14:03:59 DEBUG - Stop signal received
2020-04-11 14:03:59 DEBUG - Closing device...
2020-04-11 14:03:59 INFO  - Dongle power-off
xow: io.c:2116: handle_events: Assertion `ctx->pollfds_cnt >= internal_nfds' failed.
Segmentation fault (core dumped)

Sometimes the last line is Aborted (core dumped) instead of Segmentation fault.
Everything seems to power down correctly, the controller turns off and so does the adapter (light goes out), but it always segfaults.

This is on Fedora 31 x64 with libusbx-1.0.22-4.fc31.

gdb backtrace:

#0  discard_urbs (itransfer=itransfer@entry=0x7f9194002fb0, first=first@entry=0, last_plus_one=1) at os/linux_usbfs.c:1830
#1  0x00007f91a1a8b7ed in op_cancel_transfer (itransfer=0x7f9194002fb0) at os/linux_usbfs.c:2256
#2  0x00007f91a1a890d9 in libusb_cancel_transfer (transfer=<optimized out>) at io.c:1572
#3  0x00007f91a1a8b03d in sync_transfer_wait_for_completion (transfer=transfer@entry=0x7f9194003020) at sync.c:57
#4  0x00007f91a1a8b10b in do_sync_bulk_transfer (dev_handle=0x7f919c000de0, endpoint=<optimized out>, buffer=buffer@entry=0x7f919bffeca0 "\006", length=length@entry=512, 
    transferred=transferred@entry=0x7f919bffec5c, timeout=timeout@entry=0, type=2 '\002') at sync.c:191
#5  0x00007f91a1a8b423 in libusb_bulk_transfer (dev_handle=<optimized out>, endpoint=<optimized out>, data=data@entry=0x7f919bffeca0 "\006", length=length@entry=512, 
    transferred=transferred@entry=0x7f919bffec5c, timeout=timeout@entry=0) at sync.c:273
#6  0x0000000000410059 in UsbDevice::bulkRead (this=this@entry=0x7ffe9fe69980, endpoint=endpoint@entry=5 '\005', buffer=...) at /usr/include/c++/9/array:234
#7  0x000000000040c76d in Mt76::readBulkPackets (this=0x7ffe9fe69980, endpoint=5 '\005') at dongle/mt76.cpp:950
#8  0x000000000040c806 in std::__invoke_impl<void, void (Mt76::*)(unsigned char), Mt76*, int> (__t=<optimized out>, __f=<optimized out>)
    at /usr/include/c++/9/bits/invoke.h:89
#9  std::__invoke<void (Mt76::*)(unsigned char), Mt76*, int> (__fn=<optimized out>) at /usr/include/c++/9/bits/invoke.h:95
#10 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::_M_invoke<0ul, 1ul, 2ul> (this=<optimized out>) at /usr/include/c++/9/thread:244
#11 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::operator() (this=<optimized out>) at /usr/include/c++/9/thread:251
#12 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> > >::_M_run (this=<optimized out>)
    at /usr/include/c++/9/thread:195
#13 0x00007f91a1cb83d4 in execute_native_thread_routine () from /lib64/libstdc++.so.6
#14 0x00007f91a1a664e2 in start_thread () from /lib64/libpthread.so.0
#15 0x00007f91a197b6a3 in clone () from /lib64/libc.so.6

gdb backtrace full:

#0  discard_urbs (itransfer=itransfer@entry=0x7f9194002fb0, first=first@entry=0, last_plus_one=1) at os/linux_usbfs.c:1830
        transfer = 0x7f9194003020
        tpriv = 0x7f9194003060
        dpriv = 0x50
        i = 0
        ret = 0
        urb = 0x7f9194002770
        __FUNCTION__ = "discard_urbs"
#1  0x00007f91a1a8b7ed in op_cancel_transfer (itransfer=0x7f9194002fb0) at os/linux_usbfs.c:2256
        tpriv = 0x7f9194003060
        transfer = 0x7f9194003020
        r = <optimized out>
#2  0x00007f91a1a890d9 in libusb_cancel_transfer (transfer=<optimized out>) at io.c:1572
        itransfer = <optimized out>
        r = <optimized out>
        __FUNCTION__ = "libusb_cancel_transfer"
#3  0x00007f91a1a8b03d in sync_transfer_wait_for_completion (transfer=transfer@entry=0x7f9194003020) at sync.c:57
        r = <optimized out>
        completed = 0x7f919bffeb84
        ctx = 0x22413a0
        __FUNCTION__ = "sync_transfer_wait_for_completion"
#4  0x00007f91a1a8b10b in do_sync_bulk_transfer (dev_handle=0x7f919c000de0, endpoint=<optimized out>, buffer=buffer@entry=0x7f919bffeca0 "\006", length=length@entry=512, 
    transferred=transferred@entry=0x7f919bffec5c, timeout=timeout@entry=0, type=2 '\002') at sync.c:191
        transfer = 0x7f9194003020
        completed = 0
        r = 0
        __FUNCTION__ = "do_sync_bulk_transfer"
#5  0x00007f91a1a8b423 in libusb_bulk_transfer (dev_handle=<optimized out>, endpoint=<optimized out>, data=data@entry=0x7f919bffeca0 "\006", length=length@entry=512, 
    transferred=transferred@entry=0x7f919bffec5c, timeout=timeout@entry=0) at sync.c:273
No locals.
#6  0x0000000000410059 in UsbDevice::bulkRead (this=this@entry=0x7ffe9fe69980, endpoint=endpoint@entry=5 '\005', buffer=...) at /usr/include/c++/9/array:234
        transferred = 0
        error = <optimized out>
#7  0x000000000040c76d in Mt76::readBulkPackets (this=0x7ffe9fe69980, endpoint=5 '\005') at dongle/mt76.cpp:950
        packet = {data = std::vector of length 528, capacity 528 = {176 '\260', 20 '\024', 0 '\000', 148 '\224', 145 '\221', 127 '\177', 0 '\000', 0 '\000', 208 '\320', 
            8 '\b', 0 '\000', 148 '\224', 145 '\221', 127 '\177', 0 '\000', 0 '\000', 201 '\311', 200 '\310', 170 '\252', 2 '\002', 64 '@', 166 '\246', 164 '\244', 
            165 '\245', 0 '\000', 100 'd', 201 '\311', 200 '\310', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 136 '\210', 17 '\021', 
            160 '\240', 0 '\000', 98 'b', 69 'E', 181 '\265', 1 '\001', 154 '\232', 9 '\t', 126 '~', 237 '\355', 140 '\214', 28 '\034', 143 '\217', 116 't', 98 'b', 
            69 'E', 181 '\265', 1 '\001', 154 '\232', 9 '\t', 32 ' ', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 3 '\003', 32 ' ', 1 '\001', 4 '\004', 134 '\206', 
            1 '\001', 0 '\000', 0 '\000', 68 'D', 0 '\000', 192 '\300', 74 'J', 55 '7', 57 '9', 50 '2', 57 '9', 50 '2', 56 '8', 48 '0', 54 '6', 80 'P', 0 '\000', 
            192 '\300', 74 'J', 4 '\004', 5 '\005', 1 '\001', 0 '\000', 1 '\001', 0 '\000', 1 '\001', 0 '\000', 92 '\\', 0 '\000', 192 '\300', 74 'J', 13 '\r', 103 'g', 
            1 '\001', 153 '\231', 231 '\347', 0 '\000', 0 '\000', 0 '\000', 4 '\004', 0 '\000', 0 '\000', 0 '\000', 37 '%', 99 'c', 1 '\001', 157 '\235', 231 '\347', 
            0 '\000', 0 '\000', 0 '\000', 4 '\004', 0 '\000', 0 '\000', 0 '\000', 37 '%', 99 'c', 1 '\001', 161 '\241', 240 '\360', 0 '\000', 0 '\000', 0 '\000', 40 '(', 
            2 '\002', 0 '\000', 0 '\000', 132 '\204', 128 '\200', 160 '\240', 74 'J', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000'...}}
--Type <RET> for more, q to quit, c to continue without paging--
        buffer = {data = {
            _M_elems = "\006\000`J\003\000\002\000\001H\000\000\006\000`J\311Ȫ\002@\246\244\245\000d\311\310\000\000\000\000\000\000\000\000\210\021\240\000bE\265\001\232\t~\355\214\034\217tbE\265\001\232\t \000\000\000\000\000\003 \001\004\206\001\000\000D\000\300J79292806P\000\300J\004\005\001\000\001\000\001\000\\\000\300J\rg\001\231\347\000\000\000\004\000\000\000%c\001\235\347\000\000\000\004\000\000\000%c\001\241\360\000\000\000(\002\000\000\204\200\240J", '\000' <repeats 371 times>}}
        transferred = <optimized out>
#8  0x000000000040c806 in std::__invoke_impl<void, void (Mt76::*)(unsigned char), Mt76*, int> (__t=<optimized out>, __f=<optimized out>)
    at /usr/include/c++/9/bits/invoke.h:89
No locals.
#9  std::__invoke<void (Mt76::*)(unsigned char), Mt76*, int> (__fn=<optimized out>) at /usr/include/c++/9/bits/invoke.h:95
No locals.
#10 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::_M_invoke<0ul, 1ul, 2ul> (this=<optimized out>) at /usr/include/c++/9/thread:244
No locals.
#11 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::operator() (this=<optimized out>) at /usr/include/c++/9/thread:251
No locals.
#12 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> > >::_M_run (this=<optimized out>)
    at /usr/include/c++/9/thread:195
No locals.
#13 0x00007f91a1cb83d4 in execute_native_thread_routine () from /lib64/libstdc++.so.6
No symbol table info available.
#14 0x00007f91a1a664e2 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#15 0x00007f91a197b6a3 in clone () from /lib64/libc.so.6
No symbol table info available.

gdb backtrace full for Aborted case:

#0  0x00007f301f0d2625 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007f301f0bb8d9 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007f301f0bb7a9 in __assert_fail_base.cold () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007f301f0caa66 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007f301f2a5a70 in handle_events (ctx=ctx@entry=0x23c73a0, tv=<optimized out>, tv=<optimized out>) at io.c:2116
        r = <optimized out>
        ipollfd = <optimized out>
        nfds = 0
        internal_nfds = 2
        fds = 0x0
        i = -1
        timeout_ms = <optimized out>
        __FUNCTION__ = "handle_events"
        __PRETTY_FUNCTION__ = "handle_events"
#5  0x00007f301f2a662c in libusb_handle_events_timeout_completed (ctx=ctx@entry=0x23c73a0, tv=tv@entry=0x7f301d05db10, completed=completed@entry=0x7f301d05db84)
    at io.c:2348
        r = <optimized out>
        poll_timeout = {tv_sec = 60, tv_usec = 0}
        __FUNCTION__ = "libusb_handle_events_timeout_completed"
#6  0x00007f301f2a66d4 in libusb_handle_events_completed (ctx=ctx@entry=0x23c73a0, completed=completed@entry=0x7f301d05db84) at io.c:2447
        tv = {tv_sec = 60, tv_usec = 0}
#7  0x00007f301f2a7009 in sync_transfer_wait_for_completion (transfer=transfer@entry=0x7f3014002220) at sync.c:51
        r = <optimized out>
        completed = 0x7f301d05db84
        ctx = 0x23c73a0
        __FUNCTION__ = "sync_transfer_wait_for_completion"
#8  0x00007f301f2a710b in do_sync_bulk_transfer (dev_handle=0x7f3018000de0, endpoint=<optimized out>, buffer=buffer@entry=0x7f301d05dca0 "d", length=length@entry=512, 
    transferred=transferred@entry=0x7f301d05dc5c, timeout=timeout@entry=0, type=2 '\002') at sync.c:191
        transfer = 0x7f3014002220
        completed = 0
        r = 0
        __FUNCTION__ = "do_sync_bulk_transfer"
#9  0x00007f301f2a7423 in libusb_bulk_transfer (dev_handle=<optimized out>, endpoint=<optimized out>, data=data@entry=0x7f301d05dca0 "d", length=length@entry=512, 
    transferred=transferred@entry=0x7f301d05dc5c, timeout=timeout@entry=0) at sync.c:273
No locals.
#10 0x0000000000410059 in UsbDevice::bulkRead (this=this@entry=0x7ffeb051d0b0, endpoint=endpoint@entry=4 '\004', buffer=...) at /usr/include/c++/9/array:234
        transferred = 0
        error = <optimized out>
#11 0x000000000040c76d in Mt76::readBulkPackets (this=0x7ffeb051d0b0, endpoint=4 '\004') at dongle/mt76.cpp:950
        packet = {data = std::vector of length 620, capacity 620 = {0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 208 '\320', 8 '\b', 
            0 '\000', 20 '\024', 48 '0', 127 '\177', 0 '\000', 0 '\000', 193 '\301', 199 '\307', 163 '\243', 2 '\002', 64 '@', 173 '\255', 149 '\225', 149 '\225', 
            0 '\000', 82 'R', 193 '\301', 199 '\307', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 136 '\210', 17 '\021', 60 '<', 
            0 '\000', 98 'b', 69 'E', 181 '\265', 1 '\001', 154 '\232', 9 '\t', 126 '~', 237 '\355', 140 '\214', 28 '\034', 143 '\217', 116 't', 96 '`', 69 'E', 
            181 '\265', 1 '\001', 154 '\232', 9 '\t', 16 '\020', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 3 '\003', 32 ' ', 1 '\001', 35 '#', 134 '\206', 
--Type <RET> for more, q to quit, c to continue without paging--
            3 '\003', 0 '\000', 0 '\000', 2 '\002', 3 '\003', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 1 '\001', 
            0 '\000', 2 '\002', 1 '\001', 11 '\v', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 100 'd', 0 '\000', 8 '\b', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 
            0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000'...}}
        buffer = {data = {
            _M_elems = "d\000\b\000\222`\000\000\001HA\000\020\000\a@\301ǣ\002@\255\225\225\000R\301\307\000\000\000\000\000\000\000\000\210\021<\000bE\265\001\232\t~\355\214\034\217t`E\265\001\232\t\020\000\000\000\000\000\003 \001#\206\003\000\000\002\003\000\000\000\000\000\000\000\000\000\001\000\002\001\v", '\000' <repeats 16 times>, "d\000\b", '\000' <repeats 404 times>}}
        transferred = <optimized out>
#12 0x000000000040c806 in std::__invoke_impl<void, void (Mt76::*)(unsigned char), Mt76*, int> (__t=<optimized out>, __f=<optimized out>)
    at /usr/include/c++/9/bits/invoke.h:89
No locals.
#13 std::__invoke<void (Mt76::*)(unsigned char), Mt76*, int> (__fn=<optimized out>) at /usr/include/c++/9/bits/invoke.h:95
No locals.
#14 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::_M_invoke<0ul, 1ul, 2ul> (this=<optimized out>) at /usr/include/c++/9/thread:244
No locals.
#15 std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> >::operator() (this=<optimized out>) at /usr/include/c++/9/thread:251
No locals.
#16 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Mt76::*)(unsigned char), Mt76*, int> > >::_M_run (this=<optimized out>)
    at /usr/include/c++/9/thread:195
No locals.
#17 0x00007f301f4d43d4 in execute_native_thread_routine () from /lib64/libstdc++.so.6
No symbol table info available.
#18 0x00007f301f2824e2 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#19 0x00007f301f1976a3 in clone () from /lib64/libc.so.6
No symbol table info available.

I hope some of this is helpful.

xow stops working after suspending and waking up the computer

Hi,

Basically title is what's happening. I've noticed that after waking up the computer and trying to sync the controller, xow would not work, so I rebooted the service using systemctl and it's working fine again. This might not be appropriate for a retropie style build like the one I'm trying to make, so it would be fine if the program was able to be aware that it resumed from sleep and kept working.

Here's the output of the program as the computer goes to sleep and wakes up:

dan@retromint:~$ xow
2020-02-26 14:35:23 INFO - xow ©Severin v. W.
2020-02-26 14:35:23 INFO - Dongle plugged in
2020-02-26 14:35:23 INFO - Wireless address: 62:45:b5:0d:5b:71
2020-02-26 14:35:23 INFO - Dongle initialized
-- PC GOES TO SLEEP AND I WAKE IT UP AFTER A WHILE --
2020-02-26 14:36:28 ERROR - Error in bulk read: 5
2020-02-26 14:36:28 ERROR - Error in bulk read: 5

I'm using the reliability branch btw.
Also a big thank you for the author of this software as I'm finally able to use my xbox controller wirelessly on Linux! really hope audio is implemented sometime too <3

Make the driver be DKMS compatible in the future

Hi, I would know if you're interested in eventually convert the driver to a dkms package later on, because it wouldn't need to be linked with systemd services and would work on Linux out of the box as a (almost) integrated driver.

Also, it would do great as a integrated driver of my gaming-focused kernel fork

It doesn't need to be done now, but I would like to get an idea from you

Audio

Does this driver support audio? Or are there plans to?

Use of xow in combination with VirtualHere

I have a question:
xow runs perfectly well for me on my Linux machine if I plug the dongle directly into a USB-Port on that machine.
What does not work (yet) is the following: Plug the dongle into a USB-Port on my Steam Link and forward it via VirtualHere to my Linux machine.
This did work so far with every other USB device I ever tested, but not with the Xbox One Wireless Adapter (additional info: and it also works to forward the dongle via VirtualHere from the Steam Link to a Windows machine).
But when I forward the dongle from my Steam Link to my Linux machine where xow is running, xow crashes with the following output:

Jän 24 09:23:18 erazor systemd[1]: Started Xbox One Wireless Dongle Driver.
Jän 24 09:23:18 erazor xow[5528]: 2020-01-24 09:23:18 INFO  - xow v0.3 ©Severin v. W.
Jän 24 09:24:01 erazor xow[5528]: 2020-01-24 09:24:01 ERROR - Error resetting device: LIBUSB_ERROR_NOT_FOUND
Jän 24 09:24:01 erazor systemd[1]: xow.service: Main process exited, code=exited, status=1/FAILURE
Jän 24 09:24:01 erazor systemd[1]: xow.service: Failed with result 'exit-code'.

Is this a problem located inherently in VirtualHere, or is this something that can be fixed in xow?

Thanks in advance.

Running without root

Is this possible at all? It'd be safer if the service didn't need root, but just some privileged user.

make BUILD=RELEASE fatal error

Hi there, thanks for making this driver! I was able to install the package but make BUILD=RELEASE gave this fatal error:
make BUILD=RELEASE g++ -Wall -Wpedantic -std=c++11 -MMD -O3 -DCHANNEL=1 -DVERSION=\"v0.4-6-ga3dcb38\" -c -o xow.o xow.cpp In file included from xow.cpp:20:0: dongle/usb.h:28:10: fatal error: libusb-1.0/libusb.h: No such file or directory #include <libusb-1.0/libusb.h> ^~~~~~~~~~~~~~~~~~~~~ compilation terminated. Makefile:30: recipe for target 'xow.o' failed make: *** [xow.o] Error 1
This is on Linux Mint 19.3.

Does not pair with model 1708

I have the model 1708 but it does not pair. The dongle goes into pairing mode, when I click the button on it and the controller does as well, but it never pairs.

It goes into pairing mode until it times out:

$ sudo ./xow 
2019-12-21 19:18:32 INFO  - xow v0.1 ©Severin v. W.
2019-12-21 19:18:32 INFO  - Dongle plugged in
2019-12-21 19:18:32 INFO  - Chip address: 62:45:b4:fe:81:16
2019-12-21 19:18:32 INFO  - Dongle initialized
2019-12-21 19:18:44 INFO  - Pairing initiated
2019-12-21 19:18:44 INFO  - Pairing initiated
2019-12-21 19:18:45 INFO  - Pairing initiated
2019-12-21 19:18:45 INFO  - Pairing initiated
2019-12-21 19:22:19 ERROR - Error in bulk write: LIBUSB_ERROR_TIMEOUT
2019-12-21 19:22:19 ERROR - Failed to write WLAN packet
2019-12-21 19:22:19 ERROR - Failed to send pairing packet
2019-12-21 19:22:19 ERROR - Failed to pair client
...

I've also tried to use a 2.4 channel, but it's the same. Please tell me if you need any more informations.

cow immediately crashes after connecting the headset to the gamepad

I decided to check how works xow with audio.
And builded xow from the audio branch (fe2b41ae632120c6a334520c5ffd79d531c35240).
Testing ended immediately after connecting the headset to the gamepad as xow immediately crashed.

Here is log + backtrace xow-backtrace.txt

terminate called after throwing an instance of 'InputException'

Almost there! This is pretty exciting :) Here is the log in case it helps.

Some notes: The led in the dongle doesn't blink or lit at all.

$ sudo systemctl status xow -l
● xow.service - Xbox One Wireless Dongle Driver
   Loaded: loaded (/lib/systemd/system/xow.service; enabled; vendor preset: enabled)
   Active: failed (Result: signal) since Tue 2020-02-04 22:09:25 CET; 9s ago
  Process: 3900 ExecStart=/usr/local/bin/xow (code=killed, signal=ABRT)
 Main PID: 3900 (code=killed, signal=ABRT)

Feb 04 22:09:01 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:01 DEBUG - Firmware already loaded
Feb 04 22:09:01 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:01 DEBUG - Chip version: 7632
Feb 04 22:09:01 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:01 INFO  - Chip address: 62:45:b4:e8:c6:60
Feb 04 22:09:01 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:01 INFO  - Dongle initialized
Feb 04 22:09:25 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:25 DEBUG - Client associating: 7e:ed:80:7e:71:3e
Feb 04 22:09:25 lenovo-thinkpad xow[3900]: 2020-02-04 22:09:25 DEBUG - Client identifier: 1
Feb 04 22:09:25 lenovo-thinkpad xow[3900]: terminate called after throwing an instance of 'InputException'
Feb 04 22:09:25 lenovo-thinkpad xow[3900]:   what():  Error opening device: Permission denied
Feb 04 22:09:25 lenovo-thinkpad systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Feb 04 22:09:25 lenovo-thinkpad systemd[1]: xow.service: Failed with result 'signal'.

Please let me know how can I help

Installing on linux mint 19.3

It doesnt seem to be installing, Not sure why. Im a novice linux user, so not really familiar with error codes and all that in terminal. Just wondering if there is a different set of commands for my version of linux.

Range issues between controller and dongle

OS - Elementary OS
Controller - 1708
Dongle - 1790

Hi. Moving the controller more than about 1.5m away from the dongle results in disconnects with the controller reconnecting almost immediately when moved back into range. This doesn't happen on Windows so I'm assuming the hardware is good and I've tried various different 2.4GHz and 5GHz channels (although I'm not sure how to check if the channel has actually changed) with no change in behaviour.

If you need any more info just let me know.
Thanks

INFO  - xow v0.4-10-g53f489f ©Severin v. W.
DEBUG - Opening device...
INFO  - Dongle plugged in
DEBUG - Firmware loaded
DEBUG - ASIC version: 7632
DEBUG - MAC version: 7662
DEBUG - Chip id: 7613
INFO  - Wireless address: 62:45:b5:10:e4:fd
INFO  - Dongle initialized
DEBUG - Client associating: 7e:ed:82:1d:40:34
INFO  - Controller '1' connected
INFO  - Product ID: 02ea
DEBUG - Firmware version: 4.8.1923.0
DEBUG - Hardware version: 1284.1.1.1
INFO  - Serial number: ...
DEBUG - Battery type: 1, level: 2
...
DEBUG - Client lost: 1
INFO  - Controller '1' disconnected
DEBUG - Client associating: 7e:ed:82:1d:40:34
INFO  - Controller '1' connected
INFO  - Product ID: 02ea
DEBUG - Firmware version: 4.8.1923.0
DEBUG - Hardware version: 1284.1.1.1
INFO  - Serial number: xxx
DEBUG - Battery type: 1, level: 2

Upstream it to the kernel

Thanks for this awsome work , do you think that it will posible to upstream it with help from the one who get xbox one controler into the kernel ?

Question: what is the use of firmware.bin? Will it still work with windows after using this ?

Question: what is the use of firmware.bin? Will it still work with windows after using this or will it break the windows functionality of the dongle? Nice work btw. Thank you!

Package as a Flatpak?

Would it be feasible to package this as a Flatpak?

Segfault on disconnecting USB adapter when pairing

Issue

When setting the USB adapter to pairing mode and disconnecting the device, the driver crashes with a segfault.

Steps to reproduce

Start xow with USB adapter attached
Press the physical pairing button on the USB adapter
Wait for "Pairing Initiated" log message
Remove the USB adapter physically

Expected results

The driver should detect that the adapter got removed, wait for reconnection and continue to run

Actual results

The driver crashes with a segmentation fault.

Additional infos

I ran the process with valgrind and will post the relevant infos for the segfault below.
I'm not sure where in this stack the issue should have been catched, so I do not feel confident enough to submit a Pull request on my own.

==18572== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==18572==  Access not within mapped region at address 0x40
==18572==    at 0x4BCB7D9: libusb_control_transfer (in /usr/lib/libusb-1.0.so.0.2.0)
==18572==    by 0x1176A3: UsbDevice::controlTransfer(UsbDevice::ControlPacket) (usb.cpp:108)
==18572==    by 0x10D3A3: MT76::controlRead(unsigned short, VendorRequest) (mt76.cpp:975)
==18572==    by 0x1102E4: MT76::writeBeacon(bool) (mt76.cpp:749)
==18572==    by 0x110E7B: MT76::handleButtonPress() (mt76.cpp:175)
==18572==    by 0x1144D6: MT76::handleBulkPacket(Bytes const&) (mt76.cpp:216)
==18572==    by 0x1146EC: operator() (mt76.cpp:47)
==18572==    by 0x1146EC: __invoke_impl<void, MT76::added()::<lambda()> > (invoke.h:60)
==18572==    by 0x1146EC: __invoke<MT76::added()::<lambda()> > (invoke.h:95)
==18572==    by 0x1146EC: _M_invoke<0> (thread:244)
==18572==    by 0x1146EC: operator() (thread:251)
==18572==    by 0x1146EC: std::thread::_State_impl<std::thread::_Invoker<std::tuple<MT76::added()::{lambda()#1}> > >::_M_run() (thread:195)
==18572==    by 0x495EEE3: execute_native_thread_routine (thread.cc:80)
==18572==    by 0x4BE44CE: start_thread (in /usr/lib/libpthread-2.30.so)
==18572==    by 0x4D182D2: clone (in /usr/lib/libc-2.30.so)
==18572==  If you believe this happened as a result of a stack
==18572==  overflow in your program's main thread (unlikely but
==18572==  possible), you can try to increase the size of the
==18572==  main thread stack using the --main-stacksize= flag.
==18572==  The main thread stack size used in this run was 8388608.

After connecting controller on windows, I have to unplug and plug again in ubuntu for the service to start

If I connect my controller in windows and then restart to ubuntu, if I just turn on the controller it wont work, I need to replug the adapter for the controller to connect again.

It's already in the AUR

I was going to package this in the AUR but someone beat me: https://aur.archlinux.org/packages/xow-git/

The README should be updated with the AUR package. I can send a PR later if you'd like

Controller model 1537 compatibility

As requested in the README.md I did some packet captures with my 2016 Xbox One (S) Controller (Model 1708) and my bulky usb proprietary Microsoft dongle (Model 1713).

Captured on Arch Linux with xpad/xow via usbmon/Wireshark:
usbmon3 - Microsoft Corp. Wireless XBox Controller Dongle.zip
Captured on Windows 10 1909 via USBPcap/Wireshark:
USBPcap2 - Windows 10 Capture.zip

I only did some bare testing but it did work quite well. The capture only includes pairing to a known device and some button inputs. Will provide more if needed
captured with xow commit 877c19d

Please add battery level measurements via "upower" mechanism

This allows seeing the power charge level of the gamepad in DE.

$ upower --dump
Device: /org/freedesktop/UPower/devices/mouse_hidpp_battery_0
  native-path:          hidpp_battery_0
  model:                Zone Touch Mouse T400
  serial:               4026-cf-15-61-0d
  power supply:         no
  updated:              Sun 22 Dec 2019 02:41:30 PM +05 (89 seconds ago)
  has history:          yes
  has statistics:       yes
  mouse
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    battery-level:       normal
    percentage:          55% (should be ignored)
    icon-name:          'battery-low-symbolic'

Device: /org/freedesktop/UPower/devices/gaming_input_sony_controller_battery_f4o93o9fo34o2eodd
  native-path:          sony_controller_battery_f4:93:9f:34:2e:dd
  model:                Sony Interactive Entertainment Wireless Controller
  serial:               f4:93:9f:34:2e:dd
  power supply:         no
  updated:              Sun 22 Dec 2019 02:42:56 PM +05 (3 seconds ago)
  has history:          yes
  has statistics:       yes
  gaming-input
    rechargeable:        yes
    warning-level:       none
    percentage:          50%
    icon-name:          'battery-good-charging-symbolic'
  History (charge):
    1577007776	0.000	unknown
  History (rate):
    1577007776	0.000	unknown

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              Sun 22 Dec 2019 10:58:54 AM +05 (13445 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    icon-name:          'battery-missing-symbolic'

Daemon:
  daemon-version:  0.99.11
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: HybridSleep

Need to start command line first to make dongle link when started as service later.

I set up xow to run as a service. However, the service dies when I try to link the pad up to the dongle.
When I make sure the service is shut down again, unplug and plug the dongle in again, and I then start xom from the command line with the dongle plugged in already, all I need to do is wake the pad and the connection is established.
What is really strange: I can kill the command line instance of xom and restart the service again. The pad and the dongle then reconnect as expected and work.

Is there something wrong with the way the service initializes the dongle vs the command line init?
And why is the effect of the command line xom persistent?

Im running this on openSuSE Leap 15.1, Kernel 4.12.14-lp151.28.36-default x86_64
The Pad and dongle are brand new XBox One Controller and Wireless Adapter.

Details:

I boot PC without dongle plugged in, insert the dongle, and switch on the pad.
The pad seems to lock in (slow flashing stops) and after about 1s seems to loose connection (slow flashing starts again), dongle light is on (continuous).

sudo journalctl -b -u xow
-- Logs begin at Fri 2020-01-17 09:31:44 CET, end at Fri 2020-01-17 09:43:01 CET. --
Jan 17 09:31:48 [#] systemd[1]: Started Xbox One Wireless Dongle Driver.
Jan 17 09:31:48 [#] xow[1062]: 2020-01-17 09:31:48 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
Jan 17 09:38:50 [#.#.#] xow[1062]: 2020-01-17 09:38:50 INFO - Dongle plugged in
Jan 17 09:38:50 [#.#.#] xow[1062]: 2020-01-17 09:38:50 DEBUG - Firmware loaded
Jan 17 09:38:50 [#.#.#] xow[1062]: 2020-01-17 09:38:50 DEBUG - Chip version: 7632
Jan 17 09:38:50 [#.#.#] xow[1062]: 2020-01-17 09:38:50 INFO - Chip address: 62:45:b5:10:43:39
Jan 17 09:38:50 [#.#.#] xow[1062]: 2020-01-17 09:38:50 INFO - Dongle initialized
Jan 17 09:39:21 [#.#.#] xow[1062]: 2020-01-17 09:39:21 DEBUG - Client associating: 7e:ed:82:3c:05:f4
Jan 17 09:39:21 [#.#.#] xow[1062]: 2020-01-17 09:39:21 DEBUG - Client identifier: 1
Jan 17 09:39:21 [#.#.#] xow[1062]: terminate called after throwing an instance of 'InputException'
Jan 17 09:39:21 [#.#.#] xow[1062]: what(): Error opening device: Permission denied
Jan 17 09:39:21 [#.#.#] systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Jan 17 09:39:21 [#.#.#] systemd[1]: xow.service: Unit entered failed state.
Jan 17 09:39:21 [#.#.#] systemd[1]: xow.service: Failed with result 'signal'.

Note: "Error opening device: Permission denied".

lsusb
[..]
Bus 003 Device 006: ID 045e:02fe Microsoft Corp.
[..]

ls -la /dev/bus/usb/003/006
crw-rw-rw- 1 root root 189, 261 Jan 17 09:39 /dev/bus/usb/003/006

Here all users have rw permission.
I restart the service after the pad has gone back to sleep:

sudo systemctl start xow

Check the status:

sudo journalctl -b -u xow
[..]
Jan 17 09:54:15 [#.#.#] systemd[1]: Started Xbox One Wireless Dongle Driver.
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 INFO - Dongle plugged in
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 DEBUG - Firmware already loaded
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 DEBUG - Chip version: 7632
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 INFO - Chip address: 62:45:b5:10:43:39
Jan 17 09:54:15 [#.#.#] xow[2343]: 2020-01-17 09:54:15 INFO - Dongle initialized

So the service is up and running again, dongle initialized.
htop shows me, that xow is running as user 64499 (the DynamicUsers=true in the xow.service.in)
I unplug the dongle.
per htop, xow is still running as user 64499

sudo journalctl -b -u xow
[..]
Jan 17 09:58:37 [#.#.#] xow[2343]: 2020-01-17 09:58:37 ERROR - Error in bulk read: 1
Jan 17 09:58:37 [#.#.#] xow[2343]: 2020-01-17 09:58:37 ERROR - Error in bulk read: 1
Jan 17 09:58:37 [#.#.#] xow[2343]: 2020-01-17 09:58:37 INFO - Dongle removed

I guess this is as expected. I shut down the service and check:

sudo systemctl stop xow

sudo journalctl -b -u xow
[..]
Jan 17 10:00:43 [#.#.#] systemd[1]: Stopping Xbox One Wireless Dongle Driver...
Jan 17 10:00:43 [#.#.#] systemd[1]: Stopped Xbox One Wireless Dongle Driver.

Now I start xow from the command line and shut it down again brute force with Ctrl-C (just get the drive running, but don't touch the dongle):

sudo ./xow
2020-01-17 10:02:16 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
^C

Next I plug in the dongle and restart the service:

sudo systemctl start xow

sudo journalctl -b -u xow
[..]
Jan 17 10:03:54 [#.#.#] systemd[1]: Started Xbox One Wireless Dongle Driver.
Jan 17 10:03:54 [#.#.#] xow[2444]: 2020-01-17 10:03:54 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
Jan 17 10:03:55 [#.#.#] xow[2444]: 2020-01-17 10:03:55 INFO - Dongle plugged in
Jan 17 10:03:55 [#.#.#] xow[2444]: 2020-01-17 10:03:55 DEBUG - Firmware loaded
Jan 17 10:03:55 [#.#.#] xow[2444]: 2020-01-17 10:03:55 DEBUG - Chip version: 7632
Jan 17 10:03:55 [#.#.#] xow[2444]: 2020-01-17 10:03:55 INFO - Chip address: 62:45:b5:10:43:39
Jan 17 10:03:55 [#.#.#] xow[2444]: 2020-01-17 10:03:55 INFO - Dongle initialized

I start the pad again, and the same problem arises:

Jan 17 10:05:07 [#.#.#] xow[2444]: 2020-01-17 10:05:07 DEBUG - Client associating: 7e:ed:82:3c:05:f4
Jan 17 10:05:07 [#.#.#] xow[2444]: 2020-01-17 10:05:07 DEBUG - Client identifier: 1
Jan 17 10:05:07 [#.#.#] xow[2444]: terminate called after throwing an instance of 'InputException'
Jan 17 10:05:07 [#.#.#] xow[2444]: what(): Error opening device: Permission denied
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Unit entered failed state.
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Failed with result 'signal'.

Again, I unplug the dongle
Next I plug the dongle back in again, game pad is sleeping.

sudo journalctl -b -u xow

shows nothing has happened (Is there an udev issue?).

I run once more:

sudo ./xow
2020-01-17 10:11:55 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
2020-01-17 10:11:55 INFO - Dongle plugged in
2020-01-17 10:11:55 DEBUG - Firmware loaded
2020-01-17 10:11:55 DEBUG - Chip version: 7632
2020-01-17 10:11:55 INFO - Chip address: 62:45:b5:10:43:39
2020-01-17 10:11:55 INFO - Dongle initialized

and press the link button on the dongle and wake the pad up again.

2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:49 DEBUG - Client associating: 7e:ed:82:3c:05:f4
2020-01-17 10:12:49 DEBUG - Client identifier: 1
2020-01-17 10:12:49 INFO - Controller '1' connected
2020-01-17 10:12:49 INFO - Serial number: 02600087216940
2020-01-17 10:12:53 DEBUG - Battery type: 1, level: 3

The controller is connected and working.
Now for the really strange part:
I shut down the xow instance again.

And then start the service once more:

sudo systemctl start xow

sudo journalctl -b -u xow
[..]
Jan 17 10:15:11 [#.#.#] systemd[1]: Started Xbox One Wireless Dongle Driver.
Jan 17 10:15:11 [#.#.#] xow[2566]: 2020-01-17 10:15:11 INFO - xow v0.2-22-g1341b1e ©Severin v. W.
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 INFO - Dongle plugged in
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 DEBUG - Firmware already loaded
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 DEBUG - Chip version: 7632
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 INFO - Chip address: 62:45:b5:10:43:39
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 INFO - Dongle initialized
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 DEBUG - Client associating: 7e:ed:82:3c:05:f4
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 DEBUG - Client identifier: 1
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 INFO - Controller '1' connected
Jan 17 10:15:12 [#.#.#] xow[2566]: 2020-01-17 10:15:12 INFO - Serial number: 02600087216940
Jan 17 10:15:34 [#.#.#] xow[2566]: 2020-01-17 10:15:34 DEBUG - Battery type: 1, level: 3
Jan 17 10:15:54 [#.#.#] xow[2566]: 2020-01-17 10:15:54 DEBUG - Battery type: 1, level: 3
Jan 17 10:16:14 [#.#.#] xow[2566]: 2020-01-17 10:16:14 DEBUG - Battery type: 1, level: 3
Jan 17 10:16:34 [#.#.#] xow[2566]: 2020-01-17 10:16:34 DEBUG - Battery type: 1, level: 3
Jan 17 10:16:54 [#.#.#] xow[2566]: 2020-01-17 10:16:54 DEBUG - Battery type: 1, level: 3
Jan 17 10:17:14 [#.#.#] xow[2566]: 2020-01-17 10:17:14 DEBUG - Battery type: 1, level: 3

per htop, xow is running as user 64499 again.
All seems well.

Dongle 1790 issue? LIBUSB_ERROR_NO_DEVICE

i am not sure if this is a dongle issue or my setup issue? LIBUSB_ERROR_NO_DEVICE could that be a different issue?
I tried to connect with

Xbox One Wireless Controller 1708
Xbox One Wireless Controller Elite 2 1797

2020-04-02 14:43:05 INFO  - xow v0.4-5-g222063c ©Severin v. W.
2020-04-02 14:43:05 DEBUG - Opening device...
2020-04-02 14:43:05 INFO  - Dongle plugged in
2020-04-02 14:43:05 DEBUG - Firmware already loaded, resetting...
2020-04-02 14:43:05 DEBUG - Firmware loaded
2020-04-02 14:43:05 DEBUG - ASIC version: 7632
2020-04-02 14:43:05 DEBUG - Chip id: 7613
2020-04-02 14:43:05 INFO  - Wireless address: 6c:5d:3a:01:e7:81
2020-04-02 14:43:05 INFO  - Dongle initialized
2020-04-02 14:43:08 INFO  - Pairing initiated
2020-04-02 14:43:08 INFO  - Pairing initiated
2020-04-02 14:43:08 INFO  - Pairing initiated
2020-04-02 14:43:08 INFO  - Pairing initiated
2020-04-02 14:44:05 ERROR - Error in bulk read: LIBUSB_ERROR_NO_DEVICE
2020-04-02 14:44:05 DEBUG - Device error, terminating...
2020-04-02 14:44:05 ERROR - Error in bulk read: LIBUSB_ERROR_NO_DEVICE
2020-04-02 14:44:05 DEBUG - Device error, terminating...
2020-04-02 14:44:05 ERROR - Error in bulk write: LIBUSB_ERROR_IO
2020-04-02 14:44:05 DEBUG - Device error, terminating...
2020-04-02 14:44:05 ERROR - Failed to write command
2020-04-02 14:44:05 ERROR - Failed to burst write register
2020-04-02 14:44:05 ERROR - Failed to write beacon
2020-04-02 14:44:05 ERROR - Failed to write pairing beacon

dmesg shows me that

[  183.732292] usb 3-1: new high-speed USB device number 4 using xhci_hcd
[  183.753335] usb 3-1: New USB device found, idVendor=045e, idProduct=02fe, bcdDevice= 1.00
[  183.753338] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  183.753340] usb 3-1: Product: XBOX ACC
[  183.753342] usb 3-1: Manufacturer: Microsoft Inc.
[  183.753344] usb 3-1: SerialNumber: 020941
[  183.904452] usb 3-1: reset high-speed USB device number 4 using xhci_hcd
[  258.266904] usb 3-1: usbfs: process 3790 (xow) did not claim interface 0 before use

Changing channel

What kind of parameters do the variable channel accept? In the read me you say 2.4 ghz might work better.... why is 2.4 not default then?

Elite Wireless Support (1698)

I have the Original Elite Wireless and I'd be more than happy to test.

Boot of PI4 sometimes does not connect controllers

I run on a fully updated retro bliss image from Vman. and have installed XOW, all other controller drivers has been uninstalled and have a xbox elite and xbox one s controller connected. sometimes after a full reboot with power off, the controller won't connect, then i can reboot once again and suddenly it works fine.

Cant pair Model 1797 (newest controller firmware)

Hi,

first of all thnx for the great work!
My XBOX Elite Controller (2019) cant be paired. It seems that the dongle cant find any device.

5.6.2-arch1-2

2020-04-08 00:46:06 INFO - xow v0.4-6-ga3dcb38 ©Severin v. W.
2020-04-08 00:46:06 DEBUG - Opening device...
2020-04-08 00:46:06 INFO - Dongle plugged in
2020-04-08 00:46:06 DEBUG - Firmware already loaded, resetting...
2020-04-08 00:46:06 DEBUG - Firmware loaded
2020-04-08 00:46:06 DEBUG - ASIC version: 7632
2020-04-08 00:46:06 DEBUG - Chip id: 7613
2020-04-08 00:46:06 INFO - Wireless address: 6c:5d:3a:00:1b:f2
2020-04-08 00:46:06 INFO - Dongle initialized
2020-04-08 00:46:16 INFO - Pairing initiated
2020-04-08 00:46:16 INFO - Pairing initiated
2020-04-08 00:46:16 INFO - Pairing initiated
2020-04-08 00:46:16 INFO - Pairing initiated

Daniel

OSMC LIBUSB_ERROR_NO_DEVICE

The driver is successful while running on Raspbian, but not on kodi/OSMC (on the same machine - raspberry pi 3 b+).

osmc version:
4.19.55-6-osmc

dmesg:
[2.452045] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[2.583039] usb 1-1.2: New USB device found, idVendor=045e, idProduct=02e6, bcdDevice= 1.00
[2.583047] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2.583051] usb 1-1.2: Product: XBOX ACC
[2.583056] usb 1-1.2: Manufacturer: Microsoft Inc.
[2.583060] usb 1-1.2: SerialNumber: 461454

When I issue /usr/local/bin/xow:
2020-04-05 13:15:19 INFO - xow v0.4-5-g222063c ©Severin v. W.
2020-04-05 13:15:19 INFO - Dongle plugged in
2020-04-05 13:15:19 INFO - Wireless address: 62:45:b4:f9:3d:fb
2020-04-05 13:15:19 INFO - Dongle initialized
2020-04-05 13:15:20 INFO - Controller '1' connected
2020-04-05 13:15:21 INFO - Product ID: 02dd
2020-04-05 13:16:20 ERROR - Error in bulk read: LIBUSB_ERROR_NO_DEVICE
2020-04-05 13:16:20 ERROR - Error in bulk read: LIBUSB_ERROR_NO_DEVICE

I had a back and forth with someone on a forum with limited success. The controller would go straight to flashing the Xbox button and the dongle would light up when the controller was turned on, but no connection would be made. I was told to issue sed -i 's@/lib/modules-load.d@/etc/modules-load.d@' Makefile, and rebuild and reinstall. After doing this the controller connected briefly upon the next restart (possibly just a fluke, as I don't really know what this does), but then continued with the same behaviour afterwards (being disconnected).

"double free or corruption (fasttop)double free or corruption (fasttop)"

I'm getting this output from my terminal when running sudo xow:

2019-12-22 12:36:47 INFO  - xow v0.2-2-g297efa4 ©Severin v. W.
2019-12-22 12:36:47 INFO  - Dongle plugged in
double free or corruption (fasttop)double free or corruption (fasttop)

zsh: abort      sudo xow

Model: 1708

Shutdown doesn't turn off controllers/adapter

On windows if I restart my computer the adapter led and the controller turn off. When I try this on linux (Ubuntu Mate 18.04.3) the adapter led stays on and the controller led is blinking, as if looking to connect again until I boot up to linux or windows.

Using the old bulky adapter and 1708 controller.

Edit: Also happens when I turn it off.

xow crashing when started with systemctl

Hi,

I've an issue with xow:
I can't seem to start xow with systemctl. It exits after receiving a permission denied error.
I can start it without issue manually.

pi@SteamLink:~ $ sudo journalctl -u xow -b -f
-- Logs begin at Fri 2020-04-17 18:42:59 CEST. --
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - Opening device...
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 INFO - Dongle plugged in
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - Firmware already loaded, resetting...
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - Firmware loaded
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - Invalid MAC address, correcting...
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - ASIC version: 7632
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - MAC version: 7662
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 DEBUG - Chip id: 7613
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 INFO - Wireless address: 62:45:bd:02:25:4e
Apr 17 18:56:21 SteamLink xow[1395]: 2020-04-17 18:56:21 INFO - Dongle initialized
Apr 17 18:56:34 SteamLink xow[1395]: 2020-04-17 18:56:34 DEBUG - Client associating: 7e:ed:82:4d:8e:67
Apr 17 18:56:34 SteamLink xow[1395]: terminate called after throwing an instance of 'InputException'
Apr 17 18:56:34 SteamLink xow[1395]: what(): Error opening device: Permission denied
Apr 17 18:56:34 SteamLink systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Apr 17 18:56:34 SteamLink systemd[1]: xow.service: Failed with result 'signal'.

It seems that it is similar to #23
I've tried following commands to trigger the udev rules again but it does not change the permission of the /dev/uinput file

sudo udevadm control --reload-rules
sudo udevadm trigger

Why could this be?

Chatpad support

The XBONE Wireless dongle supports official chatpad functionality on windows PCs. Is chatpad support in the scope of this driver? It would be quite useful for multi-purpose HTPC type setups and small gaming/computing platforms like MiSTer FPGA.

xow generates too long Rumble in some games

In some games, in my case I can reproduce it in SteamWorld Dig 2, the rumble is way too long. Instead of a short light rumble, when hitting a rock, with the controller connected by wire, it rumbles for several seconds. And even overlaps and makes the rumble more intense.

Debug log output:

Mär 04 02:38:34 NoXP-PC systemd[1]: Started Xbox One Wireless Dongle Driver.
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 INFO  - xow v0.3-21-ga35977e ©Severin v. W.
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 INFO  - Dongle plugged in
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 DEBUG - Firmware already loaded, resetting...
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 DEBUG - Firmware loaded
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 DEBUG - Chip version: 7632
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 INFO  - Chip address: 62:45:b4:fe:81:16
Mär 04 02:38:34 NoXP-PC xow[31807]: 2020-03-04 02:38:34 INFO  - Dongle initialized
Mär 04 02:38:38 NoXP-PC xow[31807]: 2020-03-04 02:38:38 DEBUG - Client associating: 7e:ed:81:4f:f7:3c
Mär 04 02:38:38 NoXP-PC xow[31807]: 2020-03-04 02:38:38 INFO  - Controller '1' connected
Mär 04 02:38:39 NoXP-PC xow[31807]: 2020-03-04 02:38:39 INFO  - Serial number: 02600108383810
Mär 04 02:38:39 NoXP-PC xow[31807]: 2020-03-04 02:38:39 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:40 NoXP-PC xow[31807]: 2020-03-04 02:38:40 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:41 NoXP-PC xow[31807]: 2020-03-04 02:38:41 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:42 NoXP-PC xow[31807]: 2020-03-04 02:38:42 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 62, strong: 62
Mär 04 02:38:43 NoXP-PC xow[31807]: 2020-03-04 02:38:43 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:44 NoXP-PC xow[31807]: 2020-03-04 02:38:44 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:45 NoXP-PC xow[31807]: 2020-03-04 02:38:45 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 61, strong: 61
Mär 04 02:38:47 NoXP-PC xow[31807]: 2020-03-04 02:38:47 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 63, strong: 63
Mär 04 02:38:47 NoXP-PC xow[31807]: 2020-03-04 02:38:47 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 57, strong: 57
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 25, strong: 25
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 58, strong: 58
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Battery type: 1, level: 2
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Feedback length: 150, delay: 0, direction: 0, weak: 9, strong: 9
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 25, strong: 25
Mär 04 02:38:48 NoXP-PC xow[31807]: 2020-03-04 02:38:48 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 68, strong: 68
Mär 04 02:38:49 NoXP-PC xow[31807]: 2020-03-04 02:38:49 DEBUG - Feedback length: 500, delay: 0, direction: 0, weak: 134, strong: 134
Mär 04 02:38:49 NoXP-PC xow[31807]: 2020-03-04 02:38:49 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 105, strong: 105
Mär 04 02:38:49 NoXP-PC xow[31807]: 2020-03-04 02:38:49 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 51, strong: 51
Mär 04 02:38:49 NoXP-PC xow[31807]: 2020-03-04 02:38:49 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 27, strong: 27
Mär 04 02:38:50 NoXP-PC xow[31807]: 2020-03-04 02:38:50 DEBUG - Feedback length: 200, delay: 0, direction: 0, weak: 14, strong: 14
Mär 04 02:39:03 NoXP-PC xow[31807]: 2020-03-04 02:39:03 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 69, strong: 69
Mär 04 02:39:04 NoXP-PC xow[31807]: 2020-03-04 02:39:04 DEBUG - Feedback length: 100, delay: 0, direction: 0, weak: 69, strong: 69
Mär 04 02:39:08 NoXP-PC xow[31807]: 2020-03-04 02:39:08 DEBUG - Battery type: 1, level: 2
Mär 04 02:39:13 NoXP-PC xow[31807]: 2020-03-04 02:39:13 DEBUG - Terminating device...
Mär 04 02:39:13 NoXP-PC systemd[1]: Stopping Xbox One Wireless Dongle Driver...
Mär 04 02:39:13 NoXP-PC xow[31807]: 2020-03-04 02:39:13 ERROR - Packet for unconnected controller '1'
Mär 04 02:39:13 NoXP-PC xow[31807]: 2020-03-04 02:39:13 INFO  - Dongle disconnected
Mär 04 02:39:13 NoXP-PC systemd[1]: xow.service: Succeeded.
Mär 04 02:39:13 NoXP-PC systemd[1]: Stopped Xbox One Wireless Dongle Driver.

Tell me if you need any more informations.

coredump after connecting

➜ sudo xow
Alias tip: _ xow
2020-04-14 14:03:25 INFO - xow ©Severin v. W.
2020-04-14 14:03:25 INFO - Dongle plugged in
2020-04-14 14:03:25 INFO - Wireless address: 62:45:b4:e7:09:7f
2020-04-14 14:03:25 INFO - Dongle initialized
terminate called after throwing an instance of 'InputException'
what(): Error opening device: No such file or directory
[1] 385131 abort sudo xow

core.xow.0.2cebbca1920c48598f01d3ba74272143.385132.1586844208000000000000.lz4.zip

License and source of firmware.bin

Hello,

I'm working in the packaging of xow for Debian and would like some clarification about the file firmware.bin.

Could you explain where/how did you get firmware.bin?

I'm mostly interested in its source code and license.

Beware that if you don't own the file and the licensing, you need to clarify it, otherwise it's as if you were saying that the file is owned by you and licensed under GPL-2.

Elite controller does not pair

I have an Elite controller with model number 1698, but it won't pair.

I have built the project with the make BUILD=DEBUG command, and this is the result:

2020-01-23 19:43:42 INFO  - xow v0.2-25-gb58edb4 ©Severin v. W.
2020-01-23 19:43:43 INFO  - Dongle plugged in
2020-01-23 19:43:43 DEBUG - Firmware already loaded
2020-01-23 19:43:43 DEBUG - Chip version: 7632
2020-01-23 19:43:43 INFO  - Chip address: 62:45:b4:f5:76:96
2020-01-23 19:43:43 INFO  - Dongle initialized
2020-01-23 19:43:48 INFO  - Pairing initiated
2020-01-23 19:43:48 INFO  - Pairing initiated
2020-01-23 19:43:48 INFO  - Pairing initiated
2020-01-23 19:43:48 INFO  - Pairing initiated
2020-01-23 19:44:15 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:44:15 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:44:15 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:44:15 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:44:46 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:00 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:00 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:00 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:26 INFO  - Pairing initiated
2020-01-23 19:45:26 INFO  - Pairing initiated
2020-01-23 19:45:27 INFO  - Pairing initiated
2020-01-23 19:45:27 INFO  - Pairing initiated
2020-01-23 19:45:28 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:45 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:45 DEBUG - Client pairing: 7e:ed:89:8b:50:0e
2020-01-23 19:45:45 DEBUG - Client pairing: 7e:ed:89:8b:50:0e

I have tried to get some package captures via Wireshark, but I don't see any traffic on the usbmon{x} interfaces in Wireshark. (I do see usbmon0...6 in Wireshark, but no traffic.

Is there anything else you'd like me to try/test?

EDIT:

I can successfully connect with an Xbox controller model number 1697.
I have the old/fat Wireless Xbox adapter

Dead Zones Joysticks

Hello,

great job so far, i love it.
The only thing that bothers me is the dead zones on the joysticks.
Especially on the right side. If it is centered, it always gets low inputs down in games.
Is it possible to enlarge the dead zones or to implement them if they do not yet exist?

On bluetooth connection I have this behavior not.

Thank you

Project Support

@medusalix Would it be possible to get an English paypal link too and you might be interested in creators.brave.com you can link your github to it to accept BAT tips.

Make receiver's LED turn off when no controller is connected

Is this possible?

Proton/Wine games make controller vibrate in full force

Something went wrong. After launching the game, The Surge XBOX Elite Controllers amicably began to vibrate in full force.

Demonstration: https://youtu.be/_VevGQK8jAA

Kernel log

P.S. All games which ran under Proton can only vibrate. Native games didn't see the gamepad.

SteamOS

How can I build this on SteamOS?

At my first try it complained that the command "git" was not found. So I did a

sudo apt-get install git

Now I am getting this:

desktop@steamos:~/Downloads/xow-master$ make BUILD=RELEASE
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
g++  -Wall -Wpedantic -std=c++17 -MMD -O3 -DCHANNEL=1 -DVERSION=\"\" -c -o xow.o xow.cpp
g++: error: unrecognized command line option ‘-std=c++17’
Makefile:23: recipe for target 'xow.o' failed
make: *** [xow.o] Error 1

Random controller disconnects

Similarly to issue #35 I still experience random controller disconnects, however not too often. Logs of such occasions are:

Apr 18 15:17:26 xow[462]: 2020-04-18 15:17:26 INFO  - xow v0.4-10-g53f489f ©Severin v. W.
Apr 18 15:17:26 xow[462]: 2020-04-18 15:17:26 INFO  - Dongle plugged in
Apr 18 15:17:26 xow[462]: 2020-04-18 15:17:26 INFO  - Wireless address: 62:45:bd:00:c9:e3
Apr 18 15:17:26 xow[462]: 2020-04-18 15:17:26 INFO  - Dongle initialized
Apr 18 15:17:27 xow[462]: 2020-04-18 15:17:27 INFO  - Controller '1' connected
Apr 18 15:17:28 xow[462]: 2020-04-18 15:17:28 ERROR - Error stopping event loop: Bad file descriptor
Apr 18 15:17:28 xow[462]: 2020-04-18 15:17:28 INFO  - Controller '1' disconnected
Apr 18 15:18:14 xow[462]: 2020-04-18 15:18:14 INFO  - Controller '1' connected
Apr 18 15:18:14 xow[462]: 2020-04-18 15:18:14 INFO  - Product ID: 02ea
Apr 18 15:18:14 xow[462]: 2020-04-18 15:18:14 INFO  - Serial number: 02600224763946
Apr 18 15:18:30 xow[462]: 2020-04-18 15:18:30 INFO  - Controller '2' connected

Apr 20 20:57:44 systemd[1]: Started Xbox One Wireless Dongle Driver.
Apr 20 20:57:44 xow[759588]: 2020-04-20 20:57:44 INFO  - xow v0.4-10-g53f489f ©Severin v. W.
Apr 20 20:57:44 xow[759588]: 2020-04-20 20:57:44 INFO  - Dongle plugged in
Apr 20 20:57:44 xow[759588]: 2020-04-20 20:57:44 INFO  - Wireless address: 62:45:bd:00:c9:e3
Apr 20 20:57:44 xow[759588]: 2020-04-20 20:57:44 INFO  - Dongle initialized
Apr 20 20:57:46 xow[759588]: 2020-04-20 20:57:46 INFO  - Controller '1' connected
Apr 20 20:57:46 xow[759588]: 2020-04-20 20:57:46 INFO  - Product ID: 02ea
Apr 20 20:57:47 xow[759588]: 2020-04-20 20:57:47 INFO  - Serial number: 02600224753946
Apr 20 21:39:53 xow[759588]: 2020-04-20 21:39:53 INFO  - Controller '2' connected
Apr 20 21:39:53 xow[759588]: 2020-04-20 21:39:53 INFO  - Product ID: 02ea
Apr 20 21:39:54 xow[759588]: 2020-04-20 21:39:54 INFO  - Serial number: 02600224763946
Apr 20 21:46:32 xow[759588]: 2020-04-20 21:46:32 INFO  - Controller '2' disconnected
Apr 20 21:46:36 xow[759588]: 2020-04-20 21:46:36 INFO  - Controller '2' connected
Apr 20 21:46:37 xow[759588]: 2020-04-20 21:46:37 INFO  - Product ID: 02ea
Apr 20 21:46:37 xow[759588]: 2020-04-20 21:46:37 INFO  - Serial number: 02600224763946
Apr 20 23:06:00 xow[759588]: 2020-04-20 23:06:00 INFO  - Controller '2' disconnected
Apr 20 23:06:05 xow[759588]: 2020-04-20 23:06:05 INFO  - Controller '2' connected
Apr 20 23:06:06 xow[759588]: 2020-04-20 23:06:06 INFO  - Product ID: 02ea
Apr 20 23:06:07 xow[759588]: 2020-04-20 23:06:07 INFO  - Serial number: 02600224763946
Apr 20 23:49:36 xow[759588]: 2020-04-20 23:49:36 INFO  - Controller '2' disconnected
Apr 20 23:49:41 xow[759588]: 2020-04-20 23:49:41 INFO  - Controller '2' connected
Apr 20 23:49:41 xow[759588]: 2020-04-20 23:49:41 INFO  - Product ID: 02ea
Apr 20 23:49:42 xow[759588]: 2020-04-20 23:49:42 INFO  - Serial number: 02600224763946

Using arch and installed the xow-git version. xow runs as a system service as suggested in the package in the PKGBUILD Am I doing anything wrong here?

I now build the debug version to gather further logs - is there any other data I can collect to help debug this issue?

Possible to sync in both windows and linux?

I used the xbox 360 adapter and with that adapter i could sync once and my controllers would work in both windows and ubuntu.

Could it be possible to do that? One sync to rule them all.

Mapping of X and Y buttons is mirrored

The X and Y buttons are mirrored, X is recognized as Y and vis versa. I guess there is something mixed up in the code :)

medusalix / xow Goto Github PK

xow's People

Contributors

Stargazers

Watchers

Forkers

xow's Issues

Issue

Steps to reproduce

Expected results

Actual results

Additional infos

Recommend Projects

Recommend Topics

Recommend Org