Streamzap remote control not operating correctly

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

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

Did you restart the computer after making the changes?

Yes, I rebooted the computer.

Try "rc-5-sz" instead.

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

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.

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.

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

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

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?

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.

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.

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?

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.

Any news with a fix for this bug?

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.

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

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

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

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

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.

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.

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. ???

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?

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

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

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

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

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.

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

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

expiring

Expiring