search

libretro / mame2003-plus-libretro

Updated 2018 version of MAME (0.78) for libretro. with added game support plus many fixes and improvements
Other
190 stars 109 forks source link

tracking RetroArch input issues and PRs relevant to this core #1068

Open markwkidd opened 3 years ago

markwkidd commented 3 years ago

I have been tracking some interrelated issues and PRs in RetroArch. Twinaphex has been saying that a complete input refactor would be welcome, but even if that is not undertaken, I wonder if the same fix wouldn't address many of these.

At any rate, this is like a code dump in the sense that I don't know if I will go farther in the process or not 🥇 🥈

Issue tickets

Plugging a 2nd controller replaces the one already in port #0, previously plugged controller moves to port #1. #9296 https://github.com/libretro/RetroArch/issues/9296

[Windows] [Input] Raw input driver not detecting any mouse movement #11308 https://github.com/libretro/RetroArch/issues/11308

Windows input driver (dinput) does not correctly retrieve pointer state #3490 https://github.com/libretro/RetroArch/issues/3490

RETRO_DEVICE_MOUSE and RETRO_DEVICE_POINTER not working properly with OSX #3190 https://github.com/libretro/RetroArch/issues/3190

quick menu: mouse and lightgun controls are not displayed or remappable #12448 https://github.com/libretro/RetroArch/issues/12448

Flycast- dual mouse / lightgun button assignment problem on 2nd mouse/gun #12417 https://github.com/libretro/RetroArch/issues/12417

RetroArch - XInput driver. Major multiplayer confusion. #12436 https://github.com/libretro/RetroArch/issues/12436

Mouse index changes between boots #7638 https://github.com/libretro/RetroArch/issues/7638

[Feature request] global raw mice and/or joystick axis mapping support for lightguns (with all supported cores) #12024 https://github.com/libretro/RetroArch/issues/12024

Controller Priority Option (request) #6707 https://github.com/libretro/RetroArch/issues/6707

[overylay/touch] Touch events take precedence over overlay buttons #9043 https://github.com/libretro/RetroArch/issues/9043

Touch screen mouse pointer emulation should use custom overlay areas #5155 https://github.com/libretro/RetroArch/issues/5155

[Android] Change deprecated relative lightgun coordinates to new absolute coordinates in Andoid input driver #12482 https://github.com/libretro/RetroArch/issues/12482

Pull Requests

bind lightgun trigger to first mouse button by default #12423 MERGED https://github.com/libretro/RetroArch/pull/12423

Added input_playerX_combine_into for combining controllers #12296 NOT MERGED https://github.com/libretro/RetroArch/pull/12296

Add support for mapping multiple controllers to a single input device MERGED https://github.com/libretro/RetroArch/pull/12534

Change udev driver for dual lightgun support in X11 #11388 MERGED https://github.com/libretro/RetroArch/pull/11388

only add udev mouse if it has buttons and add vebose device friendly names MERGED https://github.com/libretro/RetroArch/pull/12536

Add support for multiple keyboards to Windows raw input driver #10257 https://github.com/libretro/RetroArch/pull/10257

markwkidd commented 3 years ago

I just filed a new one: [Android] Change deprecated relative lightgun coordinates to new absolute coordinates in Andoid input driver #12482 https://github.com/libretro/RetroArch/issues/12482

ghost commented 3 years ago

Just some information to test. You need to set every player to a different mouse index or it will press all buttons this is normal. I dont have a machine with windows on it at the moment.

Xorg no multi mouse support use udev until someone implements xinput2 support udev working fine in drm and x11 wayland no multi mouse support and cant change input driver. I did however hack in the udev drivers can be done if the project decides to do this so people can use multi mice when on wayland.

Its seems the mouse/lightgun drivers really need some work done all round.

Game focus mode is not disabling retropads binds on keyboard either. I have fixed this in udev in a pull request this will be required for all linux and windows dinput didnt look into the rest.

markwkidd commented 3 years ago

Since it has been a couple is days with you and Mahoney bug hunting without me, I want to mention that I've wound up in the hospital till the first of the week.

