search

jgeumlek / MoltenGamepad

Flexible Linux input device translator, geared for gamepads
MIT License
281 stars 42 forks source link

Classic controller mapping issues #38

Open dset0x opened 7 years ago

dset0x commented 7 years ago

Hello, I'm interested in using MoltenGamepad with the standard classic controller.

First of all, during compilation I had to comment out the following:

{KEY_RIGHT_UP, "key_right_up", ""},
{KEY_RIGHT_DOWN, "key_right_down", ""},
{KEY_LEFT_UP, "key_left_up", ""},
{KEY_LEFT_DOWN, "key_left_down", ""},
{KEY_ROOT_MENU, "key_root_menu", ""},
{KEY_MEDIA_TOP_MENU, "key_media_top_menu", ""},
{KEY_NUMERIC_11, "key_numeric_11", ""},
{KEY_NUMERIC_12, "key_numeric_12", ""},
{KEY_AUDIO_DESC, "key_audio_desc", ""},
{KEY_3D_MODE, "key_3d_mode", ""},
{KEY_NEXT_FAVORITE, "key_next_favorite", ""},
{KEY_STOP_RECORD, "key_stop_record", ""},
{KEY_PAUSE_RECORD, "key_pause_record", ""},
{KEY_VOD, "key_vod", ""},
{KEY_UNMUTE, "key_unmute", ""},
{KEY_FASTREVERSE, "key_fastreverse", ""},
{KEY_SLOWREVERSE, "key_slowreverse", ""},
{KEY_DATA, "key_data", ""},

When running jstest-gtk on the controller without MoltenGamepad, I get the following reasonable results:

When running jstest-gtk on Virtual Gamepad however:

Setting the following before wm1 is detected appears to have no effect (Although I could have misunderstood how configuration/inheritance is done) : *

gamepad.tl2_axis_btn = tl2
gamepad.tr2_axis_btn = tr2
jgeumlek commented 7 years ago

About the commenting out stuff: this is rather unavoidable if you are compiling on an older kernel. The "make eventlists" target attempts to do what is needed automatically.

I will go and test out my classic controller soon to make sure everything is working on my end. Until then, here is some guess work:

Might I ask why you are investigating the obsolete js interfaces with jstest-gtk? This is an outdated standard that most software has moved away from. Please use evtest to check the generated event devices, it will give me a much better understanding of what is happening.

I think jstest might be confused since the default MG virtual gamepad exposes different events than it might expect -- for example, whether or not analog trigger axes exist and whether the dpad is two hat axes or four independent buttons. You might have better luck with the --mimic-xpad option.

I will remark that the classic controller support currently assumes digital triggers, and I don't own one of the old classic controllers that had analog triggers. This means wiimote devices, even with a classic controller, will not have tr2_axis or tl2_axis events, and subsequently they use tr2 not tr2_axis_btn as the exposed events.

If you wish to check your understanding of the inheritance, try print profile wiimote or print profile wm1.

My understanding is that the kernel driver will still send the digital events alongside the analog values, and MG will just ignore the analog values.

jgeumlek commented 7 years ago

Looks like both of my classic controllers are working fine over here. (side note: I should probably filter out any "temporarily unavailable" error messages...)

I tried out jstest-gtk, and it appeared to match my expectations. jstest has to guess on how to number the axes and buttons. It guessed a bit better when using --mimic-xpad.

