Mouse movement being bounded by box (trackball, etc)

[telengard]

I did some poking around and found someone who ran into something similar w/ SDL Mame.  They described it as "being blocked by walls".
The suggestion was to set the environment variable SDL_MOUSE_RELATIVE=1.  I've set it in ~/.bashrc and ~/.bash_profile and it seems to be having no effect.

Is any one successfully using a trackball or spinner w/ GroovyMame?

[Calamity]

Hi telengard,

Are you having this problem with all trackball or spinner games? Have you tested base line SDL MAME too?

[telengard]

Hi telengard,

Are you having this problem with all trackball or spinner games? Have you tested base line SDL MAME too?

Heya Calamity,

I've only tried it w/ Centipede, I'll try some other games.  I'll try a few spinner games also.  I'm using an Optipac interface.  I'll try out stock SDL Mame also.

thanks for the ideas, I'll report back after I've tested all this stuff...

~telengard

[telengard]

Just finished up testing a little bit ago.

- Other trackball games exhibit the same issue
- Spinner games also exhibit the issue
- stock sdl mame trackball works fine

~telengard

[telengard]

Is it worth testing without the custom video modes to see if that is the issue?  If so, any help on how to run without that would be helpful.

thanks!

[Calamity]

You should try launching centipede at the desktop's resolution. For instance if it is 648x480@60, then launch:

groovymame centipede -resolution 648x480@60

I believe the problem is that SDL is not aware of the resolution change for some reason... not sure.

[telengard]

You should try launching centipede at the desktop's resolution. For instance if it is 648x480@60, then launch:

groovymame centipede -resolution 648x480@60

I believe the problem is that SDL is not aware of the resolution change for some reason... not sure.

Hi Calamity,

Thanks for the info.  Even running it at 800x600 it is happening.  I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

[Calamity]

I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

I meant launching GM from a desktop manager like LXDE (included GA), opening a terminal in there and launching it from command line. The idea is to launch GM at same resolution used by the desktop so any resolution switch has no effect.

[telengard]

I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

I meant launching GM from a desktop manager like LXDE (included GA), opening a terminal in there and launching it from command line. The idea is to launch GM at same resolution used by the desktop so any resolution switch has no effect.

Ok, I got some time to try this out today.  Launched LXDE, the desktop was 640x480@60.  Launched centipede w/ groovymame using the same resolution and the issue is still there.

[telengard]

Calamity,

I started poking around the source code and found this in src/ods/sdl/window.c:

  //FIXME: SDL1.3: really broken: the whole SDL code
        //       will only work correct with relative mouse movements ...
        //SDL_SetRelativeMouseMode
        if (!window->fullscreen && !sdlinput_should_hide_mouse(machine))
        {
            SDL_ShowCursor(SDL_ENABLE);
            if (SDL_GetWindowGrab(window->sdl_window ))
                SDL_SetWindowGrab(window->sdl_window, SDL_FALSE);
        }

Is this a change made for GroovyMame.

Is anyone else seeing this behavior or am I the only one using a mouse on Linux?   

[Calamity]

Hi telengard,

That code belongs to main line MAME, but it could point to the roots of the problem.

I don't have a working Linux setup at the moment since I accidentally destroyed by pendrive install. I promise I'll be looking at this problem when I have the time.

[telengard]

Hi telengard,

That code belongs to main line MAME, but it could point to the roots of the problem.

I don't have a working Linux setup at the moment since I accidentally destroyed by pendrive install. I promise I'll be looking at this problem when I have the time.

Hi Calamity,

That makes sense, it sure seems to be related.  Sorry to hear about your pendrive install, I've hosed a couple myself by not umounting correctly before removing.

Thanks for looking into this issue, I appreciate it a lot!

[strontium]

Hi guys,

This problem has been around for quite some time now, in fact I originally posted about this in sept 2013 and have been quietly holding out for a fix since: http://forum.arcadecontrols.com/index.php?topic=134528.0

It's also mentioned in abother way on the project page here as a bug: https://code.google.com/p/groovyarcade/issues/detail?id=7

It's a real shame as groocyarcade is great, calamity is there any more news on if this can be fixed or even progressed.

I appreciate were not all developers and can't really help but it would be so cool to be able to use the mouse / trackball without having to go back to windows.