It's part of some bigger health problems that I'm already dealing with, so there's a good plan to get me moving again. Needless to say, it sucks! I hope to be back on my feet soon.

Maybe I'll get my sweetie to bring the light guns to the hospital if I'm here long enough lol

I hope you all are having a better weekend!

On Sat, Jun 12, 2021, 12:44 PM grant2258 @.***> wrote:

Just some information to test. You need to set every player to a different mouse index or it will press all buttons this is normal. I dont have a machine with windows on it at the moment.

Xorg using x driver is returning button clicks to all mice indexes like android. Wayland using x driver is returning button clicks to all mice indexes like android.

Xorg using udev driver returns the right player button but the X11 path code shares the crosshairs there is a pull req to fix this Wayland using udev is returning button clicks to all mice indexes like android.

Its seems the mouse/lightgun drivers really need some work done all round.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/mame2003-plus-libretro/issues/1068#issuecomment-860078299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVGC5UPIV3XYVX6U2UWBHTTSOFFBANCNFSM46BSEYUQ .

ghost commented 3 years ago

Well health and family always comes first mark forget the other stuff that dont matter. Im not really active as such just if something is really broke ill take a peek.

mahoneyt944 commented 3 years ago

Hope you get well. Sorry to hear.

mahoneyt944 commented 3 years ago

@grant2258 educate me if I'm wrong here, but these issues are in the driver end and not the core correct?

Would it be worthwhile to attack the drivers instead of our workarounds in this core?

ghost commented 3 years ago

Well it's more to track issues our end. There are many issues with mice and light gun on ra already already. Sometimes you just need to work with what you have and live with the quirks or try work around them. I think the main problem is someone need would need a case use to get the motivation to fix it for the system they are using.

ghost commented 3 years ago

@mahoneyt944 ive put in fixes for udev here before it was adding two mice per device and decided to look into the game focus mode not working either both of the issues that bothered me are fixed now. https://github.com/libretro/RetroArch/pull/12536. Ive never used android and dont have a build toolchain for it might marks posted an issue though. The x11 driver could do with adding multiple mice support but would need to be re written to work with multiple mice.

markwkidd commented 3 years ago

Nice!!

And hello! I spent almost a week in the hospital, as it turns out I was very seriously ill.

I'm doing much better now, and I expect to start picking back up some of my trains of thought here. If nothing else, I will try to help advocate to get Grant and my patches merged.

On Sat, Jun 19, 2021 at 2:05 AM grant2258 @.***> wrote:

@mahoneyt944 https://github.com/mahoneyt944 ive put in fixes for udev here before it was adding two mice per device and decided to look into the game focus mode not working either both of the issues that bothered me are fixed now. libretro/RetroArch#12536 https://github.com/libretro/RetroArch/pull/12536

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/mame2003-plus-libretro/issues/1068#issuecomment-864361978, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVGC5S3YYJWF4Y7XQIKPK3TTQXUJANCNFSM46BSEYUQ .

-- Mark W. Kidd (he/him/his) http://facebook.com/markwkidd (606)536-0115

mahoneyt944 commented 3 years ago

Nice addition.

markwkidd commented 3 years ago

jdgleaver from RetroArch compiled an android build of my RetroArch PR that disables duplicating mouse and gun input from the first port to the other ports.

This my proposed commit: https://git.libretro.com/libretro/RetroArch/-/commit/f74fddf3fd913ff916d0163023ade43877f2bce8

This is the RA build: https://git.libretro.com/libretro/RetroArch/-/jobs/504439/artifacts/browse/retroarch-precompiled/pkg/android/phoenix/build/outputs/apk/normal/release/

They do not have an automated build system for branches for RA like we do here. If I knew I couldn't easily add to the PR I would have aimed to actually put in support for multimouse and multigun, but if the PR works and gets merged, we can at least get rid of the ANDROID ifdefs in the input polling.

MOVED THIS CONTENT FROM THE CLOSED PR SO ITS EASIER TO KEEP TRACK OF

markwkidd commented 3 years ago