Regardless, I saw all axes and buttons being reported, even if the numbering was weird. (note: still with caveat that MG doesn't report analog trigger axes for wiimote devices)

MG isn't in control of how those are numbered, and this numbering issue was a motivation for why things stopped using the js interface.

If you aren't seeing events being generated, please verify with evtest what events are being generated on the raw device and what events are being generated on the virtual device. I'll continue to look into this issue with that information. Until then, I can't reproduce anything going wrong.

dset0x commented 7 years ago

I've never attempted to set-up a joystick before, so I didn't know jstest is obsolete. My device has RVL-005 engraved on it. It should be the very first classic controller.

ZL and ZR

Nintendo Wii Remote Classic Controller

Event: time 1495693177.737326, type 1 (EV_KEY), code 312 (BTN_TL2), value 1
Event: time 1495693177.737326, -------------- SYN_REPORT ------------
Event: time 1495693177.873564, type 1 (EV_KEY), code 312 (BTN_TL2), value 0
Event: time 1495693177.873564, -------------- SYN_REPORT ------------

Event: time 1495693180.910066, type 1 (EV_KEY), code 313 (BTN_TR2), value 1
Event: time 1495693180.910066, -------------- SYN_REPORT ------------
Event: time 1495693181.076147, type 1 (EV_KEY), code 313 (BTN_TR2), value 0
Event: time 1495693181.076147, -------------- SYN_REPORT ------------

Virtual Gamepad (MoltenGamepad)

Event: time 1495692885.087361, type 3 (EV_ABS), code 2 (ABS_Z), value 255
Event: time 1495692885.087361, -------------- SYN_REPORT ------------
Event: time 1495692885.173732, type 3 (EV_ABS), code 2 (ABS_Z), value 0
Event: time 1495692885.173732, -------------- SYN_REPORT ------------

Event: time 1495692888.051192, type 3 (EV_ABS), code 5 (ABS_RZ), value 255
Event: time 1495692888.051192, -------------- SYN_REPORT ------------
Event: time 1495692888.147438, type 3 (EV_ABS), code 5 (ABS_RZ), value 0
Event: time 1495692888.147438, -------------- SYN_REPORT ------------

Left stick, Right stick:

Nintendo Wii Remote Classic Controller

# Left
Event: time 1495693267.518207, type 3 (EV_ABS), code 18 (ABS_HAT1X), value 0
Event: time 1495693267.518207, type 3 (EV_ABS), code 19 (ABS_HAT1Y), value 17
Event: time 1495693267.518207, -------------- SYN_REPORT ------------
# Right
Event: time 1495693318.555525, type 3 (EV_ABS), code 20 (ABS_HAT2X), value 22
Event: time 1495693318.555525, type 3 (EV_ABS), code 21 (ABS_HAT2Y), value 6
Event: time 1495693318.555525, -------------- SYN_REPORT ------------

Virtual Gamepad (MoltenGamepad)

# Left
Event: time 1495692979.543435, -------------- SYN_REPORT ------------
Event: time 1495692979.547100, type 3 (EV_ABS), code 0 (ABS_X), value 6254
Event: time 1495692979.547100, type 3 (EV_ABS), code 1 (ABS_Y), value -893
# Right
Event: time 1495693078.843991, -------------- SYN_REPORT ------------
Event: time 1495693078.866743, type 3 (EV_ABS), code 3 (ABS_RX), value -709
Event: time 1495693078.866743, type 3 (EV_ABS), code 4 (ABS_RY), value 1419

L (Pressed from zero all the way to button event)

(L is code 23 and 310, R is code 22 and 311)

Nintendo Wii Remote Classic Controller

Event: time 1495693421.247593, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 6
Event: time 1495693421.247593, -------------- SYN_REPORT ------------
Event: time 1495693421.303984, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 12
Event: time 1495693421.303984, -------------- SYN_REPORT ------------
Event: time 1495693421.308947, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 18
Event: time 1495693421.308947, -------------- SYN_REPORT ------------
Event: time 1495693421.325357, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 22
Event: time 1495693421.325357, -------------- SYN_REPORT ------------
Event: time 1495693421.341451, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 26
Event: time 1495693421.341451, -------------- SYN_REPORT ------------
Event: time 1495693421.357497, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 28
Event: time 1495693421.357497, -------------- SYN_REPORT ------------
Event: time 1495693421.413747, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 30
Event: time 1495693421.413747, -------------- SYN_REPORT ------------
Event: time 1495693421.460000, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 32
Event: time 1495693421.460000, -------------- SYN_REPORT ------------
Event: time 1495693421.522726, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 34
Event: time 1495693421.522726, -------------- SYN_REPORT ------------
Event: time 1495693421.538741, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 36
Event: time 1495693421.538741, -------------- SYN_REPORT ------------
Event: time 1495693421.577501, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 38
Event: time 1495693421.577501, -------------- SYN_REPORT ------------
Event: time 1495693421.624015, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 40
Event: time 1495693421.624015, -------------- SYN_REPORT ------------
Event: time 1495693421.640016, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 42
Event: time 1495693421.640016, -------------- SYN_REPORT ------------
Event: time 1495693421.716332, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 44
Event: time 1495693421.716332, -------------- SYN_REPORT ------------
Event: time 1495693421.822488, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 46
Event: time 1495693421.822488, -------------- SYN_REPORT ------------
Event: time 1495693421.928982, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 48
Event: time 1495693421.928982, -------------- SYN_REPORT ------------
Event: time 1495693421.945325, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 54
Event: time 1495693421.945325, -------------- SYN_REPORT ------------
Event: time 1495693421.961347, type 3 (EV_ABS), code 23 (ABS_HAT3Y), value 60
Event: time 1495693421.961347, type 1 (EV_KEY), code 310 (BTN_TL), value 1
Event: time 1495693421.961347, -------------- SYN_REPORT ------------
Event: time 1495693422.117515, type 1 (EV_KEY), code 310 (BTN_TL), value 0
Event: time 1495693422.117515, -------------- SYN_REPORT ------------

Virtual Gamepad (MoltenGamepad)

Event: time 1495693555.440573, type 1 (EV_KEY), code 310 (BTN_TL), value 1
Event: time 1495693555.440573, -------------- SYN_REPORT ------------
Event: time 1495693555.560619, type 1 (EV_KEY), code 310 (BTN_TL), value 0
Event: time 1495693555.560619, -------------- SYN_REPORT ------------

I've been reading and re-reading your writeup in profiles.md and I'm still confused. Why wouldn't t*2_axis and t*2_axis_btn be one and the same? Do these different controllers fire different events? Why are t*2_axis superfluous when they only let you know how far in the button is pressed (if analog), but not whether it clicked?

This means wiimote devices, even with a classic controller, will not have tr2_axis or tl2_axis events, and subsequently they use tr2 not tr2_axis_btn as the exposed events.

Are you referring to your own controller with this, meaning I should get these axis buttons? If so, doing print profile wm1 doesn't show them mapped or unmapped.

About the commenting out stuff: this is rather unavoidable if you are compiling on an older kernel. The "make eventlists" target attempts to do what is needed automatically.

Woops, my kernel is recent enough, but my headers were older.

jgeumlek commented 7 years ago

Hello. Thanks for replying. I apologize for the confusing documentation. Please continue to ask questions as needed.

It looks like all the events are being processed and handled by MG -- ABS_X, ABS_Y, ABS_RX, ABS_RY are effectively the standard for two thumb sticks, and ABS_Z, ABS_RZ are effectively the standard for two triggers. I'm not seeing anything unexpected or missing in those logs. Is there a particular game or such that is giving you trouble with the controller, other than this jstest utility?

The raw device's ABS_HAT3* events are the analog trigger values that MG unfortunately ignores since the original classic controller is an edge case. However the digital event BTN_TL is still firing.

It is also unfortunate that the original classic controller had L/R as the analog triggers, while the classic controller pro put ZL/ZR as the lower triggers. This makes it hard to provide one default mapping of L/R/ZL/ZR onto the two triggers and two bumpers that has become standard.

About the lack of tr2 in the wiimote profile: My apologies, it isn't obvious since the wiimote profile uses wiimote specific names for each of the events (e.g. cc_zr instead of tr2). If you do "print aliases wiimote" you can see how these names are mapped.

tr2     ->      cc_zr
tl      ->      cc_l
(etc.)

Now for the confusing bit. What is the difference between tr2, tr2_axis and tr2_axis_btn?

Remember that generally MG wants to map these triggers onto the two output axes ABS_Z, ABS_RZ. Our virtual output controllers don't have trigger clicks. And even if they did have clicks, they'd need to follow the logic of the output controller, not the input controller. Games would get pretty confused if they expected the click to mean full depression when it fires at the slightest.

So the best we can do: If there is no axis, then send the digital buttons as full axis pulls (i.e. 0 to 255). If there is an axis, then map it onto the range 0 to 255. If there is an axis and a "click" event, then map the axis and ignore the click, since we don't even know what the click means in general.

True, it is the headers that are important, rather than the kernel itself when it comes to those key code definitions.

dset0x commented 7 years ago

Thanks a lot for your quick responses and effort as well.

It looks like all the events are being processed and handled by MG -- ABS_X, ABS_Y, ABS_RX, ABS_RY are effectively the standard for two thumb sticks, and ABS_Z, ABS_RZ are effectively the standard for two triggers. I'm not seeing anything unexpected or missing in those logs.

These work fine and I have no issue with the changed naming. The only quirk was jstest not being able to get the ordering right. However this poses no functionality problem at all.

The raw device's ABS_HAT3* events are the analog trigger values that MG unfortunately ignores since the original classic controller is an edge case. However the digital event BTN_TL is still firing.

I have no immediate use for ABS_HAT3*. Indeed, BTN_TL fires which is good enough for me.

I say tr2_axis_btn is generally superfluous because I don't have any use cases where knowing that a trigger is "clicked" is important -- everything works just as well if they just assume it is clicked when the trigger axis reaches, say, 90% activation. Also, there is no agreement what "clicked" means. On some controllers, this extra click fires when fully depressed. On others, this extra click fires on even the slightest trigger pull.

If there is an axis and a "click" event, then map the axis and ignore the click, since we don't even know what the click means in general.

I see, this is quite bothersome indeed. However, it sounds only valid for Wii games to me, which in my mind translates to dolphin. Luckily dolphin now does its own bluetooth handling, bypassing all this.

Is there a particular game or such that is giving you trouble with the controller, other than this jstest utility?

Yes, I would like to map these buttons in antimicro, which expects buttons for Shoulders and Triggers, not axis.

jgeumlek commented 7 years ago

They all provide an analog event though, correct?

No. Only the original classic controllers had these, and they've been out of production for a while now. I see there are some third party clones of the original model, but I have no clue if they report analog values. Classic controller pros and more recent alternatives like the PDP/HORI gamecube-esque extensions do not provide the analog events.

EDIT: Oh, I think I see what you are saying. Yes, they do still send the ABS_HAT3*, even though it only takes two possible values. I could have used that as the base event for translation rather than the digital events. However with the Wii U Pro and the Classic Controller Pro, the original classic controller is unfortunately outvoted on whether L or ZL should be the virtual lower trigger. MG doesn't have a tl_axis for the upper trigger (or "bumper", in the 360 nomenclature). Having an input axis that is secretly digital adds a fair bit of unneeded complexity.

I see, this is quite bothersome indeed. However, it sounds only valid for Wii games to me, which in my mind translates to dolphin. Luckily dolphin now does its own bluetooth handling, bypassing all this.

If by valid for Wii games you mean that Dolphin is the only Linux software I know of that even has the concept of a trigger click, I agree. Not even Wii games used these analog values, since the classic controller pro didn't report them. Everything else that supports analog triggers appears to target a 360 controller (xpad) as the minimum, which has no trigger clicks.

At the moment MG only supports a limited collection of hard-coded output controller styles, and none of them have both analog triggers and trigger click events. Either there are pure digital triggers or pure analog triggers. This could be changed, and hopefully in the near future MG will give you more control over the output controllers. However, --mimic-xpad will remain a supported feature, so we can't avoid the fact that sometimes we want to ignore trigger clicks (but not ignore pure digital triggers).

(side note: it looks like MG currently has all styles hard-coded to analog triggers... but pure digital triggers are just a boolean flag away)

However, is there a technical reason to ignore them instead of forward them when available?

The real reason: I do not own such a controller, so I could not test this functionality.

If you like I can expose these as l_axis and r_axis, if you are willing to verify they work.

I am not comfortable aliasing these new events for inheritance from the gamepad profile, since it doesn't line up well due to the L/R vs. ZL/ZR swap. And I don't have a good way of detecting whether a classic controller reports analog values until we see them, and trying to dynamically swap things around like that gets messy. So these two new events will be unmapped by default.

However, with l_axis and r_axis exposed you could take the time to create whatever mapping you decide is appropriate. It will remain an edge case that is a little awkward to set up, but at least the functionality would be there.

Yes, I would like to map these buttons in antimicro, which expects buttons for Shoulders and Triggers, not axis.

I am not super familiar with antimicro's controller handling. Does it really not support analog triggers being mapped to buttons? I would figure that would be essential for its use in mapping xbox 360 controllers onto keyboard/mouse events.

dset0x commented 7 years ago

No. Only the original classic controllers had these, and they've been out of production for a while now. I see there are some third party clones of the original model, but I have no clue if they report analog values. Classic controller pros and more recent alternatives like the PDP/HORI gamecube-esque extensions do not provide the analog events.

Apologies, I meant to say "digital", not "analog", but you explained that later either way.

If you like I can expose these as l_axis and r_axis, if you are willing to verify they work.

I'd be happy to help collect information and test if you want to implement this.

I am not super familiar with antimicro's controller handling. Does it really not support analog triggers being mapped to buttons? I would figure that would be essential for its use in mapping xbox 360 controllers onto keyboard/mouse events.

It believe it does, but I use it so that I can generate SDL2 Mapping Strings, so perhaps the question is whether those support such a mapping. I do this because PCSX2-master needs such a Mapping String to use the classic controller. Jumping through this hoop is already a very sub-optimal solution to me as that limits PCSX2 to one controller.

jgeumlek commented 7 years ago

Ah, so this is really about using the classic controller in PCSX2, no? Based on the use of mapping strings, I assume they are using SDL2. Is this one controller limit because you are passing the string as an environment variable? In which case, would either of these methods get around the issue?

Looking over gamecontrollerbd, I see some controllers have lefttrigger:b6 while others have lefttrigger:a3. I think these mapping strings do in fact support either buttons or axes as being triggers.

I've been using my multiple classic controllers in SDL2 software for a while now, using the --mimic-xpad method.

After I tackle #33, I think I will add cc_l_axis and cc_r_axis just for completeness, even though they'll be ignored by default. More power to the user. I'll comment on this issue again so you can check it out for me.

dset0x commented 7 years ago

You mentioned --mimc-xpad 4 times, but seeing that I still had no BTN with it, I ignored it, not seeing how it could solve my problem. Additionally, as you noticed, lefttrigger:a3 is supported - but antimicro's interface doesn't accept it when pressed, even though it does furnish a string that does use :a* when --mimic-xpad is used.

Ah, so this is really about using the classic controller in PCSX2, no?

Yes.

I assume they are using SDL2. Is this one controller limit because you are passing the string as an environment variable?

They let you set it as a cfg variable, but essentially it's like using the environment variable.

  • use --mimic-xpad to create virtual controllers that don't need an additional mapping string.
  • Add the mapping string to SDL's gamecontrollerdb.txt, which shouldn't limit you to one controller.

I didn't know about that.

1) They use this string: 030000005e0400008e02000010010000,X360 Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux, ..which seems to swap x with y and a with b. a:b1,b:b0,x:b3,y:b2 works correctly for me instead.

