On 07/01/2009 06:28 PM, Eloy Paris wrote:
> My mceusb2 remote was not working for me after a resume from S3 sleep.
> It would work when the resume was initiated by pressing the power button
> of the PC but not when the resume was initiated by pressing the Power
> button of my remote (I do 'echo "USB0"> /proc/acpi/wakeup' to be able
> to do do this.)
>
> By comparing the kernel messages in the two scenarios I noticed that the
> following message was missing in the failure case:
>
> lirc_mceusb2[2]: resume
>
> This led me to try the following patch:
>
> --- lirc_mceusb2.c.orig 2009-01-28 16:56:52.000000000 -0500
> +++ lirc_mceusb2.c 2009-01-28 16:29:26.000000000 -0500
> @@ -1121,6 +1121,7 @@
> #if LINUX_VERSION_CODE>= KERNEL_VERSION(2, 6, 0)
> .suspend = usb_remote_suspend,
> .resume = usb_remote_resume,
> + .reset_resume = usb_remote_resume,
> #endif
> .id_table = usb_remote_table
> };
>
> This did the trick and I have been using this for a few months now. Not
> sure if this is correct but it's the only way I can suspend and resume
> (and then continue to use my remote) using the remote's Power button. No
> ill or side effects that I've noticed. Another user on the mythtv-users
> mailing list was having the same issues and after applying the above
> patch was able to get it work.
>
> This was for 0.8.4a. 0.8.5 changes function names but the driver
> structure is still missing a .reset_resume field.
Thanks much, looks perfectly sane to me, committed to cvs now.
--
Jarod Wilson
jarod@...

On 07/02/2009 12:28 PM, Rene Harder wrote:
> Hi Jarod,
>
> As discussed I had a look at the kernel ati_remote2 driver to get an
> idea how the loadable keymap support works.
> It looks promising so far, although i still have some concerns (e.g.
> maximum size of scancodes ...).
>
> An onboard encoded packet for the imon's with touchscreen are 8 bytes
> long, I think the next to last byte is device specific and do not
> contain any button press information, does it?
> So I think we need at least 7 bytes to be able to map all remote codes
> to keycodes, maybe you know more bytes which we can drop because they
> don't contain any information about the button presses.
Hm... I was thinking both bytes 7 and 8 could be dropped, but it seems
byte 7 is the only device-specific one... 8 seems to be perhaps
input-type-specific (at least to some degree)...
> Now, I'm wondering how much do the packets of the remote defer between
> the different imon models?
>
> Here are some packets of the 15c2:0034 imon touchscreen
With my 15c2:0045 packets for the same keys below...
> 0x288195B700001401 AppExit - remote
> 0x289115B700001401 Power - remote
> 0x298115B700001401 Record - remote
> 0x2A8115B700001401 Play - remote
0x2881d5b700000201 # AppExit - remote
0x289115b700000201 # Power - remote
0x298115b700000201 # Record - remote
0x2a8115b700000201 # Play - remote
> 0x0200002800000000 Enter - remote
> 0x0200002900000000 ESC - remote
0x0200002800000201 # ENTER - remote
0x0200002900000201 # Esc - remote
> 0x0200001E00000000 1 - remote
> 0x0200001F00000000 2 - remote
0x0200001e00000201 # 1 - remote
0x0200001f00000201 # 2 - remote
> 0x0000002B000014EE AppExit - frontpanel
> 0x00000017000014EE ESC - frontpanel
Don't have either of those on my front panel, but do have these:
0x00000000040002ee # Stop - front panel
0x00000000060002ee # Next - front panel
0x00010000000002ee # Volume Up (CW)
0x01000000000002ee # Volume Down (CCW)
0x00000000010002ee # Mute (Volume Knob Push)
> 0x0XXX0YYY____1486 Touchscreen
Obviously don't have that either.
So generally, it looks like byte 7 is device-specific, and byte 8 says
whether its from the remote or the front panel or touchscreen, maybe?
Oh, fyi, my entire remote config is in lirc cvs, under
remotes/imon/lircd.conf.imon-antec-veris.
I can check a few things on my brother's iMON Knob as well, but I'm
pretty sure its covered by remotes/imon/lircd.conf.imon-knob or -pad...
--
Jarod Wilson
jarod@...

