Help with lirc

[Daniel James]

I'm running round in circles trying to configure lirc, and getting
nowhere.

I've recently acquired an Acer Revo RL70 nettop. Nice little package with
an AMD E450 APU, 4GB RAM, 750GB HDD, and AVerMedia A373 dual-tuner DVB-T
card. Also came with wireless keyboard and mouse, and an MCE-style infra-
red remote control. A bit of a bargain for ~�280 inc VAT.

It came with Windows 7 Home Premium 64-bit, but I've wiped that and
installed MythBuntu 12.04 (MythTV bundled with Xubuntu AMD64). I've
managed to get the TV tuner working by applying a patch to the it913x USB
DVB-T driver, and MythTV is working quite nicely. I can't get the remote
control to work, though ...

The remote itself is apparently functioning correctly. When I press a
button the red LED on the surface flashes to say it's working, and when I
view it through a digital camera I can see the i/r transmitter light up
when a button is pressed.

On the RL70 I've got lirc installed. The receiver is an ITE8713 CIR
transceiver (as reported by dmesg). I get messages in the output from
dmesg saying (among other things):

input: ITE8713 CIR transceiver as /devices/virtual/rc/rc0/input6
rc0: ITE8713 CIR transceiver as /devices/virtual/rc/rc0
ite_cir: driver has been successfully loaded
input: MCE IR Keyboard/Mouse (ite-cir) as /devices/virtual/input/input7

However, the names paths do not exist. There is no /devices directory --
should there be?

I do have two entries in /dev -- a character device named /dev/lirc0 and a
symlink named /dev/lircd that points to a socket file named
/var/run/lirc/lircd

/proc/bus/input/devices shows these two entries that appear to be
relevant:

I: Bus=0019 Vendor=1283 Product=0000 Version=0000

N: Name="ITE8713 CIR transceiver"

P: Phys=

S: Sysfs=/devices/virtual/rc/rc0/input6

U: Uniq=

H: Handlers=kbd event6

B: PROP=0

B: EV=100013

B: KEY=fff 0 200108fc32e 237605100000000 0 700158000 419200004001
8e968000000000 10000000

B: MSC=10



I: Bus=0000 Vendor=0000 Product=0000 Version=0000

N: Name="MCE IR Keyboard/Mouse (ite-cir)"

P: Phys=/input0

S: Sysfs=/devices/virtual/input/input7

U: Uniq=

H: Handlers=sysrq kbd mouse1 event7

B: PROP=0

B: EV=100017

B: KEY=30000 7 ff87207ac14057ff febeffdfffefffff fffffffffffffffe

B: REL=3

B: MSC=10


I'm not sure why there are two of these ... unless the former refers to
the transceiver's transmit function and the latter to its receive
function?

Anyhow, /dev/input/event6 and /dev/input/event7 both exist, but there are
no links for them in /dev/input/by-id or /dev/input/by-path -- links do
exist for the keyboard and mouse (two for each in each directory).

Do I have to create links for the CIR device? It's not clear to me how
these links should be named, especially as the first device has a null
"Phys=" string.

My /etc/lirc/hardware.conf file starts:

# /etc/lirc/hardware.conf

#

# Chosen Remote Control

REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev mceusb"

REMOTE_DRIVER=""

REMOTE_DEVICE="/dev/lirc"

REMOTE_DEVICE="/dev/input/event7"

REMOTE_SOCKET=""

REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb"

REMOTE_LIRCD_ARGS=""

..

which seems to be fairly standard. I've tried /dev/input/event6 as well as
event7.

When I run:

sudo lircd -n

in a terminal I get:

lircd-0.9.0[2860]: lircd(default) ready, using /var/run/lirc/lircd

and when I run irw in another terminal I get an additional line of output
in the first terminal:

lircd-0.9.0[2860]: accepted new client on /var/run/lirc/lircd

If I then point the remote at the sensor and press a few buttons NOTHING
HAPPENS (whether I'm trying event6 or event7 in hardware.conf). If I
Ctrl+C out of irw I get a "removed client" message in the terminal running
lircd.

Syslog gives no more information when I do this, but if I try running
lircd as a daemon and running irw the syslog output contains a few extra
lines after the "accepted new client" message:

Feb 24 17:34:29 galette lircd-0.9.0[2788] could not get hardware features
Feb 24 17:34:29 galette lircd-0.9.0[2788] this device driver does not
support the LIRC ioctl interface
Feb 24 17:34:29 galette lircd-0.9.0[2788] did you mean to use the devinput
driver instead of the default driver?
Feb 24 17:34:29 galette lircd-0.9.0[2788] Failed to initialize hardware

I've no idea what that stuff about devinput drivers means ... nor what the
default driver is that it thinks I'm using.

Any idea what I might t

[Jim Price]

On 24/02/13 18:17, Daniel James wrote:
> I'm running round in circles trying to configure lirc, and getting
> nowhere.

[snip]

> Any idea what I might t

I noticed you are using the mceusb driver in lirc. That is normally
associated with the Philips eHome/MS Media Centre family of remotes. If
yours is intended to be compatible with those, the driver has been
subsumed into the kernel and you don't need lirc to get it working with
MythTV. Trying to get one of those to work via lirc is going to be a
waste of time, as that's not the way you're supposed to do it now. If it
is going via the kernel driver, it will appear as an input device when
you do xinput list. You need to check that first, so we know what we are
dealing with.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kgdncu$kl$1...@dont-email.me>, Jim Price wrote:
> I noticed you are using the mceusb driver in lirc. That is normally
> associated with the Philips eHome/MS Media Centre family of remotes.

> If yours is intended to be compatible with those ...

What can I say? I *believe* it's one of those ... but it has no
maker's mark or model number and no accompanying documentation.
It *does* have a green button with a Windows logo on it, though,
and it was supplied with my Acer RL70 which was supplied with
Windows 7 Home Premium x64 preinstalled, so I guess mce is a fair
bet.

There's a picture here:
http://cdn.avsforum.com/9/9a/9a205376_B006LV3ZS6-01._V140667549_.jpeg

An interesting point is that the remote has a media-remote style
arrangement of buttons in "portrait" arrangement on one side and an
ir emitter in the top (short side); while the other side of the remote
has a qwerty arrangement of keys in "landscape" mode, and an ir emitter
in the top edge of the keyboard (long side). Whether these are handled
logically as the same remote control device I don't know.

The remote sensor does not appear to be USB, though -- lsusb does not
list it -- so I'm not sure mceusb is the right driver.

> ... the driver has been subsumed into the kernel and you don't need

> lirc to get it working with MythTV.

OK ... so is having lirc installed going to mess that up? Would I be
better off uninstalling lirc?

> Trying to get one of those to work via lirc is going to be a
> waste of time, as that's not the way you're supposed to do it now.

Well ... I suppose I might want the remote to control something else
as well as MythTV, in which case some method of using it other than
MythTV's built-in method would be needed (and wouldn't, then, be a
waste of time). For now I'm happy to get it working in MythTV in any
way I can, but I'm also trying to get my head around the bigger picture
-- I have read a *lot* of online postings by people who have been
having trouble with lirc in one form or another, and the lirc
documentation seems to be among the more elusive and contradictory
sets of documents for Linux ... so any explanation I can get will be
interesting.

> If it is going via the kernel driver, it will appear as an input
> device when you do xinput list. You need to check that first, so
> we know what we are dealing with.

OK:

daniel@galette:~$ xinput list
? Virtual core pointer id=2 [master pointer (3)]
? ? Virtual core XTEST pointer id=4 [slave pointer (2)]
? ? Microsoft Microsoft Basic Optical Mouse id=9 [slave pointer (2)]
? ? MCE IR Keyboard/Mouse (ite-cir) id=12 [slave pointer (2)]
? Virtual core keyboard id=3 [master keyboard (2)]
? Virtual core XTEST keyboard id=5 [slave keyboard (3)]
? Power Button id=6 [slave keyboard (3)]
? Video Bus id=7 [slave keyboard (3)]
? Power Button id=8 [slave keyboard (3)]
? Chicony USB Keyboard id=10 [slave keyboard (3)]
? Chicony USB Keyboard id=11 [slave keyboard (3)]
? ITE8713 CIR transceiver id=13 [slave keyboard (3)]
daniel@galette:~$

[That's grabbed from a terminal and copied onto a Windows box for
posting in Windows CP 1252 -- sorry -- so the '?' characters should
be lines and arrows.]

Cheers,
Daniel.

[Tony Houghton]

In <kgdncu$kl$1...@dont-email.me>,

Jim Price <d1ve...@hotmail.com> wrote:

> I noticed you are using the mceusb driver in lirc. That is normally
> associated with the Philips eHome/MS Media Centre family of remotes. If
> yours is intended to be compatible with those, the driver has been
> subsumed into the kernel and you don't need lirc to get it working with
> MythTV. Trying to get one of those to work via lirc is going to be a
> waste of time, as that's not the way you're supposed to do it now. If it
> is going via the kernel driver, it will appear as an input device when
> you do xinput list. You need to check that first, so we know what we are
> dealing with.

I'm not really sure what you are supposed to use instead of lirc though.
Listen to X key events or similar? I've written a program (boxstar)
which reads the input device directly, but there seem to have been quite
a few changes to the API over the years, so I don't know if it's stable
yet. The device isn't readable by normal users though, so I had to write
a udev rule to change the permissions.

Daniel might find it easier to use inputlirc instead of the main lirc
package. There are example .lircrc files knocking around on mythtv's
wiki or whatever that will work with a few tweaks.

--
TH * http://www.realh.co.uk

[Jim Price]

On 25/02/13 14:15, Daniel James wrote:
> In article <kgdncu$kl$1...@dont-email.me>, Jim Price wrote:
>> I noticed you are using the mceusb driver in lirc. That is normally
>> associated with the Philips eHome/MS Media Centre family of remotes.
>> If yours is intended to be compatible with those ...
>
> What can I say? I *believe* it's one of those ... but it has no
> maker's mark or model number and no accompanying documentation.

Great.

> It *does* have a green button with a Windows logo on it, though,
> and it was supplied with my Acer RL70 which was supplied with
> Windows 7 Home Premium x64 preinstalled, so I guess mce is a fair
> bet.
>
> There's a picture here:
> http://cdn.avsforum.com/9/9a/9a205376_B006LV3ZS6-01._V140667549_.jpeg

I quite like the look of that. I have a Sky Navigator, which I had
working with the eHome USB transceiver in lirc before the whole thing
moved to the kernel. I thought I'd use the keyboard more than I did, but
I didn't so now I use a One-For-All remote and a bluetooth keyboard.

> An interesting point is that the remote has a media-remote style
> arrangement of buttons in "portrait" arrangement on one side and an
> ir emitter in the top (short side); while the other side of the remote
> has a qwerty arrangement of keys in "landscape" mode, and an ir emitter
> in the top edge of the keyboard (long side). Whether these are handled
> logically as the same remote control device I don't know.
>
> The remote sensor does not appear to be USB, though -- lsusb does not
> list it -- so I'm not sure mceusb is the right driver.

I wonder how they've attached that then. I presume the transceiver is
mounted pretty much directly on the motherboard.

>> ... the driver has been subsumed into the kernel and you don't need
>> lirc to get it working with MythTV.
>
> OK ... so is having lirc installed going to mess that up? Would I be
> better off uninstalling lirc?

Unless you start down the mad road of ripping out the kernel bits and
trying to get an unmaintained lirc driver going, you might as well
remove it. It won't make any real difference to getting the remote
working either way.