Thanks again

Strontium

[Calamity]

I'll be looking into this. In the meanwhile it would be good to check if the new builds based on sdl2 have this issue too.

[strontium]

Ok Calamity will do, just so I'm sure do you mean the beta version? Would you suggest the download from the hyperlink on the project page or a git pull?

Thanks again

Strontium

[Calamity]

Ok Calamity will do, just so I'm sure do you mean the beta version? Would you suggest the download from the hyperlink on the project page or a git pull?

Sorry from my late answer. Yes, I meant the beta and it can only be downloaded from the link.

[Calamity]

Ok so Ves has been checking this and finally we found the culprit for the mouse misbehaviour. It turns out its XInput what causes the issue. By default we were enabling it to provide support for wiimotes, etc. But this seems to interact with the mouse. So in the most recent GM patch (0.159 Switchres 0.015f) I've disabled Xinput by default (leaving it as official MAME is), so just compile it using the new patch and the mouse should work fine. Groovy Arcade builds will keep supporting wiimotes however.

[telengard]

Ok so Ves has been checking this and finally we found the culprit for the mouse misbehaviour. It turns out its XInput what causes the issue. By default we were enabling it to provide support for wiimotes, etc. But this seems to interact with the mouse. So in the most recent GM patch (0.159 Switchres 0.015f) I've disabled Xinput by default (leaving it as official MAME is), so just compile it using the new patch and the mouse should work fine. Groovy Arcade builds will keep supporting wiimotes however.

Hi Calamity,

Thanks so much for getting to the bottom of this!  So, it seems I just need to follow the process here

http://forum.arcadecontrols.com/index.php/topic,135823.0.html

just for Linux, all default compile options, etc?

~telengard

[telengard]

Ugh, I'm running Ubuntu 12.04 LTS and no libsdl2 for it.  I guess if anyone gets this compiled if they could share it, I would be very grateful.

[Calamity]

Hi telengard,

There are some updated 0.159 no-xinput binaries here:

https://drive.google.com/drive/#folders/0B0NB2HYUHHktSUJiRDRKWWFCV1k/0B5iMjDor3P__aEFpcVNkVW5jbEE/0B5iMjDor3P__fjNkU2MwMUNaSEY4V2NGLWQwN2dYVHh2Zy03am5GSTlsVGJMWkNIbWZMQXM

[Doozer]

Ugh, I'm running Ubuntu 12.04 LTS and no libsdl2 for it.  I guess if anyone gets this compiled if they could share it, I would be very grateful.

Have you look here already (using xbmc ppa) ? http://www.ubuntuupdates.org/libsdl2-dev

Release:    precise (12.04)
Name:    libsdl2-dev
Latest version:    2.0.3+z4~20140315-8621-1ppa1precise1

[telengard]

Ok, finally got all of the upgrades done on my GroovyArcade install (circa 2013) to run these new binaries.  For those interested, I had to upgrade or install the following:

pacman (arch's package manager) this also required removing some stuff to get the dependencies working
change SigLevel since I could not get the pacman security keys working
qt4gui
sdl_ttf
sdl2
libpng
updated romset (Centipede, etc seemed to have some files renamed), since the romset I got uses .7z I upgraded everything replacing my .zip

Dropped the new binary in and unfortunately I get no trackball at all now.   
Doesn't register for non gameplay usage too, like in the tab menu for assigning keys, etc.

It does work in advmenu as it has in the past
I have trackball_device set to mouse as it was before

Anyone else having this kind of issue with these new builds?  Or have any ideas on how to debug this?

~telengard

[Calamity]

Hi telengard,

Ask Ves directly, I know there has been a problem with SDL2 and input devices, different to the one that we were discussing. I know he solved it recently but I'd say it's in one of the beta distros. Also, check if it works inside X.

[telengard]

Hi telengard,

Ask Ves directly, I know there has been a problem with SDL2 and input devices, different to the one that we were discussing. I know he solved it recently but I'd say it's in one of the beta distros. Also, check if it works inside X.

Hi Calamity, thanks for the info.

It does seem to work in X assuming that AdvMenu is an X application.

I will contact Ves about this, thanks what is the best way to reach him?  His email on the google code page has an ellipsis (...).

~telengard

[Calamity]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

[telengard]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

Ah, OK I will try that tonight, thanks!

~telengard

[ves]

Hello,
telengard remember configure the trackball in mame/ume.ini

mouse                     1
trackball_device          mouse
mouse_device             mouse

[telengard]

Hello,
telengard remember configure the trackball in mame/ume.ini

mouse                     1
trackball_device          mouse
mouse_device             mouse

Hi Ves,

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

[telengard]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

Hi Calamity,

I tried that out (launching groovymame from the command line inside the window manager), exact same behavior.  No movement at all.  The mouse also doesn't register in the menu system.

Do you recall what the input issue was w/ SDL2?

~telengard

[Calamity]

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

Beware of this. In recent version of GroovyArcade you really need to edit ume.ini even if you're using GroovyMAME. Editing mame.ini has no effect because the GroovyMAME executable is indeed a symbolic link to the GroovyUME one. Confusing, I know.

[telengard]

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

Beware of this. In recent version of GroovyArcade you really need to edit ume.ini even if you're using GroovyMAME. Editing mame.ini has no effect because the GroovyMAME executable is indeed a symbolic link to the GroovyUME one. Confusing, I know.

Yup, had gotten bitten by that before.  In this case I dropped in the 2 different binaries groovyume and groovymame (the ones built with no xinput).  I'm pretty sure my config is being used since it picks up my roms etc.

I still have no mouse input at all, but just in groovymame.  It's working in X, advmenu, etc.

Do you know what Ves had hit as far as SDL2 input issues?

[nexuscab]

Did anyone ever figure this out? I'm having the same problem where sdlmame has no problems with the trackball, but with the noxinput build of 159 Calamity posted, I get no movement at all. With the regular builds of groovymame/groovyume I get movement but have the issue of the bounding box described above.

I have:
mouse 1
mouse_device mouse
trackball_device mouse

I am calling the noxinput build directly from the command line so it isn't an issue of the wrong binary running.

I should note that I'm running on the most recent GroovyArcade beta ISO in case that makes a difference with libraries, etc.

I'm a huge groovymame fan. I have it running on one windows machine with an HD4350, but this machine has an HD5650, plus I much prefer linux in general. I just can't live without Centipede and Tempest! :-)

Thanks everyone.

[pakoman]

I found this issue also.

I'm using Groovyarcade 32bit (don't really remember which version of groovymame is in there).

I've noticed something interesting about this: if you activate de mouse for UI navigation, the UI cursor works perfectly, but the in-game mouse/trackball/lightgun input doesn't. And if you move fast the mouse in-game the "bounding box" will move to another place of the screen.

In lxde, advancemenu, etc. works fine.

[telengard]

Odd, I don't get the bounding box anymore, I just don't get movement at all.   However if I move the trackball a LOT, I see it move a pixel or two.  I'm running 64 bit here.  Seems like it is also happening with the latest distribution, so I'm holding out hope for a fix where I can continue to keep my cabinet as is.

[Calamity]

Hi telengard,

I don't have a working Linux installation these days and I'm focused on the windows side, sorry. If you want to help me fixing this, and you have some experience compiling, please try this.

In src\osd\sdl\window.c, find this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
//sdlinput_process_events_buf();

and change it by this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
sdlinput_process_events_buf();

No idea if it could have something to do with the issue but definitely is related input and it's something we change in GM.

[telengard]

Hi telengard,

I don't have a working Linux installation these days and I'm focused on the windows side, sorry. If you want to help me fixing this, and you have some experience compiling, please try this.

In src\osd\sdl\window.c, find this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
//sdlinput_process_events_buf();

and change it by this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
sdlinput_process_events_buf();

No idea if it could have something to do with the issue but definitely is related input and it's something we change in GM.

Hi Calamity,

No problem at all, I'd be happy to help.  Should I apply this change to the 0.159 no-xinput sources?

~telengard

[Calamity]

If those are the sources you have, yes. Any version since that one should do.

[telengard]

Hi Calamity,

