[Hardy] Lirc devinput (linux-input-layer) broken

Attaching lircd.conf

Hi Ari:
Given that it can't grab a lock on the device, this probably is because the hald-addon-input service has the tight grip on it.

Perusing the man page for hal, I don't see an easy way to turn this off. If you find a scriptable way to do so, we'd be glad to adapt.

Mario Limonciello schrieb:
> Hi Ari:
> Given that it can't grab a lock on the device, this probably is because the hald-addon-input service has the tight grip on it.
>
> Perusing the man page for hal, I don't see an easy way to turn this off.
> If you find a scriptable way to do so, we'd be glad to adapt.
>
> ** Changed in: lirc (Ubuntu)
> Importance: Undecided => Wishlist
> Status: New => Incomplete
>
>
Mario,

it's possible to tell HAL to ignore certain devices. Here's what we do
to tell HAL to ignore network interfaces (found on Cardoe's blog):

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="net.interface" exists="true">
<merge key="info.ignore" type="bool">true</merge>
</match>
</device>
</deviceinfo>

That file goes into usr/share/hal/fdi/preprobe/20thirdparty/. Maybe we
can do something similar for remotes, eg by expanding the hwdb to
contain a field which triggers a remote-specific HAL rule.. Or at least
document the ability to ignore devices somewhere.

I'm surprised. Are you aware of what could have changed with respect to Gutsy / 2.6.22 and previous kernels/hald's?

This remote has been working perfectly on linux for a couple of years... SAA7134-based boards are very popular out there.

A few questions, Is there a reason why LIRC's has to lock the device?
Should I open a bug against LIRC?
Do you think all 2.6.24-based distros will have this same problem?

I'm not a programmer but I'm willing to help / test / investigate as much as I can.

Thanks

Michael,

Can you put together a patch to tell hald-addon-input service to ignore this
for Ari to try?

Thanks

On Mon, Mar 24, 2008 at 9:34 AM, laga <email address hidden> wrote:

> Mario Limonciello schrieb:
> > Hi Ari:
> > Given that it can't grab a lock on the device, this probably is because
> the hald-addon-input service has the tight grip on it.
> >
> > Perusing the man page for hal, I don't see an easy way to turn this off.
> > If you find a scriptable way to do so, we'd be glad to adapt.
> >
> > ** Changed in: lirc (Ubuntu)
> > Importance: Undecided => Wishlist
> > Status: New => Incomplete
> >
> >
> Mario,
>
> it's possible to tell HAL to ignore certain devices. Here's what we do
> to tell HAL to ignore network interfaces (found on Cardoe's blog):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <deviceinfo version="0.2">
> <device>
> <match key="net.interface" exists="true">
> <merge key="info.ignore" type="bool">true</merge>
> </match>
> </device>
> </deviceinfo>
>
>
> That file goes into usr/share/hal/fdi/preprobe/20thirdparty/. Maybe we
> can do something similar for remotes, eg by expanding the hwdb to
> contain a field which triggers a remote-specific HAL rule.. Or at least
> document the ability to ignore devices somewhere.
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Attached the output of lshal, I guess it may help build the filter. The device in question is the infrared part of the saa7134, it shows up in the attachment.

Thanks!

Any chance to post at least some guidelines on how to implement this? I can try them out.
It would be a pitty to have 8.04 ship with lirc broken for many tv card tuner users.

Yes, I know I am way too lazy.

So after a little research I came up with a workaround and now my remote is back alive.

Following laga's suggestion, you need to put the attached "remote.fdi" file in /usr/share/hal/fdi/preprobe/20thirdparty/

Also you need to modify the file to match your remote. In the line that reads:

<match key="info.product" string="saa7134 IR (Compro VideoMate TV">

...replace the string content with the string corresponding to your device (mine is a Compro videomate card).
You can find the proper string to put there by doing:

lshal > ~/hal-output.txt

gedit ~/hal-output.txt

...and then search for "saa7134 IR". To confirm, under the same key you should see in hal's output a line that looks like
input.device = '/dev/input/event6'
(your event number may be different). That was the problem, HAL was locking that device that LIRC needed to use.

So when this remote is selected, what should the option be then? Drop that file in there and modify the FDI? yuck...

I wonder if inputlirc will be able to gain exclusive access to your device. If it does, then maybe lirc is broken.

* sudo aptitude install inputlirc

* Then modify /etc/default/inputlirc to look like this:

# Options to be passed to inputlirc.
EVENTS="/dev/input/event6"
OPTIONS="-g -m 0"

It's possible you will have to remove the quotes from the OPTIONS line, but try with quotes first.

* sudo /etc/init.d/inputlirc restart

Does irw work out? Does inputlirc capture all events?

@Mario: yes, for saa7134 -based cards, the .fdi file is needed.

The problem in the file is that I match the whole info.product string, so it works only for my particular card brand.

It would somewhat more generic to just match the "saa7134 IR" substring, like this:

<match key="info.product" contains_ncase="saa7134 ir">

@laga: following your instructions, the stopping lirc and starting inputlirc:

ariel@nahuatl:~$ sudo /etc/init.d/lirc stop
 * Stopping remote control daemon(s): LIRC [ OK ]
ariel@nahuatl:~$ sudo /etc/init.d/inputlirc restart
Restarting inputlirc configuration
No /usr/sbin/inputlircd found running; none killed.
ariel@nahuatl:~$ irw
160 0 KEY_OK event6
9 0 KEY_8 event6
6 0 KEY_5 event6
b 0 KEY_0 event6
a4 0 KEY_PLAYPAUSE event6

it works. but this is with the remote.fdi blacklist installed. Not sure if you mean I have to remove it first?

Ari schrieb:

> it works. but this is with the remote.fdi blacklist installed. Not sure
> if you mean I have to remove it first?
>

Yeah, please remove it. A reboot might be good afterwards to get the
system back into a known state.

With the .fdi file removed, inputlirc no longer works, here's the output:

Starting inputlirc
Failed to grab /dev/input/event6: Device or resource busy
Unable to open any event device!

ariel@nahuatl:~$ irw
connect: Connection refused
ariel@nahuatl:~$

Also, I've changed my .fdi rule for a more generic one that should work with other brands of SAA7134-based cards. This is the xml content:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
<device>
 <match key="info.product" contains_ncase="saa7134 ir">
  <merge key="info.ignore" type="bool">true</merge>
 </match>
</device>
</deviceinfo>

...which is working fine as well.

cheers

Ari:
This bug is about to expire. Any updates on what should be done?

Mario, the fix for this is having HAL bypass the saa7134 infrared port. The most flexible way to do this is the adding and .fdi file ("remote.fdi" file in /usr/share/hal/fdi/preprobe/20thirdparty/)

This is the content:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
<device>
 <match key="info.product" contains_ncase="saa7134 ir">
  <merge key="info.ignore" type="bool">true</merge>
 </match>
</device>
</deviceinfo>

... otherwise, remote controls for this popular cards will just not work with LIRC.

Ari:
So are there negative side effects to dropping that file in place with all
LIRC installs, or should it only be enabled on a case by case basis?

On Wed, Aug 13, 2008 at 23:52, Ari <email address hidden> wrote:

> Mario, the fix for this is having HAL bypass the saa7134 infrared port.
> The most flexible way to do this is the adding and .fdi file
> ("remote.fdi" file in /usr/share/hal/fdi/preprobe/20thirdparty/)
>
> This is the content:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <deviceinfo version="0.2">
> <device>
> <match key="info.product" contains_ncase="saa7134 ir">
> <merge key="info.ignore" type="bool">true</merge>
> </match>
> </device>
> </deviceinfo>
>
>
> ... otherwise, remote controls for this popular cards will just not work
> with LIRC.
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Hi Mario, I don't think there are negative side effects to this; I am matching specifically this:

contains_ncase="saa7134 ir"

which is the infrared function of the chipset, which is bound to make LIRC fail if we don't do this.

If people install lirc, I would have this added automatically to the blacklist. These days there are a few new easy configuration tools for remotes based on lircs so people with legacy HW will run into this problem.

The use of blacklisting stuff from HAL has been suggested by laga and is used in other cases as well.

Thanks,
Ari

Ari:

OK last question for sanities sake. Is there a usecase for this IR device
outside of LIRC? Does it act like normal key presses otherwise? Reason I
ask is because lirc gets installed by default on all mythbuntu installs and
can't be removed without breaking a lot of other stuff. Do you see it as
possible that someone would want to be using a media centre without LIRC but
native support on these devices.

On Thu, Aug 14, 2008 at 09:32, Ari <email address hidden> wrote:

> Hi Mario, I don't think there are negative side effects to this; I am
> matching specifically this:
>
> contains_ncase="saa7134 ir"
>
> which is the infrared function of the chipset, which is bound to make
> LIRC fail if we don't do this.
>
> If people install lirc, I would have this added automatically to the
> blacklist. These days there are a few new easy configuration tools for
> remotes based on lircs so people with legacy HW will run into this
> problem.
>
> The use of blacklisting stuff from HAL has been suggested by laga and is
> used in other cases as well.
>
> Thanks,
> Ari
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Mario: without LIRC, the remote acts as normal keypresses (like if it were the PC's keyboard), i.e. if you open a terminal and press the "1" key, you see a "1" char entered in the terminal, which is essentially useless.

I've run mythTV in the past and I now run Elisa and both work fine (and require) their LIRC plugin in order to work properly with this remote.

As far as I have explored linux media center solutions (and I did explore this) I haven't run into any case in which you would have remote control support without LIRC. The use of linux-input-layer functionality is pretty much useless without a proper way to communicating to the Media Center app that is distinguishable from "keyboard entries to the focused application window", which is what LIRC provides in this case.

linux-input-layer just helps LIRC get the remote events from whatever infrared chipset without having to deal with the chipset itself.

As far as I know mythbuntu uses MythTV which uses LIRC so there should be no problems on that end, on the contrary, more users will get the remote working out of the box.

Ari

Spectacular explanation. Exactly what I was looking to hear before making
changes to this. In a future lirc upload i'll install your FDI file by
default then.

Regards

On Thu, Aug 14, 2008 at 13:59, Ari <email address hidden> wrote:

> Mario: without LIRC, the remote acts as normal keypresses (like if it
> were the PC's keyboard), i.e. if you open a terminal and press the "1"
> key, you see a "1" char entered in the terminal, which is essentially
> useless.
>
> I've run mythTV in the past and I now run Elisa and both work fine (and
> require) their LIRC plugin in order to work properly with this remote.
>
> As far as I have explored linux media center solutions (and I did
> explore this) I haven't run into any case in which you would have remote
> control support without LIRC. The use of linux-input-layer functionality
> is pretty much useless without a proper way to communicating to the
> Media Center app that is distinguishable from "keyboard entries to the
> focused application window", which is what LIRC provides in this case.
>
> linux-input-layer just helps LIRC get the remote events from whatever
> infrared chipset without having to deal with the chipset itself.
>
> As far as I know mythbuntu uses MythTV which uses LIRC so there should
> be no problems on that end, on the contrary, more users will get the
> remote working out of the box.
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Removing incomplete so bug doesn't expire

Thanks for all the triaging and development of this FDI file.

Fixed in bzr #26.

This bug was fixed in the package lirc - 0.8.3-0ubuntu2

---------------
lirc (0.8.3-0ubuntu2) intrepid; urgency=low

  * debian/patches/25_upstream_2.6.26.patch:
    - Fix lirc-modules-source compilation on 2.6.26 by pulling some
      patches from CVS (LP: #247233)
  * debian/rules:
    - Install original modules back into proper location for
      intrepid kernel (LP: #242216)
  * debian/patches/37_msi_tv_anywhere.dpatch:
    - Create patch for supporting MSI TV @anywhere remote. (LP: #241830)
  * debian/lirc.postinst:
    - Correct path to look for module in Intrepid.
    - Ask for a path when using dvico remotes. (LP: #238032)
    - Don't accidentally overwrite lircd.conf and hardware.conf
      when things haven't really changed at all. (LP: #206609)
  * debian/lirc.init.d:
    - Don't allow udev to put us into endless spinning loops. Instead
      pray that module hotplugging worked for all things USB. (LP: #269743)
  * debian/lirc.fdi:
    - Include this FDI file to prevent in kernel support for the
      saa7134 when LIRC is installed. (LP: #204960, #164627)
  * debian/rules:
    - Install FDI file.
  * debian/lirc.install:
    - List FDI file.
  * debian/patches/22_hauppauge_novat_500.dpatch:
    - Adapt to include alternative numeric keys. (LP: #224080)
  * debian/patches/25_upstream_2.6.27.dpatch:
    - Update to content that is currently sitting in Ubuntu GIT
      tree.

 -- Mario Limonciello <email address hidden> Wed, 24 Sep 2008 12:02:17 -0500

Hi,

I have an Avermedia M115 mini-pci-e TV card on an Acer Aspire 5652. The card has an infrared device which is exactly working as described in the original bug report. I can get some of the keys like 1-2-3-OK etc. on the login screen, terminal window etc.

System is a Mythbuntu 8.10 beta 1 updated to latest packages as of Oct 24, 2008.

Nevertheless, most of the keys on the IR remote don't work, I receive such messages in dmesg:
[100603.834359] atkbd.c: Unknown key pressed (translated set 2, code 0x9e on isa0060/serio0).
[100603.834375] atkbd.c: Use 'setkeycodes e01e <keycode>' to make it known.

I also see that my lshal reports something else, so the HAL solution here does not work. Here's the interesting part below, also stange that I have not one but two devices, event7 and event8 on the video bus:

 udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_1'
 info.addons.singleton = {'hald-addon-input'} (string list)
   info.callouts.add = {'debian-setup-keyboard'} (string list)
   info.capabilities = {'input', 'input.keys', 'button'} (string list)
 info.category = 'input' (string)
   info.parent = '/org/freedesktop/Hal/devices/computer' (string)
   info.product = 'Video Bus' (string)
   info.subsystem = 'input' (string)
   info.udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_1' (string)
   input.device = '/dev/input/event8' (string)
   input.product = 'Video Bus' (string)
   input.x11_driver = 'evdev' (string)
 input.xkb.layout = 'us' (string)
   input.xkb.model = 'pc105' (string)
   input.xkb.rules = 'evdev' (string)
   linux.device_file = '/dev/input/event8' (string)
   linux.hotplug_type = 2 (0x2) (int)
   linux.subsystem = 'input' (string)
   linux.sysfs_path = '/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:06/input/input8/event8' (string)

 udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_0'
   info.addons.singleton = {'hald-addon-input'} (string list)
   info.callouts.add = {'debian-setup-keyboard'} (string list)
   info.capabilities = {'input', 'input.keys', 'button'} (string list)
   info.category = 'input' (string)
   info.parent = '/org/freedesktop/Hal/devices/computer' (string)
   info.product = 'Video Bus' (string)
   info.subsystem = 'input' (string)
   info.udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_0' (string)
   input.device = '/dev/input/event7' (string)
   input.product = 'Video Bus' (string)
   input.x11_driver = 'evdev' (string)
   input.xkb.layout = 'us' (string)
   input.xkb.model = 'pc105' (string)
   input.xkb.rules = 'evdev' (string)
   linux.device_file = '/dev/input/event7' (string)
   linux.hotplug_type = 2 (0x2) (int)
   linux.subsystem = 'input' (string)
   linux.sysfs_path = '/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/device:02/input/input7/event7' (string)

Changing the /usr/share/hal/fdi/preprobe/20thirdparty/lirc.fdi file contents to match the upper mentioned device silences the compaints of lircd and inputlircd about the exclusive access, but does not make the remote work.

cat /dev/input/event7 and cat /dev/input/event8 and irw are always silent, even for the already recognized keys..,

I guess the...

I don't know if we need another bug report for the problem...

Hi Fastguy, this bug & workaround is specifically for SAA7134-based cards, and it is only about LIRC being unable to grab the device, because HAL did it earlier.

In any case, whatever the chipset you have, you may be having a driver problem, or a lirc misconfig (since you seem to have the basics working). Really this does not seem related to this bug. Suggest you open a new bug, or better, first ask around in #lirc and in the forums.

Hi Ari,

Thanks for your response. This M115 is in fact a card based on SAA7134 with an additional cx2028 tuner chip, but it doesn't register it's IR as described in the workaround. It's running with the latest kernel (2.6.27) and as card number 138 for the saa7134 module.

But I'll try as you suggested. Thanks for the pointer, I started to believe that it's a driver problem at first stage.

Fastguy

bzr revno 45

This bug was fixed in the package lirc - 0.8.4a-0ubuntu1

---------------
lirc (0.8.4a-0ubuntu1) jaunty; urgency=low

  * New upstream version.
  * Drop no longer necessary patches:
    - 03_extra_files
    - 25_upstream_2.6.27
    - 27_multiple_include
  * Update patches for new version:
    - 12_pvr150_transmit_support
    - 16_lirc_gpio
    - 26_transmitter_lircd.conf
    - 28_irrecord_resume_support
  * New patches:
    - 38_encore_enltv.dpatch (LP: #274087)
  * debian/lirc.fdi:
    - Update FDI file to match a few more remotes reported
      on bugs that work when keyed. (LP: #164627, #204960, #279472)
  * debian/control:
    - Update Recommends for lirc-modules-source
  * debian/lirc.preinst:
    - Remove old calls that will no longer be encountered in package
      upgrades.
  * Merge some packaging changes from Debian. They hadn't done a
    release in a long time, so this will at least get us closer to their
    packaging for an overarching goal of being in sync.
    - Sync'ed changes:
      + debian/compat
      + README.Debian
      + debian/copyright
      + debian/doc-base.lirc
      + debian/liblircclient-dev.install
      + debian/lirc-modules-source.postrm
      + debian/lirc.postrm
      + debian/po
      + debian/lirc-svga.install
      + debian/lirc-svga.links
      + drop debian/lirc.config.in
      + drop debian/lirc.config.md5sum
      + drop debian/lirc.modules
    - Merge debian/control, remaining changes:
      + We don't share same VCS
      + We recommend udev
      + Our lirc-modules-source uses DKMS
    - Merge debian/rules, remaining changes:
      + DKMS support
    - Merge debian/liblircclient0.pc, remaining changes:
      + Version number we have is higher
    - Merge debian/lirc.install, remaining changes:
      + We install udev rules
      + We install an FDI file
    - Merge debian/lirc.templates, remaining changes:
      + Some of our keys are named differently because we differentiate
        between a remote and a transmitter device.
      + We've got some extra keys for details of devices.
    - Merge debian/lirc.init.d, remaining changes:
      + We've pretty much entirely revamped the file. Our deltas will
        need to be submitted incrementally to Debian.
    - Merge debian/lirc.postinst, remaining changes:
      + We've pretty much entirely revamped the file. Our deltas will
        need to be submitted incrementally to Debian.
    - Merge debian/rules, remaining changes:
      + We install a udev rule
      + We install an FDI file
      + We install DKMS support
      + We install transmitter lircd.conf's
      + We Install the remote and transmitter hwdb explicitly
    - Merge patches that we took from debian for 0.8.4 support:
      + debian/patches/02_Makefile.in
      + debian/patches/04_man_pages

lirc (0.8.3-3) unstable; urgency=low

  * update swedish translation, thanks to Martin Bagge <email address hidden>
    (Closes: #491772).
  * add italian debconf translation, thanks to Vincenzo Campanella
    <email address hidden>.
  * silence LIRC_MODE_LIRCCODE log message, as it is not rate limited and
    tends to overflow syslog in case IR receivers get removed without
    stopping lirc or remo...

The fix in 0.8.4a-0ubuntu1 is not complete. Exceptions are made for HAL to ignore a list of known receivers, but there are surely more to come. A permanent fix can only be made upstream by making HAL able to identify dev/input IR-receivers in general, or integrate lircd to take events from dev/input via HAL/DBUS.

Per Heldal wrote:
> The fix in 0.8.4a-0ubuntu1 is not complete. Exceptions are made for HAL
> to ignore a list of known receivers, but there are surely more to come.
> A permanent fix can only be made upstream by making HAL able to identify
> dev/input IR-receivers in general, or integrate lircd to take events
> from dev/input via HAL/DBUS.
>
AFAIK, there is work going on for porting all LIRC drivers over to an input
driven interface that is customizable. This will alleviate the necessity
(likely) for lircd. Right now this is a good workaround though. As people see
more devices, adding them to this list will help at least.

--
Mario Limonciello
<email address hidden>

I experienced very nearly the same thing as above with my DViCO FusionHDTV5 RT Gold tuner card. This card has the product info string 'i2c IR (FusionHDTV)', as reported by hal-device. The patch provided below prevents hal from grabbing /dev/input/event6, and treating is an linux-input-layer device, allowing lirc to access it.

Michael:
Please add that information to another bug. It will be lost on this bug as
this bug has already been marked "closed"

On Sun, Jan 25, 2009 at 04:11, Michael Rimbert <email address hidden> wrote:

> I experienced very nearly the same thing as above with my DViCO
> FusionHDTV5 RT Gold tuner card. This card has the product info string
> 'i2c IR (FusionHDTV)', as reported by hal-device. The patch provided
> below prevents hal from grabbing /dev/input/event6, and treating is an
> linux-input-layer device, allowing lirc to access it.
>
> ** Attachment added: "Patch to lirc for hal to ignore FusionHDTV5 RT Gold
> i2c IR input"
>
> http://launchpadlibrarian.net/21613807/lirc-DViCO_FusionHDTV5_RT_Gold.patch
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

I have this issue with a TechnoTrend C1500 DVB-C card
adding this to /usr/share/hal/fdi/preprobe/20thirdparty/lirc.vdi fixes it :

     <match key="info.product" contains_ncase="Budget-CI dvb ir receiver saa7146">
        <merge key="info.ignore" type="bool">true</merge>
     </match>

Mirak:

Please open another bug to add that information ok?

Thanks

On Sun, Feb 15, 2009 at 12:12, mirak <email address hidden> wrote:

> I have this issue with a TechnoTrend C1500 DVB-C card
> adding this to /usr/share/hal/fdi/preprobe/20thirdparty/lirc.vdi fixes it
> :
>
> <match key="info.product" contains_ncase="Budget-CI dvb ir receiver
> saa7146">
> <merge key="info.ignore" type="bool">true</merge>
> </match>
>
> --
> [Hardy] Lirc devinput (linux-input-layer) broken
> https://bugs.launchpad.net/bugs/204960
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>
Sent from: Austin Texas United States.

This bug shouldn't be closed, I believe more interfaces can have this problem.

This bug shouldn't be closed, I believe more interfaces can have this problem, since mine is a Techno Trend C1500 that I got from second hand already 3 years ago.

ok mario if you think it's preferable, I don't saw your last answer

hy,

first of all, sorry about my english.

i've follow the steps to make my IR work . I have an saa7134 based tv card. now it worcks perfectly but if i want to use the IR i have to do

* sudo /etc/init.d/inputlirc restart

Is there any way to do this automaticaly?

Digital Everywhere's FireDTV has another such receiver, which should be included in that file.

<match key="info.product" contains_ncase="FireDTV remote control">
   <merge key="info.ignore" type="bool">true</merge>
</match>

I'm running Karmic. Relevant section in my HAL device list:

udi = '/org/freedesktop/Hal/devices/pci_11c1_5811_logicaldev_input'
  info.addons.singleton = {'hald-addon-input'} (string list)
  info.callouts.add = {'debian-setup-keyboard'} (string list)
  info.capabilities = {'input', 'input.keys', 'button'} (string list)
  info.category = 'input' (string)
  info.parent = '/org/freedesktop/Hal/devices/pci_11c1_5811' (string)
  info.product = 'FireDTV remote control' (string)
  info.subsystem = 'input' (string)
  info.udi = '/org/freedesktop/Hal/devices/pci_11c1_5811_logicaldev_input' (string)
  input.device = '/dev/input/event6' (string)
  input.originating_device = '/org/freedesktop/Hal/devices/pci_11c1_5811' (string)
  input.product = 'FireDTV remote control' (string)
  input.x11_driver = 'evdev' (string)
  input.xkb.layout = 'fi' (string)
  input.xkb.model = 'pc105' (string)
  input.xkb.rules = 'base' (string)
  input.xkb.variant = 'mac' (string)
  linux.device_file = '/dev/input/event6' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'input' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:10.0/0000:02:05.0/fw-host0/input/input8/event6' (string)

Really, this bug isn't solved properly, unless some more generic method is found than manually adding single devices to the HAL exception list. There should be an option for this when configuring lirc, or somwhere in input preferences. Or at least a warning while configuring Lirc, if nothing else!

Basically, this but is about configurinng hald, a daemon gone since long. Unless there is more input:_ can we close this bug?

closing