Ubuntu

Streamzap remote control not operating correctly

Reported by Bob Wiegand on 2010-10-20
94
This bug affects 16 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Brad Figg
lirc (Ubuntu)
Medium
Mario Limonciello

Bug Description

Binary package hint: lirc

After upgrading to Ubuntu 10.10 my Streamzap IR remote control does not operate correctly.
Pressing the direction buttons (Up, Down, Left and Right) generated 2 presses to the MythTV application.

Mario Limonciello (superm1) wrote :

can you please try to apply this patch to your init script and see if it helps (after a reboot)?

Bob Wiegand (bob-stuffofmine) wrote :

I put the change into /etc/init.d/lirc and it didn't help.
I still see the problem.

rhpot1991 (rhpot1991) wrote :

Did you restart the computer after making the changes?

Bob Wiegand (bob-stuffofmine) wrote :

Yes, I rebooted the computer.

tags: added: patch
rhpot1991 (rhpot1991) wrote :

Try "rc-5-sz" instead.

Bob Wiegand (bob-stuffofmine) wrote :

"rc-5-sz" doesn't work either.

Bob Wiegand (bob-stuffofmine) wrote :

The correct value is "rc5sz", but disable is broken.

echo "-rc5sz" > /sys/devices/virtual/rc/rc0/protocols

gives:

-bash: echo: write error: Invalid argument

The other protocols enable/disable with no problems.

Bob Wiegand (bob-stuffofmine) wrote :

I think I see a problem.

in ir-sysfs.c is the following:

        if (!strncasecmp(tmp, "unknown", 7)) {
                tmp += 7;
                mask = IR_TYPE_UNKNOWN;
        } else if (!strncasecmp(tmp, "rc5", 3)) {
                tmp += 3;
                mask = IR_TYPE_RC5;
        } else if (!strncasecmp(tmp, "nec", 3)) {
                tmp += 3;
                mask = IR_TYPE_NEC;
        } else if (!strncasecmp(tmp, "rc6", 3)) {
                tmp += 3;
                mask = IR_TYPE_RC6;
        } else if (!strncasecmp(tmp, "jvc", 3)) {
                tmp += 3;
                mask = IR_TYPE_JVC;
        } else if (!strncasecmp(tmp, "sony", 4)) {
                tmp += 4;
                mask = IR_TYPE_SONY;
        } else if (!strncasecmp(tmp, "rc5sz", 5)) {
                tmp += 5;
                mask = IR_TYPE_RC5_SZ;
        } else if (!strncasecmp(tmp, "lirc", 4)) {
                tmp += 4;
                mask = IR_TYPE_LIRC;
        } else {
                IR_dprintk(1, "Unknown protocol\n");
                return -EINVAL;
        }

If "rc5sz" is entered, the check for "rc5" will pass.

MarcRandolph (mrand) wrote :

Bob, thank you for finding that problem. Adding kernel task in hopes that they can make this change since it is super low risk.

