Lirc unable to initialise IR portion of Mplay Blast VFD (Zalman HD-135 case)

Bug #574432 reported by thecapsaicinkid
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux-meta-lts-trusty (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: lirc

Re-written for clarity;

The 'VL-System Mplay Blast' combined VFD/IR unit in the Zalman HD-135 case is functional with Lirc using the HD44780 driver with seemingly one caveat. Lirc seems to be unable to physically initialise the IR portion of the unit after it is powered up before it can be used.

The only way to do this is to boot into a Windows VM (with the display's usb device attached), run the Windows Mplay Home-Centre software supplied with the case which initialises the IR portion of the display (the red led on the display goes unlit) and then closing the VM (not shutting it down as this un-initialises it again) Lirc is then able to use the IR device as intended. If power is removed from the display (i.e physically unplugging the machine) then this process will need to be performed again, the display starts with the IR led lit (uninitialised) and doesn't go out on boot until the Windows software is run.

Running Lcdproc (possibly with certain options, I've read maybe relating to enabling the keypad) seemingly used to be able to send the right initialisation commands to the unit when it initialised the lcd portion of the unit so Lirc would function without having to go through the Windows software step above. Unfortunately now for one reason or another this doesn't seem to work any more.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: lirc 0.8.6-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon May 3 13:23:26 2010
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: lirc

Revision history for this message
thecapsaicinkid (thecapsaicinkid) wrote :
summary: - MPlay blast remote/VFD put in inconsistent state after reboot
+ Lirc unable to initialise IR portion of Mplay Blast VFD (Zalman HD-135
+ case)
description: updated
Revision history for this message
dsteinwe (dsteinwe) wrote :

In my case lcdproc does not display anything useful on the VFD. The problem started on a kernel update in Ubuntu 10.04 (from 2.6.32-24 to -25) and consists even in Ubuntu 10.10 (2.6.35-22).

Revision history for this message
Jonathan Brown (brown-jonathan) wrote :

I've found a workaround. At least it works for me and I honestly don't know why it does. As mentioned in the description it says that the only way to initialize the IR portion is by booting up a Windows VM and doing it from there. I've found; however, that all I have to do to get it working after booting up is to enter "screen /dev/ttyUSB0 9600" in the terminal. It will fail to open up a screen to the device but it appears to wake it up such that IR, as well as the VFD on the HD135 case, starts working. The 9600 part may be incorrect but it doesn't seem to matter as long as it wakes it up.

Taking this a step further I edited the /etc/rc.local file and added the "screen /dev/ttyUSB0 9600" line there so that it "initializes" it upon boot up.

Revision history for this message
Brian M. Abel (do7phin-hotmail) wrote : RE: [Bug 574432] Re: Lirc unable to initialise IR portion of Mplay Blast VFD (Zalman HD-135 case)
Download full text (3.3 KiB)

Awesome. Now I can look forward to messing with it some more. (I was able to replicate the virtualbox fix, but found it was too sloppy to be useful.) Thanks!! (although now I'm eyeing some of the gesture recognition software...)

   -Brian M. Abel

> Date: Sat, 30 Oct 2010 04:33:15 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 574432] Re: Lirc unable to initialise IR portion of Mplay Blast VFD (Zalman HD-135 case)
>
> I've found a workaround. At least it works for me and I honestly don't
> know why it does. As mentioned in the description it says that the only
> way to initialize the IR portion is by booting up a Windows VM and doing
> it from there. I've found; however, that all I have to do to get it
> working after booting up is to enter "screen /dev/ttyUSB0 9600" in the
> terminal. It will fail to open up a screen to the device but it appears
> to wake it up such that IR, as well as the VFD on the HD135 case, starts
> working. The 9600 part may be incorrect but it doesn't seem to matter as
> long as it wakes it up.
>
> Taking this a step further I edited the /etc/rc.local file and added the
> "screen /dev/ttyUSB0 9600" line there so that it "initializes" it upon
> boot up.
>
> --
> Lirc unable to initialise IR portion of Mplay Blast VFD (Zalman HD-135 case)
> https://bugs.launchpad.net/bugs/574432
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “lirc” package in Ubuntu: New
>
> Bug description:
> Binary package hint: lirc
>
> Re-written for clarity;
>
> The 'VL-System Mplay Blast' combined VFD/IR unit in the Zalman HD-135 case is functional with Lirc using the HD44780 driver with seemingly one caveat. Lirc seems to be unable to physically initialise the IR portion of the unit after it is powered up before it can be used.
>
> The only way to do this is to boot into a Windows VM (with the display's usb device attached), run the Windows Mplay Home-Centre software supplied with the case which initialises the IR portion of the display (the red led on the display goes unlit) and then closing the VM (not shutting it down as this un-initialises it again) Lirc is then able to use the IR device as intended. If power is removed from the display (i.e physically unplugging the machine) then this process will need to be performed again, the display starts with the IR led lit (uninitialised) and doesn't go out on boot until the Windows software is run.
>
> Running Lcdproc (possibly with certain options, I've read maybe relating to enabling the keypad) seemingly used to be able to send the right initialisation commands to the unit when it initialised the lcd portion of the unit so Lirc would function without having to go through the Windows software step above. Unfortunately now for one reason or another this doesn't seem to work any more.
>
>
>
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.04
> Package: lirc 0.8.6-0ubuntu4
> ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
> Uname: Linux 2.6.32-22-generic x86_64
> NonfreeKernelModules: nvidia
> Architecture: amd64
> Date: Mon May 3 13:23:26 2010
> ProcEnviron:
> LANG=en_GB.UT...

Read more...

Revision history for this message
Jonathan Brown (brown-jonathan) wrote :

It seems I kinda broke it the other day. After adding the command to the /etc/rc.local file it stopped working. I had also removed linux-modules-source. Anyway it's working again but I can't use the rc.local file to initialize it on boot up. So anytime i reboot I've gotta enter that command. I also edited my /etc/lirc/hardware.conf file. The changes I made are to the following lines:

REMOTE_DEVICE="/dev/ttyUSB0"
LOAD_MODULES="lirc_dev lirc_mplay"

You can see more details here: http://ubuntuforums.org/showthread.php?t=1596778

Revision history for this message
dsteinwe (dsteinwe) wrote :

I have found the debug option for the kernel module "ftdi_sio". This module is responsible to communicate with the Mplay Blast. I have add the logs from Ubuntu 10.04 and 10.10. They differ heavily. I looks like a bug in the kernel in Ubuntu 10.10.

Revision history for this message
dsteinwe (dsteinwe) wrote :

I have written a test application to figure out the problem with the Mplay Blast. It seems so that the data won't be really flushed to the physical device. An explicit flush doesn't anything. But if I disconnect and re-connect to the serial port the data going to be transmitted. Maybe a problem with a mutex or lock inside the kernel module.

Revision history for this message
Alec Leamas (leamas-alec) wrote :

Re-assigning to kernel, this is seemingly about kernel modules and mutexes..

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Revision history for this message
Alec Leamas (leamas-alec) wrote :

Probab,ly the kernel, put perhaps wrong version. Sorry. meda subsystem, though.

Changed in linux-meta-lts-trusty (Ubuntu):
status: New → Confirmed
affects: lirc (Ubuntu) → linux-meta-lts-trusty (Ubuntu)
Andy Whitcroft (apw)
Changed in linux-meta-lts-trusty (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.