>> Trying to get one of those to work via lirc is going to be a
>> waste of time, as that's not the way you're supposed to do it now.
>
> Well ... I suppose I might want the remote to control something else
> as well as MythTV, in which case some method of using it other than
> MythTV's built-in method would be needed (and wouldn't, then, be a
> waste of time). For now I'm happy to get it working in MythTV in any
> way I can, but I'm also trying to get my head around the bigger picture
> -- I have read a *lot* of online postings by people who have been
> having trouble with lirc in one form or another, and the lirc
> documentation seems to be among the more elusive and contradictory
> sets of documents for Linux ... so any explanation I can get will be
> interesting.

I've been putting off the deep inspection of how it works in the kernel
for some time. I was expecting a dustup when I moved to Mythbuntu 12.04,
but it just worked after I'd selected the MCE remote.

>> If it is going via the kernel driver, it will appear as an input
>> device when you do xinput list. You need to check that first, so
>> we know what we are dealing with.
>
> OK:
>
> daniel@galette:~$ xinput list
> ? Virtual core pointer id=2 [master pointer (3)]
> ? ? Virtual core XTEST pointer id=4 [slave pointer (2)]
> ? ? Microsoft Microsoft Basic Optical Mouse id=9 [slave pointer (2)]
> ? ? MCE IR Keyboard/Mouse (ite-cir) id=12 [slave pointer (2)]

Bingo!

> ? Virtual core keyboard id=3 [master keyboard (2)]
> ? Virtual core XTEST keyboard id=5 [slave keyboard (3)]
> ? Power Button id=6 [slave keyboard (3)]
> ? Video Bus id=7 [slave keyboard (3)]
> ? Power Button id=8 [slave keyboard (3)]
> ? Chicony USB Keyboard id=10 [slave keyboard (3)]
> ? Chicony USB Keyboard id=11 [slave keyboard (3)]
> ? ITE8713 CIR transceiver id=13 [slave keyboard (3)]

Bingo 2!?

The ITE8713 is the TV card, so it looks like whatever remote transceiver
you have is connected via the TV card - whichever way that is connected.
Mini PCIe perhaps? Anyway, that may complicate things slightly, because
it probably means the TV card driver will be responsible for the remote
transceiver. This probably means that you need to tell MythTV that it
has that TV card remote rather than the MCE remote. Try telling lirc to
use the ite-cir driver, as that seems to be the driver lirc would use
for that hardware. I'm confused, as it would seem that although your
remote is called MCE, it has very little to do with the Philips eHome/MS
Media Centre remotes I am used to as far as the hardware is concerned.

> [That's grabbed from a terminal and copied onto a Windows box for
> posting in Windows CP 1252 -- sorry -- so the '?' characters should
> be lines and arrows.]

What you have there is something the kernel has recognised as a
keyboard/mouse setup. Given your remote has a keyboard on the back, you
could try a quick test to see if it works as a keyboard in a terminal.
If that works, things are probably working fine as far as the kernel/TV
card drivers are concerned, and it should merely be an issue of getting
MythTV to pick it up and use it properly. If not, things are going to
get interesting.

My MCE remote transceiver is USB so I'm not quite sure if this is going
to work the same on your setup, but give the ite-cir lirc driver a go -
make sure to check the "generate dynamic keymappings" box in MythTV
control centre when you select it. Your lirc.conf should look something
like this for the first 4 lines:

REMOTE="Windows Media Center Transceivers/Remotes (all)"

REMOTE_MODULES="lirc_dev ite-cir"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"

Just googled for the second line of that (the important one), and got this:

http://forum.xbmc.org/showthread.php?tid=147593

It's for XBMC, but getting the remote working for anything would be a start.

Alteratively, if the keyboard works in a terminal, you may find you need
to set up a keymap manually for the media buttons in MythTV (if all keys
produce something MythTV can work with). Worst case, the USB
transceivers for Philips eHome/MS MCE are less than a tenner on ebay
last time I looked, although they are all RC-6 and I'm not convinced
your remote is necessarily, so that route would mean getting a new
remote too unfortunately.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Jim Price]

On 25/02/13 18:49, Jim Price wrote:

> Your lirc.conf should look something like this for the first 4 lines:

Oops, I probably meant /etc/lirc/hardware.conf there.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kggbmd$arr$1...@dont-email.me>, Jim Price wrote:
>> What can I say? I *believe* it's one of those ... but it has no
>> maker's mark or model number and no accompanying documentation.
>
> Great.

<smile>

>> There's a picture here:

>> _V140667549_.jpeg">http://cdn.avsforum.com/9/9a/9a205376_B006LV3ZS6-01._V140667549_.jpeg

>
> I quite like the look of that.

Yeah, it's a neat little package. Much nicer than most other MCE
remotes I've seen. Or would be, if I could get it to work!

>> The remote sensor does not appear to be USB, though -- lsusb does
>> not list it -- so I'm not sure mceusb is the right driver.
>
> I wonder how they've attached that then. I presume the transceiver
> is mounted pretty much directly on the motherboard.

Pretty-much. There's a 3-pin header on the motherboard and the actual
sensor is on a short lead.

I've heard of RL70s being found not to have the sensor fitted so I
checked -- mine has one!

>> OK ... so is having lirc installed going to mess that up? Would I
>> be better off uninstalling lirc?
>
> Unless you start down the mad road of ripping out the kernel bits
> and trying to get an unmaintained lirc driver going, you might as
> well remove it. It won't make any real difference to getting the
> remote working either way.

OK.

I'm mad enough to be fairly at home ripping bits out of kernels ...
but I know too little about how the lirc stuff works (or is meant
to work) to know *which* bits to rip out in this case ... I'll
leave well enough alone!

> I've been putting off the deep inspection of how it works in the
> kernel for some time. I was expecting a dustup when I moved to
> Mythbuntu 12.04, but it just worked after I'd selected the MCE
> remote.

Lucky you! I wish mine did!

> The ITE8713 is the TV card, so it looks like whatever remote
> transceiver you have is connected via the TV card - whichever way
> that is connected. Mini PCIe perhaps?

The TV tuner is an AVerMedia A373, which uses an ITS IT9135 chip
(I believe). It is a mini-PCIe card *but* reports itself as USB!

Bus 002 Device 002: ID 07ca:a373 AVerMedia Technologies, Inc.
Bus 004 Device 002: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
Bus 004 Device 003: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I had to patch the dvb_usb_it913x driver to recognize the card,
but it's now working nicely. The patch is simple enough:

http://www.spinics.net/lists/linux-media/msg50602.html

I'm a little surprised at the thought that the IR transceiver may
be being driven by the TV card when the header for the sensor
connects to the motherboard rather than to the TV card itself ...
the mini-PCIe cards I'm familiar with for WiFi, 3g, etc., all have
antenna connectors on the cards themselves ... but you may well be
right.

> This probably means that you need to tell MythTV that it has that
> TV card remote rather than the MCE remote. Try telling lirc to
> use the ite-cir driver, as that seems to be the driver lirc would
> use for that hardware.

So ... we're back to lirc. Just as I was hoping I wouldn't have to
learn about that after all!

> I'm confused, as it would seem that although your remote is called
> MCE, it has very little to do with the Philips eHome/MS Media
> Centre remotes I am used to as far as the hardware is concerned.

Well ... it's not *called* MCE -- it's not called anything -- but
it does have a green "Windows" key just like an MCE remote.

I agree it's confusing.

> What you have there is something the kernel has recognised as a
> keyboard/mouse setup. Given your remote has a keyboard on the back,
> you could try a quick test to see if it works as a keyboard in a
> terminal. If that works, things are probably working fine as far as
> the kernel/TV card drivers are concerned, and it should merely be an
> issue of getting MythTV to pick it up and use it properly. If not,
> things are going to get interesting.

Done that. No joy.

AIUI though, getting anything sensible to show in a terminal depends
not only on the IR signals being received but also on lirc mapping
them onto sensible keypresses. There's more than one way that this
could be failing to show anything in a terminal.

> My MCE remote transceiver is USB so I'm not quite sure if this is
> going to work the same on your setup, but give the ite-cir lirc
> driver a go - make sure to check the "generate dynamic keymappings"
> box in MythTV control centre when you select it. Your lirc.conf
> should look something like this for the first 4 lines:
>
> REMOTE="Windows Media Center Transceivers/Remotes (all)"
> REMOTE_MODULES="lirc_dev ite-cir"
> REMOTE_DRIVER=""
> REMOTE_DEVICE="/dev/lirc0"
>

I'm sure I've tried those values ...

When I select "Generate dynamic button mappings" (is that what you
meant?) in the control centre and click "Apply" I get a dialog
asking me whether I want to

-Reconfigure (as user) the following items:
generate_lircrc

I click "Apply" on that, the control centre window remains greyed
while stuff (presumably) happens, and then the tick is cleared
from the "Generate dynamic button mappings" checkbox.

Is that expected, or does it mean that the mappings didn't get
generated? I think that's a rather confusing piece of GUI design.

What is this supposed to do? Generate ~/.mythtv/lircrc ? On my
system ~/.mythtv/lircrc is a symlink pointing to ~/.lirc/mythtv
which is a file containing a number of button definitions for

remote = mceusb_hauppauge
remote = vista_mce
remote = mceusb

A lot of these are assignments for things like number keys that
my remote doesn't have.

> Just googled for the second line of that (the important one), and
> got this:
>
> http://forum.xbmc.org/showthread.php?tid=147593

Yes, I've seen that forum article (and it shows the i/r transceiver
and its connection, which you were asking about, above).

> It's for XBMC, but getting the remote working for anything would
> be a start.

Indeed. How much does XBMC's use of IR differ from Myth's? I've seen
quite a few articles talking about XBMC (it seems to be the flavour
of the month) but far fewer discussing Myth on the RL70.

Shame, as the RL70 really is a very nice piece of hardware at current
prices.

> Alteratively, if the keyboard works in a terminal, you may find you
> need to set up a keymap manually for the media buttons in MythTV
> (if all keys produce something MythTV can work with).

Yes ...

I think there are two sets of problems here. If I can get to the stage
at which I'm confident that IR signals are being received by the box
I can start worrying about key/button assignments. I've been using irw
to try to detect incoming IR messages -- but is that the right tool?

> Worst case, the USB transceivers for Philips eHome/MS MCE are less
> than a tenner on ebay last time I looked, although they are all
> RC-6 and I'm not convinced your remote is necessarily, so that route
> would mean getting a new remote too unfortunately.

No, worst case is just using the wireless keyboard ... but the remote
might be more spouse-friendly!

Thanks for your help ... I'll fiddle with some more things and see
whether it gets me anywhere.

Cheers,
Daniel.

[Daniel James]

In article <kggqfg$3on$1...@dont-email.me>, Jim Price wrote:
>> Your lirc.conf should look something like this for the first 4 lines:
>
> Oops, I probably meant /etc/lirc/hardware.conf there.

You did ... but I recognized the file from the format ...

Cheers,
Daniel.

[Jim Price]

On 26/02/13 15:11, Daniel James wrote:
> In article <kggbmd$arr$1...@dont-email.me>, Jim Price wrote:

[remote sensor]

>> I wonder how they've attached that then. I presume the transceiver
>> is mounted pretty much directly on the motherboard.
>
> Pretty-much. There's a 3-pin header on the motherboard and the actual
> sensor is on a short lead.

Hmm. That suggests it isn't one built into the TV card.

> I've heard of RL70s being found not to have the sensor fitted so I
> checked -- mine has one!

>>> OK ... so is having lirc installed going to mess that up? Would I
>>> be better off uninstalling lirc?
>>
>> Unless you start down the mad road of ripping out the kernel bits
>> and trying to get an unmaintained lirc driver going, you might as
>> well remove it. It won't make any real difference to getting the
>> remote working either way.
>
> OK.