Changed in lirc (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in linux (Ubuntu):
status: New → Confirmed
tags: added: regression-release
MarcRandolph (mrand) wrote :

Looks like Ubuntu kernel will need to be patched on its own - Upstream developer agreed that the proposed fix in this bug is proper for Ubuntu since there no easy way to pull from upstream since code has changed:

(10:33:06 AM) j-rod: that code did go upstream, but has subsequently changed
(10:36:13 AM) j-rod: so the streamzap thing can be fixed in the code in the ubuntu kernel by just moving rc5sz matching before rc5
(10:36:46 AM) j-rod: but store_protocol() changed a ton upstream since what was pulled in to the ubuntu kernel, so its not a fix that applies upstream

Changed in lirc (Ubuntu):
assignee: nobody → Mario Limonciello (superm1)
Changed in linux (Ubuntu):
status: Confirmed → Triaged
David (davidstoll+launchpad) wrote :

I guess I'm confused.

The patch has rc5-sz after rc5.
The last comment said to put rc5sz before rc5.
And several posts above, there was talk about an "rc-5-sz"

People are talking about editing
/etc/init.d/lirc
But the patch edits a different file.

It looks like there won't be any further work here, because it is a kernel issue, but can someone clear up the procedure if we want to do it ourselves?

Bob Wiegand (bob-stuffofmine) wrote :

David,

There are actually two different issues.

First was that the /etc/init.d/lirc file had both rc5sz and lirc enabled and both were reporting the Streamzap remote keys.
However, even after this file is fixed to add rc5sz (this is the correct spelling, rc5-sz and rc-5-sz are wrong) to the disable list, it doesn't get disabled.

This second error is in the ir-sysfs.c file which is part of the kernel code. This is the code that reads and processes the /etc/init.d/lirc file. This code has a bug which causes it to not correctly process the "rc3sz" entry. This can be fixed by reversing the checks for rc5 and rc5sz.

William King (quentusrex) wrote :

Is there any hope for this to be resolved soon? Also, is there a work around?

The work round I use is a *.desktop file in ~/.config/autostart pointing to a script that does:

#! /bin/bash

REMOTE_DEVICE=/dev/lirc0
export DISPLAY=:0.0

namePath="/sys/`udevadm info -q path -n $REMOTE_DEVICE`/../input*/name"
xinputLine=`xinput list | grep "$(cat $namePath)"`
id=`expr substr "$xinputLine" $(expr $(expr index "$xinputLine" "=") + 1) 100 | awk '{print $1}'`
propID=`xinput list-props $id | grep Enabled | awk '{print $3}'`
propID=${propID#"("}
propID=${propID%"):"}

xinput set-prop $id $propID 0

It isn't pretty, but it's working for me until there is a proper fix.

Ravi (asvravi) wrote :

I suggest the ir_core and related backports to the 10.10 Ubuntu kernel be removed as a fix to this issue. They seem to be added too early in the development without making sure the pieces play together well first. Mythbuntu is essentially broken due to these patches - a stock Hauppauge 150 does not work out of the box.

I am new to launchpad. This bug affects me, I waited to upgrade to 10.10 until it was released and the official Mythbuntu page endorsed it. The Streamzap remote was one of the most endorsed remotes for Mythtv by various distributions so I bought it.

How do I fix this now? Where can I find instructions on installing patches and scripts?

Steve Church (creepy) wrote :

Here's another workaround. I had to recompile my kernel anyway to re-enable ALSA OSS emulation (see https://bugs.launchpad.net/bugs/579300 for the full story if you're interested). Disabling CONFIG_IR_STREAMZAP in the kernel (Device Drivers --> Multimedia Support --> Streamzap PC Remote IR Receiver) fixed the problem for me, allowing the Streamzap drivers included in lirc to work uncontested.

See http://ubuntuforums.org/showpost.php?p=10048230&postcount=4 for instructions and my attached .config.

sr_guy (kgoerbig-gmail) wrote :

Any news with a fix for this bug?

Ravi (asvravi) wrote :

After trying atleast a dozen approaches unsuccessfully, short of re-compiling the kernel, I gave up and went back to an older kernel version. That works like a charm.

I still cant get over the fact that this major a bug could crop up in kernel backports and this version of Ubuntu/Mythbuntu was released without testing with the two most popular remote controls.

Goodwill (goodwill) wrote :

I've setup and tested Streamzap with Ubuntu 10.10 using LIRC and by disabling Streamzap Xinput Keyboard created by Xorg from UDEV. All the instructions are here, it is possible this will work for MythTV people too.

http://wiki.xbmc.org/index.php?title=Streamzap_PC_Remote

William King (quentusrex) wrote :

I can confirm that adding the file: /usr/share/X11/xorg.conf.d/90-streamzap.conf

With the following text:
Section "InputClass"
  Identifier "Ignore Streamzap IR"
  MatchProduct "Streamzap"
  MatchIsKeyboard "true"
  Option "Ignore" "true"
EndSection

Solves the issue perfectly for me. Also, this method can be built into a debian package for mythbuntu. It would be trivial to build a package that would resolve this issue as it would only include pasting the above file into the correct directory and rebooting the xserver.

http://wiki.xbmc.org/index.php?title=Streamzap_PC_Remote#Option_1:_Disable_Streamzap_Xinput_Device_usign_Xorg_Configuration

David (davidstoll+launchpad) wrote :

Yes, this does work for MythTV, but ironically, I can't get the Streamzap to control XBMC or Boxee....using the xbmc method.

Sean Meacher (sean-gongbong) wrote :

The script in #14 didn't work OOTB for me, so I rewrote it. I've been having the same issues, but with a Hauppauge remote from a Nova TD500 DVB card.

#!/bin/bash -x
export DISPLAY=:0.0
# this is my ir device
remoteDevice=$(ls /dev/input/by-path/*event-ir)
# this is what it is actually called in dmesg ("IR-receiver inside an USB DVB receiver")
remoteDeviceName=$(cat /sys/`udevadm info -q path -n $remoteDevice`/../../input*/name)
# this is the output line from xinput that matches that
xinputLine=$(xinput list | grep "$remoteDeviceName")
# this gets the column number that contains "="
position=$(expr index "$xinputLine" "=")
# but we want what's after the "=", ie the device id
positionNext=$(expr $position + 1)
# this then grabs that number
id=$(expr substr "$xinputLine" $positionNext 100 | awk '{print $1}')
# and strips the non-numeric characters form that string
propID=$(xinput list-props $id | awk '/Enabled/ {print ($3)}' | sed 's/[^0-9]//g')
# so this then turns that off.
xinput set-prop $id $propID 0

Andy Whitcroft (apw) wrote :

If disabling the STREAMZAP kernel config option worked for some of you then it is possible that just blacklisting that module would help. Creating a file named '/etc/modprobe.conf/streamzap.conf' containing 'blacklist streamzap' should prevent that module loading. If those of you affected could test that and report back here. Thanks.

Klavs Klavsen (kl-vsen) wrote :

adding a file in /etc/modprobe.d/streamzap.conf with
blacklist streamzap

did not prevent the module from being loaded, after 1 click with the remote the module was loaded and the problem was back.

the 90-streamzap.conf file for x.org.d solved the issue in mythtv for me.

David (davidstoll+launchpad) wrote :

Not sure if an update came down, but I'm not having the double key pressing issue any longer....hmmm. However, my streamzap does not seem to function in XBMC or Boxee....but MythTV works now. ???

Stefan Bader (smb) wrote :

To recap my understanding here: To fix the bug in Maverick we need:
1. The patch from comment #8 in the kernel to enable protocol changes for rc5sz (I made some test packages for -generic and put those to http://people.canonical.com/~smb/lp663651/)
2. The changes from comment #2 (but with rc5-sz changed into rc5sz)

So would 1. and 2. be all needed or is the 90-streamzap.conf file still needed in that case?

Brad Figg (brad-figg) on 2011-04-05
tags: added: maverick
DaveQB (david-dward) wrote :

Suffering the same problem after doing a clean install of Mythbuntu 10.10. Formerly running Mythbuntu 9.10 without this issue.

DaveQB (david-dward) wrote :

I can confirm that adding:

Section "InputClass"
  Identifier "Ignore Streamzap IR"
  MatchProduct "Streamzap"
  MatchIsKeyboard "true"
  Option "Ignore" "true"
EndSection

To:

/usr/share/X11/xorg.conf.d/90-streamzap

Did nothing for me.

I had to append it to my:

/etc/X11/xorg.conf directly.

Clean install of Mythbuntu 10.10

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick

Brad Figg (brad-figg) wrote :

Is this still an issue for people? If a patched kernel were created, are there folks willing to test it?

Changed in linux (Ubuntu):
status: Triaged → Incomplete
David (davidstoll+launchpad) wrote :

Still a problem for me, but I moved to an MCE remote, which is unfortunate. I'd still like to see it get fixed.

DaveQB (david-dward) wrote :

I would test a patched kernel.

One of the work arounds has worked for me and got me this far. But would like to see this fixed.

Brad Figg (brad-figg) on 2011-11-10
Changed in linux (Ubuntu):
assignee: nobody → Brad Figg (brad-figg)
importance: Undecided → Medium
status: Incomplete → In Progress
Brad Figg (brad-figg) wrote :

Maverick test kernels are available at:
    http://people.canonical.com/~bradf/lp663651/

Please test and add a comment here if it addresses this issue.

Changed in linux (Ubuntu):
status: In Progress → Incomplete
Tim Gardner (timg-tpi) wrote :

expiring

Changed in linux (Ubuntu):
status: Incomplete → Invalid
Changed in lirc (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Patches