2) In some menus, PCSX2 registers presses on the dpad twice. So does SDL2 Gamepad Tool. In fact it detects some h0.0 button press right after dpad Up (and others) is pressed. I assume it detects the button being released as a button.

jgeumlek commented 7 years ago

I mention --mimic-xpad as xpad devices are the most common game pad for PC use. I am simply guessing that using xpad devices with PCSX2 is a solved problem, and that they can handle the triggers correctly. If they are using SDL2 mapping strings, they might not even need to care whether the triggers are axes or buttons, since SDL might abstract them. I would be surprised if they required users to jump through hoops to use xpad devices.

I've personally never had to deal with SDL2 mapping strings, since xpad devices work out of the box on all my SDL2 software.

I think "h0.0" might just be how they denote the dpad hat as returning the neutral state. I'm not seeing any extra events via evtest, though I see what you mean with SDL2 Gamepad Tool. It tried to use the return to neutral dpad as an input. I don't see anything MG can do to stop them from doing that.

The swap between a/b and x/y is likely because they designed their mapping around physical button locations. On a 360 pad, "A" is the bottom most. On a classic controller, "A" is the rightmost. MoltenGamepad attempts to fix this; it assumes these two buttons should mean the same thing, depsite their different locations. Whatever you are checking this mapping against was likely designed around the xbox button layout.

