[mythtv-users] What major features are planned for 0.27?

jedi jedi at mishnet.org
Mon Nov 26 18:39:23 UTC 2012


On Sat, Nov 24, 2012 at 03:57:22PM +0000, Mark Greenwood wrote:
> On Saturday 24 Nov 2012 10:19:01 Michael T. Dean wrote:
> > On 11/24/2012 08:48 AM, Mark Greenwood wrote:
> > > On Friday 23 Nov 2012 22:37:34 Michael T. Dean wrote:
> > >> On 11/23/2012 10:02 PM, Preston Crow wrote:
> > >>> On 11/23/12 21:58, Michael T. Dean wrote:
> > >>>> On 11/21/2012 10:10 AM, Mark Greenwood wrote:
> > >>>>> One thing that could be contributed though, and I don't know how
> > >>>>> easy/hard this would be but with pointers I'd be prepared to look into
> > >>>>> it, would be to make mythtv understand the multimedia keycodes sent by
> > >>>>> IR remotes that are handled by the kernel's devinput interface (eg
> > >>>>> KEY_PLAY, KEY_FASTFORWARD etc). Xbmc understands these natively and
> > >>>>> means I didn't have to go through the trauma of setting up lirc.
> > >>>> Pretty sure you just need to use mythfrontend's Edit Keys to set what
> > >>>> you want each to do.
> > >>> Yes, but the point is that this is something that should just work
> > >>> without doing anything.  There should be good default settings for all
> > >>> those keycodes already.  (This hasn't impacted me, but it sounds like
> > >>> a simple and obvious improvement.)
> > >> Of course, you do understand that there are both TV Playback|PLAY, and
> > >> TV Playback|PAUSE (which is toggle play/pause).
> > >>
> > >> It's neither simple, nor obvious, to me which one the play button on
> > >> Mark's remote should send...  And the play button is the simplest of the
> > >> multimedia ones...  Does fast forward do a Global|RIGHT or TV
> > >> Playback|SEEKFFWD or TV Playback|FFWDSTICKY or even TV Playback|JUMPFFWD?
> > > Actually it's only complicated because mythtv makes things complicated by having too many choices. XBMC seems to take a much more pragmatic view. In a logical, simple world the Play key starts playback, the Pause key pauses and unpauses, and the Fast Forward button fast forwards - just like on any off-the-shelf PVR system made in the last 30 years, because people understand that. It's obvious what the default settings should be, and people can still customize if they want to.
> > >
> > > The keys on my remote are already mapped by the kernel's ir-keytable interface - no need for LIRC. The mapping means that whatever your remote, the kernel sends something sensible -  KEY_PLAY when you press Play, KEY_FASTFORWARD for FF etc, so assigning them to functions the average PVR should have should be simple. Of course there will alays be some that need tweaking by the user, but a sensible set of defaults that would work with any remote of this type wouldn't be hard to come up with. LIRC is pretty old hat these days, the latest kernel has mappings for most of the common remotes already.
> > >
> > 
> > Yes, and anyone who uses the built-in-to-the-kernel key mappings for the 
> > remote buttons then ends up changing the key bindings in /every/ single 
> > application on their system so that the remote button that sends an A 
> > (or KEY_A) does the appropriate thing in that application*** (and has to 
> > learn their custom keymaps/can't discuss default bindings/...).  And, to 
> > make it worse, for users with multiple frontends, using kernel key 
> > mappings for the remote means customizing every single mythfrontend on 
> > every single system (not to mention also customizing xine, mplayer, vlc, 
> > xmms, xmms2, audacious, ...
> > 
> 
> But that's exactly the point. The remote buttons don't send standard keyboard keys. The in-kernel mappings send KEY_PLAY, KEY_PAUSE, KEY_STOP, etc and not KEY_P, KEY_S, KEY_A etc. So there *is* a standard set of keys for a remote, just as there is for a keyboard. The point is that mythtv doesn't appear to recognise these 'multimedia' keys. If it did, most remotes would 'just work' without LIRC and without any special configuration. Plenty of applications now support these keys in addition to the old 'standard' keyboard shortcuts.

    Having conventions for what goes into /etc/lirc is sufficient. You don't
have to implement a system that is LESS configurable and LESS in the control
of the end user just to have something that is more manageable to a certain
class of user.

    Having something like LIRC in the middle allows for a level of abstraction
and the ability to easily support both standardization and legacy users.

    The latest *buntu can knarfle the button codes and I can unkarfle them to
what I have been using for 6 years already. Apps don't need to care. Upstream
developers for those apps don't need to care.

[deltia]


More information about the mythtv-users mailing list