More > JRiver Media Center 30 for Linux
JRiver Media Center 30.0.96 for Debian Buster (amd64, i386, arm64 and armhf)
a_yzelman:
--- Quote from: Awesome Donkey on May 10, 2023, 03:56:13 am ---JRiver only officially supports Debian (hence why .deb files are only available, there's no other packages for other distros/package managers) but it does work for other distros (Ubuntu, Mint, etc.). Generally you're on your own if any issues arise using MC on unofficially supported distros though. I've never tried to use MC on CentOS so your mileage will vary here.
--- End quote ---
Thanks, so "MC for Debian" it is then hahah
The sources though -- are they available? (Like are those embedded in the .deb packages or are those pre-compiled only?) If sources are available, I probably can get it to work for CentOS
JimH:
No source is available.
Awesome Donkey:
--- Quote from: a_yzelman on May 10, 2023, 04:16:36 am ---Thanks, so "MC for Debian" it is then hahah
The sources though -- are they available? (Like are those embedded in the .deb packages or are those pre-compiled only?) If sources are available, I probably can get it to work for CentOS
--- End quote ---
There's no need for that, another user has developed a script that can install MC on some unsupported Linux OSes, called installJRMC. And fortunately it should work on CentOS: https://yabb.jriver.com/interact/index.php/topic,134152.0.html
bob:
--- Quote from: djp on May 09, 2023, 10:50:52 pm ---Hmmmm. After diving down numerous rabbit holes trying to figure this out, it appears that what you've listed above are XFree86 keysymbols, that I suspect are generated by media keys on "fancy" keyboards that have media controls on them. Of course, MC also responds to more traditional keysymbols (number keys, cursor keys, etc).
As it turns out, the Media Center remote (the generic family of Windows Media Center remotes, of which the remote you sell is one) is supported in the Linux kernel, with no configuration necessary. That's the good news. The bad news is that the keysymbols generated by the Linux kernel are entirely different from the XFree86 keysymbols you llisted. There is a small overlap with standard keyboard keysymbols (e.g. the four cursor keys, which is why they worked with MC out of the box). The Linux MCE keysymbols are listed at:
https://github.com/torvalds/linux/blob/master/drivers/media/rc/keymaps/rc-rc6-mce.c
Since what you've listed doesn't include a lot of the video functionality of the remote (which *do* work well in the Windows version of MC, e.g. DVD menu, etc), keysymbols will need to be added to bring MC Linux functionality up to parity with MC Windows. Since additional keysymbols shouldn't conflict with the existing XFree86 keysymbols, I humbly suggest (beg?) that MC Linux add recognition of the Linux kernel xorg keysymbols. This would allow MC Linux to have full remote capabilities using a standard Linux install, vice needing to create some custom lircd driver. MC 31 maybe? :)
--- End quote ---
So I've done a bunch of testing on this.
I'm not seeing any mapping of the rc-rc6-mce codes to X keypresses.
As you say the arrow keys (and the home button) are mapped. The rest are not or are being consumed by the desktop.
When I run
ir-keytable -t
I see the presses of things like volume up and down but those are not getting into MC's main event loop where system keypresses are processed.
The cleanest solution would be to map those somehow.
There are probably other ways as well.
bob:
--- Quote from: bob on May 26, 2023, 01:44:16 pm ---So I've done a bunch of testing on this.
I'm not seeing any mapping of the rc-rc6-mce codes to X keypresses.
As you say the arrow keys (and the home button) are mapped. The rest are not or are being consumed by the desktop.
When I run
ir-keytable -t
I see the presses of things like volume up and down but those are not getting into MC's main event loop where system keypresses are processed.
The cleanest solution would be to map those somehow.
There are probably other ways as well.
--- End quote ---
Did a bunch more testing.
Most of the rc6 keys on my Bullseye system are passed through. A few are annoyingly intercepted by the display manager.
That should be controllable but it's difficult to figure out where. A quick web search shows this to be a common linux issue.
Some display managers are worse than others. GDM3 seems the least intrusive that I've tested so far.
I don't see a clean way of fixing this without writing some code to get this at a lower level, probably using libeventd
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version