The choice on whether the ideal mapping is based on button locations or button semantics is fairly subjective. MG goes for semantic, but offers you the ability to change the mappings to match the physical locations.

dset0x commented 7 years ago

I mention --mimic-xpad as xpad devices are the most common game pad for PC use. I am simply guessing that using xpad devices with PCSX2 is a solved problem, and that they can handle the triggers correctly. If they are using SDL2 mapping strings, they might not even need to care whether the triggers are axes or buttons, since SDL might abstract them. I would be surprised if they required users to jump through hoops to use xpad devices.

You are right, the shoulder buttons work with it.

The swap between a/b and x/y is likely because they designed their mapping around physical button locations. On a 360 pad, "A" is the bottom most. On a classic controller, "A" is the rightmost. MoltenGamepad attempts to fix this; it assumes these two buttons should mean the same thing, depsite their different locations. Whatever you are checking this mapping against was likely designed around the xbox button layout.

I see, that was as easy as

[gamepad]
first = second
second = first
third = fourth
fourth = third

I think "h0.0" might just be how they denote the dpad hat as returning the neutral state. I'm not seeing any extra events via evtest, though I see what you mean with SDL2 Gamepad Tool. It tried to use the return to neutral dpad as an input. I don't see anything MG can do to stop them from doing that.

