Products > Networking & Wireless

IR remote receiver for Linux

<< < (8/8)

RoGeorge:
That's why I keep posting here my settings, so I won't have to discover all that again at the next install.

Though, now that LIRC v0.9.0 kind of works as expected, I'm tempted to remove it and try to install one more time the current version of LIRC v0.10+, the one with that uses the kernel LIRC features.  ::)

DiTBho:

--- Quote from: Nominal Animal on January 07, 2023, 07:48:07 pm ---Which one are you using?

--- End quote ---

vlc compiled with OSS on SBC#1, and with ALSA support on SBC#2
(PowerPC boards)

OSS is simpler for me to be implemented/hacked/fixed, at kernel side.

DiTBho:
I don't have an audio daemon running; OSS/ALSA at the kernel side, and nothing else in userspace, except mpg123 and VLC.

Nominal Animal:

--- Quote from: DiTBho ---[OSS and ALSA, vlc and mpg123]
--- End quote ---
We'll want to monitor processes having the /dev/dsp (OSS) or /dev/snd/pcm* (ALSA) devices open.  Since we are only interested in a few applications, we can do that by checking their /proc/PID/fd/ (using readlink()/readlinkat()), to determine which one is potentially playing audio.

This will fail for PulseAudio, because it will be the PulseAudio daemon that has the device open.

Could you please check what
    lsof /dev/dsp /dev/snd/pcm*
outputs when you have both vlc and mpg123 running, with a combination of one playing and one paused or stopped?
If only the active one is shown, then the X11 redirector will be very straightforward to implement.

(If you don't have lsof, you can do the same by finding out the PIDs of the two processes, and using ls -l /proc/PID/fd/ or stat -c '%N' /proc/PID/fd/*)

Also, please compare the output to wmctrl -l -p, especially the PIDs in the third column.  I am assuming the PIDs should match.

If you want the same without X, then feeding them the events is a bit more complicated.  The issue is that while we can easily determine the controlling terminal for them, we'd need to find a way to feed additional input to the master side of the terminal –– we can only easily determine the slave side.  If they only used terminal consoles (/dev/ttyN), we could use chvt, but for things like ssh'ing in and playing audio via mpg123, it gets tricky.
I suspect that it would then be easiest to configure the players to accept control from a local socket or named pipe also.

Navigation

[0] Message Index

[*] Previous page