[ubuntu-mythtv] Mythbuntu - Lirc Ideas

Nick Fox nickj.fox at gmail.com
Tue Jul 17 02:21:05 BST 2007


On my end with the Python script to parse the Lircd.conf's out I am still
hacking away at it trying to learn the proper way to parse the config for
the best results. Any one that can provide a little help, I would greatly
welcome it.

-Nick

On 7/16/07, Mario Limonciello <superm1 at ubuntu.com> wrote:
>
> Alright, some more updates regarding the lirc situation, including some
> interim fixes.  See responses below:
>
> Dave Walker wrote:
> > On Wed, 2007-07-11 at 02:43 -0500, Mario Limonciello wrote:
> >
> > lirc.hwdb is entirely new to me, i'll have to read up on it.  If it
> > makes integration easier, Great!
> >
> lirc.hwdb is a very convenient database that is shipped now.  It indexes
> all remotes and drivers in a very easy to parse semicolon delimited
> file.  In order to push changes into ubuntu and mythbuntu, I plan to add
> some debconf magic for configuring a single remote.  (This will assume
> the case of multiple remotes to be an "advanced" option that has to be
> done by manual hacking at the files).  Debconf should be able to parse
> that file, and provide the user with a fairly lengthy list of options
> for remotes then.
> >
> > Considering a kernel upgrade is normally followed by a reboot, an if
> > statement comparing the kernel from the previous boot (uname -r > file)
> > to current `uname -r`.  If they differ then the module can be rebuilt
> > fairly easily.  This could be added to upstart very easily.
> >
> > I agree it's not the cleanest solution, but it's practical, and easily
> > implementable and short work until better kernel support is available.
> >
> >
> I came up with a much cleaner solution for kernel integration.  Starting
> with Gutsy, a package called linux-ubuntu-modules is shipped on all
> gutsy machines.  This package includes all of the "extra" drivers that
> ubuntu ships with its kernels.  You'll see ndiswrapper, apparmor,
> squashfs, unionfs, intel wifi and a whole lot of other stuff in there.
>
> I updated the ubuntu lirc package to the latest release (0.8.2) and then
> cherry picked the source files out to make a kernel patch.  Now, all
> Ubuntu gutsy boxes will have those kernel modules.  All of the usb ones
> should hotplug.
>
> A later expansion on this I forsee is shipping a udev rule that will
> restart lircd upon plugging in / booting with plugged in or unplugging
> any of the usb modules.  I'm not sure how powerful udev is for this sort
> of thing (any udev hackers subscribed ?).  I see it most definitely a
> step in the right direction and worth investigating.
> >
> > Lircrc config file should be no problem, and would certainly aid
> > development if standardised to a single Lircrc.
> >
> > lircd.conf's - These are available on lirc's site
> > ( http://lirc.sourceforge.net/remotes/ ) - but they are dreadfully
> > non-standard (ie Rec & Record, Vol+ & VolUP etc).  So these would need
> > to be standardised - at least for the commonly used mythtv remotes.
> >
> All lircd.conf's should be in /usr/share/lirc/remotes afaik.  Within
> that debconf, I plan to write out a new lircd.conf in /etc/lirc based
> upon the remote you choose.  How exactly this will be worked out yet I
> don't know.
>
>
> Michael Haas wrote:
> > That sounds great. Does it really cover all hardware supported by LIRC
> > including all their pre-made lircd.conf files?
> I think it does.  Obviously, anything custom written won't be there -
> but this is the exact reason you want to submit it upstream!  Anything
> that is added upstream will show up delayed in ubuntu releases, but a
> patch can easily be added to our packages in the meanwhile.
> >
> >> The new way the GUI works, is by parsing this file for that
> information.
> >>
> >> Considering a kernel upgrade is normally followed by a reboot, an if
> >> statement comparing the kernel from the previous boot (uname -r > file)
> >> to current `uname -r`.  If they differ then the module can be rebuilt
> >> fairly easily.  This could be added to upstart very easily.
> >>
> >> I agree it's not the cleanest solution, but it's practical, and easily
> >> implementable and short work until better kernel support is available.
> >>
> See above :)
> >>
> >
> >>> 2) Lircrc config files.
> >>> The official lirc website doesn't ship these, but expects the end user
> >>> to sort it out instead.  Generating one for each lircd.conf would be
> >>> an
> >>> utter nightmare.  So any ideas how we can do such things on the fly?
> >>> It's not exactly a solution to just ship a few of them either.  It's
> >>> gotta be all or nothing.
> >>>
> >> Lircrc config file should be no problem, and would certainly aid
> >> development if standardised to a single Lircrc.
> >>
> >>
> > We could make a GUI where the user is presented with the most important
> > keys. For each key, they can press a button on their remote which would
> > be assigned to said key. I have a very ugly shell script that'll ask me
> > to enter a key and press a button on my remote. It's really easy to
> > create a lircrc that way.
> > A list of important keys can be obtained from keys.txt near the end of
> > the file. Of course, it should be possible for the user to enter
> > additional keys or have a two sets of keys: very important ones and less
> > important ones.
> Well I like this idea as a supplement for the control centre.  I don't
> think it fits well into the installer, because then that is a very time
> consuming process.  The idea for the installer is supposed to be very
> fast and not require lots of user intervention.
> >
> > Another approach: just assign random keys to the lircd.conf entries and
> > leave it to the user to assign keys in mythcontrols.
> >
> Oooh bad idea i think.  We want things "functional" out of the box - no
> requiring much end user intervention.
> > There was a patch <http://svn.mythtv.org/trac/ticket/757> that made
> > MythTV use lirc buttons directly, bypassing .lircrc. It's oudated, but I
> > really like that approach.
> >
> This is a shame that the patch is outdated.  That sounds like an awesome
> way to do things here.
> >
>
>
> There is lots of discussion on lirc-list lately about the
> standardization of the namespace for lircd.conf and lircrc.  At the
> going rate, I *really* don't anticipate it being ready for our release.
> We will have to work with the non standard namespace in the current
> lircd.conf to generate usable lircrcs.  I've been in contact with the
> author of the online lircrc / lircd configuration and got him to join in
> on the spec for the standardized namespace.  This should hopefully help
> for the long term solution with all of his experience in the matter.
>
> For the short term, Nick Fox is working on a python script that will
> parse the lircd.conf and attempt to make some sane guesses at generating
> a lircrc for the user.  I'm not sure on the progress of it.  Perhaps he
> can speak up in this thread a little to find out some more.
>
> The absolute fall back option will be to only support a limited set of
> remotes and ship preconfigured lircrcs for those remotes.  I really hope
> we don't have to resort to that, as I'm about 90% on the rest of the
> lirc code for ubiquity.
>
>
> --
> Ubuntu-mythtv mailing list
> Ubuntu-mythtv at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-mythtv
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-mythtv/attachments/20070716/1da96d27/attachment.htm 


More information about the Ubuntu-mythtv mailing list