The strange thing is that even if I manually correct the Mapping String to not include h0.0, PCSX2 still appears to pass two same movements to some game menus.

Even though I don't see extra events in evtest, I noticed that the events I do get are ABS_HAT. In the docs it's mentioned that this happens if BTN_DPAD_* aren't available. They should be though as I'm running 4.9.16.

In fact print profile gamepad (executed as moltengamepad --mimic-xpad -n 1) prints these among others:

gamepad.left = left
gamepad.updown = (up,down)
gamepad.leftright = (left,right)
gamepad.down = down
gamepad.up = up
gamepad.right = right

Does this look right to you? Should they all be enabled? If not, how does one "unmap" a button?

jgeumlek commented 7 years ago

Ah, sorry for the confusion. Thanks for identifying another part of the documentation that should be rewritten/clarified.

When using --mimic-xpad, the virtual controller dpad is a hat rather than four buttons. A normal xpad controller uses these hat events rather than the four more recently added BTN_DPAD events.

However, MG eventually supported using "left" or BTN_DPAD_LEFT as mappings/translations even on older kernels. At the very final moment on the virtual devices, and references to those events will be changed to the ABS_HAT events. So being on an older kernel limits what the output device looks like, but shouldn't require changing any profiles.

That portion of your game pad profile looks right. Devices that inherit this profile will either have the four separate digital events or the two hat axes. You don't need to disable any of those mappings, as the input sources will only use the ones that are appropriate.