Reading my bit above, that was written while I was still a bit unsure
about how the sensor is connected. I'm still a bit unsure, but more
inclined to think it is separate from the TV card now.

> I'm mad enough to be fairly at home ripping bits out of kernels ...
> but I know too little about how the lirc stuff works (or is meant
> to work) to know *which* bits to rip out in this case ... I'll
> leave well enough alone!
>
>> I've been putting off the deep inspection of how it works in the
>> kernel for some time. I was expecting a dustup when I moved to
>> Mythbuntu 12.04, but it just worked after I'd selected the MCE
>> remote.
>
> Lucky you! I wish mine did!
>
>> The ITE8713 is the TV card, so it looks like whatever remote
>> transceiver you have is connected via the TV card - whichever way
>> that is connected. Mini PCIe perhaps?
>
> The TV tuner is an AVerMedia A373, which uses an ITS IT9135 chip
> (I believe). It is a mini-PCIe card *but* reports itself as USB!

I think mini-PCIe has pins for USB built into it.

> Bus 002 Device 002: ID 07ca:a373 AVerMedia Technologies, Inc.
> Bus 004 Device 002: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
> Bus 004 Device 003: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> I had to patch the dvb_usb_it913x driver to recognize the card,
> but it's now working nicely. The patch is simple enough:
>
> http://www.spinics.net/lists/linux-media/msg50602.html
>
> I'm a little surprised at the thought that the IR transceiver may
> be being driven by the TV card when the header for the sensor
> connects to the motherboard rather than to the TV card itself ...
> the mini-PCIe cards I'm familiar with for WiFi, 3g, etc., all have
> antenna connectors on the cards themselves ... but you may well be
> right.

I'm beginning to think that the evidence is suggesting it's a seperate
device now.

>> This probably means that you need to tell MythTV that it has that
>> TV card remote rather than the MCE remote. Try telling lirc to
>> use the ite-cir driver, as that seems to be the driver lirc would
>> use for that hardware.
>
> So ... we're back to lirc. Just as I was hoping I wouldn't have to
> learn about that after all!

It's not that bad once you have seen a complete workthrough for a given
device. The major problem is you normally end up having to create that
first workthrough yourself. I did it in 2009 for a troublesome
remote/sensor pair, and it seems to have made sense to me since.

Yep, that sounds about right.

> What is this supposed to do? Generate ~/.mythtv/lircrc ? On my
> system ~/.mythtv/lircrc is a symlink pointing to ~/.lirc/mythtv
> which is a file containing a number of button definitions for
>
> remote = mceusb_hauppauge
> remote = vista_mce
> remote = mceusb
>
> A lot of these are assignments for things like number keys that
> my remote doesn't have.

mceusb is intended to cover a wide range of remotes, with a wide range
of (usually only slightly) differing keys.

>> Just googled for the second line of that (the important one), and
>> got this:
>>
>> http://forum.xbmc.org/showthread.php?tid=147593
>
> Yes, I've seen that forum article (and it shows the i/r transceiver
> and its connection, which you were asking about, above).
>
>> It's for XBMC, but getting the remote working for anything would
>> be a start.
>
> Indeed. How much does XBMC's use of IR differ from Myth's?

If it is going via lirc, the only differences are app specific - all the
underlying gubbins are the same.

> I've seen
> quite a few articles talking about XBMC (it seems to be the flavour
> of the month) but far fewer discussing Myth on the RL70.

I'm keeping my eye on XBMC, as it might make a less finicky front end to
MythTV at some point in the not too distant future. I was not impressed
by the DVB-S backend which came with XBMC last time I tried it.

> Shame, as the RL70 really is a very nice piece of hardware at current
> prices.

If I didn't build all my own machines I would probably be tempted by
something along those lines.

>> Alteratively, if the keyboard works in a terminal, you may find you
>> need to set up a keymap manually for the media buttons in MythTV
>> (if all keys produce something MythTV can work with).
>
> Yes ...
>
> I think there are two sets of problems here. If I can get to the stage
> at which I'm confident that IR signals are being received by the box
> I can start worrying about key/button assignments. I've been using irw
> to try to detect incoming IR messages -- but is that the right tool?

If IRW isn't working, it's time to go lower level. The thing for that is
mode2. It spews out numbers which are ms delays as provided by the
hardware, and before any protocol interpretation. Any signal which
doesn't match in the protocol interpreter gets dropped as spurious, and
not intended for your purposes. Thus, if you have the wrong protocol
interpreter, irw shows you no output. It's also handy to plot the graph
of the timings to work out which protocol is being used and to work out
timing values to give to lirc when you're trying to mix and match a
remote and sensor which aren't normally paired together.

>> Worst case, the USB transceivers for Philips eHome/MS MCE are less
>> than a tenner on ebay last time I looked, although they are all
>> RC-6 and I'm not convinced your remote is necessarily, so that route
>> would mean getting a new remote too unfortunately.
>
> No, worst case is just using the wireless keyboard ... but the remote
> might be more spouse-friendly!
>
> Thanks for your help ... I'll fiddle with some more things and see
> whether it gets me anywhere.

If you can get anything out of mode2, it is almost certain you can then
go on to get it working. Try all the /dev/lirc* devices which appear, as
at least one of them should do something in mode2. If you can't, then
it's time to look at whether to rip out the kernel support for the
device and use lirc, or try and work out how to get it working with the
kernel support. I'll have a further read up on that, and should be in a
position to say something more sensible this evening. It's something
I've been meaning to get around to for ages, and you're providing the
cue for me to actually do it.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kgim6b$qh7$1...@dont-email.me>, Jim Price wrote:
>> There's a 3-pin header on the motherboard and the actual
>> sensor is on a short lead.
>
> Hmm. That suggests it isn't one built into the TV card.

It hadn't occurred to me that there would /be/ an IR controller built
into the TV card until you suggested it. I have a PCI Hauppauge card in
another machine and I think that does (though I've never tried to use
it) so it's entirely plausible that it might.

I guess it doesn't though (or, at least, the RL70 doesn't use it if it
does) in the light of what we now know.

> I think mini-PCIe has pins for USB built into it.

Apparently so. I didn't know that.

>> So ... we're back to lirc. Just as I was hoping I wouldn't have to
>> learn about that after all!
>
> It's not that bad once you have seen a complete workthrough for a
> given device. The major problem is you normally end up having to
> create that first workthrough yourself. I did it in 2009 for a
> troublesome remote/sensor pair, and it seems to have made sense to
> me since.

I find that a lot with Linux -- anything you read about it is really
hard to understand until you already know what it's trying to say; then
it's obvious!

>> I click "Apply" on that, the control centre window remains greyed
>> while stuff (presumably) happens, and then the tick is cleared
>> from the "Generate dynamic button mappings" checkbox.
>>
>> Is that expected, or does it mean that the mappings didn't get
>> generated? I think that's a rather confusing piece of GUI design.
>
> Yep, that sounds about right.

OK, bad GUI design then. The checkbox just means "when you apply this
selection, generate the lircrc file as well, please" and once that's
been done it becomes unchecked. That's not an appropriate use of a
checkbox (but I'm not sure how else I'd do it)!

>> A lot of these are assignments for things like number keys that
>> my remote doesn't have.
>
> mceusb is intended to cover a wide range of remotes, with a wide
> range of (usually only slightly) differing keys.

Of course ... but more to the point there are no assignments for many
buttons that my remote *does* have ... at least, not with remote =
mceusb. I suppose the "remote =" line does actually mean something?

>> Indeed. How much does XBMC's use of IR differ from Myth's?
>
> If it is going via lirc, the only differences are app specific - all
> the underlying gubbins are the same.

Of course -- that makes sense ... if it's all down to lirc. Knowing
that MythTV has its own mechanism that bypasses lirc makes me wonder
whether anyones findings with XBMC have any relevance, but if MythTV
isn't using it its 'private' IR setup then it must work much like other
apps.

>> Shame, as the RL70 really is a very nice piece of hardware at
>> current prices.
>
> If I didn't build all my own machines I would probably be tempted by
> something along those lines.

I build most of my own machines, but when I see something like the RL70
-- that seems an ideal solution to a particular problem -- I'll choose
it over a home-build if the price is right. I didn't build my own ADSL
router either!

> If IRW isn't working, it's time to go lower level. The thing for
> that is mode2.

Ah! <facepalm> I forgot about mode2. I did try that earlier in the
process of trying to get this working, but I always seemed to get
"permission denied".

I've just tried it again, though -- as: sudo mode2 -d /dev/lirc0 -- and
I'm getting streams of lines like:

pulse 60
space 12967
pulse 69
space 6449
pulse 104
space 32506
..

scrolling up the screen. If I blip the remote at it the sequence
*seems* to change ... it's as though there's a lot of ambient IR noise
being picked up as well as the remote. I'll have to look into that.

Still, it shows that IR *is* being picked up (somehow) and the PC *is*
capable of detecting it -- I think that's a big step forward.

> Any signal which doesn't match in the protocol interpreter gets
> dropped as spurious, and not intended for your purposes. Thus, if
> you have the wrong protocol interpreter, irw shows you no output.

Yeah, I'd guessed that. Thanks for confirming it and for reminding me
of mode2 (nice helpful, meaningful, name that has!)

> It's also handy to plot the graph of the timings to work out which
> protocol is being used and to work out timing values to give to
> lirc when you're trying to mix and match a remote and sensor which
> aren't normally paired together.

I can see I have more fun ahead <smile>!

> If you can get anything out of mode2, it is almost certain you can
> then go on to get it working.

I hope so -- thanks again for your help and (especially) encouragement!

Cheers,
Daniel.

[Jim Price]

On 26/02/13 18:35, Daniel James wrote:
> In article <kgim6b$qh7$1...@dont-email.me>, Jim Price wrote:

>> It's not that bad once you have seen a complete workthrough for a
>> given device. The major problem is you normally end up having to
>> create that first workthrough yourself. I did it in 2009 for a
>> troublesome remote/sensor pair, and it seems to have made sense to
>> me since.
>
> I find that a lot with Linux -- anything you read about it is really
> hard to understand until you already know what it's trying to say; then
> it's obvious!

And usually quite a good way of doing things.

>>> I click "Apply" on that, the control centre window remains greyed
>>> while stuff (presumably) happens, and then the tick is cleared
>>> from the "Generate dynamic button mappings" checkbox.
>>>
>>> Is that expected, or does it mean that the mappings didn't get
>>> generated? I think that's a rather confusing piece of GUI design.
>>
>> Yep, that sounds about right.
>
> OK, bad GUI design then. The checkbox just means "when you apply this
> selection, generate the lircrc file as well, please" and once that's
> been done it becomes unchecked. That's not an appropriate use of a
> checkbox (but I'm not sure how else I'd do it)!

A regular button labelled something like "Generate lircrc" and some
indication that that would un-grey-out options which would only work
with a sensible lircrc perhaps. Anyway, I'm used to it now.

>>> A lot of these are assignments for things like number keys that
>>> my remote doesn't have.
>>
>> mceusb is intended to cover a wide range of remotes, with a wide
>> range of (usually only slightly) differing keys.
>
> Of course ... but more to the point there are no assignments for many
> buttons that my remote *does* have ... at least, not with remote =
> mceusb. I suppose the "remote =" line does actually mean something?

Yep, it's setting the protocol that is going to be used to decode the
button presses. If that is set to something which has a protocol
unrelated to the remote you're using, you won't get much out of it.

