[ubuntu-mythtv] Mythbuntu - Lirc Ideas
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
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
> >> 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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-mythtv