On 07/02/2009 09:40 PM, awmawlawd wrote:
> dear sirs,
>
> today i received a HP ir receiver and a RC6 remote combo from hong kong
> which i won on ebay for $17. they said the receiver was an authentic HP.
> i don't know how true that is, but that's not important.
>
> lsusb returned: ID 045e:006d Microsoft Corp. eHome Remote Control
> Keyboard keys
Yup, I've got the same device. At least, I have the transceiver, don't
have the original remote that came with it.
> i followed lirc instructions very closely and attempted to compile 0.8.5
> with mceusb driver. it compiled successfully and i proceeded to launch a
> "lircd" and then "irw." this is when the problem came. in irw, whenever
> i would push a button on any remote, the entire system froze and i had
> to manually reboot it.
Hrm. Not good. Haven't seen that myself, but mine isn't "in production",
I only occasionally pull it out to poke at. As it happens though, I've
been poking at it a LOT the past few days...
> i dont know what the problem was but i was in #mythtv-users and i asked
> for suggestions. some jerk started hassling me about mceusb2 and telling
> me to read the documentation, so i tried the same thing above but with
> mceusb2. it didn't work.
Nope, you have the original device, which was only supported by the
lirc_mceusb driver. Until a few minutes ago, that is. I just committed a
bunch of changes to lirc cvs, which add support for that device to
lirc_mceusb2, then renamed lirc_mceusb2 to lirc_mceusb, since there's no
need anymore for a "2" driver, all devices are supported by the one and
only.
> i also entered this jerk's name in google and
> his wow profile came up-- he was a level 70 hunter. i told him his
> suggestion did not help and he started giving me a lecture on how people
> don't read documentation.
Sorry to hear that, but irrelevant here. :)
> after arguing with him, some other guy
> suggested i try a different version.
>
> so, i downloaded 0.8.4a and followed the same procedure to install
> (mceusb driver-- NOT MCEUSB2 like the huntard suggested). after a
> reboot, i was in irw mashing remote buttons and getting a response. all
> was well. no more crashing.
>
> so if you have the same remote, use 0.8.4a with mceusb
I won't bother to try tracking down what broke, since current cvs and
lirc 0.8.6 and later simply drop the code in question. So sure, stick to
either lirc 0.8.4a or go with current cvs/lirc-0.8.6pre2 (not yet
released) or later (using driver lirc_mceusb in both cases).
--
Jarod Wilson
jarod@...

On 07/04/2009 01:27 AM, Jarod Wilson wrote:
> On Jul 2, 2009, at 2:38 AM, Jarod Wilson<jarod@...> wrote:
>
>> Beat on lirc_mceusb2
>> a bunch tonight, inching closer to functionality w/the first-gen
>> device
>
>
> I've now got IR receive 100% functional using a first-gen mceusb
> receiver with the mceusb2 driver, so the old driver will be going away
> soon. Internet access is horrible here (yes, I'm spending part of my
> vacation by hacking on lirc...), so it won't officially show up for a
> few more days. No regressions w/the 2nd-gen receiver either, fwiw. All
> testing done w/a Motorola DRC800 remote thus far, and haven't yet
> tried xmit on the older device, but it can't regress, since it never
> worked before either... :)
Also tested with a Windows Media Center Ed. remote, works great there
too. Haven't tested out xmit, but meh. Its all in cvs now, as well as in
my git tree.
Will get around to xmit testing sometime soon, but its not particularly
high priority to me, so if you've got a 1st-gen mceusb device and can
test xmit support, that would be appreciated.
--
Jarod Wilson
jarod@...

On Sat, Jul 4, 2009 at 2:41 PM, Kyle McKay<mackyle@...> wrote:
> On Jul 3, 2009, at 17:48:29 PDT, TJ Harris <tjharris@...> wrote:
>>
>> Are there any guides on building lircd (0.8.5) in Mac OS X?
>>
>> I am trying to build lircd to receive IR commands from a HDHomeRun
>> tuner via UDP, but my attempts at building in Mac OS X haven't gotten
>> me very far.
>> I see in the changelog that there are comments about compiling in Mac
>> OS. Is there some trick to get this to work?
>
> 0.8.4a builds out-of-the-box on Mac OS X 10.5.7
>
> If you apply the patches attached to:
>
> https://sourceforge.net/tracker/?func=detail&atid=105444&aid=2808075&group_id=5444
>
> (Which have already been committed to CVS) you will also be able to build
> 0.8.5 on Mac OS X 10.5.7.
>
> I build it like this (as I'm using an iguanaIR device):
>
> ./configure --with-driver=iguanaIR --with-devdir=/tmp/lircd
> --with-syslog=LOG_DAEMON
> make
>
> You'll probably need this though for HDHomeRun:
>
> ./configure --with-driver=udp --with-devdir=/tmp/lircd
> --with-syslog=LOG_DAEMON
> make
>
> The --with-syslog part is optional, but --with-devdir is required. Also
> note that when you run it you'll need to provide a suitable
> --pidfile=filename (or -P) value. I usually run it like this:
>
> lircd -n -P /tmp/lircd/lircd.pid
>
> So it doesn't detach and I can monitor output.
Thanks for the response. After the patch, 0.8.5 built fine.