I was finally able to get it built for 64 bit using a VM (I only have a 32 bit Linux desktop and it is old, so some libraries weren't available). 
So, unfortunately with that change the same behavior (no mouse movement at all).

However, I was fiddling with arguments to mame by editing .xinitrc and noticed that if I ran at a resolution of 800x600 the mouse worked fine!
So, something with the correct resolution or  related is the issue?  In my case I am always testing out centipede which I believe is 240x256.

Also, it might not be clear from my previous posts, but I'm no longer getting the bounding box.  That went away w/ the no-xinput build.  Instead it is no movement at all (for certain resolutions).

Hopefully that is useful information!

[telengard]

Just wondering if anyone has any ideas of what to try next?

[Calamity]

Hi telengard,

Sorry for my late answer.

Do you mean it works when MAME runs at 800x600 or when the desktop is at 800x600? What I'd do is to get two logs, one when it works, one when it doesn't, so we can compare.

[telengard]

Hi telengard,

Sorry for my late answer.

Do you mean it works when MAME runs at 800x600 or when the desktop is at 800x600? What I'd do is to get two logs, one when it works, one when it doesn't, so we can compare.

Hi Calamity, no problem at all... I've been tinkering away trying to narrow this down.

I meant when MAME runs @ 800x600, I don't use a desktop.

So, the mouse input works if I choose 800x600 and generic_15 for a monitor.  800x600 w/ my usual d9200 setting has no mouse input.  Not specifying a resolution and choosing either monitor type no mouse input as well.
I've found this by recreating a mame config and changing one thing at a time and playing around with settings.

I've attached 4 -log -verbose log files for each monitor type w/ 800x600 specified, and without after changing the monitor type in mame.ini.

groovymame -mouse -rol -resolution 800x600 -log -verbose centiped > output.txt
groovymame -mouse -rol -log -verbose centiped > output.txt

If you need any other types of logs I can get them for you...

thanks!

[Calamity]

Ok, actually what happens when you force 800x600 with generic_15, is that mode switching is disabled, because 800x600 is out of range for that monitor preset. For the rest of cases the mode switch keeps enabled.

So this confirms the problem is that after a mode switch SDL (or whatever) can't read the mouse properly any more. Maybe something must be done explicitly after a mode change to restart the mouse.

It'd be interesting to test with -monitor lcd (and no -resolution setting), in theory it should work (not 100% sure).

You must not use the -ror/rol options with GroovyMAME. Instead, use the options -orientation horizontal / vertical / rotate_r / rotate_l. Otherwise you'll be short-circuiting SwitchRes internal orientation management.

[telengard]

Ok, actually what happens when you force 800x600 with generic_15, is that mode switching is disabled, because 800x600 is out of range for that monitor preset. For the rest of cases the mode switch keeps enabled.

So this confirms the problem is that after a mode switch SDL (or whatever) can't read the mouse properly any more. Maybe something must be done explicitly after a mode change to restart the mouse.

It'd be interesting to test with -monitor lcd (and no -resolution setting), in theory it should work (not 100% sure).

You must not use the -ror/rol options with GroovyMAME. Instead, use the options -orientation horizontal / vertical / rotate_r / rotate_l. Otherwise you'll be short-circuiting SwitchRes internal orientation management.

I tried w/ the -monitor lcd and surprisingly it did not work (I've attached the output).

I can't seem to use the -orientation X option because advmenu does not allow rotation options with a space according to the documentation.  I tried it and it didn't work unfortunately.

[strontium]

Hey Guys,

I've just come back to check this thread and I still see that this issue persists, how frustrating. It's nice to see telengard, ves and calamity working on this to finally try and move it forward. As a linux distro nothing comes close to groovyarcade and the only reason I don't use it is because of this precise reason. I play Snakepit, golden tea, centipede, millipede and arkanoid a lot. I Just wanted to show some support although I can only do that morally as my linux skills are limited.

Hopefully this will get cracked soon as it will be a big win for the distro and it's future.

Thanks again,

Strontium   

[Manta]

Hello,

I'm seeing the same behavior with no mouse movement also. If there is anything you want me to try please ask. It would be great to have this solved for all.

Cheers,

-M

[Calamity]

Hi,

VeS has been looking into this and he believes to have found the problem in the Groovy patch itself, some of the input polling code I moved around had created a redundancy that broke the mouse. We believe there have been two issues going on, first one is when we used to compile it with xinput enabled for wiimotes that caused the mouse to be bounded by a box, second one is this specific bug I mentioned, that completely broke the mouse even without xinput.

Please download and check the file groovymame64_0164.015h_fix_linux.tar.bz2 from here.

[Calamity]

Nobody tested this?

[secretv]

First off I want to say a heartfelt thank you to you Calamity. Secondly I've tested the file you provided with my GroovyArcade. Prior to installing your file my trackball mouse did not work and now it does. Hooray!

[Manta]

Thank you to both of you. The mouse does work now! Sorry it took me a while to get back here and check the thread.

-M

[strontium]

Hey guys thanks so much for getting this sorted. I've not had chance to test this myself as I'm just finding the time to rebuild my cabinet but I'm sure it does work.

    

Quick question to either Calamity or VES, if this is working as the guys have stated does that mean this fix is Incorporated into all new releases on linux or just the one that is linked. I presume its in all the new ones?

The reason I ask is as part of the new build I was going to use the latest groovymame version I think 168 but need to be sure that this contains the fix mentioned above.

Look forward to hearing back from you guys,

Many thanks

Strontium

[telengard]

 

Thanks so much for the fix, I plan on integrating it this weekend.  Have been so busy hadn't seen this had been addressed such a while ago.

~telengard

[telengard]

Couldn't wait until the weekend so I tried it out last night.  Unfortunately, it is built against a newer c library (glibc) so it will not run for me.  I'll have to either upgrade my OS, or try and spin a build myself.

[telengard]

I'm going to try building a version first, but I noticed that the binaries were built on August 29th, but the source code didn't change.  Was the issue a build related on?  I guess I'd like to know what the issue was so I can make sure when I build I have it in there.

thanks!

[Calamity]

The relevant change was added to Switchres 0.015i (check the changelog).

[telengard]

The relevant change was added to Switchres 0.015i (check the changelog).

Thanks Calamity,

I took a shot at upgrading the Arch Linux install and have spent the past few nights trying to get it up and going (first grub was hosed, then initrd, the list goes on and on).

At this point I'll probably do a re-install which means re-doing things and what I'm wondering is, can I run GroovyMame on a different distribution, like Ubuntu or Debian (which I'm MUCH more familiar with)?
Is there a tweaked kernel or x-server, or can I just drop the groovymame binary on any distro and it will work?

~telengard

[Calamity]

Hi telengard,

You'll need patched radeon drivers for low resolution modes to work. Probably Doozer can give you some hint.

[telengard]

Hi telengard,

You'll need patched radeon drivers for low resolution modes to work. Probably Doozer can give you some hint.

I have an ArcadeVGA so I /think/ that won't be an issue, but I don't know enough to be sure.  Should I PM Doozer?

thanks for the help Calamity, I'll eventually get this going...

[Calamity]

ArcadeVGA is like any other card under Linux.

[telengard]

ArcadeVGA is like any other card under Linux.

Ok, I guess I'll PM Doozer.

thanks

[Doozer]

ArcadeVGA is like any other card under Linux.

Ok, I guess I'll PM Doozer.

thanks

The arcadevga cards will behave like vanilla ATI cards. Nothing special to do on that site under Linux.

@telengard, just to copy the answer I have PMed you. You just need to patch your kernel (for 15kHz) and take the latest binary from the google drive.

[telengard]

ArcadeVGA is like any other card under Linux.

Ok, I guess I'll PM Doozer.

thanks

The arcadevga cards will behave like vanilla ATI cards. Nothing special to do on that site under Linux.

@telengard, just to copy the answer I have PMed you. You just need to patch your kernel (for 15kHz) and take the latest binary from the google drive.

Thanks Doozer,

I ended up just upgrading the GroovyArcade install, but putting my /home/roms and /home/arcade on a separate partition so I don't have to go through the migration of all my settings/files again.  I just symlink to the other partition and it works perfectly.  I was considering switching to Debian but trying to figure out the patches to apply, etc.  I just don't have the time.  I want to play games on it.   

I dropped in the fixed groovymame and will test out the trackball soon and report back.

thanks everyone for their persistence and help on this, I truly appreciate it!

~telengard

[Doozer]

thanks everyone for their persistence and help on this, I truly appreciate it!

~telengard

Enjoy your new setup Telengard ;-) If you face any trouble, just drop a post here.