keyboard input no longer working after system update

[jazztickets]

I'm using omxplayer in Arch Linux ARM and keyboard input no longer works after a certain update. I've tested it with both RPi2 and 3.

List of packages here:
update.txt

Basically, getchar() always returns -1

omxplayer/Keyboard.cpp

Line 95 in 9680057

while ((ch[chnum] = getchar()) != EOF) chnum++;

getchar() seems to work if you don't call tcsetattr, but keyboard input still doesn't work in that case.

omxplayer/Keyboard.cpp

Line 28 in 9680057

tcsetattr(STDIN_FILENO, TCSANOW, &new_termios);

I believe the update to glibc is causing this. I tried reverting a handful packages like the kernel to no avail. I didn't try reverting glibc because it's a pain (multiple package dependencies).

Any insight as to why this is happening?

Forum post: https://archlinuxarm.org/forum/viewtopic.php?f=57&t=13005#p59159

[jehutting]

Have a look at this omxplayer and keybindings.

If I understood it correctly, the solution was to change

new_termios.c_lflag &= ~(ICANON | ECHO | ECHOCTL | ECHONL);

to

new_termios.c_lflag &= ~(ICANON);

[jazztickets]

That causes control codes to be displayed in the terminal, but the problem still persists.

[thomasduchatelle]

Ah! I spent my day re-installing my rpi3 to see what was wrong.

Reproducible on fresh install: https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

[jehutting]

OK...so a misunderstanding.

I installed the ArchLinuxARM-rpi-2-latest.tar.gz on my RPI 3B.

I found termios VMIN VTIME and blocking/non-blocking read operations, especially

Andrey Hanin : "Make sure to unset the FNDELAY flag for descriptor using fcntl, otherwise VMIN/VTIME are ignored."

So I patched

diff --git a/Keyboard.cpp b/Keyboard.cpp
index d38a102..d940421 100644
--- a/Keyboard.cpp
+++ b/Keyboard.cpp
@@ -23,9 +23,11 @@ Keyboard::Keyboard()
     new_termios = orig_termios;
     new_termios.c_lflag &= ~(ICANON | ECHO | ECHOCTL | ECHONL);
     new_termios.c_cflag |= HUPCL;
-    new_termios.c_cc[VMIN] = 0;
-
+    new_termios.c_cc[VMIN] = 1;
     tcsetattr(STDIN_FILENO, TCSANOW, &new_termios);
+
+    orig_fl = fcntl(STDIN_FILENO, F_GETFL);
+    fcntl(STDIN_FILENO, F_SETFL, FNDELAY);
   } 
   else 
   {    
@@ -67,6 +69,7 @@ void Keyboard::restore_term()
   if (isatty(STDIN_FILENO)) 
   {
     tcsetattr(STDIN_FILENO, TCSANOW, &orig_termios);
+    fcntl(STDIN_FILENO, F_SETFL, orig_fl);
   } 
   else 
   {

and got OMXPlayer back responding on the keys :-)

Tried the code also on Stretch and Jessie. Seems to do no harm.

@jazztickets : Please ask on the Arch Linux ARM forum where you posted this issue why this is necessary after the certain update. Hopefully someone can give more background info.

Hope the patch will work for you guys too.

[jazztickets]

Awesome, that worked. Thank you!

[MagicMuscleMan]

I had the same problem after upgrading from Debian Stretch to Debian testing (close to freeze to become Buster) with the Raspbian version of omxplayer and tested the patch posted two comments above and it solved the problem, so thanks a lot @jehutting!

As this might suggest that more recent distributions seem to be affected by this problem and Raspbian probably is affected, too, after they synchronize to the new Debian release, it probably makes sense to generally apply this patch to the repository.

For people who also want to build the Raspbian package on Debian Buster: The package dependencies are too strict for e.g. libboost*-dev and libssh*-dev. Just install the more recent versions of the dependencies and build the package with e.g. "debuild --no-sign --build=binary -d" to avoid checking the dependencies (after the usual apt source and apt build-dep).

[MagicMuscleMan]

So this patch has two additional effects:

1. The RPI demands 100% CPU instead of about 4% while playing a 1080p video
2. Instead of exiting after playing the omxplayer freezes showing the last frame and not reacting to any command anymore (killing is needed).

So this patch should not be applied until further investigation and fixing.

[jazztickets]

So this patch has two additional effects:

1. The RPI demands 100% CPU instead of about 4% while playing a 1080p video

2. Instead of exiting after playing the omxplayer freezes showing the last frame and not reacting to any command anymore (killing is needed).

So this patch should not be applied until further investigation and fixing.

1. On my rpi3, omxplayer takes about 3-4% when playing 1080p with the patch.
2. I've had problems with omxplayer randomly hanging after the video finishes regardless of this patch.

[jehutting]

Neither did I detected an increase of CPU usage that high :-)