The way to "unmap" an event in MG is to set its translation to nothing.

wiimote.wm_b = nothing
dset0x commented 7 years ago

Thank you again for all the detailed support and thorough explanations. It would be great if we could eventually extract some tips from this conversation for the docs.

I noticed that PCSX2 moves twice in some menus before I let go of the button (unlike the Gamepad Tool), so this has to be an unrelated issue.

Should be okay to close this now. I only have one unrelated question. Currently, with this configuration, the Wiimote's buttons are also read as the CC's buttons (as in, I can use them interchangeably). Would I be able to have them appear as two different controllers so that two people can play without connecting a second wiimote?

jgeumlek commented 7 years ago

A documentation update is on my to do list.

For the last question: not easily, but possible. Make simple things easy and complex things possible has been the effective motto of MG.

Let's say that wm1 has a classic controller.

# ensure wm1 is on virtpad1
move wm1 to virtpad1

# redirect all the core wiimote events to virtpad2
wm1.wm_1 = redirect(second, virtpad2)
wm1.wm_2 = redirect(first, virtpad2)
# ... (etc) ...

This should result in the classic controller events going to virtpad1 and the core wiimote events going to virtpad2.

jgeumlek commented 7 years ago

No rush, but if you find the time could you try the devel branch (commit 5cdf954, linked above) and verify the cc_l_axis and cc_r_axis are working? They aren't mapped to anything by default, and you might want to unmap all four trigger buttons while testing.

