LIRC killed or sees new usbdevice after suspend

[mascer]

Lirc or related components (no clue, 'm just a user), will not work after coming back from suspend mode, thus leaving me no (simple) option than to reboot the pc. I noticed after the suspend another lirc-device was made onder /dev/ besides the original one.

[David Siegel (djsiegel-deactivatedaccount)]

Please give more detail. Which version of ubuntu? Which device(s)? Steps to reproduce, with expected/actual behavior.

[mascer (masc-cyberelf)]

Ubuntu Desktop 9.04, 2.6.28-11-generic
--------------------------------------------------------------------------
While booting, dev lirc0 is created, infrared remote control works fine with for instance XBMC, suspend pc, boot up, remote control doesn't work. Besides lirc0 a lirc1 is created, need reboot to fix.
Standard reboot: remote control always works.
--------------------------------------------------------------------------
cat /var/log/syslog | grep lirc
kernel: [ 110.001225] lirc_dev: IR Remote Control driver registered, major 61
kernel: [ 110.006241] lirc_mceusb2: Philips eHome USB IR Transceiver and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.44 $
kernel: [ 110.006244] lirc_mceusb2: Daniel Melander <email address hidden>, Martin Blatter <email address hidden>
kernel: [ 110.270203] lirc_dev: lirc_register_plugin: sample_rate: 0
kernel: [ 110.274202] lirc_mceusb2[3]: BB+ Dongle(e.d) on usb5:3
kernel: [ 110.274248] usbcore: registered new interface driver lirc_mceusb2
--------------------------------------------------------------------------
sudo lsusb -v

Bus 005 Device 002: ID 0471:060c Philips
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x0471 Philips
  idProduct 0x060c
  bcdDevice 1.01
  iManufacturer 1
  iProduct 2 BB+ Dongle(e.d)
  iSerial 3 JIBA
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 255 Vendor Specific Class
      bInterfaceSubClass 255 Vendor Specific Subclass
      bInterfaceProtocol 255 Vendor Specific Protocol
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x01 EP 1 OUT
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0010 1x 16 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0010 1x 16 bytes
        bInterval 1
Device Status: 0x0000
  (Bus Powered)

[Martin Albisetti (beuno)]

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

[Jarno Suni (jarnos)]

Workaround is to run "/etc/init.d/lirc stop" in conjunction with suspend and "/etc/init.d/lirc start" in conjunction with resume.

See also http://en.opensuse.org/Pm-utils#Creating_your_own_hooks

[Ryan Steele (rgsteele)]

This was resolved in 0.8.6 which is the version shipped with Karmic. A fix is discussed at

http://sourceforge.net/mailarchive/message.php?msg_id=20090701222804.GA18821%40chapus.net

which can be viewed here:

http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_mceusb/lirc_mceusb.c?hideattic=0&r1=1.40&r2=1.41

The issue has been reported in a number of threads on Ubuntu Forums:
http://ubuntuforums.org/showthread.php?t=1055819
http://ubuntuforums.org/showthread.php?t=873482
http://ubuntuforums.org/showthread.php?t=909195

Might this be a candidate for an SRU?

[Shock (mmiron)]

This happens to me in Lucid while using a Streamzap PC Remote.

[cmcginty (casey-mcginty)]

See this link for a fix: http://wiki.xbmc.org/index.php?title=Ubuntu_Suspend_/_Wake#Fix_the_Lirc_Device_Increment_Bug

[Jarno Suni (jarnos)]

If you use irxevent or irexec, their respective daemons are killed in conjunction with stopping lirc. To automatically re-run these I could only run
DISPLAY=:0.0 su user -c "irxevent --daemon && irexec --daemon"
where "user" is your user name, in resume|thaw case after starting lirc daemon. I suppose it might not work well, if the user is not logged in or a different used the daemons.

[Jarno Suni (jarnos)]

Bug is still present in ubuntu 11.04.

Note that the recommended way to stop and start lirc in ubuntu nowdays is "sudo service lirc stop" and "sudo service lirc start", respectively.

The presented workaround is not ideal for irxevent and irexec daemons, since it may be that the user "user" is not at DISPLAY :0.0 (if it is not the first logged in user), user doing the suspend-resume might not be user "user", and it might be impossible to read the config from "user"'s home directory due to encryption. But in one user system it is ok.

[Jarod Wilson (jarod-wilsonet)]

For the love of all that is good, do NOT use that atrocious xbmc wiki script, that's Doing It Wrong on multiple levels, particularly for the very latest lirc bits.

[Jarod Wilson (jarod-wilsonet)]

For the record, suspend and resume with both the mceusb and streamzap drivers in 2.6.38 and up works just fine her, without stopping/starting lircd. Pretty sure cases where they aren't working are either old kernels and/or IR device drivers, or buggy usb chipset support.