This is another udev/frontend issue that could cause trouble: https://github.com/libretro/RetroArch/issues/12279

ghost commented 3 years ago

We really need to rule out other core issues as well a few mice devices are found. I think the documentation will need updated will go through this with the user to debug. People will see /dev/input/mouse[x[]skipped and assume is all gone wrong and the mouse isint working the fact is we dont use this legacy ps2 interface we use the udev events

markwkidd commented 3 years ago

Grant that is a good idea, let me see what I can do to update documentation with the old udev logging

markwkidd commented 3 years ago

I have been looking closer at https://github.com/libretro/RetroArch/issues/12436 and it does seem like another input driver bug that could be causing user frustrations. This time it's in xinput. This multi mouse/multi gun project is uncovering a whole nest of frontend quirks 😁 🗡️

markwkidd commented 3 years ago

@mahoneyt944 here is a significant analog input PR that is now merged: https://github.com/libretro/RetroArch/pull/12562

The next version of RA is going to be full of input improvements. Fun!

ghost commented 3 years ago

@markwkidd I try stay away from input related discussion in general. There is one issue with the api in wayland the input driver is hard coded in and you guessed it no multi mice support. I did force udev myself and it worked fine but its not something I want to get into im sure someone will pick it up in time. Im happy enough getting the more agnostic approach of fixing udev if something comes up that can help this core.

mahoneyt944 commented 3 years ago

Analog to digital type has always been wonky. Hopefully that makes it easier.

markwkidd commented 3 years ago

@mahoneyt944 could you possibly confirm or test something for me? With the regular nightly RetroArch and the buildbot version of this core, are lightgun games working as expected in Android?

I'm trying to understand what's going on in the Android input driver, but my own lack of experience with Android is a speedbump. Here's what I get with the current builds:

In your experience, is this the expected baseline functionality? I thought pointer and lightgun were working.

mahoneyt944 commented 3 years ago

I've never used pointer personally and don't own a lightgun. My experience with mouse is the same behavior as you described though. There maybe odd behaviors if trying to use a pointer on a Android touch screen I would think. The general use is the same but I'm not sure how the devices interact when crossing hardware lines. I'll test the behavior tomorrow and update you here.

mahoneyt944 commented 3 years ago

@markwkidd is pointer type apple based or?

mahoneyt944 commented 3 years ago

I wonder too how the ports are working when on Android and selecting lightgun and pointer. I imagine the screen is registering as port 0 and I have a touch retropad active. So is the lightgun and pointer also sharing the screen?

markwkidd commented 3 years ago

These input types are really designed to model the input that the emulated game used, and the idea is that every input driver can produce every kind of abstracted input. So if the input driver completely implements the API, a physical mouse can be accessed through the mouse callback, the pointer callback, or the lightgun callback.

Or for fun/chaos, all three at once.

The underlying issue in my opinion is that a lot of these input drivers are incomplete, in that they do not implement every input callback, or that they don't allow some devices to be remapped.

So there are these half-complete input drivers where only the pointer is implemented, or only the mouse, etc, and then the cores have been programmed around the limitations.

That's why there is an #ifdef for IOS in the xydevice core option, no one had (and this might still be true) implemented the mouse callbacks fully on that platform. A reference IOS frontend should be providing cores with whatever kind of xyinput it wants from the API callbacks (mouse-type/relative, pointer/absolute, or lightgun/absolute), regardless of physical input device, but that's not reality yet.

I hope this wasn't completely off target as a response. I'm a little frustrated :) I've hit the almost limits of what I can fake in terms of my Android coding.

For example I'll either have to get some other help or learn more Android API and study other input drivers in order to get multiple mice and lightguns working in Android. Even though I can make some other fixes, I was hoping to get that far 👼

ghost commented 3 years ago

Something is very wrong the lightgun used to work on android. You need to look at the raw data on Windows or Linux before assuming its the android end. The problem is so much changed. The old mame code path would have ignored the mouse or joystick if a lightgun input came in anyway analog input that is

markwkidd commented 3 years ago