# one possible mapping to try
wiimote.cc_r_axis = tr2_axis

If you move wm1 to debugslot, you should see the generated events range smoothly across +/- 32768. If you check via evtest you should see it go from 0 to 255.

dset0x commented 7 years ago 
wiimote.cc_r_axis = tr2_axis
wiimote.cc_l_axis = tl2_axis

..and rejoice!

These are potentially useful as throttle/break/clutch in driving games.

Edit: Fwiw, the lowest value I've gotten is 16/255 (and sometimes it'll be 25), never 0.

dset0x commented 7 years ago 
// Could not reproduce
wiimote.cc_r_axis = tr2_axis
parse: setting wiimote.cc_r_axis = tr2_axis+
wiimote.cc_l_axis = tl2_axis
parse: setting wiimote.cc_l_axis = tl2_axis+
move wm1 to debugslot
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
move wm1 to debugslot
slot: wm1 assigned to slot debugslot
wiimote.cc_r_axis = tr2_axis
parse: setting wiimote.cc_r_axis = tr2_axis+
wiimote.cc_l_axis = tl2_axis
parse: setting wiimote.cc_l_axis = tl2_axis+

Some values I see upon release upon release instead of -32768:

debugslot: 2 -26215(tl2_axis)
debugslot: 2 -28399(tl2_axis)

debugslot: 5 -26215(tr2_axis)
debugslot: 5 -28399(tr2_axis)

Oddly specific even though these are the two different shoulders.

jgeumlek commented 7 years ago

Hm. The devel branch has some new slot movement code that still needs more testing -- I think that might have introduced the bad_alloc and hopefully I'll have that fixed before it hits master.

Ah, I guess the Classic Controller doesn't physically use the full range of the reported values. The code assumed a range of 0 to 60, but looking at your earlier log it seems like they might still be sending 6 or so when released. Could you do evtest on the raw classic controller and tell me some reasonable values to use as the maximum/minimum?

The non-analog classic controllers appear to fake the analog values using 0 and 62.

dset0x commented 7 years ago

Could you do evtest on the raw classic controller and tell me some reasonable values to use as the maximum/minimum?

The non-analog classic controllers appear to fake the analog values using 0 and 62.

I get 4 to 62 on either shoulder (4 being a rarity compared to 6) and I only ever get even numbers.

dset0x commented 7 years ago

To correct/rephrase that, 6 to 60 is what I would calibrate to. (4 barely ever occurs, 62 can be tricky to press hard enough and from the right angle)

madsl commented 4 years ago

