[mythtv-users] 1212 and channel changing

[Jarod Wilson]

On Wednesday 26 August 2009 14:08:57 Jarod Wilson wrote:
> On Aug 25, 2009, at 7:48 PM, David Engel wrote:
...
> > For example, a quick press of the OK button when running irw resulted
> > in the following output:
> >
> > 00000000000017a5 00 OK Hauppauge_350
> > 00000000000017a5 01 OK Hauppauge_350
> > 00000000000017a5 02 OK Hauppauge_350
> > 00000000000017a5 03 OK Hauppauge_350
> > 00000000000017a5 04 OK Hauppauge_350
> > 00000000000017a5 05 OK Hauppauge_350
> > 00000000000017a5 06 OK Hauppauge_350
> > 00000000000017a5 07 OK Hauppauge_350
> > 00000000000017a5 00 OK Hauppauge_350
> > 00000000000017a5 01 OK Hauppauge_350
> > 00000000000017a5 02 OK Hauppauge_350
> > 00000000000017a5 03 OK Hauppauge_350
> > 00000000000017a5 04 OK Hauppauge_350
> > 00000000000017a5 05 OK Hauppauge_350
> > 00000000000017a5 06 OK Hauppauge_350
> > 00000000000017a5 07 OK Hauppauge_350
> >
> > Longer presses of the OK button resulted in more sets of 8 events.
> > Methinks each set of 8 events should be reported as one event with
> > repeats marked appropriately.  IOW, I would expect the output to look
> > like the forllowing:
> >
> > 00000000000017a5 00 OK Hauppauge_350
> > 00000000000017a5 01 OK Hauppauge_350
> 
> Seems its about time I pull my HD PVR out from behind the AV cabinet  
> so I can actually fire IR signals at it... Just tied up with other  
> driver work at the moment...
> 
> 

Finally got around to some in-depth lirc_zilog hacking tonight, I've
now got the following spit out:

$ irw
000000000000178f 00 Mute Hauppauge_350
000000000000178f 01 Mute Hauppauge_350
0000000000001792 00 Prev.Ch Hauppauge_350
0000000000001792 01 Prev.Ch Hauppauge_350
0000000000001792 02 Prev.Ch Hauppauge_350
00000000000017b0 00 Pause Hauppauge_350
00000000000017b0 01 Pause Hauppauge_350
00000000000017b0 02 Pause Hauppauge_350
00000000000017b5 00 Play Hauppauge_350
00000000000017b5 01 Play Hauppauge_350

In other words, its behaving as expected. Its a kludgy fix though, and
one likely to break lirc_zilog with other devices, possibly...

The root problem is that there's a check in add_to_buf() that isn't
ever triggering (if ((ir->b[0] & 0x80) == 0)), so we're looping a good
long time, until we fill the entire buffer -- which fills after 8
iterations. My hack is to simply return if (got_data), after sending it
out to userspace.

Nb: I can't actually modprobe -r lirc_zilog, it hangs -- some of the
completion stuff fails to, well, complete... Some sort of deadlock with
ir_detach() that I need to hunt down, I think. (To be quite honest, a
fair amount of this driver is a bit dodgy, and admits as much in some
of its comments...)

-- 
Jarod Wilson
jarod at wilsonet.com