Thank you for confirming my memory, I was pretty sure the lightgun interface was working. This is why I wanted to make sure there wasn't a regression before losing my mind looking at the input driver code :)

Next time I'm coding I'll check the gun on desktop/windows as a sanity check, then move on from there.

ghost commented 3 years ago

We never used it on mame I'll look at the code when I get the time today. Pointer should only poll x y when pressed though else your using it like a normal mouse

ghost commented 3 years ago

@markwkidd I would need more clarification on the pointer device is it a touchscreen device ie you touch and the x/y returns. If so how would you deal with touchpads on a laptop. If it the former see no need for a lightgun interface at all .

mahoneyt944 commented 3 years ago

Does anyone have a pointer to test? Wasn't tested since switching to osd_xy_device_read()

markwkidd commented 3 years ago

I have a touchpad on my Windows laptop, but neither the winraw and the dinput input drivers implement the pointer callbacks 👯‍♂️

The lightgun interface does work correctly right now in Windows for what it's worth, although I only have one lightgun set up yself. Earlier today another user tested this core in Windows with 2 Sinden lightguns and it was successful. There is a little bug where Guns 2-8 mappings aren't showing up in the RA GUI though: https://github.com/libretro/RetroArch/issues/12417#issuecomment-869208922

The upshot is that I believe the Android input driver does need a little more work to get the lightgun working right, but I can probably figure it out.

In the meantime, I've started writing a specification for the RetroArch input drivers which if the RA devs like it, I will add to the docs to make tracking the varying levels of functionality between input drivers a little easier. Maybe.

ghost commented 3 years ago

I've put a pull request in to fix touch devices for udev. Not sure what the spec are every driver varies

markwkidd commented 3 years ago

@grant2258 you're totally right about each driver varying. I've started writing an RetroArch input driver spec with the encouragement of twinaphex and jdgleaver.

Probably it will be another week or two before the spec is ready to share, I'm not the fastest at this work plus there is a lot of distraction among RA developers after Near's death.

ghost commented 3 years ago

@markwkidd the pointer device should be absolute yet mame converts it to relative. The RA driver should do this itself when using a mouse device return when its a pointer device device in use or just return 0 for mouse device when its pointer depending on how the api should deal with this.

markwkidd commented 3 years ago

I think the existing POINTER support in this core may have just been to get it running with RetroArch input drivers on platforms that didn't/don't have the mouse abstraction implemented yet. It doesn't really make sense in terms of the purpose of the pointer API in libretro or the mouse functions in MAME.

So therefore I'm thinking hooking up the libretro pointer was a hack so that people on IOS and maybe other touchscreen devices with incomplete RA input drivers could use this core. It may not be a necessary codepath if the RA input drivers are more fully implemented.

On Sat, Jul 3, 2021 at 5:48 AM grant2258 @.***> wrote:

@markwkidd https://github.com/markwkidd the pointer device should be absolute yet mame converts it to relative. The RA driver should do this itself when using a mouse device return when its a pointer device device in use or just return 0 for mouse device when its pointer.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/mame2003-plus-libretro/issues/1068#issuecomment-873379551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVGC5T76X2M73O77YHQIWDTV3MINANCNFSM46BSEYUQ .

-- Mark W. Kidd (he/him/his) http://facebook.com/markwkidd (606)536-0115

markwkidd commented 3 years ago

FWIW the first phase of my RA input driver documentation is merged: https://github.com/libretro/RetroArch/blob/master/input/input_driver.h#L149-L297

I have a lot more documentation to go to clarify things, but I'm still working on it.

ghost commented 3 years ago

Im thinking the pointer hacked into a mouse device structure is probably a bad idea each device should probably have there own structure. Just a thought and it would make the code path clearer as for as implementing drivers go. I know its a small detail and seems kind of redundant but it keeps path code ways for implementing driver much cleaner and easier to follow the code path. In my pull request i added a pp (pointer pressed button to the mouse device structure) to not break things. https://github.com/libretro/RetroArch/pull/12579/files

mahoneyt944 commented 3 years ago

@grant2258 Yeah I agree. Separate is probably better at the top level.