[Solution] Attract Mode freezing on pressing enter under DRM

[oomek]

Found the issue why Attract Mode is freezing on pressing Enter under DRM. It was hiding in the plain sight. When AM is running the console underneath is still receiving keyboard events. What it needs is the exclusive control over keyboard events.

to lock:

for ( std::vector<int>::iterator itr=fds.begin(); itr != fds.end(); ++itr )
  ioctl(*itr, EVIOCGRAB, 1);

to unlock:

  ioctl(*itr, EVIOCGRAB, 0);

The problem may arise that some emulators will stop receiving keyboard input events, so it may be neccessary to lock/unlock it every time we launch/exit emulator in Attract Mode.

[mickelson]

great find! I can get a fix for this into sfml-pi

thank you

On Jun 3, 2020, at 5:58 PM, Radek Dutkiewicz notifications@github.com wrote:

 Found the issue why Attract Mode is freezing on pressing Enter under DRM. It was hiding in the plain sight. When AM is running the console underneath is still receiving keyboard events. What it needs is the exclusive control over keyboard events.

for ( std::vector::iterator itr=fds.begin(); itr != fds.end(); ++itr ) ioctl(*itr, EVIOCGRAB, 1);

ioctl(*itr, EVIOCGRAB, 1);

The problem may arise that some emulators will stop receiving keyboard input events, so it may be neccessary to lock/unlock it every time we launch/exit emulator in Attract Mode.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[oomek]

You're welcome. I'm still not sure if it can be done solely in sfml if it's blocking emulators. I haven't checked it as I did not have any emus configired and it's pretty late here.

[joyrider3774]

@mickelson @oomek the fix breaks joypad support it seems with me (on rpi4) before i git pulled and rebuilded sfml-pi it worked correctly, but after joypads stop functioning. Another thing that does not seem to work with me is when for example going to add new display, i can not type the display name using keyboard. going back to previous commit (3121aea7334bdc00bd4e952fc1611531c3601495) makes joypads work again it also makes entering display names work again (if you do not use enter and do not launch using ssh, i use joypad button to be able to add a new display without enter)

[oomek]

That's unfortunate. It seems an additional check must be performed and only keyboard devices should be locked. My xbox controller for example is both js0 and event0

pi@retropie:~ $ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0:      Microsoft X-Box One pad (Firmware 2015)
/dev/input/event1:      Logitech TK820
/dev/input/event2:      Logitech M570
/dev/input/event3:      Logitech K800
/dev/input/event4:      Dell Dell QuietKey Keyboard

Regarding the text input I'll look into it.

[joyrider3774]

mine use event as well not sure about js devices have not checked

[oomek]

I temporarily excluded event0 from locking and Joystick and keyboard is working fine, just entering text is still an issue.

[oomek]

We can exclude non keyboard devices from locking by checking if it has a speciffic key. I've checked other flags and they were not conclusive enough, this seems foolproof:

void InputImpl::grabInput()
{
    sf::Lock lock( inpMutex );
    init();

    for ( std::vector<int>::iterator itr=fds.begin(); itr != fds.end(); ++itr )
        if ( isKeyboard( *itr ) )
            ioctl( *itr, EVIOCGRAB, 1 );
}

void InputImpl::ungrabInput()
{
    sf::Lock lock( inpMutex );
    init();

    for ( std::vector<int>::iterator itr=fds.begin(); itr != fds.end(); ++itr )
        if ( isKeyboard( *itr ) )
            ioctl( *itr, EVIOCGRAB, 0 );
}

bool InputImpl::isKeyboard( int fd )
{
    size_t nchar = KEY_MAX / 8 + 1;
    unsigned char bits[nchar];
    ioctl( fd, EVIOCGBIT( EV_KEY, sizeof( bits ) ), &bits );
    return bits[ KEY_B / 8 ] & ( 1 << ( KEY_B % 8 ) );
}

[oomek]

Btw, if you're wondering why I'm not making any PR, my sfml-pi repo is unbranched and ahead with baseline commits. Looking into that inability to enter text now.

[oomek]

My current observations: When you lock the console only sf::Event::KeyPressed and sf::Event::KeyReleased flags are being generated, but not sf::Event::TextEntered on which the text input in AM relies on.

[2play]

@mickelson @oomek the fix breaks joypad support it seems with me (on rpi4) before i git pulled and rebuilded sfml-pi it worked correctly, but after joypads stop functioning. Another thing that does not seem to work with me is when for example going to add new display, i can not type the display name using keyboard. going back to previous commit (3121aea) makes joypads work again it also makes entering display names work again (if you do not use enter and do not launch using ssh, i use joypad button to be able to add a new display without enter)

I confirm above with latest patch. No joystick work but KB is ok. I have used SFML-pi prior latest patch and just removed ENTER key from select as LCTRL also being used. Joy and KB work great until you press the ENTER key (even if not assigned it freezes). Everything else seems to be ok. Just to share my feedback

