tracking RetroArch input issues and PRs relevant to this core #1068
Comments
|
I just filed a new one: |
|
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 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. |
|
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
<#1068 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5UPIV3XYVX6U2UWBHTTSOFFBANCNFSM46BSEYUQ>
.
|
|
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. |
|
Hope you get well. Sorry to hear. |
|
@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? |
|
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. |
|
@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. 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. |
|
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
<libretro/RetroArch#12536>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1068 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5S3YYJWF4Y7XQIKPK3TTQXUJANCNFSM46BSEYUQ>
.
--
Mark W. Kidd (he/him/his)
http://facebook.com/markwkidd
(606)536-0115
|
|
Nice addition. |
|
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 |
|
This is another udev/frontend issue that could cause trouble: libretro/RetroArch#12279 |
|
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 |
|
Grant that is a good idea, let me see what I can do to update documentation with the old |
|
I have been looking closer at libretro/RetroArch#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 😁 🗡️ |
|
@mahoneyt944 here is a significant analog input PR that is now merged: libretro/RetroArch#12562 The next version of RA is going to be full of input improvements. Fun! |
|
@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. |
|
Analog to digital type has always been wonky. Hopefully that makes it easier. |
|
@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. |
|
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. |
|
@markwkidd is pointer type apple based or? |
|
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? |
|
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 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 👼 |
|
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 |
|
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. |
|
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 |
|
@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 . |
|
Does anyone have a pointer to test? Wasn't tested since switching to osd_xy_device_read() |
|
I have a touchpad on my Windows laptop, but neither the 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: libretro/RetroArch#12417 (comment) 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. |
|
I've put a pull request in to fix touch devices for udev. Not sure what the spec are every driver varies |
|
@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. |
|
@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. |
|
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
<#1068 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5T76X2M73O77YHQIWDTV3MINANCNFSM46BSEYUQ>
.
--
Mark W. Kidd (he/him/his)
http://facebook.com/markwkidd
(606)536-0115
|
|
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. |
|
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 |
|
@grant2258 Yeah I agree. Separate is probably better at the top level. |
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
libretro/RetroArch#9296
[Windows] [Input] Raw input driver not detecting any mouse movement #11308
libretro/RetroArch#11308
Windows input driver (dinput) does not correctly retrieve pointer state #3490
libretro/RetroArch#3490
RETRO_DEVICE_MOUSE and RETRO_DEVICE_POINTER not working properly with OSX #3190
libretro/RetroArch#3190
quick menu: mouse and lightgun controls are not displayed or remappable #12448
libretro/RetroArch#12448
Flycast- dual mouse / lightgun button assignment problem on 2nd mouse/gun #12417
libretro/RetroArch#12417
RetroArch - XInput driver. Major multiplayer confusion. #12436
libretro/RetroArch#12436
Mouse index changes between boots #7638
libretro/RetroArch#7638
[Feature request] global raw mice and/or joystick axis mapping support for lightguns (with all supported cores) #12024
libretro/RetroArch#12024
Controller Priority Option (request) #6707
libretro/RetroArch#6707
[overylay/touch] Touch events take precedence over overlay buttons #9043
libretro/RetroArch#9043
Touch screen mouse pointer emulation should use custom overlay areas #5155
libretro/RetroArch#5155
[Android] Change deprecated relative lightgun coordinates to new absolute coordinates in Andoid input driver #12482
libretro/RetroArch#12482
Pull Requests
bind lightgun trigger to first mouse button by default #12423MERGEDlibretro/RetroArch#12423Added input_playerX_combine_into for combining controllers #12296NOT MERGEDlibretro/RetroArch#12296Add support for mapping multiple controllers to a single input deviceMERGEDlibretro/RetroArch#12534Change udev driver for dual lightgun support in X11 #11388MERGEDlibretro/RetroArch#11388only add udev mouse if it has buttons and add vebose device friendly namesMERGEDlibretro/RetroArch#12536Add support for multiple keyboards to Windows raw input driver #10257
libretro/RetroArch#10257
The text was updated successfully, but these errors were encountered: