From: Anders E. <aer...@fa...> - 2010-03-04 09:32:58
|
Hi, I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the current recommendations for the imon driver? Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. -Anders |
From: Jonathan I. <je...@gm...> - 2010-03-16 19:42:12
|
On Thu, Mar 4, 2010 at 4:16 AM, Anders Eriksson <aer...@fa...> wrote: > > Hi, > I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the > current recommendations for the imon driver? > > Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and > the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. Is there any time frame on a 2.6.33 compatible lirc? I'm using mceusb driver and it fails to build with 2.6.33.1. Later Jonathan > -Anders > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- ASUS m3a78 motherboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 4 Gigabytes of DDR2-800 Gigabyte NVidia 9400gt Graphics adapter Kworld ATSC 110 TV Capture Card Kworld ATSC 115 TV Capture Card |
From: Jarod W. <ja...@wi...> - 2010-03-16 20:09:18
|
On Tue, Mar 16, 2010 at 3:34 PM, Jonathan Isom <je...@gm...> wrote: > On Thu, Mar 4, 2010 at 4:16 AM, Anders Eriksson <aer...@fa...> wrote: >> >> Hi, >> I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the >> current recommendations for the imon driver? >> >> Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and >> the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. The git tree should build just fine on 2.6.33. At least, the tree itself, which is now 2.6.34-rc1-based, everything builds just fine, and the 2.6.33 Fedora kernel builds w/the lirc bits patched in builds just fine. I've not actually had time to test the resulting builds, mind you... > Is there any time frame on a 2.6.33 compatible lirc? I'm using mceusb > driver and it fails to build with 2.6.33.1. I'll try to take a look and see what needs to be done to make lirc cvs build against 2.6.33 sometime this week. Day job is keeping me rather busy right now though. -- Jarod Wilson ja...@wi... |
From: Jonathan I. <je...@gm...> - 2010-03-16 20:36:42
|
On Tue, Mar 16, 2010 at 3:09 PM, Jarod Wilson <ja...@wi...> wrote: > On Tue, Mar 16, 2010 at 3:34 PM, Jonathan Isom <je...@gm...> wrote: >> On Thu, Mar 4, 2010 at 4:16 AM, Anders Eriksson <aer...@fa...> wrote: >>> >>> Hi, >>> I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the >>> current recommendations for the imon driver? >>> >>> Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and >>> the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. > > The git tree should build just fine on 2.6.33. At least, the tree > itself, which is now 2.6.34-rc1-based, everything builds just fine, > and the 2.6.33 Fedora kernel builds w/the lirc bits patched in builds > just fine. I've not actually had time to test the resulting builds, > mind you... > >> Is there any time frame on a 2.6.33 compatible lirc? I'm using mceusb >> driver and it fails to build with 2.6.33.1. > > I'll try to take a look and see what needs to be done to make lirc cvs > build against 2.6.33 sometime this week. Day job is keeping me rather > busy right now though. Hi I was able to get 0.8.6 working for mceusb. Changed #include <linux/autoconf.h> to #include <generated/autoconf.h> and undefined LIRC_HAVE_KFIFO and it works for me for now. Thanks Jonathan > -- > Jarod Wilson > ja...@wi... > -- ASUS m3a78 motherboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 4 Gigabytes of DDR2-800 Gigabyte NVidia 9400gt Graphics adapter Kworld ATSC 110 TV Capture Card Kworld ATSC 115 TV Capture Card |
From: Dale P. <DEP...@ed...> - 2010-03-16 22:16:48
|
On 03/16/10 16:27, Jonathan Isom wrote: > On Tue, Mar 16, 2010 at 3:09 PM, Jarod Wilson <ja...@wi...> wrote: >> On Tue, Mar 16, 2010 at 3:34 PM, Jonathan Isom <je...@gm...> wrote: >>> On Thu, Mar 4, 2010 at 4:16 AM, Anders Eriksson <aer...@fa...> wrote: >>>> >>>> Hi, >>>> I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the >>>> current recommendations for the imon driver? >>>> >>>> Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and >>>> the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. >> >> The git tree should build just fine on 2.6.33. At least, the tree >> itself, which is now 2.6.34-rc1-based, everything builds just fine, >> and the 2.6.33 Fedora kernel builds w/the lirc bits patched in builds >> just fine. I've not actually had time to test the resulting builds, >> mind you... >> >>> Is there any time frame on a 2.6.33 compatible lirc? I'm using mceusb >>> driver and it fails to build with 2.6.33.1. >> >> I'll try to take a look and see what needs to be done to make lirc cvs >> build against 2.6.33 sometime this week. Day job is keeping me rather >> busy right now though. > > Hi > I was able to get 0.8.6 working for mceusb. Changed > #include <linux/autoconf.h> > to > #include <generated/autoconf.h> > > and undefined LIRC_HAVE_KFIFO > > and it works for me for now. > I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to satisfy openafs, and tried it for lirc - then failed because of the kfifo. So this means that kfifo really isn't necessary? Where do you undefine it? Now to find an nVidia driver that works with 2.6.33, since they retracted the one that messes up the fan. (195.36.03/08?) Thanks, Dale |
From: Jonathan I. <je...@gm...> - 2010-03-17 00:03:13
|
On Tue, Mar 16, 2010 at 4:59 PM, Dale Pontius <DEP...@ed...> wrote: > On 03/16/10 16:27, Jonathan Isom wrote: >> On Tue, Mar 16, 2010 at 3:09 PM, Jarod Wilson <ja...@wi...> wrote: >>> On Tue, Mar 16, 2010 at 3:34 PM, Jonathan Isom <je...@gm...> wrote: >>>> On Thu, Mar 4, 2010 at 4:16 AM, Anders Eriksson <aer...@fa...> wrote: >>>>> >>>>> Hi, >>>>> I'm rebuilding my machine for a 64bit setup using the 2.6.33 kernel. What's the >>>>> current recommendations for the imon driver? >>>>> >>>>> Latest cvs seems to have issues building towards the vanilla 2.6.33 tree and >>>>> the linux-2.6-lirc git tree seems to not have the 2.6.33 bits in it. >>> >>> The git tree should build just fine on 2.6.33. At least, the tree >>> itself, which is now 2.6.34-rc1-based, everything builds just fine, >>> and the 2.6.33 Fedora kernel builds w/the lirc bits patched in builds >>> just fine. I've not actually had time to test the resulting builds, >>> mind you... >>> >>>> Is there any time frame on a 2.6.33 compatible lirc? I'm using mceusb >>>> driver and it fails to build with 2.6.33.1. >>> >>> I'll try to take a look and see what needs to be done to make lirc cvs >>> build against 2.6.33 sometime this week. Day job is keeping me rather >>> busy right now though. >> >> Hi >> I was able to get 0.8.6 working for mceusb. Changed >> #include <linux/autoconf.h> >> to >> #include <generated/autoconf.h> >> >> and undefined LIRC_HAVE_KFIFO >> >> and it works for me for now. >> > I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to > satisfy openafs, and tried it for lirc - then failed because of the kfifo. > > So this means that kfifo really isn't necessary? Where do you undefine it? it is defined in /drivers/lirc_dev/lirc_dev.h > Now to find an nVidia driver that works with 2.6.33, since they > retracted the one that messes up the fan. (195.36.03/08?) The have a new release 195.36.15 > > Thanks, > Dale > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- ASUS m3a78 motherboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 4 Gigabytes of DDR2-800 Gigabyte NVidia 9400gt Graphics adapter Kworld ATSC 110 TV Capture Card Kworld ATSC 115 TV Capture Card |
From: Jarod W. <ja...@wi...> - 2010-03-17 15:04:31
|
On Tue, Mar 16, 2010 at 5:59 PM, Dale Pontius <DEP...@ed...> wrote: > On 03/16/10 16:27, Jonathan Isom wrote: ... >> and undefined LIRC_HAVE_KFIFO >> >> and it works for me for now. >> > I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to > satisfy openafs, and tried it for lirc - then failed because of the kfifo. > > So this means that kfifo really isn't necessary? Historically, lirc_dev implemented its own fifo buffer. It was converted to use the kernel-provided kfifo interface a little while back. I've used kfifo exclusively for some time now, including in 2.6.33 builds, but built from my lirc git tree, which tracks the upstream kernel, and thus doesn't have all the legacy #ifdefs all over. I thought I'd ported all the kfifo changes in 2.6.33 into lirc cvs successfully, and swear I did test builds w/o a problem, but maybe I missed something. I'll try to get that fixed shortly. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-03-17 15:12:24
|
On Wed, Mar 17, 2010 at 10:40 AM, Jarod Wilson <ja...@wi...> wrote: > On Tue, Mar 16, 2010 at 5:59 PM, Dale Pontius <DEP...@ed...> wrote: >> On 03/16/10 16:27, Jonathan Isom wrote: > ... >>> and undefined LIRC_HAVE_KFIFO >>> >>> and it works for me for now. >>> >> I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to >> satisfy openafs, and tried it for lirc - then failed because of the kfifo. >> >> So this means that kfifo really isn't necessary? > > Historically, lirc_dev implemented its own fifo buffer. It was > converted to use the kernel-provided kfifo interface a little while > back. I've used kfifo exclusively for some time now, including in > 2.6.33 builds, but built from my lirc git tree, which tracks the > upstream kernel, and thus doesn't have all the legacy #ifdefs all > over. I thought I'd ported all the kfifo changes in 2.6.33 into lirc > cvs successfully, and swear I did test builds w/o a problem, but maybe > I missed something. I'll try to get that fixed shortly. Not seeing anything to fix, actually. Just built current cvs against 2.6.33.1 without a problem. -- Jarod Wilson ja...@wi... |
From: Dale E. P. <DEP...@ed...> - 2010-03-17 18:53:56
|
On 03/17/10 11:05, Jarod Wilson wrote: > On Wed, Mar 17, 2010 at 10:40 AM, Jarod Wilson <ja...@wi...> wrote: > >> On Tue, Mar 16, 2010 at 5:59 PM, Dale Pontius <DEP...@ed...> wrote: >> >>> On 03/16/10 16:27, Jonathan Isom wrote: >>> >> ... >> >>>> and undefined LIRC_HAVE_KFIFO >>>> >>>> and it works for me for now. >>>> >>>> >>> I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to >>> satisfy openafs, and tried it for lirc - then failed because of the kfifo. >>> >>> So this means that kfifo really isn't necessary? >>> >> Historically, lirc_dev implemented its own fifo buffer. It was >> converted to use the kernel-provided kfifo interface a little while >> back. I've used kfifo exclusively for some time now, including in >> 2.6.33 builds, but built from my lirc git tree, which tracks the >> upstream kernel, and thus doesn't have all the legacy #ifdefs all >> over. I thought I'd ported all the kfifo changes in 2.6.33 into lirc >> cvs successfully, and swear I did test builds w/o a problem, but maybe >> I missed something. I'll try to get that fixed shortly. >> > Not seeing anything to fix, actually. Just built current cvs against > 2.6.33.1 without a problem. > > I'm running Gentoo, and "lirc-0.8.6-r2" is the latest they've got. I can try making a local ebuild to work with a cvs checkout. I could also try undefining LIRC_HAVE_KFIFO, but I think the previous way is better. Is there any significant (to lirc) difference between 2.6.33 and 2.6.33.1? While I'm asking, any idea when this stuff is going into the kernel? Is there any sort of guide to moving to the event framework instead of traditional lirc devices? Can the current lirc use the event framework instead of traditional lirc devices? (In other words, is there a really disruptive change coming up, or can we take it in smaller pieces?) Dale |
From: Jarod W. <ja...@wi...> - 2010-03-17 19:42:51
|
On Wed, Mar 17, 2010 at 2:53 PM, Dale E. Pontius <DEP...@ed...> wrote: > On 03/17/10 11:05, Jarod Wilson wrote: >> On Wed, Mar 17, 2010 at 10:40 AM, Jarod Wilson <ja...@wi...> wrote: >> >>> On Tue, Mar 16, 2010 at 5:59 PM, Dale Pontius <DEP...@ed...> wrote: >>> >>>> On 03/16/10 16:27, Jonathan Isom wrote: >>>> >>> ... >>> >>>>> and undefined LIRC_HAVE_KFIFO >>>>> >>>>> and it works for me for now. >>>>> >>>>> >>>> I've been doing a symlink linux/autoconf.h -> ../generated/autoconf.h to >>>> satisfy openafs, and tried it for lirc - then failed because of the kfifo. >>>> >>>> So this means that kfifo really isn't necessary? >>>> >>> Historically, lirc_dev implemented its own fifo buffer. It was >>> converted to use the kernel-provided kfifo interface a little while >>> back. I've used kfifo exclusively for some time now, including in >>> 2.6.33 builds, but built from my lirc git tree, which tracks the >>> upstream kernel, and thus doesn't have all the legacy #ifdefs all >>> over. I thought I'd ported all the kfifo changes in 2.6.33 into lirc >>> cvs successfully, and swear I did test builds w/o a problem, but maybe >>> I missed something. I'll try to get that fixed shortly. >>> >> Not seeing anything to fix, actually. Just built current cvs against >> 2.6.33.1 without a problem. >> >> > I'm running Gentoo, and "lirc-0.8.6-r2" is the latest they've got. Ah. That would explain it. The kfifo interface changed in 2.6.33, and lirc didn't get the code to handle that change until post-0.8.6 cvs. > I can try making a local ebuild to work with a cvs checkout. I could also > try undefining LIRC_HAVE_KFIFO, but I think the previous way is better. > Is there any significant (to lirc) difference between 2.6.33 and 2.6.33.1? No. > While I'm asking, any idea when this stuff is going into the kernel? "When it gets there" ;) I need to get together another round of patches to submit to put lirc into staging first, I think. I've been rather busy with a new job I took on here at work though, so my time for lirc has been quite limited for the past few months. This week is the first significant time I've had to work on it in a while. > Is there any sort of guide to moving to the event framework instead of > traditional lirc devices? > Can the current lirc use the event framework instead of traditional lirc > devices? > (In other words, is there a really disruptive change coming up, or can > we take it in smaller pieces?) Input subsystem integration is one of the hot topics that stalled out lirc inclusion upstream. And its part of why I think we're going to try to go in via staging. Then people that really want lirc input subsystem integration can work on it in a centralized place. Mauro Carvalho Chehab has done a fair amount of related work already under drivers/media/IR/ lately, and looking over that and seeing how we can tie into it is on my TODO list. Ultimately going for a hybrid approach, where most devices can do pure input layer or classic lirc interface, at the users choice (pure input w/stock remotes could Just Work with zero config, but we still need a way to pass raw IR out to userspace for lircd to parse). -- Jarod Wilson ja...@wi... |
From: Marco S. <mar...@gm...> - 2010-03-17 19:57:15
|
On Wed, Mar 17, 2010 at 20:42, Jarod Wilson <ja...@wi...> wrote: > Input subsystem integration is one of the hot topics that stalled out > lirc inclusion upstream. And its part of why I think we're going to > try to go in via staging. Then people that really want lirc input > subsystem integration can work on it in a centralized place. Since you're already discussing that subject, I'd like to ask what's in store for the imon driver you released last December? It would seem lirc_imon is getting more love than imon? TIA -- Best Regards, Marco |
From: Jarod W. <ja...@wi...> - 2010-03-17 20:00:34
|
On Wed, Mar 17, 2010 at 3:56 PM, Marco Salvagno <mar...@gm...> wrote: > On Wed, Mar 17, 2010 at 20:42, Jarod Wilson <ja...@wi...> wrote: > >> Input subsystem integration is one of the hot topics that stalled out >> lirc inclusion upstream. And its part of why I think we're going to >> try to go in via staging. Then people that really want lirc input >> subsystem integration can work on it in a centralized place. > > Since you're already discussing that subject, I'd like to ask what's > in store for the imon driver you released last December? > > It would seem lirc_imon is getting more love than imon? Heh, trust me, very much NOT the case. :) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=history;f=drivers/input/misc/imon.c;h=0c05f95e34136a5be94b397614042d15b9837e1d;hb=HEAD -- Jarod Wilson ja...@wi... |
From: Anders E. <aer...@fa...> - 2010-03-17 20:22:54
|
For what it's worth. I pulled the 2.6.33 patches you'd put in from Fedora and applied to vanilla 2.6.33. Works file except the (mce) codes are busted. I'll post a patch later to show the details of that. On the plus side.. the old drivers emitted three presses for each key press (no repeat markers). The 2.6.33+patch thing emits just one per keypress! /Anders |
From: Jarod W. <ja...@wi...> - 2010-03-17 21:54:57
|
On Wed, Mar 17, 2010 at 4:22 PM, Anders Eriksson <aer...@fa...> wrote: > > For what it's worth. I pulled the 2.6.33 patches you'd put in from Fedora and > applied to vanilla 2.6.33. Works file except the (mce) codes are busted. I'll > post a patch later to show the details of that. > > On the plus side.. the old drivers emitted three presses for each key press > (no repeat markers). The 2.6.33+patch thing emits just one per keypress! Which Fedora kernel did you pull the patches from and when? I've been actively updating them today... :) Best bet is actually to grab from my git tree, I'm pushing everything there first, and using that to generate the patches for Fedora. -- Jarod Wilson ja...@wi... |
From: Anders E. <aer...@fa...> - 2010-03-18 10:01:42
|
ja...@wi... said: > Which Fedora kernel did you pull the patches from and when? I've been > actively updating them today... :) Can't say for certain, but it was from a page similar to http://lists.fedoraproject.org/pipermail/scm-commits/2010-January/379502.html and I pulled it 13 Mars 17.24 GMT+1 It has: include/linux/lirc.h | 94 ++ drivers/input/Kconfig | 2 + drivers/input/Makefile | 2 + drivers/input/lirc/Kconfig | 116 ++ drivers/input/lirc/Makefile | 21 + drivers/input/lirc/lirc_bt829.c | 383 ++++++ drivers/input/lirc/lirc_dev.c | 736 ++++++++++ drivers/input/lirc/lirc_dev.h | 225 +++ drivers/input/lirc/lirc_ene0100.c | 646 +++++++++ drivers/input/lirc/lirc_ene0100.h | 169 +++ drivers/input/lirc/lirc_i2c.c | 536 ++++++++ drivers/input/lirc/lirc_igorplugusb.c | 556 ++++++++ drivers/input/lirc/lirc_imon.c | 1054 ++++++++++++++ drivers/input/lirc/lirc_it87.c | 991 ++++++++++++++ drivers/input/lirc/lirc_it87.h | 116 ++ drivers/input/lirc/lirc_ite8709.c | 540 ++++++++ drivers/input/lirc/lirc_mceusb.c | 1222 +++++++++++++++++ drivers/input/lirc/lirc_parallel.c | 709 ++++++++++ drivers/input/lirc/lirc_parallel.h | 26 + drivers/input/lirc/lirc_sasem.c | 931 +++++++++++++ drivers/input/lirc/lirc_serial.c | 1317 ++++++++++++++++++ drivers/input/lirc/lirc_sir.c | 1283 +++++++++++++++++ drivers/input/lirc/lirc_streamzap.c | 794 +++++++++++ drivers/input/lirc/lirc_ttusbir.c | 397 ++++++ drivers/input/lirc/lirc_zilog.c | 1396 +++++++++++++++++++ drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile | 1 + drivers/input/misc/imon.c | 2430 +++++++++++++++++++++++++++++++++ 28 files changed, 16705 insertions(+), 0 deletions(-) > Best bet is actually to grab from my git tree, I'm pushing everything there > first, and using that to generate the patches for Fedora. At the time, git://git.wilsonet.com/linux-2.6-lirc.git/ didn't have any 2.6.33 tags in it, so i wnt googling and found the patch. here's the mce table I ended up with: /* mce-mode imon mce remote key table */ static const struct key_entry imon_mce_key_table[] = { /* keys sorted mostly by frequency of use to optimize lookups */ { KE_KEY, 0x800ff415, { KEY_REWIND } }, { KE_KEY, 0x800ff414, { KEY_FASTFORWARD } }, { KE_KEY, 0x800ff41b, { KEY_PREVIOUS } }, { KE_KEY, 0x800ff41a, { KEY_NEXT } }, { KE_KEY, 0x800ff416, { KEY_PLAY } }, { KE_KEY, 0x800ff418, { KEY_PAUSE } }, { KE_KEY, 0x800ff418, { KEY_PAUSE } }, { KE_KEY, 0x800ff419, { KEY_STOP } }, { KE_KEY, 0x800ff417, { KEY_RECORD } }, { KE_KEY, 0x800FF41E, { KEY_UP } }, { KE_KEY, 0x800FF41F, { KEY_DOWN } }, { KE_KEY, 0x800FF420, { KEY_LEFT } }, { KE_KEY, 0x800FF421, { KEY_RIGHT } }, { KE_KEY, 0x800FF424, { KEY_MENU } }, { KE_KEY, 0x800FF41C, { KEY_PREVIOUS } }, { KE_KEY, 0x800FF422, { KEY_OK } }, /* the OK and Enter buttons decode to the same value { KE_KEY, 0x02000028, { KEY_OK } }, */ { KE_KEY, 0x800FF423, { KEY_EXIT } }, { KE_KEY, 0x02000029, { KEY_DELETE } }, { KE_KEY, 0x800ff40E, { KEY_MUTE } }, { KE_KEY, 0x800ff410, { KEY_VOLUMEUP } }, { KE_KEY, 0x800ff411, { KEY_VOLUMEDOWN } }, { KE_KEY, 0x800ff412, { KEY_CHANNELUP } }, { KE_KEY, 0x800ff413, { KEY_CHANNELDOWN } }, { KE_KEY, 0x800FF401, { KEY_NUMERIC_1 } }, { KE_KEY, 0x800FF402, { KEY_NUMERIC_2 } }, { KE_KEY, 0x800FF403, { KEY_NUMERIC_3 } }, { KE_KEY, 0x800FF404, { KEY_NUMERIC_4 } }, { KE_KEY, 0x800FF405, { KEY_NUMERIC_5 } }, { KE_KEY, 0x800FF406, { KEY_NUMERIC_6 } }, { KE_KEY, 0x800FF407, { KEY_NUMERIC_7 } }, { KE_KEY, 0x800FF408, { KEY_NUMERIC_8 } }, { KE_KEY, 0x800FF409, { KEY_NUMERIC_9 } }, { KE_KEY, 0x800FF400, { KEY_NUMERIC_0 } }, { KE_KEY, 0x800FF40A, { KEY_NUMERIC_STAR } }, { KE_KEY, 0x800FF40B, { KEY_NUMERIC_POUND } }, { KE_KEY, 0x800f8446, { KEY_TV } }, { KE_KEY, 0x800f8447, { KEY_AUDIO } }, { KE_KEY, 0x800f8448, { KEY_PVR } }, /* RecordedTV */ { KE_KEY, 0x800f8449, { KEY_CAMERA } }, { KE_KEY, 0x800f844a, { KEY_VIDEO } }, { KE_KEY, 0x800f8424, { KEY_DVD } }, { KE_KEY, 0x800f8425, { KEY_TUNER } }, /* LiveTV */ { KE_KEY, 0x800FF466, { KEY_RED } }, { KE_KEY, 0x800FF425, { KEY_GREEN } }, { KE_KEY, 0x800FF468, { KEY_YELLOW } }, { KE_KEY, 0x800FF41D, { KEY_BLUE } }, { KE_KEY, 0x800ff40f, { KEY_INFO } }, { KE_KEY, 0x800ff426, { KEY_EPG } }, /* Guide */ { KE_KEY, 0x800f845a, { KEY_SUBTITLE } }, /* Caption */ { KE_KEY, 0x800f840c, { KEY_POWER } }, { KE_KEY, 0x800f840d, { KEY_PROG1 } }, /* Windows MCE button */ { KE_END, 0 } }; My remote only emits 0x800... codes so I had to fix all the 0x2... codes. Additionally, the 0x800.. codes had "f8" in them and i had to change that to FF as you can see above (My remote doesn't have the TV AUDIO etc keys, so they're untouched). And KEY_ENTER for some reason didn't make it to userspace (inputlirc), but changing it to KEY_OK did the trick (odd). |
From: Jarod W. <ja...@wi...> - 2010-03-19 19:51:26
|
On Thu, Mar 18, 2010 at 6:01 AM, Anders Eriksson <aer...@fa...> wrote: > > ja...@wi... said: >> Which Fedora kernel did you pull the patches from and when? I've been >> actively updating them today... :) > > Can't say for certain, but it was from a page similar to > http://lists.fedoraproject.org/pipermail/scm-commits/2010-January/379502.html > > and I pulled it 13 Mars 17.24 GMT+1 Heh, yeah way outdated now. ;) >> Best bet is actually to grab from my git tree, I'm pushing everything there >> first, and using that to generate the patches for Fedora. > At the time, git://git.wilsonet.com/linux-2.6-lirc.git/ didn't have any > 2.6.33 tags in it, so i wnt googling and found the patch. Ah, yeah, I should just remove that tree and replace it with a pointer... Its now out on kernel.org: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary > here's the mce table I ended up with: > /* mce-mode imon mce remote key table */ > static const struct key_entry imon_mce_key_table[] = { > /* keys sorted mostly by frequency of use to optimize lookups */ > { KE_KEY, 0x800ff415, { KEY_REWIND } }, > { KE_KEY, 0x800ff414, { KEY_FASTFORWARD } }, > { KE_KEY, 0x800ff41b, { KEY_PREVIOUS } }, > { KE_KEY, 0x800ff41a, { KEY_NEXT } }, > > { KE_KEY, 0x800ff416, { KEY_PLAY } }, > { KE_KEY, 0x800ff418, { KEY_PAUSE } }, > { KE_KEY, 0x800ff418, { KEY_PAUSE } }, > { KE_KEY, 0x800ff419, { KEY_STOP } }, > { KE_KEY, 0x800ff417, { KEY_RECORD } }, > > { KE_KEY, 0x800FF41E, { KEY_UP } }, > { KE_KEY, 0x800FF41F, { KEY_DOWN } }, > { KE_KEY, 0x800FF420, { KEY_LEFT } }, > { KE_KEY, 0x800FF421, { KEY_RIGHT } }, > > { KE_KEY, 0x800FF424, { KEY_MENU } }, > { KE_KEY, 0x800FF41C, { KEY_PREVIOUS } }, > > { KE_KEY, 0x800FF422, { KEY_OK } }, > /* the OK and Enter buttons decode to the same value > { KE_KEY, 0x02000028, { KEY_OK } }, */ > { KE_KEY, 0x800FF423, { KEY_EXIT } }, > { KE_KEY, 0x02000029, { KEY_DELETE } }, > > { KE_KEY, 0x800ff40E, { KEY_MUTE } }, > { KE_KEY, 0x800ff410, { KEY_VOLUMEUP } }, > { KE_KEY, 0x800ff411, { KEY_VOLUMEDOWN } }, > { KE_KEY, 0x800ff412, { KEY_CHANNELUP } }, > { KE_KEY, 0x800ff413, { KEY_CHANNELDOWN } }, > > { KE_KEY, 0x800FF401, { KEY_NUMERIC_1 } }, > { KE_KEY, 0x800FF402, { KEY_NUMERIC_2 } }, > { KE_KEY, 0x800FF403, { KEY_NUMERIC_3 } }, > { KE_KEY, 0x800FF404, { KEY_NUMERIC_4 } }, > { KE_KEY, 0x800FF405, { KEY_NUMERIC_5 } }, > { KE_KEY, 0x800FF406, { KEY_NUMERIC_6 } }, > { KE_KEY, 0x800FF407, { KEY_NUMERIC_7 } }, > { KE_KEY, 0x800FF408, { KEY_NUMERIC_8 } }, > { KE_KEY, 0x800FF409, { KEY_NUMERIC_9 } }, > { KE_KEY, 0x800FF400, { KEY_NUMERIC_0 } }, > > { KE_KEY, 0x800FF40A, { KEY_NUMERIC_STAR } }, > { KE_KEY, 0x800FF40B, { KEY_NUMERIC_POUND } }, > > { KE_KEY, 0x800f8446, { KEY_TV } }, > { KE_KEY, 0x800f8447, { KEY_AUDIO } }, > { KE_KEY, 0x800f8448, { KEY_PVR } }, /* RecordedTV */ > { KE_KEY, 0x800f8449, { KEY_CAMERA } }, > { KE_KEY, 0x800f844a, { KEY_VIDEO } }, > { KE_KEY, 0x800f8424, { KEY_DVD } }, > { KE_KEY, 0x800f8425, { KEY_TUNER } }, /* LiveTV */ > > { KE_KEY, 0x800FF466, { KEY_RED } }, > { KE_KEY, 0x800FF425, { KEY_GREEN } }, > { KE_KEY, 0x800FF468, { KEY_YELLOW } }, > { KE_KEY, 0x800FF41D, { KEY_BLUE } }, > > { KE_KEY, 0x800ff40f, { KEY_INFO } }, > { KE_KEY, 0x800ff426, { KEY_EPG } }, /* Guide */ > { KE_KEY, 0x800f845a, { KEY_SUBTITLE } }, /* Caption */ > > { KE_KEY, 0x800f840c, { KEY_POWER } }, > { KE_KEY, 0x800f840d, { KEY_PROG1 } }, /* Windows MCE button */ > { KE_END, 0 } > > }; > > > My remote only emits 0x800... codes so I had to fix all the 0x2... codes. > > Additionally, the 0x800.. codes had "f8" in them and i had to change that to > FF as you can see above (My remote doesn't have the TV AUDIO etc keys, so > they're untouched). > > And KEY_ENTER for some reason didn't make it to userspace (inputlirc), but > changing it to KEY_OK did the trick (odd). Hell. Yet another 0xffdc device that decodes things differently. I really hate those things. I'm sure we can hack up something that works for all of them... So, note that my devices, the mce keys actually send two different values, 0x800f04xx and 0x800f84xx, because 0x8000 is the mce toggle bit, used to differentiate the start of a new key press. Does your device also toggle between values of maybe 0x800f74xx and 0x800ff4xx? You'd have to run with debugging enabled and look in dmesg to see the different versions. The lookup for the keys is done by or'ing in the 0x8000 so we don't have to have both versions in the table. -- Jarod Wilson ja...@wi... |
From: Marco S. <mar...@gm...> - 2010-03-18 15:15:06
|
On Wed, Mar 17, 2010 at 21:00, Jarod Wilson <ja...@wi...> wrote: > Heh, trust me, very much NOT the case. :) Great :) I'm not really much into kernel development, but what would happen if the imon driver was merged? would this mean the end for its lirc_imon sibling? |
From: Jarod W. <ja...@wi...> - 2010-03-19 19:53:30
|
On Thu, Mar 18, 2010 at 11:14 AM, Marco Salvagno <mar...@gm...> wrote: > On Wed, Mar 17, 2010 at 21:00, Jarod Wilson <ja...@wi...> wrote: > >> Heh, trust me, very much NOT the case. :) > > Great :) > > I'm not really much into kernel development, but what would happen if > the imon driver was merged? would this mean the end for its lirc_imon > sibling? To be determined. We still need a way for people to remap keys, add missing keys, etc., without having to recompile, before its a complete replacement (its on the TODO list). lirc_imon would continue to exist to support the oldest 4 imon device types, which don't do onboard signal decoding though. -- Jarod Wilson ja...@wi... |
From: Anders E. <aer...@fa...> - 2010-03-20 08:02:55
|
ja...@wi... said: > Ah, yeah, I should just remove that tree and replace it with a pointer... Its > now out on kernel.org: > > http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary Ok. I just pulled that one and it seems to work as well (with my codes). ja...@wi... said: > Hell. Yet another 0xffdc device that decodes things differently. I really > hate those things. I'm sure we can hack up something that works for all of > them... Sound good. Not sure if it matters but I use Harmony remote to drive it, so is there a chance that I've slightly misprogrammed it and the stuff it sends is not 'common' mce codes? Or are the codes entire cooked up by the IR recever (I suspect they are)? ja...@wi... said: > So, note that my devices, the mce keys actually send two different values, > 0x800f04xx and 0x800f84xx, because 0x8000 is the mce toggle bit, used to > differentiate the start of a new key press. Does your device also toggle > between values of maybe 0x800f74xx and 0x800ff4xx? yes it does. Spot on. > You'd have to run with > debugging enabled and look in dmesg to see the different versions. The lookup > for the keys is done by or'ing in the 0x8000 so we don't have to have both > versions in the table. Yep. Been poking in that area, and I found that I have these extra bits high all the time. While adding some printks in the table look up code (in the old diff I had pulled) I discovered that it tries to lookup _something_ ~50 times/second even if nothing is pressed on the remote. Any chance to make this interrupt driven, or not poll as frequently? Seems something is looping a bit more than necessary... |
From: Marco S. <mar...@gm...> - 2010-03-22 16:16:25
|
> To be determined. We still need a way for people to remap keys, add > missing keys, etc., without having to recompile, before its a complete > replacement (its on the TODO list). lirc_imon would continue to exist > to support the oldest 4 imon device types, which don't do onboard > signal decoding though. That answers a lot of Qs I had in my mind, thanks. BTW I'm still experiencing that problem with LCDd blasting the iMon and generating packet write errors. Is that an issue that will have to find a fix within LCDd ? I seem to recall the usleep fix has been discussed some time ago but I haven't been able to find the messages. |
From: Jarod W. <ja...@wi...> - 2010-03-23 03:07:03
|
On Sat, Mar 20, 2010 at 4:02 AM, Anders Eriksson <aer...@fa...> wrote: > > ja...@wi... said: >> Ah, yeah, I should just remove that tree and replace it with a pointer... Its >> now out on kernel.org: >> >> http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary > > Ok. I just pulled that one and it seems to work as well (with my codes). > > > ja...@wi... said: >> Hell. Yet another 0xffdc device that decodes things differently. I really >> hate those things. I'm sure we can hack up something that works for all of >> them... > > Sound good. Not sure if it matters but I use Harmony remote to drive it, so is > there a chance that I've slightly misprogrammed it and the stuff it sends is > not 'common' mce codes? Or are the codes entire cooked up by the IR recever (I > suspect they are)? The codes are cooked up by the IR receiver. It decodes the IR signals in hardware, then dumps the synthesized codes into a buffer for us to read. > ja...@wi... said: >> So, note that my devices, the mce keys actually send two different values, >> 0x800f04xx and 0x800f84xx, because 0x8000 is the mce toggle bit, used to >> differentiate the start of a new key press. Does your device also toggle >> between values of maybe 0x800f74xx and 0x800ff4xx? > yes it does. Spot on. Okay, cool, should be able to tweak the code slightly to handle that too. Just looked at it a bit... Its a bit messier than I was first thinking, but certainly doable. > While adding some printks in the table look up code (in the old diff I had > pulled) I discovered that it tries to lookup _something_ ~50 times/second even > if nothing is pressed on the remote. Any chance to make this interrupt driven, > or not poll as frequently? Seems something is looping a bit more than > necessary... Sadly, it *is* interrupt-driven. The imon driver gets its data from interrupt usb request buffers, handled by an interrupt-triggered callback. Its a flaw/deficiency of the 0xffdc devices that was remedied in the current generation of hardware, not really sure what we can do about it. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-03-23 03:30:14
|
On Mon, Mar 22, 2010 at 11:06 PM, Jarod Wilson <ja...@wi...> wrote: > On Sat, Mar 20, 2010 at 4:02 AM, Anders Eriksson <aer...@fa...> wrote: ... >>> So, note that my devices, the mce keys actually send two different values, >>> 0x800f04xx and 0x800f84xx, because 0x8000 is the mce toggle bit, used to >>> differentiate the start of a new key press. Does your device also toggle >>> between values of maybe 0x800f74xx and 0x800ff4xx? >> yes it does. Spot on. > > Okay, cool, should be able to tweak the code slightly to handle that > too. Just looked at it a bit... Its a bit messier than I was first > thinking, but certainly doable. Okay, I *think* this patch would do the trick. I've yet to actually test it out on my own hardware though... http://wilsonet.com/jarod/junk/imon-0xff4xx-keys.patch -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-03-23 03:12:13
|
On Mon, Mar 22, 2010 at 12:15 PM, Marco Salvagno <mar...@gm...> wrote: >> To be determined. We still need a way for people to remap keys, add >> missing keys, etc., without having to recompile, before its a complete >> replacement (its on the TODO list). lirc_imon would continue to exist >> to support the oldest 4 imon device types, which don't do onboard >> signal decoding though. > > That answers a lot of Qs I had in my mind, thanks. Sure, no problem. Mauro Carvalho Chehab has been working on some in-kernel IR infra, including a userspace utility for loading keymaps, which I hope to have time to poke at soon, and tie the imon driver into. > BTW I'm still experiencing that problem with LCDd blasting the iMon > and generating packet write errors. Is that an issue that will have to > find a fix within LCDd ? Hopefully, it can be fixed in the imon driver. I don't think anything tried so far has proven successful yet though. This would be easier to get taken care of if I had a device in front of me that produced the problem -- which I *might* have soon... > I seem to recall the usleep fix has been discussed some time ago but I > haven't been able to find the messages. There was some discussion both here and on the lcdproc mailing list, but I thought I'd at least floated a patch here. Its a simple enough thing to redo though, basically just throw in an mdelay(x); at the end of the send_packet() routine, trying various values of x, iirc. -- Jarod Wilson ja...@wi... |
From: Marco S. <mar...@gm...> - 2010-03-23 17:21:24
|
On Tue, Mar 23, 2010 at 04:12, Jarod Wilson <ja...@wi...> wrote: > Hopefully, it can be fixed in the imon driver. I don't think anything > tried so far has proven successful yet though. This would be easier to > get taken care of if I had a device in front of me that produced the > problem -- which I *might* have soon... My recent switch from an older lirc_imon to imon (0.7 IIRC) seems to have made things better. With lirc_imon the display often became irrecuperable, meaning a restart of LCDd was needed to restore the screen functionality. ATM the worst I've seen is the backlight comes back on (the display is driven by a patched XBMC which turns off backlight when the HTPC is not being used), when it really should just stay off. I'm not 100% sure this is the driver's merit though, I've also kept fiddling with configuration. Anyway, should you need a tester, my XBMC setup is able to consistently generate that sort of error and I'd be glad to help. |
From: Anders E. <aer...@fa...> - 2010-03-23 20:08:24
|
>Okay, I *think* this patch would do the trick. I've yet to actually >test it out on my own hardware though... > >http://wilsonet.com/jarod/junk/imon-0xff4xx-keys.patch Tested it and it mostly works. Some keys give the wrong KEY_??? though. Here's the ones: MENU -> KEY_DVD PREV -> KEY_NUMERIC_POUND STAR -> KEY_DELETE GREEN -> KEY_TUNER BLUE -> KEY_STAR These keys are now dead: POUND RED YELLOW Looking at the patch, and comparing the new one with mine, I see that my codes for e.g. RED differs from yours: Mine: 0x800FF466 Yours 0x800ff45b So there are some diffs in the lower bits as well :-( The same goes for PREV (mine is 0x800FF41C, not ....41B) However looking at MENU, it's the same code as you have mapped to DVD (...ff424). -Anders |