>>> Indeed. How much does XBMC's use of IR differ from Myth's?
>>
>> If it is going via lirc, the only differences are app specific - all
>> the underlying gubbins are the same.
>
> Of course -- that makes sense ... if it's all down to lirc. Knowing
> that MythTV has its own mechanism that bypasses lirc makes me wonder
> whether anyones findings with XBMC have any relevance, but if MythTV
> isn't using it its 'private' IR setup then it must work much like other
> apps.

As far as I can tell, the "private" way is just taking stuff from the
virtual keyboard driver and assigning actions to that. Hence when the
remote is one which has been subsumed into the virtual keyboard way of
doing things, it is just sending codes which correspond to what are
effectively the keyboard shortcuts in MythTV. That's fine when it works,
but perplexedly different when it doesn't.

>>> Shame, as the RL70 really is a very nice piece of hardware at
>>> current prices.
>>
>> If I didn't build all my own machines I would probably be tempted by
>> something along those lines.
>
> I build most of my own machines, but when I see something like the RL70
> -- that seems an ideal solution to a particular problem -- I'll choose
> it over a home-build if the price is right. I didn't build my own ADSL
> router either!

I did built my first ADSL router. My, that seems like a long time ago.
It expired in 2006.

>> If IRW isn't working, it's time to go lower level. The thing for
>> that is mode2.
>
> Ah! <facepalm> I forgot about mode2. I did try that earlier in the
> process of trying to get this working, but I always seemed to get
> "permission denied".
>
> I've just tried it again, though -- as: sudo mode2 -d /dev/lirc0 -- and
> I'm getting streams of lines like:
>
> pulse 60
> space 12967
> pulse 69
> space 6449
> pulse 104
> space 32506
> ..

That pins a few things down. It still leaves a few other things open for
research though. Somehow we need to work out what protocol that remote
is using, so you can stick the appropriate shim in there to get from raw
on-off timings to something which lirc can use to control MythTV. In
theory if it is MCE compatible, the protocol should be RC-6. I'm going
to have another read of that XBMC article with that in mind to see if
there's a clue what it is. I'd say the worst case has now shifted to
having to use irrecord to generate a keymap, the best case is being able
to identify a pre-existing setup which works.

> scrolling up the screen. If I blip the remote at it the sequence
> *seems* to change ... it's as though there's a lot of ambient IR noise
> being picked up as well as the remote. I'll have to look into that.

The numbers are rarely consistent - they only need to be within a
certain percentage for the run length of each remote code. That tends to
be of the order of 20 odd bits, so better than 5% tolerance is needed.
The most likely cause of an offset I've seen has been the tendency for
different receivers to have different transition points between a 1 and
0, giving timings like 650,350 rather than the expected 505,500 given
the bit lengths are supposed to be the same.

> Still, it shows that IR *is* being picked up (somehow) and the PC *is*
> capable of detecting it -- I think that's a big step forward.

Ho yus!

>> Any signal which doesn't match in the protocol interpreter gets
>> dropped as spurious, and not intended for your purposes. Thus, if
>> you have the wrong protocol interpreter, irw shows you no output.
>
> Yeah, I'd guessed that. Thanks for confirming it and for reminding me
> of mode2 (nice helpful, meaningful, name that has!)

I'm not sure I can think of a meaningful name which isn't rather a lot
longer.

>> It's also handy to plot the graph of the timings to work out which
>> protocol is being used and to work out timing values to give to
>> lirc when you're trying to mix and match a remote and sensor which
>> aren't normally paired together.
>
> I can see I have more fun ahead <smile>!

Only if we end up having to reverse engineer the protocol. I'm
reasonably optimistic we won't.

>> If you can get anything out of mode2, it is almost certain you can
>> then go on to get it working.
>
> I hope so -- thanks again for your help and (especially) encouragement!

I actually love trying to solve these sorts of problems.

OK, I read the XBMC article again, and from the config he is using, I'd
guess the protocol is RC-6. There are a couple of differences which may
be causing your setup to fail when testing it with irw. He is probably
using a different IR receiver to the one you have, which can cause the
timings at the mode2 layer to be a bit offset. If that is the case, we
can work out what they should be from the mode2 data. The other missing
link is the actual remote itself. We can take that out of the equation
if you have a suitable universal remote (I use One-For-All 7140s, which
can emulate the RC-6 MCE remote). If you don't have access to another
remote, we should also be able to work out what the existing one is
doing from the mode2 data. Can you post a complete mode2 output for one
keystroke - the play button would be a good bet. What I'd do with that
is put it in a spreadsheet and look for the data bits. If it's RC-6 they
are manchester encoded and I have some notes on the other details of the
encoding somewhere. Also, try irrecord, as the output from that can be
handy for seeing what it is doing. That should do something if you use
it with the /etc/lirc/hardware.conf from the XBMC article.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kgj5kf$rku$1...@dont-email.me>, Jim Price wrote:
>>> mceusb is intended to cover a wide range of remotes, with a wide
>>> range of (usually only slightly) differing keys.
>>
>> Of course ... but more to the point there are no assignments for
>> many
>> buttons that my remote *does* have ... at least, not with remote =
>> mceusb. I suppose the "remote =" line does actually mean something?
>
> Yep, it's setting the protocol that is going to be used to decode
> the button presses. If that is set to something which has a protocol
> unrelated to the remote you're using, you won't get much out of it.

Setting the *protocol*?

I had assumed that the button definitions with different "remote ="
lines were for different physical remotes (and I guess I assumed they
would all use the same protocol) ... and that there would be a setting
somewhere to specify the actual remote in use.

So ... what's the point of having button definitions using different
protocols in the same lircrc file -- can a single remote use different
protocols for different buttons?

I've been trying to read up on this stuff, but useful information is
hard to find.

>> Of course -- that makes sense ... if it's all down to lirc.
>> Knowing that MythTV has its own mechanism that bypasses lirc
>> makes me wonder whether anyones findings with XBMC have any
>> relevance, but if MythTV isn't using it its 'private' IR setup
>> then it must work much like other apps.
>
> As far as I can tell, the "private" way is just taking stuff from
> the virtual keyboard driver and assigning actions to that.

"virtual keyboard driver" ... another piece of the jigsaw.

> Hence when the remote is one which has been subsumed into the
> virtual keyboard way of doing things, it is just sending codes
> which correspond to what are effectively the keyboard shortcuts
> in MythTV. That's fine when it works, but perplexedly different
> when it doesn't.

I'd assumed -- perhaps entirely incorrectly -- that the "private" way
involved MythTV (mythfrontend?) reading data from the hardware driver
directly and mapping the data received straight onto MythTV commands,
while the "public" way used lirc to generate input events of other
kinds (keypresses, etc) that could be fed to the relevant applications.
In this case Myth would still work, but would be unaware that it wasn't
being directed by a normal keyboard.

However, the fact that when the mythbuntu control centre configures an
IR device it actually writes /etc/lirc/hardware.conf and creates the
lircrc file sorta suggests that more of lirc is involved even in the
"private" case (if that is the "private" case).

I do note that the "No Additional Remote Support" option in the control
centre says "If you don't have a remote right now, or it's supported
natively". I'd overlooked that ... perhaps I should play with the
"supported natively" option?

Oh dear: "The application Mythbuntu Control Centre has closed
unexpectedly". It's not the first time I've seen that!

>> I didn't build my own ADSL router either!
>
> I did built my first ADSL router. My, that seems like a long time
> ago. It expired in 2006.

Well, I keep saying I'll build my next one ... but I expect someone
will produce a commercial one with decent IPv6 support before I get
around to it, and I won't need to.

>> I've just tried it again, though -- as: sudo mode2 -d /dev/lirc0
>> -- and I'm getting streams of lines like:
>>
>> pulse 60
>> space 12967
>> pulse 69
>> space 6449
>> pulse 104
>> space 32506
>> ..
>
> That pins a few things down. It still leaves a few other things open
> for research though.

I moved the box, and now it doesn't pick up random background (I think
it was pointing too nearly towards an LCD monitor and picking up IR
from the backlight). It now gives much less erratic-looking values for
pulse and space:

pulse 2725
space 815
pulse 520
space 364
pulse 546
space 338
..

I can also get a bunch of possibly helpful numbers by doing:

hexdump -C /dev/lirc0

