Well after a long day of upgrading, I'm all up to 7.1 on 3 machines.

But... both use streamzap remotes and both are not working. I had Custom remotes setup, bumped down to the stock remote and still nothing. I see I'm not the first here, is there a fix yet?

TIA

OK this seemed to work on one FE. But not the FE that I did a update with disk. (I did run updates after install)

The streamzap worked for me on 7.1, but I did a fresh install. I did have to downgrade the version of the nvidia-drivers I was using as the frontend would blow up periodically, but the streamzap worked before and after.

If you run "irw", do you see any of the events?

_________________
Marc

The views expressed are my own and do not necessarily reflect the views of my employer.

This is interesting as I can get my Streamzap to work with my system but can't get my Streamzap receiver to work with my custom remote no matter what I do (it worked fine in 6.04)

Martian

_________________
ABIT NF-M2 nView | Athlon 64 X2 3800+ | 2GB DDR2 800 | HDHomerun | GeForce 6150 (onboard) | WD 640 GB SATA HD | DVD-RW (sata) | StreamZap IR receiver with Logitech Harmony remote

Vizio 37" LCD HDTV (1080p)

I get nothing with irw. Hmm...

OK, changed USB ports and now it's working, sort of! Weird!! Only arrow keys work and it's only after I plug in the receiver after a reboot!? Enter key or exit keys don't work, only arrow keys and only after I unplug and re-plug the receiver.

Hummm... There is a lot written out there about an issue where someone else picks up the IR events instead of or in addition to lirc. There is also an issue that comes up if you downgraded to version 280.13 of the nvidia driers due to the instability of the driver bundled with 7.1. Some things to try:

1. Do your keyboard and mouse work? If not, try "pacman -Sy xf86-input-mouse xf86-input-keyboard", reboot and see if that solves the problem.

2. If that doesn't help, post the contents of "/sys/class/rc/rc0/protocols" and "/var/log/Xorg.0.log".

_________________
Marc

The views expressed are my own and do not necessarily reflect the views of my employer.

Thanks for the help Marc. I'm all stock on the nvidia drivers. Would rolling back help the blocky look on some transcodes?

I don't have a problem with keyboard and have no mouse hooked up, should I still try the above fix?



This is the Streamzap from Xorg, idk if more would be helpful. Is the "configuring as keyboard" correct?

I don't know if the drivers are used in transcoding. What many of us have noticed is a high degree on instability with the frontend with the stock driver. If you aren't having problems with the myth frontend periodically blowing up on you, I wouldn't make any changes. If you do run into problems with front end stability, check out this thread.

I don't know if the pacman installs I suggest would help or not. The logs suggest that your IR receiver is being treated like a keyboard. As a first step I would try the idea documented made here, but I would do it this way:

1. Save the current values: cat /sys/class/rc/rc0/protocols > /myth/tmp/protocols.save

2. Make the change: echo lirc> /sys/class/rc/rc0/protocols

I would also make sure that that your lirc daemon is running: ps auxw | grep lircd

_________________
Marc

The views expressed are my own and do not necessarily reflect the views of my employer.

No dice. I tried the above protocols edit, but I'm not seeing any actual change, it still appears the same (see first post). I've read thru the thread you linked, and that just doesn't seem to be making a difference.

I only have 1 more suggestion, and it seems really unlikely, but it can't make things any worse and I suspect you will need to downgrade your nvidia driver at some point. The full thread is here, but here is a synopsis of the steps:


1.1. Save your current /etc/X11/xorg.conf file
1.2. Download Nvidia drivers (http://www.nvidia.com/Download/index.aspx?lang=en-us)
1.3. sudo pacman –Sy mercurial
1.4. sudo pacman –Sy gcc
1.5. sudo pacman –Sy make
1.6. sudo pacman -Sy kernel26-headers
1.7. sv stop frontend
1.8. sh NVIDIA-Linux-x86-280.13.run and follow scripts.
1.9. pacman -Sy xf86-input-mouse xf86-input-keyboard
1.10. Reboot.

Also check that /etc/lircrc and /etc/lircd.conf are pointing at the correct configuration files. Sorry I don't have any better ideas...

_________________
Marc

The views expressed are my own and do not necessarily reflect the views of my employer.

Thanks Marc for all your help. I was able to get the remote to work after a few more searches and tinkering.

First I blacklistedthe remote so that xorg wouldn't recognize it as a keyboard.

I also had to manually recreate the /etc/lircrc and /etc/lircd.conf which were missing for some reason.

Finally I noticed that somewhere along the way, my changes to the remote on the FE were not being made. From this post, I checked the /etc/systemconfig file and made a change manually which then enabled the changes on the FE to be accepted again.

Bottom line, I'm working and it survives a reboot.

I've got this problem as well. After some searching and trial and error here are my findings. But first where the system is at.

I decided since IR is now in the kernel I didn't want/need lircd because I only want/need the limited functionality, so I have removed the lircd service and am dealing with just the kernel and ir-keytable.

On boot with the streamzap plugged in if I do nothing else but start ir-keytable -t I see the streamzap keys defined properly (kind of) As others have found only the arrow keys seem to work. So, we must edit the keymap file.

For some time with the keymap file edited when I would "write" the file (ir-keytable -w /etc/rc_keymaps/streamzap) I'd get back an error about invalid parameter. For some time I thought this had to do entirely with the command. Tonight I found however what it did not like was the "type" definition on the first line of the keymap file.

At this point I'd try using the -p option on ir-keytable with all the protocols (commonly listed) at which point when I would test the codes were nowhere near what they needed to be.

After a closer look at both after a reboot and after listing all protocols I noticed this difference:

Before using -p option


After using -p option


After much searching I've found some posts on the internet about not being able to dissable the protocol due to the order it is listed in the protocol, but my problem is I can't re-enable it. When I try to enable it with:


I get this error:



Basically I can't find a way to re-enable the protocol that is needed for the streamzap to work correctly, and since I can't get it to work from the command line it also won't take the parameter from the keymap file either. And since I can't read a keymap file without having the protocol listed in the file I can't change the keymap and use it, so beyond the arrow keys I don't have any functionality.

The only other option I can think of at the moment, as I've found suggested elsewhere, is to blacklist the kernel module and use lirc to handle things, but since it appears that looking forward the kernel is the way to go that seems like taking steps backwards.

_________________
---------
Amos B.