Using URC6440 and OARUSB04G Remotes with Linux
When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.
However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. You will not need to take any special action, just Plug and Play. If that's the case, you don't need to read this section further. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is thought to be because the file system on these two remotes does not fully conform to standards. The problem is that it wasn't documented what you have to do if it doesn't mount... until now.
The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.
That shortcut is: /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
It's not very short for a shortcut, but it will always be the same, so we can make use of it in the mount command.
One User at a Time Method
The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.
Create the following script and store it under /etc/udev/rules.d with a name of your choice, such as 62-usbremote.rules -- it's all one line, by the way.
ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"
The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".
This next script serves merely to return control to the udev system as quickly as possible, hence the & at the end of the line. I've called it mount_ofa_setup and it goes in /usr/local/bin. It must be made executable:
#!/bin/bash /usr/local/bin/mount_ofa &
This next script does the actual job. It also goes in /usr/local/bin and is called mount_ofa and must be made executable:
#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137
NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between part1 and /media.
An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:
hisname=`who | awk '/tty[17]/ {print $1;}'`
After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.
Set up RemoteMasterIR to point to it correctly from its menus:
Remote > Interface > JPS... > Other : /media/your-user-name/REMOTE/settings.bin
Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.
Any User Method
The problem is that when you use su, sudo, gksu, and so on, to become root, the $USER variable is not changed, it will still return your username, but if it's run from UDEV, it will return root. If and when it has been determined how to get this to work for any user, this page will be updated.
