From: Jarod W. <ja...@wi...> - 2010-07-05 18:35:52
|
We finally hit a major milestone this weekend with upstreaming lirc. The lirc_dev bits (lirc_dev.c, lirc_dev.h, and lirc.h) are now all merged in an upstream staging tree, waiting for the 2.6.36 merge window to open, at which point, they *should* get pulled into Linus' tree proper-like. In addition to lirc_dev, a new mceusb driver is also in the same tree. This new driver is written for the new ir-core infrastructure with in-kernel decoding of signals for the default remote out of the box, but can also be used with lirc_dev (i.e., classic /dev/lirc0 w/lircd decoding -- and tramsitting) using the ir-core ir-lirc-codec driver I've written to interface between ir-core drivers and lirc_dev. The next bits of fun involve updating lirc a bit for the slightly altered ioctl interface definitions in the merged lirc_dev, and then the fun of porting several more lirc_foo drivers over to ir-core, so we're not done yet, but this is huge progress here. http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc -- Jarod Wilson ja...@wi... |
From: <li...@ba...> - 2010-07-06 17:14:47
|
Hi! Jarod Wilson "ja...@wi..." wrote: > We finally hit a major milestone this weekend with upstreaming lirc. Great work Jarod. Thank you. [...] > http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc Had a brief look at lirc.h. This seems to be based on an old version. PULSE_BIT / PULSE_MASK are obsolete and I think we should not introduce them in a kernel header. LIRC_SETUP_START / LIRC_SETUP_END are missing. I don't mind removing them again, this has been a request from Andy during the various discussions. LIRC_MEASURE_CARRIER_ENABLE / LIRC_MEASURE_CARRIER_DISABLE have been replaced by LIRC_SET_MEASURE_CARRIER_MODE. This is the only ioctl that currently is unused. (EDIT: It is used by lirc_ene0100 already but it's not supported by user-space yet: need to implement it in irrecord). Despite the comments in the header all others are used by lircd already even though some are not implemented by any drivers yet. So they shouldn't be commented out because lircd won't compile without. Christoph |
From: Jarod W. <ja...@wi...> - 2010-07-07 21:17:49
|
On Tue, Jul 6, 2010 at 1:13 PM, Christoph Bartelmus <li...@ba...> wrote: > Hi! > > Jarod Wilson "ja...@wi..." wrote: > >> We finally hit a major milestone this weekend with upstreaming lirc. > > Great work Jarod. Thank you. > > [...] >> http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc > > Had a brief look at lirc.h. This seems to be based on an old version. > PULSE_BIT / PULSE_MASK are obsolete and I think we should not introduce > them in a kernel header. > > LIRC_SETUP_START / LIRC_SETUP_END are missing. I don't mind removing them > again, this has been a request from Andy during the various discussions. > > LIRC_MEASURE_CARRIER_ENABLE / LIRC_MEASURE_CARRIER_DISABLE have been > replaced by LIRC_SET_MEASURE_CARRIER_MODE. > This is the only ioctl that currently is unused. (EDIT: It is used by > lirc_ene0100 already but it's not supported by user-space yet: need to > implement it in irrecord). Yeah, I hadn't resync'd the lirc.h in my lirc git tree for an embarrassingly long time... I've got them resync'd in my local git tree. > Despite the comments in the header all others are used by lircd already > even though some are not implemented by any drivers yet. Yeah, I went with upstream review suggestions, keeping only the minimum needed for the ir-lirc-codec bridge to compile and function w/the ir-core mceusb driver, but upstream is perfectly okay to have things enabled as needed, the preference was to not enable them until it was known they actually were needed, and I hadn't yet looked at lircd. I know Andy Walls is working on the cx23888 tx driver for ir-core, and will definitely need to enable a number of them for his work, and... > So they shouldn't > be commented out because lircd won't compile without. ...making sure lircd will compile against this kernel-provided lirc.h is one of the next things on my TODO list, so I'll no doubt encounter this problem ever so shortly. :) -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2010-07-18 19:26:50
|
On Wed, 2010-07-07 at 17:17 -0400, Jarod Wilson wrote: > On Tue, Jul 6, 2010 at 1:13 PM, Christoph Bartelmus <li...@ba...> wrote: > > Hi! > > > > Jarod Wilson "ja...@wi..." wrote: > > > >> We finally hit a major milestone this weekend with upstreaming lirc. > > > > Great work Jarod. Thank you. > > > > [...] > >> http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc > > > > Had a brief look at lirc.h. This seems to be based on an old version. > > PULSE_BIT / PULSE_MASK are obsolete and I think we should not introduce > > them in a kernel header. > > > > LIRC_SETUP_START / LIRC_SETUP_END are missing. I don't mind removing them > > again, this has been a request from Andy during the various discussions. > > > > LIRC_MEASURE_CARRIER_ENABLE / LIRC_MEASURE_CARRIER_DISABLE have been > > replaced by LIRC_SET_MEASURE_CARRIER_MODE. > > This is the only ioctl that currently is unused. (EDIT: It is used by > > lirc_ene0100 already but it's not supported by user-space yet: need to > > implement it in irrecord). > > Yeah, I hadn't resync'd the lirc.h in my lirc git tree for an > embarrassingly long time... I've got them resync'd in my local git > tree. > > > Despite the comments in the header all others are used by lircd already > > even though some are not implemented by any drivers yet. > > Yeah, I went with upstream review suggestions, keeping only the > minimum needed for the ir-lirc-codec bridge to compile and function > w/the ir-core mceusb driver, but upstream is perfectly okay to have > things enabled as needed, the preference was to not enable them until > it was known they actually were needed, and I hadn't yet looked at > lircd. I know Andy Walls is working on the cx23888 tx driver for > ir-core, and will definitely need to enable a number of them for his > work, and... > > > So they shouldn't > > be commented out because lircd won't compile without. > > ...making sure lircd will compile against this kernel-provided lirc.h > is one of the next things on my TODO list, so I'll no doubt encounter > this problem ever so shortly. :) > > I have few things to add. First of all we indeed miss few lirc ioctls aren't passed to driver. For example duty cycle, carrier measure, timeout reports, etc. I am sure these will be added as soon as needed. I also suggest to add a interface to select which receiver to use. (Sometimes there is a normal and wide band receiver) I soon (in a week) port the ene driver to ir-core, and fill missing gaps (if you don't beat me to that...) Lastly, and most importantly, I have another concern about in-kernel decoding. As it stands, each receiver currently gets one input device. Therefore although you can configure it to work with 2 or more remotes, they will be merged in 'one' remote. In my opinion this is wrong. Different remotes are different input devices, and therefore userspace should be able to distinguish between them. Currently X already does that. I am also toying with an idea of simple yet powerful program that will add scripting features (modes for example) for a remote. I want it to be generic as possible, and therefore attach to evdev device, and send output via uinput. I want it to be able do different things based on the remote. (To be honest lircd uinput support suffers from same problem, but it can be fixed, and I do that if I have no objections from you). Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2010-07-18 22:08:56
|
On Sun, Jul 18, 2010 at 3:19 PM, Maxim Levitsky <max...@gm...> wrote: > On Wed, 2010-07-07 at 17:17 -0400, Jarod Wilson wrote: >> On Tue, Jul 6, 2010 at 1:13 PM, Christoph Bartelmus <li...@ba...> wrote: >> > Hi! >> > >> > Jarod Wilson "ja...@wi..." wrote: >> > >> >> We finally hit a major milestone this weekend with upstreaming lirc. >> > >> > Great work Jarod. Thank you. >> > >> > [...] >> >> http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc >> > >> > Had a brief look at lirc.h. This seems to be based on an old version. >> > PULSE_BIT / PULSE_MASK are obsolete and I think we should not introduce >> > them in a kernel header. >> > >> > LIRC_SETUP_START / LIRC_SETUP_END are missing. I don't mind removing them >> > again, this has been a request from Andy during the various discussions. >> > >> > LIRC_MEASURE_CARRIER_ENABLE / LIRC_MEASURE_CARRIER_DISABLE have been >> > replaced by LIRC_SET_MEASURE_CARRIER_MODE. >> > This is the only ioctl that currently is unused. (EDIT: It is used by >> > lirc_ene0100 already but it's not supported by user-space yet: need to >> > implement it in irrecord). >> >> Yeah, I hadn't resync'd the lirc.h in my lirc git tree for an >> embarrassingly long time... I've got them resync'd in my local git >> tree. >> >> > Despite the comments in the header all others are used by lircd already >> > even though some are not implemented by any drivers yet. >> >> Yeah, I went with upstream review suggestions, keeping only the >> minimum needed for the ir-lirc-codec bridge to compile and function >> w/the ir-core mceusb driver, but upstream is perfectly okay to have >> things enabled as needed, the preference was to not enable them until >> it was known they actually were needed, and I hadn't yet looked at >> lircd. I know Andy Walls is working on the cx23888 tx driver for >> ir-core, and will definitely need to enable a number of them for his >> work, and... >> >> > So they shouldn't >> > be commented out because lircd won't compile without. >> >> ...making sure lircd will compile against this kernel-provided lirc.h >> is one of the next things on my TODO list, so I'll no doubt encounter >> this problem ever so shortly. :) >> >> > > I have few things to add. > > First of all we indeed miss few lirc ioctls aren't passed to driver. > For example duty cycle, carrier measure, timeout reports, etc. > I am sure these will be added as soon as needed. I've recently posted a patch to go ahead and enable these (and move lirc_dev.h from drivers/media/IR to include/media/), which lirc userspace and all currently lirc_foo drivers happily build against. I'm still sorting out a few build errors when CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is enabled, but almost there, then I hope to get the staging patch in flight. I've also got a work-in-progress lirc 0.9.0-to-be git tree I'm working on to match up with that. > I also suggest to add a interface to select which receiver to use. > (Sometimes there is a normal and wide band receiver) Yeah, that's on the TODO list for the mceusb driver, as mce transceivers do indeed have both. > I soon (in a week) port the ene driver to ir-core, and fill missing gaps > (if you don't beat me to that...) Excellent, I suspect I won't beat you to it, I've got several other things crowding my plate, and was planning to work on the drivers for which I've got hardware first (so lirc_zilog, lirc_streamzap, lirc_i2c and lirc_serial are all likely to get attention from me before any other driver). > Lastly, and most importantly, I have another concern about in-kernel > decoding. > > As it stands, each receiver currently gets one input device. > Therefore although you can configure it to work with 2 or more remotes, > they will be merged in 'one' remote. > > In my opinion this is wrong. > Different remotes are different input devices, and therefore userspace > should be able to distinguish between them. > Currently X already does that. We've had some parallel discussions on linux-media, and there does seem to be a majority preference that we have one input device per remote, even if they're being used w/the same receiver. I haven't looked myself to see what all is involved in making that a reality yet though. If its an itch you'd like to scratch, by all means, have at it, I think patches for that would be welcomed. :) > I am also toying with an idea of simple yet powerful program that will > add scripting features (modes for example) for a remote. > I want it to be generic as possible, and therefore attach to evdev > device, and send output via uinput. > I want it to be able do different things based on the remote. > > (To be honest lircd uinput support suffers from same problem, but it can > be fixed, and I do that if I have no objections from you). None from me. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2010-07-18 23:31:45
|
On Sun, 2010-07-18 at 18:08 -0400, Jarod Wilson wrote: > On Sun, Jul 18, 2010 at 3:19 PM, Maxim Levitsky <max...@gm...> wrote: > > On Wed, 2010-07-07 at 17:17 -0400, Jarod Wilson wrote: > >> On Tue, Jul 6, 2010 at 1:13 PM, Christoph Bartelmus <li...@ba...> wrote: > >> > Hi! > >> > > >> > Jarod Wilson "ja...@wi..." wrote: > >> > > >> >> We finally hit a major milestone this weekend with upstreaming lirc. > >> > > >> > Great work Jarod. Thank you. > >> > > >> > [...] > >> >> http://git.linuxtv.org/v4l-dvb.git?a=shortlog;h=refs/heads/staging/rc > >> > > >> > Had a brief look at lirc.h. This seems to be based on an old version. > >> > PULSE_BIT / PULSE_MASK are obsolete and I think we should not introduce > >> > them in a kernel header. > >> > > >> > LIRC_SETUP_START / LIRC_SETUP_END are missing. I don't mind removing them > >> > again, this has been a request from Andy during the various discussions. > >> > > >> > LIRC_MEASURE_CARRIER_ENABLE / LIRC_MEASURE_CARRIER_DISABLE have been > >> > replaced by LIRC_SET_MEASURE_CARRIER_MODE. > >> > This is the only ioctl that currently is unused. (EDIT: It is used by > >> > lirc_ene0100 already but it's not supported by user-space yet: need to > >> > implement it in irrecord). > >> > >> Yeah, I hadn't resync'd the lirc.h in my lirc git tree for an > >> embarrassingly long time... I've got them resync'd in my local git > >> tree. > >> > >> > Despite the comments in the header all others are used by lircd already > >> > even though some are not implemented by any drivers yet. > >> > >> Yeah, I went with upstream review suggestions, keeping only the > >> minimum needed for the ir-lirc-codec bridge to compile and function > >> w/the ir-core mceusb driver, but upstream is perfectly okay to have > >> things enabled as needed, the preference was to not enable them until > >> it was known they actually were needed, and I hadn't yet looked at > >> lircd. I know Andy Walls is working on the cx23888 tx driver for > >> ir-core, and will definitely need to enable a number of them for his > >> work, and... > >> > >> > So they shouldn't > >> > be commented out because lircd won't compile without. > >> > >> ...making sure lircd will compile against this kernel-provided lirc.h > >> is one of the next things on my TODO list, so I'll no doubt encounter > >> this problem ever so shortly. :) > >> > >> > > > > I have few things to add. > > > > First of all we indeed miss few lirc ioctls aren't passed to driver. > > For example duty cycle, carrier measure, timeout reports, etc. > > I am sure these will be added as soon as needed. > > I've recently posted a patch to go ahead and enable these (and move > lirc_dev.h from drivers/media/IR to include/media/), which lirc > userspace and all currently lirc_foo drivers happily build against. > I'm still sorting out a few build errors when > CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is enabled, but almost there, > then I hope to get the staging patch in flight. I've also got a > work-in-progress lirc 0.9.0-to-be git tree I'm working on to match up > with that. Just want to say Thanks for all your work. Thank you very much! > > > I also suggest to add a interface to select which receiver to use. > > (Sometimes there is a normal and wide band receiver) > > Yeah, that's on the TODO list for the mceusb driver, as mce > transceivers do indeed have both. > > > I soon (in a week) port the ene driver to ir-core, and fill missing gaps > > (if you don't beat me to that...) > > Excellent, I suspect I won't beat you to it, I've got several other > things crowding my plate, and was planning to work on the drivers for > which I've got hardware first (so lirc_zilog, lirc_streamzap, lirc_i2c > and lirc_serial are all likely to get attention from me before any > other driver). > > > Lastly, and most importantly, I have another concern about in-kernel > > decoding. > > > > As it stands, each receiver currently gets one input device. > > Therefore although you can configure it to work with 2 or more remotes, > > they will be merged in 'one' remote. > > > > In my opinion this is wrong. > > Different remotes are different input devices, and therefore userspace > > should be able to distinguish between them. > > Currently X already does that. > > We've had some parallel discussions on linux-media, and there does > seem to be a majority preference that we have one input device per > remote, even if they're being used w/the same receiver. I haven't > looked myself to see what all is involved in making that a reality yet > though. If its an itch you'd like to scratch, by all means, have at > it, I think patches for that would be welcomed. :) Glad to know that, thanks. > > > I am also toying with an idea of simple yet powerful program that will > > add scripting features (modes for example) for a remote. > > I want it to be generic as possible, and therefore attach to evdev > > device, and send output via uinput. > > I want it to be able do different things based on the remote. > > > > (To be honest lircd uinput support suffers from same problem, but it can > > be fixed, and I do that if I have no objections from you). > > None from me. Best regards, Maxim Levitsky |
From: <li...@ba...> - 2010-07-19 19:51:39
|
Hi! Jarod Wilson "ja...@wi..." wrote: [...] >> I also suggest to add a interface to select which receiver to use. >> (Sometimes there is a normal and wide band receiver) > Yeah, that's on the TODO list for the mceusb driver, as mce > transceivers do indeed have both. When you do that think about the use cases first. LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band receiver. Is there really any other usage for the wide band receiver? If a device really has a second receiver not just for learning mode, then the driver could also make it available as a second (lirc) device. Christoph |
From: Jarod W. <ja...@wi...> - 2010-07-19 21:36:58
|
On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: > Hi! > > Jarod Wilson "ja...@wi..." wrote: > [...] >>> I also suggest to add a interface to select which receiver to use. >>> (Sometimes there is a normal and wide band receiver) > >> Yeah, that's on the TODO list for the mceusb driver, as mce >> transceivers do indeed have both. > > When you do that think about the use cases first. > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band > receiver. Is there really any other usage for the wide band receiver? > > If a device really has a second receiver not just for learning mode, then > the driver could also make it available as a second (lirc) device. Learning mode was the only thing I had in mind to be enabling, so yeah, I should just wire up that ioctl properly. With the mceusb, as far as I can tell, it can only be in one mode or the other at any given time. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2010-07-26 09:33:28
|
On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: > On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: > > Hi! > > > > Jarod Wilson "ja...@wi..." wrote: > > [...] > >>> I also suggest to add a interface to select which receiver to use. > >>> (Sometimes there is a normal and wide band receiver) > > > >> Yeah, that's on the TODO list for the mceusb driver, as mce > >> transceivers do indeed have both. > > > > When you do that think about the use cases first. > > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band > > receiver. Is there really any other usage for the wide band receiver? > > > > If a device really has a second receiver not just for learning mode, then > > the driver could also make it available as a second (lirc) device. > > Learning mode was the only thing I had in mind to be enabling, so > yeah, I should just wire up that ioctl properly. With the mceusb, as > far as I can tell, it can only be in one mode or the other at any > given time. > Although maybe hackish, but think about following scenario: User has a CIR device with narrow (and I mean it, think something like 30-34 kHz) receiver. Such receiver just won't work with many remotes. So it might be good for this user to enable learning mode permanenly, because a reduced range (if it is that, it might not be reduced at all) is better that no reception at all. Microsoft's IR stack is focused around receive of RC6 and nothing more, but lirc doesn't. And now my main question. As I resumed development today, I want to ask which git tree to use as a base of development? Should I use linux-media tree or your linux-2.6-ir-wip? I am asking because your tree crashes on my system right after a setkeycode attempt from userspace. (and udev does few. and of course no IR drivers present because I didn't yet port ene driver.) Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2010-07-26 15:42:01
|
On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: >> > Hi! >> > >> > Jarod Wilson "ja...@wi..." wrote: >> > [...] >> >>> I also suggest to add a interface to select which receiver to use. >> >>> (Sometimes there is a normal and wide band receiver) >> > >> >> Yeah, that's on the TODO list for the mceusb driver, as mce >> >> transceivers do indeed have both. >> > >> > When you do that think about the use cases first. >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band >> > receiver. Is there really any other usage for the wide band receiver? >> > >> > If a device really has a second receiver not just for learning mode, then >> > the driver could also make it available as a second (lirc) device. >> >> Learning mode was the only thing I had in mind to be enabling, so >> yeah, I should just wire up that ioctl properly. With the mceusb, as >> far as I can tell, it can only be in one mode or the other at any >> given time. >> > Although maybe hackish, but think about following scenario: > > User has a CIR device with narrow (and I mean it, think something like > 30-34 kHz) receiver. > Such receiver just won't work with many remotes. > > So it might be good for this user to enable learning mode permanenly, > because a reduced range (if it is that, it might not be reduced at all) > is better that no reception at all. > > Microsoft's IR stack is focused around receive of RC6 and nothing more, > but lirc doesn't. Hm. Possible, I suppose. "Cross that bridge when we come to it", I think. :) For now, I'd just be happy with actually having things wired up to use the short-range receiver in the mce for learning, since its completely untouched by anything right now. > And now my main question. > As I resumed development today, I want to ask which git tree to use as a > base of development? > > Should I use linux-media tree or your linux-2.6-ir-wip? No, sorry, that tree is a bit outdated now, I should remove it... > I am asking because your tree crashes on my system right after a > setkeycode attempt from userspace. (and udev does few. and of course no > IR drivers present because I didn't yet port ene driver.) I think that should be fixed by either or both of these: http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e I think these are both in the linuxtv staging/other tree, so I'd either work from that, or even better, all of those are also in my linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all the lirc drivers in prep for them being submitted to staging (which I've already gotten thumbs up for from gregkh). http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2010-07-26 16:40:17
|
On Mon, 2010-07-26 at 11:41 -0400, Jarod Wilson wrote: > On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: > > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: > >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: > >> > Hi! > >> > > >> > Jarod Wilson "ja...@wi..." wrote: > >> > [...] > >> >>> I also suggest to add a interface to select which receiver to use. > >> >>> (Sometimes there is a normal and wide band receiver) > >> > > >> >> Yeah, that's on the TODO list for the mceusb driver, as mce > >> >> transceivers do indeed have both. > >> > > >> > When you do that think about the use cases first. > >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band > >> > receiver. Is there really any other usage for the wide band receiver? > >> > > >> > If a device really has a second receiver not just for learning mode, then > >> > the driver could also make it available as a second (lirc) device. > >> > >> Learning mode was the only thing I had in mind to be enabling, so > >> yeah, I should just wire up that ioctl properly. With the mceusb, as > >> far as I can tell, it can only be in one mode or the other at any > >> given time. > >> > > Although maybe hackish, but think about following scenario: > > > > User has a CIR device with narrow (and I mean it, think something like > > 30-34 kHz) receiver. > > Such receiver just won't work with many remotes. > > > > So it might be good for this user to enable learning mode permanenly, > > because a reduced range (if it is that, it might not be reduced at all) > > is better that no reception at all. > > > > Microsoft's IR stack is focused around receive of RC6 and nothing more, > > but lirc doesn't. > > Hm. Possible, I suppose. "Cross that bridge when we come to it", I > think. :) For now, I'd just be happy with actually having things wired > up to use the short-range receiver in the mce for learning, since its > completely untouched by anything right now. > > > And now my main question. > > As I resumed development today, I want to ask which git tree to use as a > > base of development? > > > > Should I use linux-media tree or your linux-2.6-ir-wip? > > No, sorry, that tree is a bit outdated now, I should remove it... > > > I am asking because your tree crashes on my system right after a > > setkeycode attempt from userspace. (and udev does few. and of course no > > IR drivers present because I didn't yet port ene driver.) > > I think that should be fixed by either or both of these: > > http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 > http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e Its the first one, I *know* that the hard way... > > I think these are both in the linuxtv staging/other tree, so I'd > either work from that, or even better, all of those are also in my > linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all > the lirc drivers in prep for them being submitted to staging (which > I've already gotten thumbs up for from gregkh). > > http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git Great, I take this tree from now. Thanks! Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2010-07-26 18:33:17
|
On Mon, Jul 26, 2010 at 12:40 PM, Maxim Levitsky <max...@gm...> wrote: > On Mon, 2010-07-26 at 11:41 -0400, Jarod Wilson wrote: >> On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: >> > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: >> >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: >> >> > Hi! >> >> > >> >> > Jarod Wilson "ja...@wi..." wrote: >> >> > [...] >> >> >>> I also suggest to add a interface to select which receiver to use. >> >> >>> (Sometimes there is a normal and wide band receiver) >> >> > >> >> >> Yeah, that's on the TODO list for the mceusb driver, as mce >> >> >> transceivers do indeed have both. >> >> > >> >> > When you do that think about the use cases first. >> >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band >> >> > receiver. Is there really any other usage for the wide band receiver? >> >> > >> >> > If a device really has a second receiver not just for learning mode, then >> >> > the driver could also make it available as a second (lirc) device. >> >> >> >> Learning mode was the only thing I had in mind to be enabling, so >> >> yeah, I should just wire up that ioctl properly. With the mceusb, as >> >> far as I can tell, it can only be in one mode or the other at any >> >> given time. >> >> >> > Although maybe hackish, but think about following scenario: >> > >> > User has a CIR device with narrow (and I mean it, think something like >> > 30-34 kHz) receiver. >> > Such receiver just won't work with many remotes. >> > >> > So it might be good for this user to enable learning mode permanenly, >> > because a reduced range (if it is that, it might not be reduced at all) >> > is better that no reception at all. >> > >> > Microsoft's IR stack is focused around receive of RC6 and nothing more, >> > but lirc doesn't. >> >> Hm. Possible, I suppose. "Cross that bridge when we come to it", I >> think. :) For now, I'd just be happy with actually having things wired >> up to use the short-range receiver in the mce for learning, since its >> completely untouched by anything right now. >> >> > And now my main question. >> > As I resumed development today, I want to ask which git tree to use as a >> > base of development? >> > >> > Should I use linux-media tree or your linux-2.6-ir-wip? >> >> No, sorry, that tree is a bit outdated now, I should remove it... >> >> > I am asking because your tree crashes on my system right after a >> > setkeycode attempt from userspace. (and udev does few. and of course no >> > IR drivers present because I didn't yet port ene driver.) >> >> I think that should be fixed by either or both of these: >> >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e > > Its the first one, I *know* that the hard way... Heh, yeah, that one triggered on my thinkpad t61 when thinkpad_acpi was trying to register an input device. >> I think these are both in the linuxtv staging/other tree, so I'd >> either work from that, or even better, all of those are also in my >> linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all >> the lirc drivers in prep for them being submitted to staging (which >> I've already gotten thumbs up for from gregkh). >> >> http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git > > Great, I take this tree from now. > Thanks! No problem! One last thing then... Since the lirc header update and move has been committed and pulled into linux-next, I'm going to go ahead and get patches in flight to add all the lirc drivers to staging tonight. I'll cc you on the ene0100 driver and add a note that you're already working on it. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2010-07-26 19:49:29
|
On Mon, 2010-07-26 at 14:33 -0400, Jarod Wilson wrote: > On Mon, Jul 26, 2010 at 12:40 PM, Maxim Levitsky > <max...@gm...> wrote: > > On Mon, 2010-07-26 at 11:41 -0400, Jarod Wilson wrote: > >> On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: > >> > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: > >> >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: > >> >> > Hi! > >> >> > > >> >> > Jarod Wilson "ja...@wi..." wrote: > >> >> > [...] > >> >> >>> I also suggest to add a interface to select which receiver to use. > >> >> >>> (Sometimes there is a normal and wide band receiver) > >> >> > > >> >> >> Yeah, that's on the TODO list for the mceusb driver, as mce > >> >> >> transceivers do indeed have both. > >> >> > > >> >> > When you do that think about the use cases first. > >> >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band > >> >> > receiver. Is there really any other usage for the wide band receiver? > >> >> > > >> >> > If a device really has a second receiver not just for learning mode, then > >> >> > the driver could also make it available as a second (lirc) device. > >> >> > >> >> Learning mode was the only thing I had in mind to be enabling, so > >> >> yeah, I should just wire up that ioctl properly. With the mceusb, as > >> >> far as I can tell, it can only be in one mode or the other at any > >> >> given time. > >> >> > >> > Although maybe hackish, but think about following scenario: > >> > > >> > User has a CIR device with narrow (and I mean it, think something like > >> > 30-34 kHz) receiver. > >> > Such receiver just won't work with many remotes. > >> > > >> > So it might be good for this user to enable learning mode permanenly, > >> > because a reduced range (if it is that, it might not be reduced at all) > >> > is better that no reception at all. > >> > > >> > Microsoft's IR stack is focused around receive of RC6 and nothing more, > >> > but lirc doesn't. > >> > >> Hm. Possible, I suppose. "Cross that bridge when we come to it", I > >> think. :) For now, I'd just be happy with actually having things wired > >> up to use the short-range receiver in the mce for learning, since its > >> completely untouched by anything right now. > >> > >> > And now my main question. > >> > As I resumed development today, I want to ask which git tree to use as a > >> > base of development? > >> > > >> > Should I use linux-media tree or your linux-2.6-ir-wip? > >> > >> No, sorry, that tree is a bit outdated now, I should remove it... > >> > >> > I am asking because your tree crashes on my system right after a > >> > setkeycode attempt from userspace. (and udev does few. and of course no > >> > IR drivers present because I didn't yet port ene driver.) > >> > >> I think that should be fixed by either or both of these: > >> > >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 > >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e > > > > Its the first one, I *know* that the hard way... > > Heh, yeah, that one triggered on my thinkpad t61 when thinkpad_acpi > was trying to register an input device. > > >> I think these are both in the linuxtv staging/other tree, so I'd > >> either work from that, or even better, all of those are also in my > >> linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all > >> the lirc drivers in prep for them being submitted to staging (which > >> I've already gotten thumbs up for from gregkh). > >> > >> http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git > > > > Great, I take this tree from now. > > Thanks! > > No problem! One last thing then... Since the lirc header update and > move has been committed and pulled into linux-next, I'm going to go > ahead and get patches in flight to add all the lirc drivers to staging > tonight. I'll cc you on the ene0100 driver and add a note that you're > already working on it. Thanks. Small note, I now read mceusb.c to get an overview of new interface. I think that in mceusb_init_input_dev, you wrongly allocate the 'ir_input_dev', because later, the __ir_input_register allocates it too, and overrides the structure with 'input_set_drvdata(input_dev, ir_dev);' Probably was just recently added or so. Best regards, Maxim Levitsky > |
From: Maxim L. <max...@gm...> - 2010-07-26 23:19:05
|
On Mon, 2010-07-26 at 22:49 +0300, Maxim Levitsky wrote: > On Mon, 2010-07-26 at 14:33 -0400, Jarod Wilson wrote: > > On Mon, Jul 26, 2010 at 12:40 PM, Maxim Levitsky > > <max...@gm...> wrote: > > > On Mon, 2010-07-26 at 11:41 -0400, Jarod Wilson wrote: > > >> On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: > > >> > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: > > >> >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: > > >> >> > Hi! > > >> >> > > > >> >> > Jarod Wilson "ja...@wi..." wrote: > > >> >> > [...] > > >> >> >>> I also suggest to add a interface to select which receiver to use. > > >> >> >>> (Sometimes there is a normal and wide band receiver) > > >> >> > > > >> >> >> Yeah, that's on the TODO list for the mceusb driver, as mce > > >> >> >> transceivers do indeed have both. > > >> >> > > > >> >> > When you do that think about the use cases first. > > >> >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band > > >> >> > receiver. Is there really any other usage for the wide band receiver? > > >> >> > > > >> >> > If a device really has a second receiver not just for learning mode, then > > >> >> > the driver could also make it available as a second (lirc) device. > > >> >> > > >> >> Learning mode was the only thing I had in mind to be enabling, so > > >> >> yeah, I should just wire up that ioctl properly. With the mceusb, as > > >> >> far as I can tell, it can only be in one mode or the other at any > > >> >> given time. > > >> >> > > >> > Although maybe hackish, but think about following scenario: > > >> > > > >> > User has a CIR device with narrow (and I mean it, think something like > > >> > 30-34 kHz) receiver. > > >> > Such receiver just won't work with many remotes. > > >> > > > >> > So it might be good for this user to enable learning mode permanenly, > > >> > because a reduced range (if it is that, it might not be reduced at all) > > >> > is better that no reception at all. > > >> > > > >> > Microsoft's IR stack is focused around receive of RC6 and nothing more, > > >> > but lirc doesn't. > > >> > > >> Hm. Possible, I suppose. "Cross that bridge when we come to it", I > > >> think. :) For now, I'd just be happy with actually having things wired > > >> up to use the short-range receiver in the mce for learning, since its > > >> completely untouched by anything right now. > > >> > > >> > And now my main question. > > >> > As I resumed development today, I want to ask which git tree to use as a > > >> > base of development? > > >> > > > >> > Should I use linux-media tree or your linux-2.6-ir-wip? > > >> > > >> No, sorry, that tree is a bit outdated now, I should remove it... > > >> > > >> > I am asking because your tree crashes on my system right after a > > >> > setkeycode attempt from userspace. (and udev does few. and of course no > > >> > IR drivers present because I didn't yet port ene driver.) > > >> > > >> I think that should be fixed by either or both of these: > > >> > > >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 > > >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e > > > > > > Its the first one, I *know* that the hard way... > > > > Heh, yeah, that one triggered on my thinkpad t61 when thinkpad_acpi > > was trying to register an input device. > > > > >> I think these are both in the linuxtv staging/other tree, so I'd > > >> either work from that, or even better, all of those are also in my > > >> linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all > > >> the lirc drivers in prep for them being submitted to staging (which > > >> I've already gotten thumbs up for from gregkh). > > >> > > >> http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git > > > > > > Great, I take this tree from now. > > > Thanks! > > > > No problem! One last thing then... Since the lirc header update and > > move has been committed and pulled into linux-next, I'm going to go > > ahead and get patches in flight to add all the lirc drivers to staging > > tonight. I'll cc you on the ene0100 driver and add a note that you're > > already working on it. > > Thanks. > > Small note, I now read mceusb.c to get an overview of new interface. > > I think that in mceusb_init_input_dev, you wrongly allocate the > 'ir_input_dev', because later, the __ir_input_register allocates it too, > and overrides the structure with 'input_set_drvdata(input_dev, ir_dev);' > Probably was just recently added or so. Another question. Some devices can send several pulses or spaces in a row due to limitation of hardware buffer. For example the ENE device has 4 byte buffer, and each byte is a sample + pulse / space bit. How about moving that to ir_raw_event_store? Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2010-07-27 05:59:14
|
On Mon, Jul 26, 2010 at 7:18 PM, Maxim Levitsky <max...@gm...> wrote: ... > Another question. > > Some devices can send several pulses or spaces in a row due to > limitation of hardware buffer. > > For example the ENE device has 4 byte buffer, and each byte is a sample > + pulse / space bit. > > How about moving that to ir_raw_event_store? I'm not following... What exactly is "that" which you're suggesting moving into ir_raw_event_store? (Might be better to ask this over on linux-media too, Mauro and David are more familiar with that part of the code, and I don't know that either reads this list). -- Jarod Wilson ja...@wi... |
From: Rajesh K. B. <ra...@cs...> - 2010-07-27 06:09:38
|
Hi, are there any known issues with the mceusb driver and linux 2.6.34? I'm using debian unstable and the 2.6.34 kernels from the liquorix project http://liquorix.net/ with the CVS lirc sources, everything compiles fine and the drivers and lircd load. however, no IR events from the remote are being captured by the driver. irw shows no remote events. rebooting into 2.6.32 and running the same irw command shows all the remote button presses (using the silver remote from the hauppauge 150 MC version). have not tried the IR blaster support (using lirc_serial) in 2.6.34. that's the next step after the mceusb driver starts detecting remote events. Rajesh |
From: Jarod W. <ja...@wi...> - 2010-07-27 15:46:04
|
On Tue, Jul 27, 2010 at 2:09 AM, Rajesh Krishna Balan <ra...@cs...> wrote: > Hi, > > are there any known issues with the mceusb driver and linux 2.6.34? No. > I'm using debian unstable and the 2.6.34 kernels from the liquorix project > http://liquorix.net/ > > with the CVS lirc sources, everything compiles fine and the drivers and > lircd load. > > however, no IR events from the remote are being captured by the driver. > irw shows no remote events. rebooting into 2.6.32 and running the same > irw command shows all the remote button presses (using the silver remote > from the hauppauge 150 MC version). Please load the driver adding the mod param debug=1, and see what gets dumped into dmesg. You might also give 0.8.6 a try, see if that behaves any differently (will require trivial patching to make it build on 2.6.34). -- Jarod Wilson ja...@wi... |
From: Jonathan I. <je...@gm...> - 2010-07-27 16:16:50
|
On Tue, Jul 27, 2010 at 10:20 AM, Jarod Wilson <ja...@wi...> wrote: > On Tue, Jul 27, 2010 at 2:09 AM, Rajesh Krishna Balan <ra...@cs...> wrote: >> Hi, >> >> are there any known issues with the mceusb driver and linux 2.6.34? > > No. > >> I'm using debian unstable and the 2.6.34 kernels from the liquorix project >> http://liquorix.net/ >> >> with the CVS lirc sources, everything compiles fine and the drivers and >> lircd load. >> >> however, no IR events from the remote are being captured by the driver. >> irw shows no remote events. rebooting into 2.6.32 and running the same >> irw command shows all the remote button presses (using the silver remote >> from the hauppauge 150 MC version). > > Please load the driver adding the mod param debug=1, and see what gets > dumped into dmesg. You might also give 0.8.6 a try, see if that > behaves any differently (will require trivial patching to make it > build on 2.6.34). I'm running 2.6.34.1 and on gentoo they have a package called app-misc/lirc-0.8.7_pre1. lirc-0.8.7pre1.tar.bz2 is the source archive on the gentoo. works fine here with a mceusb2 device. Mirror site <ftp://gentoo.cites.uiuc.edu/pub/gentoo/distfiles/lirc-0.8.7pre1.tar.bz2> > -- > Jarod Wilson > ja...@wi... > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > |
From: Jarod W. <ja...@wi...> - 2010-07-27 20:56:47
|
On Tue, Jul 27, 2010 at 12:16 PM, Jonathan Isom <je...@gm...> wrote: > On Tue, Jul 27, 2010 at 10:20 AM, Jarod Wilson <ja...@wi...> wrote: >> On Tue, Jul 27, 2010 at 2:09 AM, Rajesh Krishna Balan <ra...@cs...> wrote: >>> Hi, >>> >>> are there any known issues with the mceusb driver and linux 2.6.34? >> >> No. >> >>> I'm using debian unstable and the 2.6.34 kernels from the liquorix project >>> http://liquorix.net/ >>> >>> with the CVS lirc sources, everything compiles fine and the drivers and >>> lircd load. >>> >>> however, no IR events from the remote are being captured by the driver. >>> irw shows no remote events. rebooting into 2.6.32 and running the same >>> irw command shows all the remote button presses (using the silver remote >>> from the hauppauge 150 MC version). >> >> Please load the driver adding the mod param debug=1, and see what gets >> dumped into dmesg. You might also give 0.8.6 a try, see if that >> behaves any differently (will require trivial patching to make it >> build on 2.6.34). > > I'm running 2.6.34.1 and on gentoo they have a package called > app-misc/lirc-0.8.7_pre1. > lirc-0.8.7pre1.tar.bz2 is the source archive on the gentoo. works fine > here with a mceusb2 device. Note that there *were* some code changes to lirc_mceusb.c between 0.8.7pre1 and current cvs, but looking back over them, I don't see how any would have resulted in a non-functioning device, and I've tested all these changes with four different mce devices here (albeit not with lirc_mceusb, but rather with the new mceusb driver... okay, I should probably try an lirc_mceusb build from current cvs too). -- Jarod Wilson ja...@wi... |
From: Rajesh K. B. <ra...@cs...> - 2010-07-28 07:05:56
|
okay. let me try all the suggestions in the next few days and report back. Thanks Jarod, Jonathan! Rajesh On 28/7/2010 4:56 AM, Jarod Wilson wrote: > On Tue, Jul 27, 2010 at 12:16 PM, Jonathan Isom<je...@gm...> wrote: > >> On Tue, Jul 27, 2010 at 10:20 AM, Jarod Wilson<ja...@wi...> wrote: >> >>> On Tue, Jul 27, 2010 at 2:09 AM, Rajesh Krishna Balan<ra...@cs...> wrote: >>> >>>> Hi, >>>> >>>> are there any known issues with the mceusb driver and linux 2.6.34? >>>> >>> No. >>> >>> >>>> I'm using debian unstable and the 2.6.34 kernels from the liquorix project >>>> http://liquorix.net/ >>>> >>>> with the CVS lirc sources, everything compiles fine and the drivers and >>>> lircd load. >>>> >>>> however, no IR events from the remote are being captured by the driver. >>>> irw shows no remote events. rebooting into 2.6.32 and running the same >>>> irw command shows all the remote button presses (using the silver remote >>>> from the hauppauge 150 MC version). >>>> >>> Please load the driver adding the mod param debug=1, and see what gets >>> dumped into dmesg. You might also give 0.8.6 a try, see if that >>> behaves any differently (will require trivial patching to make it >>> build on 2.6.34). >>> >> I'm running 2.6.34.1 and on gentoo they have a package called >> app-misc/lirc-0.8.7_pre1. >> lirc-0.8.7pre1.tar.bz2 is the source archive on the gentoo. works fine >> here with a mceusb2 device. >> > Note that there *were* some code changes to lirc_mceusb.c between > 0.8.7pre1 and current cvs, but looking back over them, I don't see how > any would have resulted in a non-functioning device, and I've tested > all these changes with four different mce devices here (albeit not > with lirc_mceusb, but rather with the new mceusb driver... okay, I > should probably try an lirc_mceusb build from current cvs too). > > > |
From: Maxim L. <max...@gm...> - 2010-07-27 09:30:20
|
On Tue, 2010-07-27 at 01:59 -0400, Jarod Wilson wrote: > On Mon, Jul 26, 2010 at 7:18 PM, Maxim Levitsky <max...@gm...> wrote: > ... > > Another question. > > > > Some devices can send several pulses or spaces in a row due to > > limitation of hardware buffer. > > > > For example the ENE device has 4 byte buffer, and each byte is a sample > > + pulse / space bit. > > > > How about moving that to ir_raw_event_store? > > I'm not following... What exactly is "that" which you're suggesting > moving into ir_raw_event_store? (Might be better to ask this over on > linux-media too, Mauro and David are more familiar with that part of > the code, and I don't know that either reads this list). > > I explain again. On ene devices the hardware buffer is 4 bytes long. Each byte consists of 7 bits of timing and one bit for pulse/space. The timing is expresses in units of sample period that can be programmed into device. default it 50 us So a single byte can express 127 * 50 = 6350 us sample. If sample is longer, hardware just sends two or more samples. something like that: 6350 (pulse) 1250 (pulse) 4000 (space) .... To combat this, I defer sending last sample to lirc, and store it internally, and add samples of same type until I receive sample of different type. Also when last sample is *too* large and its space, I put hardware in a mode in which it stops sending samples till it gets a pulse. I also remember current time, and on next pulse send the accumulated sample. Unfortunately new revisions of this device miss that functionality, but these stop sending samples automatically, however this doesn't break the code. I want to move that logic to common code. Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2010-07-27 05:57:01
|
On Mon, Jul 26, 2010 at 3:49 PM, Maxim Levitsky <max...@gm...> wrote: > On Mon, 2010-07-26 at 14:33 -0400, Jarod Wilson wrote: >> On Mon, Jul 26, 2010 at 12:40 PM, Maxim Levitsky >> <max...@gm...> wrote: >> > On Mon, 2010-07-26 at 11:41 -0400, Jarod Wilson wrote: >> >> On Mon, Jul 26, 2010 at 5:33 AM, Maxim Levitsky <max...@gm...> wrote: >> >> > On Mon, 2010-07-19 at 17:36 -0400, Jarod Wilson wrote: >> >> >> On Mon, Jul 19, 2010 at 3:38 PM, Christoph Bartelmus <li...@ba...> wrote: >> >> >> > Hi! >> >> >> > >> >> >> > Jarod Wilson "ja...@wi..." wrote: >> >> >> > [...] >> >> >> >>> I also suggest to add a interface to select which receiver to use. >> >> >> >>> (Sometimes there is a normal and wide band receiver) >> >> >> > >> >> >> >> Yeah, that's on the TODO list for the mceusb driver, as mce >> >> >> >> transceivers do indeed have both. >> >> >> > >> >> >> > When you do that think about the use cases first. >> >> >> > LIRC_SET_MEASURE_CARRIER_MODE is already intended to enable the wide band >> >> >> > receiver. Is there really any other usage for the wide band receiver? >> >> >> > >> >> >> > If a device really has a second receiver not just for learning mode, then >> >> >> > the driver could also make it available as a second (lirc) device. >> >> >> >> >> >> Learning mode was the only thing I had in mind to be enabling, so >> >> >> yeah, I should just wire up that ioctl properly. With the mceusb, as >> >> >> far as I can tell, it can only be in one mode or the other at any >> >> >> given time. >> >> >> >> >> > Although maybe hackish, but think about following scenario: >> >> > >> >> > User has a CIR device with narrow (and I mean it, think something like >> >> > 30-34 kHz) receiver. >> >> > Such receiver just won't work with many remotes. >> >> > >> >> > So it might be good for this user to enable learning mode permanenly, >> >> > because a reduced range (if it is that, it might not be reduced at all) >> >> > is better that no reception at all. >> >> > >> >> > Microsoft's IR stack is focused around receive of RC6 and nothing more, >> >> > but lirc doesn't. >> >> >> >> Hm. Possible, I suppose. "Cross that bridge when we come to it", I >> >> think. :) For now, I'd just be happy with actually having things wired >> >> up to use the short-range receiver in the mce for learning, since its >> >> completely untouched by anything right now. >> >> >> >> > And now my main question. >> >> > As I resumed development today, I want to ask which git tree to use as a >> >> > base of development? >> >> > >> >> > Should I use linux-media tree or your linux-2.6-ir-wip? >> >> >> >> No, sorry, that tree is a bit outdated now, I should remove it... >> >> >> >> > I am asking because your tree crashes on my system right after a >> >> > setkeycode attempt from userspace. (and udev does few. and of course no >> >> > IR drivers present because I didn't yet port ene driver.) >> >> >> >> I think that should be fixed by either or both of these: >> >> >> >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2bec574ec14e3478b1971411dec5ab96b6159995 >> >> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=218d38c793adac37f0a981e1e8351cc025090a3e >> > >> > Its the first one, I *know* that the hard way... >> >> Heh, yeah, that one triggered on my thinkpad t61 when thinkpad_acpi >> was trying to register an input device. >> >> >> I think these are both in the linuxtv staging/other tree, so I'd >> >> either work from that, or even better, all of those are also in my >> >> linux-2.6-lirc tree on git.kernel.org, along with a reshuffling of all >> >> the lirc drivers in prep for them being submitted to staging (which >> >> I've already gotten thumbs up for from gregkh). >> >> >> >> http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git >> > >> > Great, I take this tree from now. >> > Thanks! >> >> No problem! One last thing then... Since the lirc header update and >> move has been committed and pulled into linux-next, I'm going to go >> ahead and get patches in flight to add all the lirc drivers to staging >> tonight. I'll cc you on the ene0100 driver and add a note that you're >> already working on it. > > Thanks. > > Small note, I now read mceusb.c to get an overview of new interface. > > I think that in mceusb_init_input_dev, you wrongly allocate the > 'ir_input_dev', because later, the __ir_input_register allocates it too, > and overrides the structure with 'input_set_drvdata(input_dev, ir_dev);' > Probably was just recently added or so. Hrm. Good catch, thanks. Though I'd swear I fixed that already. Maybe it was a similar something or other that I fixed... I've looked at way too much code lately. :) Anyhow, both the imon driver and mceusb driver have the same problem (cribbed from imon into mceusb), will fix those both up properly tomorrow. -- Jarod Wilson ja...@wi... |