PS1 Also tested typing in text fields (display names etc) and KB working also ok with smfl-pi prior patch

[oomek]

Joysticks not working fixed in https://github.com/mickelson/sfml-pi/commit/8b173ac983a0e2508180dba375c707f6dad0ec8f

The problem with entering text remains though. I've been experimenting with a fix yesterday of translating keycodes to utf without using tables, but no luck so far.

@mickelson As per https://github.com/mickelson/attract/issues/622 I can understand that the amount of comments can be overwhelming sometimes and you may not be able to track all of it, but PLEASE at least leave a note of what you're currently working on so we do not duplicate our efforts.

[2play]

@oomek I understand. Maybe code was better before the patch. As mentioned on my last, if you can isolate the ENTER key only on initial code, everything else works great, joy, KB, text in fields. I have tested this morning before posting.

Thank you for your work

[oomek]

@2play The app should not allow mirroring keyboard input to the console, so it needs to be fixed the proper way.

[mickelson]

Hey I thought it would be obvious, It was only just a few days ago that I first checked in this rather large new feature I have been working on (drm), of course I’m going to try to get it working by fixing critical problems that are reported with it???

your help is appreciated, please do look into the text entry issue that remains, I’m going to take a break now, I won’t touch it.

On Jun 5, 2020, at 5:05 AM, Radek Dutkiewicz notifications@github.com wrote:

 FIxed in 8b173ac

The problem with entering text remains though. I've been experimenting with a fix yesterday of translating keycodes to utf without using tables, but no luck so far.

As per mickelson/attract#622 I can understand that the amount of comments can be overwhelming sometimes and you may not be able to track all of it, but PLEASE at least leave a note of what you're currently working on so we do not duplicate our efforts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[oomek]

Would anyone please confirm if my recent commit fixes all the keyboard issues described in this thread? I haven't pushed the PR yet. The fix is on my repo: https://github.com/oomek/sfml-pi

[MancV21]

Would anyone please confirm if my recent commit fixes all the keyboard issues described in this thread? I haven't pushed the PR yet. The fix is on my repo: https://github.com/oomek/sfml-pi

Just tried your fix and so far so good! Can now enter text as normal around AM. Will continue testing to see if any issues pop up but nothing so far. Nice work!

[2play]

Would anyone please confirm if my recent commit fixes all the keyboard issues described in this thread? I haven't pushed the PR yet. The fix is on my repo: https://github.com/oomek/sfml-pi

Tested, KB, txt entries, enter key, joystick. ALL work as supposed to! Thank you

[mickelson]

Would anyone please confirm if my recent commit fixes all the keyboard issues described in this thread? I haven't pushed the PR yet. The fix is on my repo: https://github.com/oomek/sfml-pi

Hi oomek, I tried your fix out and it works great for me

[oomek]

Thanks for the tests. There is one issue remaining though that we just discovered. When AM is launched from ssh and hardwired keyboard is used for navigation there is still echo in the main terminal in the background. I'm wondering how much is that an issue, if I remember it was always like that, wasn't it?

[oomek]

I ordered a spare ssd for tomorrow, so I can test it simultaneously on pi3 gles an pi4 drm. This console mirroring is quite dangerous thing. Ideally we should block the input of the hardwired keyboard when AM is run from ssh and just get the keycodes from ssh. I'm gonna postpone the PR for 1 more day and see if I can do anything about it.

[oomek]

For the time being, please be careful when launching AM from the SSH. You do not want to accidentally generate rm -rf ;)

[mickelson]

yikes!

On Jun 6, 2020, at 11:21 AM, Radek Dutkiewicz notifications@github.com wrote:

 For the time being, please be careful when launching AM from the SSH. You do not want to accidentally generate rm -rf ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[oomek]

Seems like all AM, ES, RA have the same problem.

[multigamesystem]

Thanks for the tests. There is one issue remaining though that we just discovered. When AM is launched from ssh and hardwired keyboard is used for navigation there is still echo in the main terminal in the background. I'm wondering how much is that an issue, if I remember it was always like that, wasn't it?

Yeah the keyboard text echo has always been there with Attract Mode and Retropie. Its a minor annoyance but doesnt seem to have any effect on operation. It happens regardless of being launched from SSH. When I exit back to the cmd line from Attract Mode it shows all the key presses. https://drive.google.com/file/d/1iB3XvfD0VvYPiXP0z_3JjZ36lyenaMCC/view?usp=sharing

[oomek]

It was. My commit seems to fix the echo when you launch from the PI console directly. Just trying to figure out if It can be eliminated also when the launch command comes from the ssh session.

[oomek]

