[mythtv-users] Remote control not working in MythWelcome after hibernate

[Eduard Huguet]

>
> Hello MythTV-users!
>
> As stated in the topic, the remote control for my Hauppauge Nova-T 500
> DVB-T
> card is not working in MythWelcome after resume from hibernate.
> I am using ACPI wakeup and as my system will not wake up from a complete
> power
> off, I hibernate the system instead. Waking up for scheduled recordings
> works
> fine, as well as going back to S4 sleep state after the desired period of
> idleness.
>
> The remote control used to be adressed as /dev/input/eventX where the X
> would
> vary after hibernation, thus causing it to be non functional (except the
> arrow keys, which by the way do work in MythWelcome too) in the frontend.
> I have solved this problem by creating a udev link called
> /dev/input/remote
> and pointing the /etc/lirc/hardware.conf to the link instead of the
> eventX.
>
> When I power on the Myth box, MythWelcome will instantly start the
> countdown
> to shut down again and pressing the OK button on the remote to start the
> frontend doesn't do a thing. I will have to press space or return on the
> keyboard (which I ultimately want to get rid off when the HTPC will move
> to
> the living room). Also the menu button on the remote will not bring up the
>
> menu. If I open it with M on the keyboard, the arrow keys on the remote
> will
> let me select the menu options though... In the frontend, the remote
> always
> works after hibernation.
>
> I think you get the point...
>
>
> I already changed the focus settings of XFCE, that did not help.
> If I launch irw in a ssh session while the MythBox is in MythWelcome, I
> can
> see every keypress.
>
>
> The facts that the arrow keys always work and ALL keys work after a cold
> boot/reboot make me assume that MythWelcome is addressing the remote
> control
> as /dev/input/eventX where the X only matches the remote before the system
>
> got hibernated the first time.
> Still, the only config file I found that mentions the remote as a device
> is /etc/lirc/hardware.conf.
>
>
> Now some info on my system:
>
> Asus P4B266-LM mainboard with a P4 1.8 GHz and 664 MB RAM
> GeForce 6200 256 MB NVidia Driver 100.14.11
> Hauppauge Nova-T 500 (set up as described in and config files for the
> remote
> from the wiki)
> MythBuntu 7.10, MythTV 0.20.2
>
> Rock on,
> Jan
>
> PS: This is my first post on a mailing list ever, be gentle... ;)
>
> PPS: Seems like KMail does not like Gmail or something. It seemed to me
> that
> the mail never made it to the list, so I resent it. If it now appears
> twice,
> I am truly sorry for that.
>


Hi,
    I have the same card as you (Nova T-500) and I usually have the same
issue. I suspect it's something related to the IR driver for this card,
which is not properly restoring after a suspend / resume cycle. My solution
was to add also 'lircd' and 'xdm' to the lists of services being stopped /
started on suspending, so both the LIRC daemon and whole X (and thus
MythFrontend) are restarted. In my case, restarting X was also a must, as
sometimes resuming didn't work fine always othewise.

Anyway, a final thought: your computer should wake up properly with ACPI
either from suspending or from powering off, or simply not work on either
case. I mean, both things are exactly the same from a pure hardware point of
view (suspending IS a full power off, it's just the kernel who saves /
restores the OS state).

So if ACPI wakeup is working from resume but not from power-off then it's
probably because your Linux is saving your "system" time into the BIOS when
powering off (most Linux do that by default), and your BIOS doesn't like
that (at least, mine doesn't like neither...).

You'll probably have to edit the /etc/init.d/clockd script (or whatever is
called in your distro) to save / restore the ACPI programmed time. Basically
you must something like this:

· search for the stop() function in /etc/init.d/clock script
· add this line in the beginning of the function:

ACPI=`cat /proc/acpi/alarm`

· and this one at the end of the function:

echo $ACPI > /proc/acpi/alarm

This should solve your issue.

Best regards,
  Eduard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080115/d652df94/attachment.htm