(about 256 bytes per button press ... but not a constant amount (or is
it that it's just over 256 bytes and being buffered by hexdump?))

However:

irw /dev/lirc0

gives:

connect: Connection refused

which surprised me. I had expected that mode2 and irw would read the
same IR input but that mode2 would simply report it while irw would try
to interpret the raw data and report keystrokes. Clearly I still don't
understand quite how this jigsaw fits together!

> Somehow we need to work out what protocol that remote is using, so
> you can stick the appropriate shim in there to get from raw
> on-off timings to something which lirc can use to control MythTV.

Makes sense.

> In theory if it is MCE compatible, the protocol should be RC-6.
> I'm going to have another read of that XBMC article with that in
> mind to see if there's a clue what it is.

..

> I'd say the worst case has now shifted to having to use irrecord to
> generate a keymap, the best case is being able to identify a
> pre-existing setup which works.

I wondered whether irrecord would be the way to go ... I rather hope
not as there are 30 buttons to record, and the qwerty keypad on the
back has another 37 keys! It could take a while ...

> ... mode2 (nice helpful, meaningful, name that has!)

>
> I'm not sure I can think of a meaningful name which isn't rather a
> lot longer.

<smile> ... well, something with "ir" in it, maybe, and something less
superficially similar to "mode3"!

>> I can see I have more fun ahead <smile>!
>
> Only if we end up having to reverse engineer the protocol. I'm
> reasonably optimistic we won't.

It's nice of you to say "we" -- you've been a great help already.

> I actually love trying to solve these sorts of problems.

I'm grateful.

> OK, I read the XBMC article again, and from the config he is using,
> I'd guess the protocol is RC-6. There are a couple of differences
> which may be causing your setup to fail when testing it with irw.
> He is probably using a different IR receiver to the one you have,
> which can cause the timings at the mode2 layer to be a bit offset.
> If that is the case, we can work out what they should be from the
> mode2 data.

OK ...

> The other missing link is the actual remote itself. We can take
> that out of the equation if you have a suitable universal remote
> (I use One-For-All 7140s, which can emulate the RC-6 MCE remote).

I think I can do one better ...
as it happens, my wife has an Asus EEE
Box 1501 that she uses as a desktop PC/thin client. That came with a
remote control that claims to be an RC-6 remote (and which she doesn't
use). I thought she'd thrown it out, but I seem to have "rescued" it,
so I am able to compare it with my Acer remote, if that helps.

There's a thread here:
http://ubuntuforums.org/showthread.php?t=1609423

that discusses getting that remote to work on the Asus EEE Box -- and
it seems the Asus also uses the IT8713. I note that the poster there is
using

REMOTE_MODULES="lirc_dev lirc_it87"

rather than my

REMOTE_MODULES="lirc_dev ite-cir"

in hardware.conf ... which is surprising as lirc-it87 seems to be for
the IT8712 and IT8705. That post is from 2010, though, and things
change ... I have read there were some problems with lirc_it87 in 2011
-vintage Ubuntus, and maybe ite-cir is newer?

> Can you post a complete mode2 output for one
> keystroke - the play button would be a good bet.

The "Play" button on my remote is play/pause ... that probably wouldn't
matter, but I'll do "Stop" instead.

daniel@galette:~$ sudo mode2 -d /dev/lirc0
space 16777215
pulse 2751
space 789
pulse 512
space 373
pulse 538
space 347
pulse 546
space 781
pulse 572
space 755
pulse 1423
space 789
pulse 546
space 338
pulse 546
space 338
pulse 546
space 338
pulse 572
space 312
pulse 572
space 312
pulse 572
space 312
pulse 572
space 312
pulse 1015
space 312
pulse 546
space 781
pulse 1006
space 321
pulse 546
space 338
pulse 546
space 781
pulse 1015
space 755
pulse 572
space 312
pulse 572
space 312
pulse 546
space 338
pulse 989
space 781
pulse 546
space 338
pulse 572
space 312
pulse 546
space 338
pulse 989
space 338
pulse 572
space 755
pulse 546
space 338
pulse 572
space 312
pulse 1015
pulse 100340

> Also, try irrecord, as the output from that can be handy for seeing
> what it is doing.

Ah, that seems to be making some sense. I tried:

irrecord -d /dev/lirc0 myremote

and after setting up a handful of obvious keys I got a myremote file
that looks like this:

----------
# Please make this file available to others
# by sending it to <li...@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.9.0(default) on Wed Feb 27 14:29:35 2013
#
# contributed by
#
# brand: myremote
# model no. of remote control:
# devices being controlled by this remote:
#

begin remote

name myremote
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100

header 2735 807
one 516 367
zero 516 367
pre_data_bits 21
pre_data 0x37F91
gap 105497
toggle_bit_mask 0x0
rc6_mask 0x100000000

begin codes
KEY_PLAY 0xFB6C
KEY_STOP 0x7BCE
KEY_OK 0xFBA3
KEY_LEFT 0x7BA5
KEY_RIGHT 0xFBA4
KEY_UP 0x7BA7
KEY_DOWN 0xFBA6
end codes

end remote
----------

Is that 0x7BCE what you'd expect from the pulse/space values above?

If I copy that file to /etc/lirc/lircd.conf and restart lirc I can then
run irw and get:

daniel@galette:~$ irw
000000037f917ba7 00 KEY_UP myremote
000000037f917ba7 01 KEY_UP myremote
000000037f917ba7 02 KEY_UP myremote
000000037f91fba4 00 KEY_RIGHT myremote
000000037f91fba4 01 KEY_RIGHT myremote
000000037f91fba4 02 KEY_RIGHT myremote
000000037f91fb6c 00 KEY_PLAY myremote
000000037f917bce 00 KEY_STOP myremote
000000037f917bce 01 KEY_STOP myremote
000000037f917bce 02 KEY_STOP myremote
000000037f917bce 03 KEY_STOP myremote
^C
daniel@galette:~$

*BINGO*!

I seem to have to hold each button down for quite some time (only a
fraction of a second, but more than a rapid push) before I get any
response, and then I tend to get multiple lines echoed by irw ... but I
suppose that gets debounced somewhere along the line?

I've regenerated lircrc and got something plausible-looking including
same the keys as in lirc.conf ... however, those keys aren't doing
anything in mythfrontend.

I feel I'm getting close ...

Cheers,
Daniel.

[Daniel James]

In article <VA.0000078...@me.invalid>, Daniel James wrote:
> I've regenerated lircrc and got something plausible-looking including
> same the keys as in lirc.conf ... however, those keys aren't doing
> anything in mythfrontend.

Oh, I am an idiot!

For some reason (probably because I was fiddling with it in the hope of
getting things to work without actually having to understand how) I had
the "LIRC daemon socket" setting in mythfrontend set to "/dev/lirc0"
when it should have been "/dev/lircd" (obviously wrong, once you
appreciate that /dev/lirc0 is a character device but /dev/lircd is a
(symlink to a) socket).

It's now working for the buttons on the "media" side of the remote
control. I haven't manager to get irrecord to recognize the sequences
generated by pressing the buttons on the "qwerty" side of the remote
control, yet. I just get:

Something went wrong. Please try again. (N retries left)

After 10 retries irrecord gives up and tells me to try with the -f
(force raw) option.

So, I tried that ... and I got

...
Now hold down button "KEY_A"
Got it.
Signal length is 28
That's weird because the signal length must be odd!
Try again.
...

But the signal length remains resolutely 28 however many times I try.

Looks like the "qwerty" side isn't RC-6 (or anything else sensible)?

I must say, though, that using the remote control to control
mythfrontend is a frustratingly slow process. I have to press each
button for about a second to get any response from it, and even then the
GUI takes a moment or two to respond. This is annoying as the GUI seems
really snappy when used with a PC keyboard.

Anyhow, thanks again, Jim. I feel I owe you a beer, or something!

Cheers,
Daniel.

[Jim Price]

On 27/02/13 15:09, Daniel James wrote:
> In article <kgj5kf$rku$1...@dont-email.me>, Jim Price wrote:

>> Yep, it's setting the protocol that is going to be used to decode
>> the button presses. If that is set to something which has a protocol
>> unrelated to the remote you're using, you won't get much out of it.
>
> Setting the *protocol*?

In this case the protocol being RC-6.

> I had assumed that the button definitions with different "remote ="
> lines were for different physical remotes (and I guess I assumed they
> would all use the same protocol) ... and that there would be a setting
> somewhere to specify the actual remote in use.

A given remote will use a particular protocol. There is a certain amount
of standardisation, and the Philips eHome RC-6 is the one in theory you
might be able to use more than one remote via the same receiver, but in
practice that can be a can of worms if the two remotes you are trying to
use each use a different protocol. Basically what happens is the remote
flashes on and off, where on is a brief duration of several tens of kHz
flashes, and off is just off. The duration of those flashes is what
mode2 shows you. The protocol is what gets you from the flashing data to
a byte or two of stuff you can use as data. This sort of stuff is
unbelievably poorly documented on the internet, possibly because it is
proprietary in a lot of cases.

> So ... what's the point of having button definitions using different
> protocols in the same lircrc file -- can a single remote use different
> protocols for different buttons?

In general, no. The exception is universal remotes, which can emulate
more than one remote and assign buttons to produce output which can be
of a different protocol for a different key on the remote.

> I've been trying to read up on this stuff, but useful information is
> hard to find.

As I said above, that's because it largely isn't there. I did a fair bit
of stuff with re-programming the One-For-All remotes a few years ago,
based on the JP1 software from here:

http://www.hifi-remote.com/forums/

Their IR protocol page is the best source of low level remote info on
the net, if a little bit cryptic for the beginner:

http://www.hifi-remote.com/johnsfine/DecodeIR.html

e.g. RC-6 is casually defined as:

{36k,444,msb}<-1,1|1,-1>(6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)+

>> As far as I can tell, the "private" way is just taking stuff from
>> the virtual keyboard driver and assigning actions to that.
>
> "virtual keyboard driver" ... another piece of the jigsaw.

That's just the kernel putting together all the physical keyboards
together, as seen when you do xinput list.

>> Hence when the remote is one which has been subsumed into the
>> virtual keyboard way of doing things, it is just sending codes
>> which correspond to what are effectively the keyboard shortcuts
>> in MythTV. That's fine when it works, but perplexedly different
>> when it doesn't.
>
> I'd assumed -- perhaps entirely incorrectly -- that the "private" way
> involved MythTV (mythfrontend?) reading data from the hardware driver
> directly and mapping the data received straight onto MythTV commands,
> while the "public" way used lirc to generate input events of other
> kinds (keypresses, etc) that could be fed to the relevant applications.
> In this case Myth would still work, but would be unaware that it wasn't
> being directed by a normal keyboard.

That's pretty much it. Myth needs to know which remote you are using so
it knows what to do in the case of lirc data, but in the case of kernel
supported remotes it does seem to be a case of just having the virtual
keyboard input understand what is likely to come its way. Your remote is
going to have to go via lirc because of the receiver, and use a
buttonmap something like that implied by mceusb, but the old version
which hadn't been ported to the kernel.

> However, the fact that when the mythbuntu control centre configures an
> IR device it actually writes /etc/lirc/hardware.conf and creates the
> lircrc file sorta suggests that more of lirc is involved even in the
> "private" case (if that is the "private" case).

I'm not sure whether the buttonmap MythTV needs in order to use your
remote actually exists in quite the format MythTV expects for mceusb
devices.

> I do note that the "No Additional Remote Support" option in the control
> centre says "If you don't have a remote right now, or it's supported
> natively". I'd overlooked that ... perhaps I should play with the
> "supported natively" option?

Worth a try I suppose. However, the supported natively means via the
virtual keyboard method, whereas your remote is going to have to go via
lirc. The test for this is one you've already done - do the number keys
produce numbers in a terminal.

> Oh dear: "The application Mythbuntu Control Centre has closed
> unexpectedly". It's not the first time I've seen that!

Which version of MythTV are you running? 0.25 is what you get by default
in 12.04, but there is an upgrade to 0.26 available with relatively
little hassle in 12.04.

>>> I didn't build my own ADSL router either!
>>
>> I did built my first ADSL router. My, that seems like a long time
>> ago. It expired in 2006.
>
> Well, I keep saying I'll build my next one ... but I expect someone
> will produce a commercial one with decent IPv6 support before I get
> around to it, and I won't need to.

My current router does support IPv6 - rather a lot better than my ISP
supports it, but I'm looking at changing ISP in the near future to one
which does (A+A have a new Home::1 tariff, which looks good).

> I moved the box, and now it doesn't pick up random background (I think
> it was pointing too nearly towards an LCD monitor and picking up IR
> from the backlight). It now gives much less erratic-looking values for
> pulse and space:
>
> pulse 2725
> space 815
> pulse 520
> space 364
> pulse 546
> space 338
> ..
>
> I can also get a bunch of possibly helpful numbers by doing:
>
> hexdump -C /dev/lirc0
>
> (about 256 bytes per button press ... but not a constant amount (or is
> it that it's just over 256 bytes and being buffered by hexdump?))

Not sure about that.

> However:
>
> irw /dev/lirc0
>
> gives:
>
> connect: Connection refused
>
> which surprised me. I had expected that mode2 and irw would read the
> same IR input but that mode2 would simply report it while irw would try
> to interpret the raw data and report keystrokes. Clearly I still don't
> understand quite how this jigsaw fits together!

irw uses the current lirc daemon config file for its protocol
information, and if that is not correct, it won't give any (sensible)
output.

>> Somehow we need to work out what protocol that remote is using, so
>> you can stick the appropriate shim in there to get from raw
>> on-off timings to something which lirc can use to control MythTV.
>
> Makes sense.
>
>> In theory if it is MCE compatible, the protocol should be RC-6.
>> I'm going to have another read of that XBMC article with that in
>> mind to see if there's a clue what it is.
> ..
>> I'd say the worst case has now shifted to having to use irrecord to
>> generate a keymap, the best case is being able to identify a
>> pre-existing setup which works.
>
> I wondered whether irrecord would be the way to go ... I rather hope
> not as there are 30 buttons to record, and the qwerty keypad on the
> back has another 37 keys! It could take a while ...

Well, at least it only needs doing once.

>> ... mode2 (nice helpful, meaningful, name that has!)
>>
>> I'm not sure I can think of a meaningful name which isn't rather a
>> lot longer.
>
> <smile> ... well, something with "ir" in it, maybe, and something less
> superficially similar to "mode3"!

ir2 it is then. I'm not going to write the bug report though.

>>> I can see I have more fun ahead <smile>!
>>
>> Only if we end up having to reverse engineer the protocol. I'm
>> reasonably optimistic we won't.
>
> It's nice of you to say "we" -- you've been a great help already.

Thanks. You are doing all the actual work though. Thankfully you seem to
have enough of a clue to keep things moving in the right general direction.

ite-cir replaces lirc_it87, and yes it is newer.

That's RC-6. It's a bit longer than I get from my remotes, so it could
be RC-6-20. Timing is about 458. 444 is the standard, but my Sky remotes
are 433 and work fine, so it's close enough for rock and roll.

The alternating 7B and FB may be because of the toggle bit - which is
supposed to help debounce things, but isn't always used. CE is the
actual key code, but according to my
/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb, the code for stop
should be E6. My inference from that is that your remote does not have
the standard mceusb keymap. That's not good for being able to get things
tied into MythTV using a standard config file, unless we can identify
which config file it is.

> If I copy that file to /etc/lirc/lircd.conf and restart lirc I can then
> run irw and get:
>
> daniel@galette:~$ irw
> 000000037f917ba7 00 KEY_UP myremote
> 000000037f917ba7 01 KEY_UP myremote
> 000000037f917ba7 02 KEY_UP myremote
> 000000037f91fba4 00 KEY_RIGHT myremote
> 000000037f91fba4 01 KEY_RIGHT myremote
> 000000037f91fba4 02 KEY_RIGHT myremote
> 000000037f91fb6c 00 KEY_PLAY myremote
> 000000037f917bce 00 KEY_STOP myremote
> 000000037f917bce 01 KEY_STOP myremote
> 000000037f917bce 02 KEY_STOP myremote
> 000000037f917bce 03 KEY_STOP myremote
> ^C
> daniel@galette:~$
>
> *BINGO*!

We have ignition.

> I seem to have to hold each button down for quite some time (only a
> fraction of a second, but more than a rapid push) before I get any
> response, and then I tend to get multiple lines echoed by irw ... but I
> suppose that gets debounced somewhere along the line?

I'm guessing at this stage that the toggle bit setting might not be
right. I think the way that is supposed to work is that it is changed
every keypress, so you can distinguish between a constant keypress and
multiple individual keypresses. My remotes don't use it, so I'm not
sure, but there is a setting in the config file to try playing with.
There is also the mask, which can be set to ignore the byte of data
which may be causing that. In general remotes only actually send one of
256 codes, so only the one byte is actually needed. Lets worry about
that after we've got the keymap sorted though.

> I've regenerated lircrc and got something plausible-looking including
> same the keys as in lirc.conf ... however, those keys aren't doing
> anything in mythfrontend.
>
> I feel I'm getting close ...

There is certainly light at the end of the tunnel now. I'm not sure how
to find out whether there is already a keymap for your remote - looking
on the lirc site is the obvious check, but I couldn't find anything
which sounded like your remote on there. The complete absence of any
manufacturer or model info is a bit of a problem. There aren't any clues
inside the battery compartment are there, or any other text on the
thing? If we can't find that, we're left with creating the button map
with irrecord and possibly using the button names from the mceusb config
to make sure they get passed to MythTV in a way which makes sense to it.
At least we do now know enough to get the thing working.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Jim Price]

On 27/02/13 19:04, Daniel James wrote:
> In article <VA.0000078...@me.invalid>, Daniel James wrote:
>> I've regenerated lircrc and got something plausible-looking including
>> same the keys as in lirc.conf ... however, those keys aren't doing
>> anything in mythfrontend.
>
> Oh, I am an idiot!
>
> For some reason (probably because I was fiddling with it in the hope of
> getting things to work without actually having to understand how) I had
> the "LIRC daemon socket" setting in mythfrontend set to "/dev/lirc0"
> when it should have been "/dev/lircd" (obviously wrong, once you
> appreciate that /dev/lirc0 is a character device but /dev/lircd is a
> (symlink to a) socket).

Doh!

> It's now working for the buttons on the "media" side of the remote
> control. I haven't manager to get irrecord to recognize the sequences
> generated by pressing the buttons on the "qwerty" side of the remote
> control, yet. I just get:
>
> Something went wrong. Please try again. (N retries left)
>
> After 10 retries irrecord gives up and tells me to try with the -f
> (force raw) option.
>
> So, I tried that ... and I got
>
> ...
> Now hold down button "KEY_A"
> Got it.
> Signal length is 28
> That's weird because the signal length must be odd!
> Try again.
> ...
>
> But the signal length remains resolutely 28 however many times I try.
>
> Looks like the "qwerty" side isn't RC-6 (or anything else sensible)?

You mentioned that the qwerty side has a different IR sender - it is
entirely possible that it uses something completely different protocol
wise. That's going to need some grabs of the mode2 output and a spot of
head scratching to figure out. The "U" key is usually a good one, as
that has a group of alternating ones and zeros which are usually easy to
spot in the data stream.

> I must say, though, that using the remote control to control
> mythfrontend is a frustratingly slow process. I have to press each
> button for about a second to get any response from it, and even then the
> GUI takes a moment or two to respond. This is annoying as the GUI seems
> really snappy when used with a PC keyboard.

I have a feeling that the irrecord method has missed something, and the
delay is down to it not doing debouncing properly. To be honest, the
solution I always use is a One-For_All universal remote with the Philips
eHome receiver, as that responds quickly and uses built in config files.
Were you still using the output of irrecord in your lircd config? It
might be an idea to see if going back to the mceusb one helps response
time and debouncing.

> Anyhow, thanks again, Jim. I feel I owe you a beer, or something!

I'm enjoying myself anyway, but if you ever find yourself near the
mid-Wales border I wouldn't say no to a beer.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kglo1p$t5u$1...@dont-email.me>, Jim Price wrote:
> > Setting the *protocol*?
>
> In this case the protocol being RC-6.

Right ... but the "remote =" lines don't specify RC-6 by name, they
specify the name given to a particular set of remote codes defined in a
lirc.conf file (IIRC, I'm not at home at the moment and don't have the
Myth box available to refer to).

Looking closer ... it seems that the combination of a remote name and a
button name refer to a particular binary IR code, and both those names
are needed by lircrc to associate that code with the appropriate
"config =" string.

> A given remote will use a particular protocol.

That much seems sure ... though I'm not sure that my remote isn't
effectively two remotes in the same box (using different transmitter
LEDs), and these might not use the same protocol!

> There is a certain amount of standardisation, and the Philips eHome
> RC-6 is the one in theory you might be able to use more than one
> remote via the same receiver, but in practice that can be a can of
> worms if the two remotes you are trying to use each use a different
> protocol.

Yeah ... I've been reading up on RC-6.

I *suppose* (maybe wrongly) that a given Linux system could be set up
to recognize codes from multiple remotes. These would all have actions
defined in the same lircrc file, but might use different protocols
(i.e. one or more remotes might not use RC-6) and different definitions
in lirc.conf.

I'm wandering way off the point here, though ...

> This sort of stuff is unbelievably poorly documented on the internet,
> possibly because it is proprietary in a lot of cases.

Yes, indeed ... though I found this:

http://www.pcbheaven.com/userpages/The_Philips_RC6_Protocol/

fairly clear. Worth bookmarking, anyway.

>> So ... what's the point of having button definitions using
>> different protocols in the same lircrc file -- can a single
>> remote use different protocols for different buttons?
>
> In general, no. The exception is universal remotes, which can
> emulate more than one remote and assign buttons to produce output
> which can be of a different protocol for a different key on the
> remote.

Sorry, yes, that was meant to be rhetorical -- but good point about
universal remotes.

> I did a fair bit of stuff with re-programming the One-For-All
> remotes a few years ago, based on the JP1 software from here:
>
> http://www.hifi-remote.com/forums
>

> Their IR protocol page is the best source of low level remote info
> on the net, if a little bit cryptic for the beginner:
>
> http://www.hifi-remote.com/johnsfine/DecodeIR.html

Interesting, thanks for the links.

>> I do note that the "No Additional Remote Support" option in the
>> control centre says "If you don't have a remote right now, or it's
>> supported natively". I'd overlooked that ... perhaps I should play
>> with the "supported natively" option?
>
> Worth a try I suppose. However, the supported natively means via the
> virtual keyboard method, whereas your remote is going to have to go
> via lirc. The test for this is one you've already done - do the
> number keys produce numbers in a terminal.

Ah, no ... I think I misunderstood ... my remote doesn't /have/ number
keys (on the "media" side) ... I tried other buttons and got no output
but I couldn't try numbers.

>> Oh dear: "The application Mythbuntu Control Centre has closed
>> unexpectedly". It's not the first time I've seen that!
>
> Which version of MythTV are you running? 0.25 is what you get by
> default in 12.04, but there is an upgrade to 0.26 available with
> relatively little hassle in 12.04.

I think it's 0.25, yes. I'll check later. It's the most recent that was
flagged as "stable".

I should have thought of looking for updates.

> My current router does support IPv6 - rather a lot better than my
> ISP supports it, but I'm looking at changing ISP in the near future
> to one which does (A+A have a new Home::1 tariff, which looks good).

I use A&A (but not the new tariff). Their reputation for knowing their
stuff seems well-deserved.

>> <smile> ... well, something with "ir" in it, maybe, and something
>> less superficially similar to "mode3"!
>
> ir2 it is then. I'm not going to write the bug report though.

<smile> again! I was thinking of something more like "ir_raw_scan"!

>> It's nice of you to say "we" -- you've been a great help already.
>
> Thanks. You are doing all the actual work though. Thankfully you
> seem to have enough of a clue to keep things moving in the right
> general direction.

That's the nicest thing anyone has said to me in ages!

I'm not afraid of a steep learning curve, as long as I can get some
traction ... and at least the config files aren't XML!

> ite-cir replaces lirc_it87, and yes it is newer.

Great. Thanks for confirming that.

>> Is that 0x7BCE what you'd expect from the pulse/space values above?
>
> The alternating 7B and FB may be because of the toggle bit - which
> is supposed to help debounce things, but isn't always used. CE is
> the actual key code, but according to my
> /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb, the code for stop
> should be E6. My inference from that is that your remote does not
> have the standard mceusb keymap. That's not good for being able to
> get things tied into MythTV using a standard config file, unless we
> can identify which config file it is.

I've now recorded a handful of keys, and there doesn't seem to be any
correspondence with the values from other configurations that I've
looked at -- though I haven't looked at them all.

I can, at lest, record them from scratch, and that does seem to work.

> ... looking on the lirc site is the obvious check, but I couldn't

> find anything which sounded like your remote on there. The complete
> absence of any manufacturer or model info is a bit of a problem.

I'm guessing that Acer made it themselves ... they're not known for
rebadging third-party kit they could have made themselves, and anything
third-party would probably have contained a clue as to who actually
made it.

The codes from the only other Acer remote that I have a config file for
are nothing like, though.

> If we can't find that, we're left with creating the button map with
> irrecord and possibly using the button names from the mceusb config
> to make sure they get passed to MythTV in a way which makes sense to
> it. At least we do now know enough to get the thing working.

irrecord seems to be the key here, and I'm happy that I can use that.

.. except that -- as I said in my other post -- it doesn't recognize
the keys from the "qwerty" side of the remote!

Cheers,
Daniel.

[Jim Price]

On 28/02/13 00:12, Daniel James wrote:
> In article <kglo1p$t5u$1...@dont-email.me>, Jim Price wrote:

>> This sort of stuff is unbelievably poorly documented on the internet,
>> possibly because it is proprietary in a lot of cases.
>
> Yes, indeed ... though I found this:
>
> http://www.pcbheaven.com/userpages/The_Philips_RC6_Protocol/
>
> fairly clear. Worth bookmarking, anyway.

Ta. Added to my list.

>> Which version of MythTV are you running? 0.25 is what you get by
>> default in 12.04, but there is an upgrade to 0.26 available with
>> relatively little hassle in 12.04.
>
> I think it's 0.25, yes. I'll check later. It's the most recent that was
> flagged as "stable".

0.26 was released sometime late last year so I'm planning on trying an
upgrade to that on my test system in the not too distant.

> I should have thought of looking for updates.
>
>> My current router does support IPv6 - rather a lot better than my
>> ISP supports it, but I'm looking at changing ISP in the near future
>> to one which does (A+A have a new Home::1 tariff, which looks good).
>
> I use A&A (but not the new tariff). Their reputation for knowing their
> stuff seems well-deserved.

I've used them before at work. Now my exchange has got 21CN the data
allowance has gone up by a factor of 2.5, which makes them not much more
expensive than the hopeless ones.

> I've now recorded a handful of keys, and there doesn't seem to be any
> correspondence with the values from other configurations that I've
> looked at -- though I haven't looked at them all.
>
> I can, at lest, record them from scratch, and that does seem to work.

That does look like you're confirming what I suspected about the
different (from mceusb) keymap.

>> ... looking on the lirc site is the obvious check, but I couldn't
>> find anything which sounded like your remote on there. The complete
>> absence of any manufacturer or model info is a bit of a problem.
>
> I'm guessing that Acer made it themselves ... they're not known for
> rebadging third-party kit they could have made themselves, and anything
> third-party would probably have contained a clue as to who actually
> made it.
>
> The codes from the only other Acer remote that I have a config file for
> are nothing like, though.

Standards, eh? We've got lots of them...

>> If we can't find that, we're left with creating the button map with
>> irrecord and possibly using the button names from the mceusb config
>> to make sure they get passed to MythTV in a way which makes sense to
>> it. At least we do now know enough to get the thing working.
>
> irrecord seems to be the key here, and I'm happy that I can use that.
>
> .. except that -- as I said in my other post -- it doesn't recognize
> the keys from the "qwerty" side of the remote!

It does seem strange, and looking around there isn't much about that
remote anywhere - even people who sell the RL70 don't seem to include or
mention it much.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kglp7l$4j7$1...@dont-email.me>, Jim Price wrote:
>> Looks like the "qwerty" side isn't RC-6 (or anything else
>> sensible)?
>
> You mentioned that the qwerty side has a different IR sender - it
> is entirely possible that it uses something completely different
> protocol wise. That's going to need some grabs of the mode2 output
> and a spot of head scratching to figure out. The "U" key is usually
> a good one, as that has a group of alternating ones and zeros which
> are usually easy to spot in the data stream.

Sorry, been away from home for a couple of days without access to the
RL70 ...

I recorded the pulses from the 'u' key, as you suggested. Here they
are:

space 5692013
pulse 512
space 182
pulse 269
space 173
pulse 269
space 503
pulse 269
space 338
pulse 269
space 668
pulse 269
space 338
pulse 260
space 182
pulse 269
space 503
pulse 260
space 182
pulse 269
space 173
pulse 269
space 503
pulse 234
space 538
pulse 260
space 347
pulse 269
space 71757
pulse 512
space 182
pulse 269
space 173
pulse 269
space 503
pulse 269
space 338
pulse 269
space 668
pulse 269
space 338
pulse 295
space 147
pulse 260
space 512
pulse 260
space 182
pulse 269
space 503
pulse 295
space 477
pulse 269
space 503
pulse 269
space 338
pulse 269
pulse 100037

It looks to me as though that may be two sequences, one for key-down
and another for key-up.

When I ran irrecord I did get an output file. It doesn't contain any
key recordings, but there is a header which may be of interest:

[snip comments for brevity]

begin remote

name mykeys
bits 13
flags SPACE_ENC
eps 30
aeps 100

header 486 208
one 234 596
zero 234 269
gap 164241
toggle_bit_mask 0x0

begin codes
end codes

end remote

I don't know whether you (or your spreadsheet) can make any sense of
that?

>> Anyhow, thanks again, Jim. I feel I owe you a beer, or something!
>
> I'm enjoying myself anyway, but if you ever find yourself near the
> mid-Wales border I wouldn't say no to a beer.

I'm in the London suburb of Berkshire (smile) so not exactly on your
doorstep ... but I'll try to remember if I find myself over your way.

Cheers,
Daniel.

[Daniel James]

In article <kgoqbc$7rf$1...@dont-email.me>, Jim Price wrote:
>> I think it's 0.25, yes. I'll check later. It's the most recent
>> that was flagged as "stable".
>
> 0.26 was released sometime late last year so I'm planning on
> trying an upgrade to that on my test system in the not too distant.

Oh, decisions ...

I went for Mythbuntu because it appeared to be an easy way to get a
complete MythTV setup installed with minimal fuss (I know my way around
Linux but I'm still learning Myth -- as you can tell). I'd forgotten
how much I don't care for XFCE, though. If I'm going to upgrade Myth I
might bite the bullet and do a complete reinstall starting with regular
Ubuntu or perhaps Debian ...

Does installing the appropriate MythTV package(s) on the standard
desktop OS bring in and set up everything that Mythbuntu gives you as
standard (in terms of MythTV itself, I mean) or will I have a lot more
faffing about to do?

At least now I (think I) understand what the hardware is!

>> I use A&A (but not the new tariff). Their reputation for knowing
>> their stuff seems well-deserved.
>
> I've used them before at work. Now my exchange has got 21CN the data
> allowance has gone up by a factor of 2.5, which makes them not much
> more expensive than the hopeless ones.

I like "not much more expensive than the hopeless ones", that seems a
fair summary. I wouldn't want to do too many heavy downloads -- or
watch internet TV -- during the day on an A&A line, but with 2 units a
month on 21CN and keeping big downloads until the evening I've never
come near my monthly allowance.

>> I can, at lest, record them from scratch, and that does seem to
>> work.
>
> That does look like you're confirming what I suspected about the
> different (from mceusb) keymap.

I haven't had the chance to sit down and record the whole set, yet (and
may not for a couple of weeks) but those I have recorded all seem to
work as expected. I'll upload the whole set to the lirc site when I get
a chance.

>> .. except that -- as I said in my other post -- it doesn't
>> recognize the keys from the "qwerty" side of the remote!
>
> It does seem strange, and looking around there isn't much about that
> remote anywhere - even people who sell the RL70 don't seem to
> include or mention it much.

It is weird, isn't it?

Mind you, there are several models of RL70 and not all of them are
supplied with a remote control (or have the sensor fitted). The one I
have is Acer stock number DT.SJEEK.009 which (in addition to the "basic
spec") has the TV card, the remote and sensor, and a Blu-ray combo
drive (reads Blu-ray, writes DVD and CD). The HDD is advertised at
640GB but I actually got a 750GB drive (that's not uncommon, I gather),
and I have 4GB RAM (2x2GB SODIMM) ... other models come with less. This
model also has a rather plasticky but usable USB wireless
keyboard/mouse combo.

Where was I? Oh, yes ... it's really quite hard to tell from the
information put out by Acer or their dealers which models of RL70 have
the keyboard and mouse (and whether it's the wired or wireless set),
let alone whether the remote is included.

I'm really surprised Acer don't make more noise about this particular
model, as I think it's just about perfect for a PVR box and comes at a
very good price. The only thing missing is an HD tuner.

Cheers,
Daniel

[Martin Liddle]

On 03/03/2013 00:27, Daniel James wrote:

> I'm really surprised Acer don't make more noise about this particular
> model, as I think it's just about perfect for a PVR box and comes at a
> very good price.
>

As a matter of interest, what price was it?


--
Martin Liddle, Tynemouth Computer Services, Chesterfield, Derbyshire,UK
http://www.tynecomp.co.uk

[Daniel James]

In article <513300a5$0$63805$862e...@ngroups.net>, Martin Liddle
wrote:

> As a matter of interest, what price was it?

£280 (in VAT) plus or minus. I got mine from CCL (because I was buying
some other stuff at the same time) but Acer Direct and a few other have
the same model a whisker cheaper.

Just Google for the model number: DT.SJEEK.009

Cheers,
Daniel.

[Martin Liddle]

On 03/03/2013 20:02, Daniel James wrote:
>
> Ł280 (in VAT) plus or minus. I got mine from CCL (because I was buying

> some other stuff at the same time) but Acer Direct and a few other have
> the same model a whisker cheaper.
>

So what advantages does MythTv offer over a commercial PVR running Linux
such as the Humax HDR-FOX T2 (which has a significant number of user
community add ons)?

[Jim Price]

On 03/03/13 00:27, Daniel James wrote:
> In article <kgoqbc$7rf$1...@dont-email.me>, Jim Price wrote:
>>> I think it's 0.25, yes. I'll check later. It's the most recent
>>> that was flagged as "stable".
>>
>> 0.26 was released sometime late last year so I'm planning on
>> trying an upgrade to that on my test system in the not too distant.
>
> Oh, decisions ...
>
> I went for Mythbuntu because it appeared to be an easy way to get a
> complete MythTV setup installed with minimal fuss (I know my way around
> Linux but I'm still learning Myth -- as you can tell). I'd forgotten
> how much I don't care for XFCE, though. If I'm going to upgrade Myth I
> might bite the bullet and do a complete reinstall starting with regular
> Ubuntu or perhaps Debian ...

You can just install other desktop environments in Mythbuntu. I'm not
that keen on XFCE myself.

> Does installing the appropriate MythTV package(s) on the standard
> desktop OS bring in and set up everything that Mythbuntu gives you as
> standard (in terms of MythTV itself, I mean) or will I have a lot more
> faffing about to do?

You can do it that way, and there isn't much faff if your TV card is
supported. I've gone a different way, and my normal desktop build is to
install 64bit Mythbuntu 12.04 followed by my standard package list and
then add the MATE desktop (mainly for the Caja file manager, which is a
fork of the old Gnome2 Nautilus) and configure Enlightenment as my
preferred desktop environment. Enlightenment handles multiple monitors
in a manner I prefer. This means I avoid Unity altogether, I get the
option to upgrade to more recent versions of MythTV built in (as do all
versions of 12.04), and have a choice of desktop environments, some of
which still work with FreeNX unlike the latest 3D desktop abominations
(Unity, Gnome3 etc.). Mythbuntu is delightfully free of extraneous
bloat, and ideal as a base install for use with a different desktop
IMHO. Stock Ubuntu with Unity is not.

>> I've used them before at work. Now my exchange has got 21CN the data
>> allowance has gone up by a factor of 2.5, which makes them not much
>> more expensive than the hopeless ones.
>
> I like "not much more expensive than the hopeless ones", that seems a
> fair summary. I wouldn't want to do too many heavy downloads -- or
> watch internet TV -- during the day on an A&A line, but with 2 units a
> month on 21CN and keeping big downloads until the evening I've never
> come near my monthly allowance.

That's my plan. I've just been implementing measures to make sure I
can't accidentally download more than a reasonable amount during peak
hours, so all I need to do now is steel myself for the horror that is
talking to Talk-Talk to get a MAC code. Then I can undo all the stupid
things I've had to do to my machines to make them work on the Talk-Talk
infrastructure.

>>> I can, at lest, record them from scratch, and that does seem to
>>> work.
>>
>> That does look like you're confirming what I suspected about the
>> different (from mceusb) keymap.
>
> I haven't had the chance to sit down and record the whole set, yet (and
> may not for a couple of weeks) but those I have recorded all seem to
> work as expected. I'll upload the whole set to the lirc site when I get
> a chance.

Good stuff.

> Mind you, there are several models of RL70 and not all of them are
> supplied with a remote control (or have the sensor fitted). The one I
> have is Acer stock number DT.SJEEK.009 which (in addition to the "basic
> spec") has the TV card, the remote and sensor, and a Blu-ray combo
> drive (reads Blu-ray, writes DVD and CD). The HDD is advertised at
> 640GB but I actually got a 750GB drive (that's not uncommon, I gather),
> and I have 4GB RAM (2x2GB SODIMM) ... other models come with less. This
> model also has a rather plasticky but usable USB wireless
> keyboard/mouse combo.
>
> Where was I? Oh, yes ... it's really quite hard to tell from the
> information put out by Acer or their dealers which models of RL70 have
> the keyboard and mouse (and whether it's the wired or wireless set),
> let alone whether the remote is included.
>
> I'm really surprised Acer don't make more noise about this particular
> model, as I think it's just about perfect for a PVR box and comes at a
> very good price. The only thing missing is an HD tuner.

Due to local mountains I don't get terrestrial TV here, so I have to do
satellite, but other than that it does sound pretty good for the 90-odd
percent of the population with terrestrial TV coverage.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Jim Price]

On 03/03/13 00:27, Daniel James wrote:

There does seem to be a break in the middle. The rest of it definitely
makes no sense as an RC-6 stream. I'm mainly tooled up to do RC-6 stuff
here, but I'll see if I can find another protocol which might fit that
sort of stream. What might help is if there is a driver for the Windows
version which I could have a look at. I found an FIR driver on the Acer
support site, but FIR is fast infrared, usually associated with IrDA,
and that is not something which lirc is going to do well. That doesn't
explain how you got any output from mode2 though, so I'm not sure what
is going on there. I don't seem to be able to extract the cab files from
that driver either.

> When I ran irrecord I did get an output file. It doesn't contain any
> key recordings, but there is a header which may be of interest:
>
> [snip comments for brevity]
>
> begin remote
>
> name mykeys
> bits 13
> flags SPACE_ENC
> eps 30
> aeps 100
>
> header 486 208
> one 234 596
> zero 234 269
> gap 164241
> toggle_bit_mask 0x0
>
> begin codes
> end codes
>
> end remote
>
> I don't know whether you (or your spreadsheet) can make any sense of
> that?

My spreadsheet only does RC-6, so no joy there. It is entirely possible
that they have come up with their own protocol based on how a keyboard
works rather than a traditional remote. The RC-6 keyboards I have are
rather limited as PC keyboards - no concept of control or alt keys and
no function keys.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Daniel James]

In article <kh0hnn$glq$1...@dont-email.me>, Jim Price wrote:
>> I recorded the pulses from the 'u' key, as you suggested. Here they
>> are:
>>
>> space 5692013
>> pulse 512
>> space 182

[snip]

>> space 338
>> pulse 269
>> pulse 100037
>>
>> It looks to me as though that may be two sequences, one for key-down
>> and another for key-up.
>
> There does seem to be a break in the middle. The rest of it
> definitely makes no sense as an RC-6 stream.

I feared as much -- thanks for taking a look.

> I'm mainly tooled up to do RC-6 stuff here, but I'll see if I can
> find another protocol which might fit that sort of stream.

I wouldn't want you to spend time on that on my account. I'm rather going
off the thought of using this remote in anger, given the very slow
responses I'm getting from the media side. Pity, as it's a nice-looking
unit.

> What might help is if there is a driver for the Windows
> version which I could have a look at.

I wiped the windows install that was on the hard drive, and there's no
install disk I can easily look at. I *did* make backup media before I
wiped it, but I don't know what format they're in and I don't really want
to wipe my current system and reinstall Windows just to look for a driver
(that may not be there anyway).

> My spreadsheet only does RC-6, so no joy there. It is entirely
> possible that they have come up with their own protocol based on how
> a keyboard works rather than a traditional remote.

That doesn't sound at all unlikely, I agree.

> The RC-6 keyboards I have are rather limited as PC keyboards - no
> concept of control or alt keys and no function keys.

Ah ... I don't think it has those. Again, I'm not where the unit is so I
can't check it, but there are certainly no function keys, and the picture
I posted a link to on 25th February doesn't seem to show Ctrl or Alt.

.. that does rather limit its usefulness as a keyboard ... but it also
means it may be a simpler protocol.

Don't worry too much about it. I probably won't have time to play with it
much in the next couple of weeks, anyway. I'll let you know if I discover
anything new.

Cheers,
Daniel.

[Daniel James]

In article <5133b0ea$0$12725$862e...@ngroups.net>, Martin Liddle wrote:
> So what advantages does MythTv offer over a commercial PVR running
> Linux such as the Humax HDR-FOX T2 (which has a significant number
> of user community add ons)?

Good question ... from my point of view running either MythTV or
something like XBMC on an actual PC has the advantage that I have more
control over what the box does and how it does it -- and, or course, the
box is a full PC so it can be used for non-TV-related things as well.

I haven't used a Humax box, so I don't know exactly what can be done
with it and what can't, but MythTV is pretty flexible and seems to offer
all the things I want to do. It also plays optical disks (the Acer box I
have can play Blu-ray disks, I'm not sure yet whether Myth handles those
as I haven't any disks to try!) ... and, of course, I can use the box to
view iPlayer and its ilk as well.

The Humax box probably uses less electricity. I haven't measured the
consumption of the Acer box, yet, but I'm expecting something around 20W
when it's powered up, more (maybe significantly more) when it's playing
video.

Cheers,
Daniel.

[Daniel James]

In article <kh0g55$7r0$1...@dont-email.me>, Jim Price wrote:
> You can just install other desktop environments in Mythbuntu. I'm not
> that keen on XFCE myself.

Yes, of course ... but Xubuntu makes other decisions for you (chromium
instead of firefox, for example) that I'd also want to change.

I can either spend time changing packages in Mythbuntu to get something
more like the Ubuntu boxes I'm used to, or I can start again with
Ubuntu or Debian and spend time adding packages to get myth running --
trouble is, I don't know exactly what's needed for that (which is
probably a good reason to try it!)

>> Does installing the appropriate MythTV package(s) on the standard
>> desktop OS bring in and set up everything that Mythbuntu gives you
>> as standard (in terms of MythTV itself, I mean) or will I have a
>> lot more faffing about to do?
>
> You can do it that way, and there isn't much faff if your TV card is
> supported. I've gone a different way, and my normal desktop build is

> to install 64bit Mythbuntu 12.04 ...

.. which is what I've done so far ...

> ... followed by my standard package list and then add the MATE

> desktop (mainly for the Caja file manager, which is a fork of the
> old Gnome2 Nautilus) and configure Enlightenment as my preferred
> desktop environment.

Makes sense. I'm getting more fond of Nautilus the more I use it (on
10.04) ... I used to prefer Konqueror under KDE but now that KDE has
gone with Dolphin I prefer Gnome more than ever.

I've not yet tried MATE or Cinnamon or any of that crowd, but I keep
hearing how good they are, so maybe that's something I should play with
soon.

> Mythbuntu is delightfully free of extraneous bloat, and ideal as a
> base install for use with a different desktop IMHO. Stock Ubuntu
> with Unity is not.

Fair enough.

> Due to local mountains I don't get terrestrial TV here, so I have to
> do satellite, but other than that it does sound pretty good for the
> 90-odd percent of the population with terrestrial TV coverage.

You win some you lose some ... I wish I had some local mountains!

Cheers,
Daniel.

[Tony Houghton]

In <5133b0ea$0$12725$862e...@ngroups.net>,

Martin Liddle <new...@tynecomp.co.uk> wrote:

> On 03/03/2013 20:02, Daniel James wrote:
>>

>> £280 (in VAT) plus or minus. I got mine from CCL (because I was buying

>> some other stuff at the same time) but Acer Direct and a few other have
>> the same model a whisker cheaper.
>>
> So what advantages does MythTv offer over a commercial PVR running Linux
> such as the Humax HDR-FOX T2 (which has a significant number of user
> community add ons)?

Does the Humax have a web server for setting timers etc remotely? That's
a big must for me. Also, IME STB makers are living in the past and think
that people with 16:9 TVs are in a minority. Whenever I visited my aunt
I used to have to correct the option for her, so the box obviously
resets the option when switched off. Things have changed since she
upgraded her TV to an LCD with HDMI: now I can't correct it: the 16:9
anamorphic option is no longer available in the STB!

Humax must have seen so many of their customers watching squashed
pictures perhaps they've convinced themselves everyone prefers it that
way and don't want their nephews fiddling with things.

[Jim Price]

On 04/03/13 13:29, Daniel James wrote:
> In article <kh0g55$7r0$1...@dont-email.me>, Jim Price wrote:

>> You can just install other desktop environments in Mythbuntu. I'm not
>> that keen on XFCE myself.
>
> Yes, of course ... but Xubuntu makes other decisions for you (chromium
> instead of firefox, for example) that I'd also want to change.

My package list sorts almost all of that out - I just have to set the
preferred apps if I leave any behind which might not be my first choice.
If you have another Ubuntu box which has what you want on it, export the
package list from that and use it to bring the Mythbuntu box in line
with what you want on it. I usually check the package list for hardware
specific things (removing the ATI proprietary drivers for systems where
they won't work is the main one) and remove the lib files as they get
picked up as dependencies anyway. I use Firefox, Thunderbird, and
several of the other standard Ubuntu apps on Mythbuntu with no issues.

> I can either spend time changing packages in Mythbuntu to get something
> more like the Ubuntu boxes I'm used to, or I can start again with
> Ubuntu or Debian and spend time adding packages to get myth running --
> trouble is, I don't know exactly what's needed for that (which is
> probably a good reason to try it!)

Indeed. You don't learn anything by not trying stuff. I've tried MythTV
on a number of different distros, but Mythbuntu won out in my version of
that particular exercise. I'm not interested in non-apt based
distributions unless someone is paying me to be.

>>> Does installing the appropriate MythTV package(s) on the standard
>>> desktop OS bring in and set up everything that Mythbuntu gives you
>>> as standard (in terms of MythTV itself, I mean) or will I have a
>>> lot more faffing about to do?
>>
>> You can do it that way, and there isn't much faff if your TV card is
>> supported. I've gone a different way, and my normal desktop build is
>> to install 64bit Mythbuntu 12.04 ...
>
> .. which is what I've done so far ...
>
>> ... followed by my standard package list and then add the MATE
>> desktop (mainly for the Caja file manager, which is a fork of the
>> old Gnome2 Nautilus) and configure Enlightenment as my preferred
>> desktop environment.
>
> Makes sense. I'm getting more fond of Nautilus the more I use it (on
> 10.04) ... I used to prefer Konqueror under KDE but now that KDE has
> gone with Dolphin I prefer Gnome more than ever.
>
> I've not yet tried MATE or Cinnamon or any of that crowd, but I keep
> hearing how good they are, so maybe that's something I should play with
> soon.

Mate is definitely worth a try - with only a minimal amount of
configuration you can make a 12.04 box look and feel like a 10.04 box
with a reduction in the number of little annoyances compared to Gnome2.
Personally I prefer Enlightenment, but a lot of people bounce off that
before they learn what it can do.

--
╔═╦═╦═════╦═══╗
║ ║ ║ ║ ║
╔═╝ ║ ║ ║ ║ ║ ╔═╝
╚═══╩═╩═╩═╩═╩═╝ -- JimP.

[Martin Liddle]

On 04/03/2013 17:02, Tony Houghton wrote:
>
> Does the Humax have a web server for setting timers etc remotely? That's
> a big must for me.

The standard firmware does not but the custom firmware (which enhances
rather than replaces the standard firmware) has a remote scheduling
capability; you make the reservations on a portal which the box polls
from time to time to update its recording schedule

> Also, IME STB makers are living in the past and think
> that people with 16:9 TVs are in a minority. Whenever I visited my aunt
> I used to have to correct the option for her, so the box obviously
> resets the option when switched off. Things have changed since she
> upgraded her TV to an LCD with HDMI: now I can't correct it: the 16:9
> anamorphic option is no longer available in the STB!
>

We have never had a problem with aspect ratio changes failing to stick;
not surprisingly it will be lost when resetting the box to default
settings but I don't remember having to do that in the two and a bit
years we have owned the box.