Added preliminary analog stick support. Added support for buttons on extended controllers

[zakkudo]

Added preliminary analog stick support. Added support for buttons on extended controllers. This seemed to be a good stopping point to see if the style works for you. I need to do some further testing on the analog stick settings and I don't have a pro or classic controller to test with.

[zakkudo]

I'm basically code complete for my goal. I'm going to need to know if you want this merged and what changes you need to make it merge-worthy.

1. The layout defaults to to mouse-mode which is ideal for anything using using a cursor, including controlling x11 desktops and game menus
2. The ir cursor movement has been steadied and is forced to animate it's movement transisions which makes it easier to control.
3. If you press the home button, it toggles the ir handling to work best for first person and third person games, this includes the "edge scrolling" feature. in "game mode" the ir motion posts are relative.
4. The nunchuk is configured for wasd key mappings on the analog stick, with z set to the jump key and c set to the crouch key. This makes it compatible automatically with most fps games.
5. The source code has been split into separate files
6. I set up defines for most of the magic numbers
7. I included the nunchuk settings in the driver for those games that don't recognize joypads it (like minecraft) and because of how it's used,. This means the nunchuk can be included in ir keyset flips.
8. Added scrollup and scroll down to available mouse buttons
9. Most of my new options are configurable through a standard xorg config file

Looking forward to your reply!

PS. I have been testing with both Minecraft and Portal if you want to test the functionality under a similar environment.

[dnschneid]

I can't speak for @dvdhrm, but in general, massive PRs like these are really hard to review and accept, even if the contents are gold.

If you can, it would (probably) be appreciated if you split the PR into multiple steps, especially considering the refactoring you did:

1. A PR splitting the code into multiple files. There shouldn't be any functional changes.
2. A PR for each distinct feature based off of the refactored code in 1., preferably with each PR being <100 lines. Each PR hopefully doesn't touch the same code, so you should be able to merge them in any order.

The code in each PR should, of course, work. The side-benefit is that @dvdhrm can pick and choose features if he doesn't think all of them should be included.

Just my two cents; maybe @dvdhrm is happy with this kind of PR, but usually huge PRs sit in review for a very, very long time.

[damianatorrpm]

@zachary

Many Thanks! I'm also an owner of the wiimote with nunchuk and subscribed
to this list, cause I was hoping for something like that!

2015-01-26 9:50 GMT+01:00 David Schneider [email protected]:

I can't speak for @dvdhrm https://github.com/dvdhrm, but in general,
massive PRs like these are really hard to review and accept, even if the
contents are gold.

If you can, it would (probably) be appreciated if you split the PR into
multiple steps, especially considering the refactoring you did:

1. A PR splitting the code into multiple files. There shouldn't be any
   functional changes.
2. A PR for each distinct feature based off of the refactored code in
   1., preferably with each PR being <100 lines. Each PR hopefully doesn't
   touch the same code, so you should be able to merge them in any order.

The code in each PR should, of course, work. The side-benefit is that
@dvdhrm https://github.com/dvdhrm can pick and choose features if he
doesn't think all of them should be included.

Just my two cents; maybe @dvdhrm https://github.com/dvdhrm is happy
with this kind of PR, but usually huge PRs sit in review for a very, very
long time.

—
Reply to this email directly or view it on GitHub
#21 (comment)
.

[damianatorrpm]

PS: I will package rpm's for your branch Zachary and inform you via a
github issue when it's done (for openSUSE and Fedora).

2015-01-26 9:57 GMT+01:00 Damian Ivanov [email protected]:

@zachary

Many Thanks! I'm also an owner of the wiimote with nunchuk and subscribed
to this list, cause I was hoping for something like that!

2015-01-26 9:50 GMT+01:00 David Schneider [email protected]:

I can't speak for @dvdhrm https://github.com/dvdhrm, but in general,
massive PRs like these are really hard to review and accept, even if the
contents are gold.

If you can, it would (probably) be appreciated if you split the PR into
multiple steps, especially considering the refactoring you did:

1. A PR splitting the code into multiple files. There shouldn't be
   any functional changes.
2. A PR for each distinct feature based off of the refactored code in
   1., preferably with each PR being <100 lines. Each PR hopefully doesn't
   touch the same code, so you should be able to merge them in any order.

The code in each PR should, of course, work. The side-benefit is that
@dvdhrm https://github.com/dvdhrm can pick and choose features if he
doesn't think all of them should be included.

Just my two cents; maybe @dvdhrm https://github.com/dvdhrm is happy
with this kind of PR, but usually huge PRs sit in review for a very, very
long time.

—
Reply to this email directly or view it on GitHub
#21 (comment)
.

[dvdhrm]

@zakkudo I'm currently not working on this, anymore. I'd be more than glad to redirect my repository to yours.

[zakkudo]

I'm fine with whichever guys. I had some fun with this and don't mind maintaining it foe a while

[zakkudo]

I'll split this up to make it more mergable if you want dvdhrm or take the project over

[zakkudo]

Any updates on this guys? I'm thinking of integrating my branch into travisci so I can know when new versions of xorg /xwiimote breaks the x11 driver