What's the status on this? I have some classic controllers that seems to give analogue values when I test with evtest, but I cannot get anything registering within MoltenGamepad after unsetting cc_r and cc_l and setting cc_l_axis and r_axis to tl2/tr2_axis

Output from moltengamepad startup: ...

parse: setting wiimote.cc_l_axis = tl2_axis+
parse: setting wiimote.cc_r_axis = tr2_axis+

...

But nothing happens in moltengamepad (after move wm1 to debugslot) when I press the buttons.

Here's output from evtest when doing a quick press on the right shoulder key:

Event: time 1601131800.637029, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 34
Event: time 1601131800.637029, -------------- SYN_REPORT ------------
Event: time 1601131800.653275, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 38
Event: time 1601131800.653275, -------------- SYN_REPORT ------------
Event: time 1601131800.673310, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 54
Event: time 1601131800.673310, type 1 (EV_KEY), code 311 (BTN_TR), value 1
Event: time 1601131800.673310, -------------- SYN_REPORT ------------
Event: time 1601131800.721957, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 56
Event: time 1601131800.721957, -------------- SYN_REPORT ------------
Event: time 1601131800.932076, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 54
Event: time 1601131800.932076, type 1 (EV_KEY), code 311 (BTN_TR), value 0
Event: time 1601131800.932076, -------------- SYN_REPORT ------------
Event: time 1601131800.942060, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 40
Event: time 1601131800.942060, -------------- SYN_REPORT ------------
Event: time 1601131800.952052, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 34
Event: time 1601131800.952052, -------------- SYN_REPORT ------------
Event: time 1601131800.962038, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 18
Event: time 1601131800.962038, -------------- SYN_REPORT ------------
Event: time 1601131800.969604, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 6
Event: time 1601131800.969604, -------------- SYN_REPORT ------------
Event: time 1601131800.980910, type 3 (EV_ABS), code 22 (ABS_HAT3X), value 4
Event: time 1601131800.980910, -------------- SYN_REPORT ------------
madsl commented 4 years ago

@jgeumlek sorry for bothering, but do you have any idea what might be wrong with my setup?

I can't get any tl2_axis or tr2_axis output to debugslot within MoltenGamepad no matter what I do, but if I run evtest on the raw device, I get the output you see in the previous post.

madsl commented 2 years ago

@dset0x would you mind posting the profile you use, or every step of what you need to do to get the analog buttons to work? I've had four wiimotes for years now, but I've never been able to use the analogue buttons for anything other than digital buttons, and I feel like I'm missing something simple or implied that I just can't catch.

All these years having the perfect gamepads, but not able to use them properly :p

dset0x commented 2 years ago

@madsl I'm afraid I don't recall much from what was going on this thread. Luckily my vim undo file goes back to 2012. :D

Here's what my config looked like 5 days before this post:

[gamepad]
gamepad.left = left
gamepad.updown = (up,down)
gamepad.leftright = (left,right)
gamepad.thumbl = thumbl
gamepad.second = second
gamepad.first = first
gamepad.down = down
gamepad.up = up
gamepad.right = right
gamepad.start = start
gamepad.third = third
gamepad.select = select
gamepad.fourth = fourth
gamepad.thumbr = thumbr
gamepad.mode = mode
gamepad.(left_x,left_y) = stick(left_x,left_y)
gamepad.(right_x,right_y) = stick(right_x,right_y)

gamepad.tl = tl
gamepad.tr = tr

#gamepad.tl2 = tl2
#gamepad.tr2 = tr2

gamepad.tl2_axis = tl2_axis+
gamepad.tr2_axis = tr2_axis+

gamepad.tl2_axis_btn = tl2
gamepad.tr2_axis_btn = tr2

Perhaps you can figure out what I changed in it from the contents of this thread and the commit jgeumlek asked me to use (if still relevant).

madsl commented 2 years ago

No luck yet unfortunately, but thanks for the quick reply! Still no analog output on any tl2/tr2 with debugslot