Nevertheless it would be great to know the change in Debian causing the need of this patch (or for its validation).

@MagicMuscleMan Have a look at # 637. Seems to me thats your real problem.

[MagicMuscleMan]

@jehutting Thanks a lot for pointing to #637. The patch from you indeed fixes both(!?) problems.

To be honest, I am not sure if the high CPU load was due to the insertion of my debugging messages, after observing the non-quitting behavior for the MKV test files, which I added when quickly hacking a very similar patch as you did (although I missed the new return value and the check for EOF, so it did not work).

I guess I could test it, but it's probably pointless, as it now seems obvious that it makes sense to apply both patches. However, I have not yet understood why I reliably have a freezing omxplayer at the end of file with patch in #649 applied (without #637) but not without either patch, but I guess this does neither matter.

[MagicMuscleMan]

As to the root cause: As I observed it after a distribution upgrade, a lot of package upgrades could cause the need for the patch. As @jazztickets assumes, a glibc update might be the reason. If that's the case the last known good would be Debian package version 2.24-11+deb9u3 and first known bad would be 2.28-2.

I checked the dependencies and omxplayer (recursively) depends on 126 packages in Debian (with the Raspbian package). If it's really the libc upgrade I might be able to pin it down to the following packages:
libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg libidn2-0 libnih-dbus1 libnih1 locales
This would be quite some work, so I'd only do it if that would really help you.

[jehutting]

@MagicMuscleMan Thanks for looking for the root cause. I gave up after an comparison between the glibc-2.24 (as for the Raspbian version) and glibc-2.28, as for the ArchLinux version. Simply couldn't find -yeah but hey what should I look for :-)- something what makes sense to me! Perhaps a change in the kernel/firmware, I simply don't know.

It would help me just to have a better understanding of the root cause. But as you already said, that takes quite a lot of work. And as Raspbian probably will go to glibc-2.28 sometime and also probably will run into this, hopefully someone from the RPF kernel/firmware/packages group will have an answer. Go ahead if you want to look further but don't do it especially for me.

Issues 649 and 637 are for me two separate, independent issues. This issue is related to glibc (?) while 637 is more FFmpeg version related.

In 637 the ffmpeg code gets stuck into an endless loop due to omxplayer wrapper not returning AVERROR_EOF upon EOF. AVERROR_EOF is a condition to leave the loop, the faulty 0 (zero) not. As it is a real loop with no end or sleep or whatever, the CPU loops at full speed, so causing a 100% usage.

[popcornmix]

@jehutting could you PR your patch that hopefully resolves this issue?

[MagicMuscleMan]

Okay, so it was less work than I feared: I can confirm that the problem definitely is related to the libc upgrade:

• In the most recent version of libc version 2.27 in Debian (Debian version 2.27-8) keyboard input works without the proposed patch.
• In the first version of libc version 2.28 in Debian (Debian version 2.28-0experimental0) keyboard input does not work without the proposed patch.

Upgraded and downgraded Debian packages while bi-secting:
libc-bin, libc-dev-bin, libc-l10n, libc6, libc6-dbg

The glibc changelog to release 2.28 contains an item which sounds like it could be describing exactly the issue at hand:

All stdio functions now treat end-of-file as a sticky condition. If you
read from a file until EOF, and then the file is enlarged by another
process, you must call clearerr or another function with the same effect
(e.g. fseek, rewind) before you can read the additional data. This
corrects a longstanding C99 conformance bug. It is most likely to affect
programs that use stdio to read interactive input from a terminal.
(Bug #1190.)