I would like to propose adding a new flag to AM makefile, since the issue with running attract from SSH is quite complex scenario ( navigation comes from hardwired keyboard, but entering text in text fields comes from a SSH session ) NO_SSH=1 set as default and when set to 1 would prevent AM from running when called from SSH session. AM would in that case throw a suitable message and exit. It's way better solution in my opinion as if we blocked the non busy console underneath AM and for some reason segfaulted we would end up with inactive shell. Devs who know the dangers of that flag set to 0 would still be allowed to launch am from SSH, but the end user is disallowed, so there is no danger of typing unknowingly commands to the terminal. This has no relation to my latest fix which I'm ready to push today as soon as I get my spare sdcard and done testing on the PI3.

[cyborgcnc]

Would anyone please confirm if my recent commit fixes all the keyboard issues described in this thread? I haven't pushed the PR yet. The fix is on my repo: https://github.com/oomek/sfml-pi

So compiled it all, and YES the keyboard issue (hardwired Keyboard on a RPi-4) now works in Attract mode. However, I am having other issues:

-Launching a game with lr-mame2010, I have the Launch Menu enabled. Only way to go into the config (at the Press Any key to configure prompt) is to use the escape key (I have it set to esc). Now, the config menu comes up, but if I use ANY of the arrow keys to scroll, it just exists back to Attract mode.

-More weird behavior: If I let a game Launch (again in lr-mame2010), and then hit the Tab key to configure inputs, the MAME config screen comes up. If I go to configure input, and hit Enter, the game just exits, as if I am exiting the emulator running the game, and I am back into Attract Mode.

-While in Attract Mode, if I hit the ESC key (which I have set to exit) I get the prompt, Do you want to exit Attract mode, I go to yes, and hit enter. Attract mode exits, but once I am back at the terminal prompt, the plugged in keyboard no longer works, and there is no input.

Anyone seeing this?

[joyrider3774]

-Launching a game with lr-mame2010, I have the Launch Menu enabled. Only way to go into the config (at the Press Any key to configure prompt) is to use the escape key (I have it set to esc). Now, the config menu comes up, but if I use ANY of the arrow keys to scroll, it just exists back to Attract mode.

do you use launch images ? i just tested it (without launch images) with hardwired keyboard and i just pressed enter key and i entered runcommand menu and can use arrow keys without problems, i can enter menu's and setup options and i can escape them again, using arrow keys does not exit to attract with me. The escape key thing is something i had seen starting from emulationsstation as well if i remember correctly but with launch images

-More weird behavior: If I let a game Launch (again in lr-mame2010), and then hit the Tab key to configure inputs, the MAME config screen comes up. If I go to configure input, and hit Enter, the game just exits, as if I am exiting the emulator running the game, and I am back into Attract Mode.

This is not an attract problem, i just tested this by running retroarch directly for lr-mame2010 and it crashes also with a bus error when doing same steps i ran it outside attract like this : /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame2010/mame2010_libretro.so --config /opt/retropie/configs/mame-libretro/retroarch.cfg /home/pi/RetroPie/roms/mame-libretro/88games.zip --appendconfig /dev/shm/retroarch.cfg Do test your emulators outside attract first as i think this is a lr-mame2010 problem not attract problem (look in /dev/shm/runncommand.log to find last command used exit attract and run from terminal there)

-While in Attract Mode, if I hit the ESC key (which I have set to exit) I get the prompt, Do you want to exit Attract mode, I go to yes, and hit enter. Attract mode exits, but once I am back at the terminal prompt, the plugged in keyboard no longer works, and there is no input.

does not happen with me, seems like the restoreterminal function did not get called with you. Attract did not segfault did it and you did not press ctrl-c ? also you did not launch from ssh ?

[multigamesystem]

@oomek Enter works as it should now but I lost the ability to type anything in within Attract Mode. I compiled with your Attract build last night.

[joyrider3774]

@tonberryhunter do not run from ssh and did you compile sfml-pi (not attract, attract from here is fine) from oomek's repo as the repo here does not the fix for that (yet)

[multigamesystem]

@tonberryhunter do not run from ssh and did you compile sfml-pi (not attract, attract from here is fine) from oomek's repo as the repo here does not the fix for that (yet)

I never run Attract Mode from SSH I have my Pi 4 right here on my desktop set to auto boot to Attract Mode. I didnt realize I had to also compile sfml-pi from oomeks repo. It seems complicated we have separate builds and edits being made. Why arent these all merged to one? Andrew seems too busy to manage Attract Mode so why not let the community handle it? The forums are an utter wasteland of questions with no answers thats how I ended up here in the first place.

[oomek]

I've just pushed a pull request https://github.com/mickelson/sfml-pi/pull/17 with the fix. I've tested it on PI3 and PI4. All seems to be working. @tonberryhunter you can either build sfml-pi from my repo, or wait until it gets merged.

[multigamesystem]

Thanks again @oomek