From: Tony B. <aar...@gm...> - 2009-03-31 17:28:38
|
Hi all, I've been searching for lirc support for this CIR chip. I found another thread about how Intel and Nuvoton are not releasing information for Linux support. But on the tech details page for the chip it says that: Glue functions to complement the South Bridge functionality identical to the PC8374L Glue Pin and software compliance with the existing PC8374L features (see more here http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/WPCD376I.htm ) So I was wondering if PC8374L has been implemented in lirc? This chip is on the Intel DG45FC mini-itx mobo. Is there any hope for support for this chipset in my lifetime? hehehe Is there anything I can do to help? Any info I can provide? Thanks, Tony |
From: Tony B. <aar...@gm...> - 2009-08-25 21:58:09
|
Just came across this kernel patch that's suppose to add this Winbond CIR WPCD376I support. http://patchwork.kernel.org/patch/33573/ Also depends on this patch http://patchwork.kernel.org/patch/32657/ Haven't tried to apply it against 2.6.30.5 yet. And I haven't seen it in the .31 branch yet. So not sure how well it works. I don't have a windows MCE remote anyway :/ On Tue, Mar 31, 2009 at 10:28 AM, Tony Bones <aar...@gm...> wrote: > Hi all, > I've been searching for lirc support for this CIR chip. I found another > thread about how Intel and Nuvoton are not releasing information for Linux > support. But on the tech details page for the chip it says that: > Glue functions to complement the South Bridge functionality identical to > the PC8374L Glue > Pin and software compliance with the existing PC8374L features (see more > here > http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/WPCD376I.htm > ) > > So I was wondering if PC8374L has been implemented in lirc? > > This chip is on the Intel DG45FC mini-itx mobo. Is there any hope for > support for this chipset in my lifetime? hehehe > Is there anything I can do to help? Any info I can provide? > > Thanks, > Tony > > |
From: Tony B. <aar...@gm...> - 2009-08-25 22:22:41
|
I stand corrected, just found another patch that converted the original patch from ACPI to PNP. http://patchwork.kernel.org/patch/41110/ and http://patchwork.kernel.org/patch/40704/ On Tue, Aug 25, 2009 at 2:57 PM, Tony Bones <aar...@gm...> wrote: > Just came across this kernel patch that's suppose to add this Winbond CIR > WPCD376I support. > > http://patchwork.kernel.org/patch/33573/ > Also depends on this patch > http://patchwork.kernel.org/patch/32657/ > > Haven't tried to apply it against 2.6.30.5 yet. And I haven't seen it in > the .31 branch yet. So not sure how well it works. I don't have a windows > MCE remote anyway :/ > > > > > On Tue, Mar 31, 2009 at 10:28 AM, Tony Bones <aar...@gm...> wrote: > >> Hi all, >> I've been searching for lirc support for this CIR chip. I found another >> thread about how Intel and Nuvoton are not releasing information for Linux >> support. But on the tech details page for the chip it says that: >> Glue functions to complement the South Bridge functionality identical to >> the PC8374L Glue >> Pin and software compliance with the existing PC8374L features (see more >> here >> http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/WPCD376I.htm >> ) >> >> So I was wondering if PC8374L has been implemented in lirc? >> >> This chip is on the Intel DG45FC mini-itx mobo. Is there any hope for >> support for this chipset in my lifetime? hehehe >> Is there anything I can do to help? Any info I can provide? >> >> Thanks, >> Tony >> >> > |
From: Juan J. G. de S. L. <ska...@gm...> - 2009-08-26 14:59:49
|
Hi... These patches seem very interesting. You could try putting your own values into the code if you own any other RC6 remote and can get to know the key values. Check whether you have something under the WEC1022 name in the output of lspnp... Some of the things in this patch may apply to my wpc7869l driver for LIRC. I wish I had some kind of datasheet when I got the driver written. Best regards, Juan Jesus. 2009/8/26 Tony Bones <aar...@gm...> > I stand corrected, just found another patch that converted the original > patch from ACPI to PNP. > http://patchwork.kernel.org/patch/41110/ > and > http://patchwork.kernel.org/patch/40704/ > > > > On Tue, Aug 25, 2009 at 2:57 PM, Tony Bones <aar...@gm...> wrote: > >> Just came across this kernel patch that's suppose to add this Winbond CIR >> WPCD376I support. >> >> http://patchwork.kernel.org/patch/33573/ >> Also depends on this patch >> http://patchwork.kernel.org/patch/32657/ >> >> Haven't tried to apply it against 2.6.30.5 yet. And I haven't seen it in >> the .31 branch yet. So not sure how well it works. I don't have a windows >> MCE remote anyway :/ >> >> >> >> >> On Tue, Mar 31, 2009 at 10:28 AM, Tony Bones <aar...@gm...>wrote: >> >>> Hi all, >>> I've been searching for lirc support for this CIR chip. I found another >>> thread about how Intel and Nuvoton are not releasing information for Linux >>> support. But on the tech details page for the chip it says that: >>> Glue functions to complement the South Bridge functionality identical to >>> the PC8374L Glue >>> Pin and software compliance with the existing PC8374L features (see more >>> here >>> http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/WPCD376I.htm >>> ) >>> >>> So I was wondering if PC8374L has been implemented in lirc? >>> >>> This chip is on the Intel DG45FC mini-itx mobo. Is there any hope for >>> support for this chipset in my lifetime? hehehe >>> Is there anything I can do to help? Any info I can provide? >>> >>> Thanks, >>> Tony >>> >>> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > -- Dream small if success is enough for you; dream big if you need to change the world. |
From: Tony B. <aar...@gm...> - 2009-08-28 22:25:36
|
I def have the chip, I'm using the same mobo as the author of the driver, a DG45FC. I do have WEC1022 under lshal udi = '/org/freedesktop/Hal/devices/pnp_WEC1022' > info.parent = '/org/freedesktop/Hal/devices/computer' (string) > info.product = 'PnP Device (WEC1022)' (string) > info.subsystem = 'pnp' (string) > info.udi = '/org/freedesktop/Hal/devices/pnp_WEC1022' (string) > linux.hotplug_type = 2 (0x2) (int) > linux.subsystem = 'pnp' (string) > linux.sysfs_path = '/sys/devices/pnp0/00:04' (string) > pnp.id = 'WEC1022' (string) > So I got the 2 patches to compile with 2.6.30.5. And the module loads without error from the command line, but gives this in dmesg: Winbond CIR 00:04: disabled > Winbond CIR: probe of 00:04 failed with error -12 > what's weird is if I unload it and load it again I get: Winbond CIR 00:04: activated > Winbond CIR 00:04: disabled > Winbond CIR: probe of 00:04 failed with error -12 > But I still don't have anything actually plugged into the CIR port on the mobo yet (it is enabled in bios though). I have it all wired on a breadboard, just haven't had the time to hook it up and test it. Have looked through the code for that error but haven't found anything in the module itself, might be a pnp error code, haven't made it that far. # modinfo winbond-cir > filename: > /lib/modules/2.6.30-gentoo-r5/kernel/drivers/input/misc/winbond-cir.ko > license: GPL > description: Winbond SuperI/O Consumer IR Driver > author: David Härdeman <da...@ha...> > alias: acpi*:WEC1022:* > alias: pnp:dWEC1022* > depends: led-class > vermagic: 2.6.30-gentoo-r5 SMP preempt mod_unload > parm: protocol:IR protocol to use (0 = RC5, 1 = NEC, 2 = RC6A, > default) (uint) > parm: invert:Invert the signal from the IR receiver (bool) > parm: wake_sc:Scancode of the power-on IR command (uint) > parm: wake_rc6mode:RC6 mode for the power-on command (0 = 0, 6 = > 6A, default) (uint) > Wondering if I can set my own scancode for the power-on command using one of the wake_* params. Would be nice since I don't have MCE remote. I do have a universal/learning remote, so I could set it to whatever works. Currently using codes for the Pioneer VXX2910 DVR, just happened to be a preset in my remote. I just don't know much about IR technology/protocols. Whats this RC6 stuff? lirc.conf (partial) > # contributed by Maluta > # > # brand: Pioneer > # model: DVR-520 > # tested with: PIONEER VIDEORECORDER > > begin remote > > name Pioneer_VXX2910 > flags CONST_LENGTH|RAW_CODES > eps 30 > aeps 140 > > ptrail 0 > repeat 0 0 > gap 179619 > > begin raw_codes > > name power > 8570 4189 586 1547 586 1547 > 586 467 586 1547 586 467 > 586 1547 586 467 586 1547 > 586 467 586 467 586 1547 > 586 467 586 1547 586 467 > 586 1547 586 467 586 467 > 586 467 586 1547 586 1547 > 586 467 586 1547 586 467 > 586 467 586 1547 586 1547 > 586 467 586 467 586 1547 > 586 467 586 1547 586 1547 > 586 25485 8570 4189 586 1547 > 586 1547 586 1547 586 1547 > 586 467 586 1547 586 467 > 586 1547 586 467 586 467 > 586 467 586 467 586 1547 > 586 467 586 1547 586 467 > 586 467 586 467 586 1547 > 586 1547 586 1547 586 1547 > 586 467 586 1547 586 1547 > 586 1547 586 467 586 467 > 586 467 586 467 586 1547 > 586 467 586 > -Tony > 2009/8/26 Juan Jesús García de Soria Lucena <ska...@gm...> > > Hi... >> These patches seem very interesting. You could try putting your own values >> into the code if you own any other RC6 remote and can get to know the key >> values. >> >> Check whether you have something under the WEC1022 name in the output of >> lspnp... >> >> >> Some of the things in this patch may apply to my wpc7869l driver for LIRC. >> I wish I had some kind of datasheet when I got the driver written. >> >> >> Best regards, >> >> Juan Jesus. >> >> 2009/8/26 Tony Bones <aar...@gm...> >> >>> I stand corrected, just found another patch that converted the original >>> patch from ACPI to PNP. >>> http://patchwork.kernel.org/patch/41110/ >>> and >>> http://patchwork.kernel.org/patch/40704/ >>> >>> >>> >>> On Tue, Aug 25, 2009 at 2:57 PM, Tony Bones <aar...@gm...>wrote: >>> >>>> Just came across this kernel patch that's suppose to add this Winbond >>>> CIR WPCD376I support. >>>> >>>> http://patchwork.kernel.org/patch/33573/ >>>> Also depends on this patch >>>> http://patchwork.kernel.org/patch/32657/ >>>> >>>> Haven't tried to apply it against 2.6.30.5 yet. And I haven't seen it >>>> in the .31 branch yet. So not sure how well it works. I don't have a >>>> windows MCE remote anyway :/ >>>> >>>> >>>> >>>> >>>> On Tue, Mar 31, 2009 at 10:28 AM, Tony Bones <aar...@gm...>wrote: >>>> >>>>> Hi all, >>>>> I've been searching for lirc support for this CIR chip. I found >>>>> another thread about how Intel and Nuvoton are not releasing information for >>>>> Linux support. But on the tech details page for the chip it says that: >>>>> Glue functions to complement the South Bridge functionality identical >>>>> to the PC8374L Glue >>>>> Pin and software compliance with the existing PC8374L features (see >>>>> more here >>>>> http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/WPCD376I.htm >>>>> ) >>>>> >>>>> So I was wondering if PC8374L has been implemented in lirc? >>>>> >>>>> This chip is on the Intel DG45FC mini-itx mobo. Is there any hope for >>>>> support for this chipset in my lifetime? hehehe >>>>> Is there anything I can do to help? Any info I can provide? >>>>> >>>>> Thanks, >>>>> Tony >>>>> >>>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> >> >> >> >> -- >> Dream small if success is enough for you; dream big if you need to change >> the world. >> > > |
From: Juan J. G. de S. L. <ska...@gm...> - 2009-08-29 07:59:56
|
Hi :-) El 29 de agosto de 2009 00:24, Tony Bones <aar...@gm...> escribió: > I def have the chip, I'm using the same mobo as the author of the driver, a > DG45FC. I do have WEC1022 under lshal > > pnp.id = 'WEC1022' (string) >> > Nice :-) So I got the 2 patches to compile with 2.6.30.5. And the module loads > without error from the command line, but gives this in dmesg: > > Winbond CIR 00:04: disabled >> Winbond CIR: probe of 00:04 failed with error -12 >> > > what's weird is if I unload it and load it again I get: > > Winbond CIR 00:04: activated >> Winbond CIR 00:04: disabled >> Winbond CIR: probe of 00:04 failed with error -12 >> > After looking a little bit at the patch, -12 is a -ENODEV return code (as per include/asm-generic/errno-base.h). And if it's in the probe callback for PNP, you should look at the wbcir_probe() function in the winbond-cir.c file of the patch. There are several instances there where it can return -ENODEV. Several of them should print an error message to the dmesg output ("Invalid resources"), which doesn't seem to happen. There's several dev_dbg() calls in there that probably are disabled. In order to get that debug output in dmesg, just include a line like #define DEBUG 1 as the very first line in the winbond-cir.c file, and recompile. See the following two references: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-06/msg12325.html http://mail.nl.linux.org/kernelnewbies/2006-05/msg00549.html You could also include more debug messages just before the cases that return -ENOMEM without printing anything iin wbcir_probe(). After that you'll have more information about what's actually happening. But I still don't have anything actually plugged into the CIR port on the > mobo yet (it is enabled in bios though). I have it all wired on a > breadboard, just haven't had the time to hook it up and test it. Have > looked through the code for that error but haven't found anything in the > module itself, might be a pnp error code, haven't made it that far. > > # modinfo winbond-cir >> filename: >> /lib/modules/2.6.30-gentoo-r5/kernel/drivers/input/misc/winbond-cir.ko >> license: GPL >> description: Winbond SuperI/O Consumer IR Driver >> author: David Härdeman <da...@ha...> >> alias: acpi*:WEC1022:* >> alias: pnp:dWEC1022* >> depends: led-class >> vermagic: 2.6.30-gentoo-r5 SMP preempt mod_unload >> parm: protocol:IR protocol to use (0 = RC5, 1 = NEC, 2 = RC6A, >> default) (uint) >> parm: invert:Invert the signal from the IR receiver (bool) >> parm: wake_sc:Scancode of the power-on IR command (uint) >> parm: wake_rc6mode:RC6 mode for the power-on command (0 = 0, 6 = >> 6A, default) (uint) >> > > Wondering if I can set my own scancode for the power-on command using one > of the wake_* params. The code seems to be prepared to do so... > Would be nice since I don't have MCE remote. I do have a > universal/learning remote, so I could set it to whatever works. Currently > using codes for the Pioneer VXX2910 DVR, just happened to be a preset in my > remote. I just don't know much about IR technology/protocols. Whats this > RC6 stuff? Just look at http://www.sbprojects.com/knowledge/ir/ir.htm Apart from RAW_CODES (lirc just tries to match pre-recorded space-pulse patterns), lirc supports at least RC6, RC5, SHIFT_ENC, SPACE_ENC modes in which the pulse patterns are translated to actual bits depending on protocol rules. The patch you're looking at doesn't use lirc, but uses its own in-driver decoding for RC5, RC6 and NEC (a variant of SPACE_ENC) protocols. The keys in the default keymap for RC6 mode match the ones I have in the MCE remote that came with my laptop (you can find it in acer/Aspire6530G_input.lircd.conf in the latest lirc distribution), taking into account that lirc actually stores ones and zeros reversed (negated) in the config files. After setting a mode for the driver with the protocol module parameter you should be able to specify the wakeup protocol-specific scan-code in the wake_sc parameter, and to put any desired scancode -> key mapping into the driver by using the input-kbd command of the inpututils package (though I haven't tried it myself). > lirc.conf (partial) > >> # contributed by Maluta >> # >> # brand: Pioneer >> # model: DVR-520 >> # tested with: PIONEER VIDEORECORDER >> >> begin remote >> >> name Pioneer_VXX2910 >> flags CONST_LENGTH|RAW_CODES >> eps 30 >> aeps 140 >> >> ptrail 0 >> repeat 0 0 >> gap 179619 >> >> begin raw_codes >> >> name power >> 8570 4189 586 1547 586 1547 >> 586 467 586 1547 586 467 >> 586 1547 586 467 586 1547 >> 586 467 586 467 586 1547 >> 586 467 586 1547 586 467 >> 586 1547 586 467 586 467 >> 586 467 586 1547 586 1547 >> 586 467 586 1547 586 467 >> 586 467 586 1547 586 1547 >> 586 467 586 467 586 1547 >> 586 467 586 1547 586 1547 >> 586 25485 8570 4189 586 1547 >> 586 1547 586 1547 586 1547 >> 586 467 586 1547 586 467 >> 586 1547 586 467 586 467 >> 586 467 586 467 586 1547 >> 586 467 586 1547 586 467 >> 586 467 586 467 586 1547 >> 586 1547 586 1547 586 1547 >> 586 467 586 1547 586 1547 >> 586 1547 586 467 586 467 >> 586 467 586 467 586 1547 >> 586 467 586 > > This remote definition uses a SPACE_ENC protocol variant. After pasting this excerpt into a file and using irrecord -a to analyze it: skandalfo@rimmer:~$ irrecord -a remote.conf # # this config file was automatically generated # using lirc-0.8.6-CVS(emulation) on Sat Aug 29 09:27:10 2009 # # contributed by # # brand: Pioneer_VXX2910 # model no. of remote control: # devices being controlled by this remote: # begin remote name Pioneer_VXX2910 bits 32 flags SPACE_ENC|CONST_LENGTH eps 30 aeps 140 header 8570 4189 one 586 1547 zero 586 467 ptrail 586 gap 89808 toggle_bit_mask 0x0 begin codes power 0xD52A34CB 0xF50A3DC2 end codes end remote Of course, the first step is knowing whether the driver is loading properly or not, and why it's not loading, if it isn't loading... Best regards, and good luck, Juan Jesus. -- Dream small if success is enough for you; dream big if you need to change the world. |
From: Tony B. <aar...@gm...> - 2009-09-02 23:45:20
|
Thanks for all the great info. It's failing at: > led_trigger_register_simple("cir-tx", &data->txtrigger); > I'm guessing because there is no device actually plugged into the CIR port yet. I'm going to try that later when I have more time. You bring up another point, this is kernel driver and does not work with lirc. I wonder why the author wrote this as a kernel driver instead of a lirc driver. So I'm wondering how this driver would then interact with an application like MythTV. Or even if it would be worthwhile (how much effort) to convert this to a lirc driver so it would just work everywhere lirc works. I can't really use it in its current state until I can get application support for it, I'm guessing. Thanks again Juan, Tony |
From: Juan J. G. de S. L. <ska...@gm...> - 2009-09-04 14:50:21
|
Hi :-) I'm copying David Härdeman, the patch author... Just came across this kernel patch that's suppose to add this Winbond CIR > WPCD376I support. ... http://patchwork.kernel.org/ <http://patchwork.kernel.org/patch/41110/><http://patchwork.kernel.org/patch/41110/> > patch/41110/ <http://patchwork.kernel.org/patch/41110/> <http://patchwork.kernel.org/patch/41110/>and http://patchwork.kernel.org/patch/40704/ El 3 de septiembre de 2009 01:45, Tony Bones <aar...@gm...>escribió: > Thanks for all the great info. It's failing at: > >> led_trigger_register_simple("cir-tx", &data->txtrigger); > > This looks rather strange... This call is simply informing the kernel that a new possible source for triggering a LED is possible (in this case setting the LED on when transmitting IR). I don't know how it may be that this function fails to set data->txtrigger. You could try just commenting out all led_XXX() calls in the code, along with the error checking ifs() to see what happens. > I'm guessing because there is no device actually plugged into the CIR port > yet. I'm going to try that later when I have more time. > > You bring up another point, this is kernel driver and does not work with > lirc. I wonder why the author wrote this as a kernel driver instead of a > lirc driver. So I'm wondering how this driver would then interact with an > application like MythTV. Or even if it would be worthwhile (how much > effort) to convert this to a lirc driver so it would just work everywhere > lirc works. > <long-rant> I've searched a little bit into the mailing lists. It seems there are two camps about this all. "Input" guys just want devices that return keys. This is what the patch you found does, at the cost of decoding the RC-(5|6) protocol in a receiver-specific driver. And, moreover, at the cost of restricting a perfectly generic receiver to a handful of supported protocols (no custom/raw remotes allowed). At least, it seems this patch allows (or at least it should allow) keymap configuration via input-utils input-kbd. Christoph's view (may he correct me if I'm wrong) is that it's not good to tie perfectly generic receivers into specific protocols or remotes. His work in LIRC takes this approach and (most) drivers just report raw data (pulse/space time lengths) to a user space daemon (lircd) that's able to decode any protocol. It's even able to decode the signals of different remotes with different protocols at the same time with any generic (pulse/space length sending) IR receiver. BTW, programs prepared to use LIRC directly talk to lircd via a socket, instead of using input "keys". IIRC, LIRC has a devinput driver that can read the actual keys (decoded key codes) of any input device (the IR receiver in that patch, a real keyboard...) and translate them as a kind of IR remote that programs that know how to use LIRC can then use. In the same way, LIRC now has uinput support, that allows lircd to create a virtual input device (following the kernel input device interface) that emits as key events after lircd has decoded them (be it from a generic LIRC-supported generic receiver, or by forwarding/translating devinput precooked codes). So far my only involvement with LIRC so far has been the wpc8769l driver that I wrote by reverse engineering the thing in my laptop. It seems that the driver you found the patch is for a hardware that shares a fair amount of registers with mine. Probably both of them should be merged. Alas! Each one lives on a different side of the fence, because mine is a generic space/pulse one :-( Without knowing too much about the input/LIRC debate, I think I'm with Christoph about supporting a generic interface with only one point of decoding supporting multiple protocols. In other case you'll have every IR receiver driver doing its own decoding once and again. On the other hand, I prefer the decoding output to get to programs via standard input-device events rather than a LIRC-specific protocol. The X server understands input-device events. The Linux console understands them too... Active focus issues (which application receives the keys you push) are already handled more or less properly, while using the daemons and interfaces native to LIRC requires you to configure a maze of switching "modes" depending on which application you want to receive them (it's MythTV or Xine the one you wanted to "PLAY"?). So I like a lot the work Christoph has put into the uinput support, because it's a very nice step in unifying the "output" half of IR receiving in Linux. The problem is that, even with this, there seems to be people that complains that they are required to install and configure a user space daemon (lircd) in order to use the remote (with receiver) they've just plugged into their machine. They just want to plug in the TV receiver card and be able to just use the remote provided with that card to type in 1, 2, 3, PLAY, PAUSE. They seem to consider the configuration of lircd and the piping of data kernel receiver -> user lircd -> kernel uinput -> user application to be overkill to use a bundled remote. It may be that there is a well defined set of common receiver-remote combinations, but they are specific setups, anyways, and from my point of view you end up coding a lot of specific cases into the kernel instead of using a generic framework with user-space configuration. You duplicate the code (duplicate decoding of signals in each receiver driver) and you reduce the flexibility (fixed receiver <-> protocol combinations). So, if you ask me, I would go the LIRC way in the kernel with a minimalist lircd daemon (just decode -> uinput), or even moving the minimalist decoding daemon into the kernel (some new generic any-protocol framework available for all the drivers), providing user-space interfaces for the mapping of remote codes to input device key codes, and for mapping input receivers to virtual input devices. The other part that LIRC addresses is the sending of IR codes. I don't have any idea about whether it could or should fit into the input-dev framework, or it would be better to put it into a parallel send-only infrastructure. I would actually like to get some authoritative information on the current status of this all and whether there are plans to unify things up. Perhaps Christoph may provide some links or further info (if he has the time and isn't infinitely bored by this saga). </long-rant> I can't really use it in its current state until I can get application > support for it, I'm guessing. > If your application understands LIRC, you could use the devinput driver for lircd. If not, you should be able to configure its keymap to match the "keyboard" keys expected by your application. > Thanks again Juan, > Tony > Best regards, Juan Jesus. -- Dream small if success is enough for you; dream big if you need to change the world. |
From: <li...@ba...> - 2009-09-04 20:37:13
|
Hi! Juan Jesús García de Soria Lucena "ska...@gm..." wrote: [...] > I would actually like to get some authoritative information on the current > status of this all and whether there are plans to unify things up. Perhaps > Christoph may provide some links or further info (if he has the time and > isn't infinitely bored by this saga). Yes, I'm kind of tired of the discussions that come up periodically. Just one point to add to your explanation: the lircd decoder will always stay in user-space, because there are a lot of user-space drivers that rely on it. If you want decoding in kernel-space, you'll have to duplicate code. To a certain degree I can understand David's point when he says "LIRC is out-of-tree, so my only chance to add my driver is to use the input layer". But I would really appreciate it if you guys could help getting LIRC into the tree instead of making it more and more difficult for us by pushing drivers into the kernel that use the input layer instead of LIRC. The LIRC kernel drivers are in a pretty good shape by now and all it needs is someone who can invest some time to post patches on LKML to get it accepted. I know that Jarod plans to do this, but I guess he would be glad if someone could help. Christoph |
From: Jarod W. <ja...@wi...> - 2009-09-04 20:56:41
|
On Sep 4, 2009, at 4:34 PM, Christoph Bartelmus wrote: > Hi! > > Juan Jesús García de Soria Lucena "ska...@gm..." wrote: > [...] >> I would actually like to get some authoritative information on the >> current >> status of this all and whether there are plans to unify things up. >> Perhaps >> Christoph may provide some links or further info (if he has the >> time and >> isn't infinitely bored by this saga). > > Yes, I'm kind of tired of the discussions that come up periodically. > Just one point to add to your explanation: the lircd decoder will > always > stay in user-space, because there are a lot of user-space drivers that > rely on it. If you want decoding in kernel-space, you'll have to > duplicate > code. > > To a certain degree I can understand David's point when he says > "LIRC is > out-of-tree, so my only chance to add my driver is to use the input > layer". But I would really appreciate it if you guys could help > getting > LIRC into the tree instead of making it more and more difficult for > us by > pushing drivers into the kernel that use the input layer instead of > LIRC. > > The LIRC kernel drivers are in a pretty good shape by now and all it > needs > is someone who can invest some time to post patches on LKML to get it > accepted. I know that Jarod plans to do this, but I guess he would > be glad > if someone could help. Indeed. Most of the commonly used drivers are in pretty good shape now, and I've got vacation coming up shortly, during which I plan to submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I will definitely need reviewers for the code at that time. Any drivers not mentioned probably aren't being submitted, as they've had less attention paid to them, and could really use a good in-depth technical read-through and possibly some cleanups before they get sent in. So yeah, I'm actually planning another upstream submission attempt in about 2 weeks. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-09-04 22:05:04
|
On Fri, 2009-09-04 at 16:54 -0400, Jarod Wilson wrote: > On Sep 4, 2009, at 4:34 PM, Christoph Bartelmus wrote: > > > Hi! > > > > Juan Jesús García de Soria Lucena "ska...@gm..." wrote: > > [...] > >> I would actually like to get some authoritative information on the > >> current > >> status of this all and whether there are plans to unify things up. > >> Perhaps > >> Christoph may provide some links or further info (if he has the > >> time and > >> isn't infinitely bored by this saga). > > > > Yes, I'm kind of tired of the discussions that come up periodically. > > Just one point to add to your explanation: the lircd decoder will > > always > > stay in user-space, because there are a lot of user-space drivers that > > rely on it. If you want decoding in kernel-space, you'll have to > > duplicate > > code. > > > > To a certain degree I can understand David's point when he says > > "LIRC is > > out-of-tree, so my only chance to add my driver is to use the input > > layer". But I would really appreciate it if you guys could help > > getting > > LIRC into the tree instead of making it more and more difficult for > > us by > > pushing drivers into the kernel that use the input layer instead of > > LIRC. > > > > The LIRC kernel drivers are in a pretty good shape by now and all it > > needs > > is someone who can invest some time to post patches on LKML to get it > > accepted. I know that Jarod plans to do this, but I guess he would > > be glad > > if someone could help. > > > Indeed. Most of the commonly used drivers are in pretty good shape > now, and I've got vacation coming up shortly, during which I plan to > submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, > lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I > will definitely need reviewers for the code at that time. Any drivers > not mentioned probably aren't being submitted, as they've had less > attention paid to them, and could really use a good in-depth technical > read-through and possibly some cleanups before they get sent in. > > So yeah, I'm actually planning another upstream submission attempt in > about 2 weeks. > I got few notes: * I foresee that every driver that uses LIRCCODE will be met with forks and torches. Devices that work with finite subset of remotes, and send keycodes, really should be handled by a input driver. (And this is the only case) So maybe hold the lirc_i2c? * Currently lirc_dev lacks support for transmitting, thus each and every driver implements their own. Btw, the less drivers are submitted initially, the better. I don't even ask to submit mine, although I did test it against checkpatch. The core problem is the lirc_dev. As soon as it is accepted, drivers can be sent/cleaned up one after another. And, maybe redefine this: #define IRCTL_DEV_NAME "BaseRemoteCtl" Best regards, Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2009-09-05 03:08:35
|
On 09/04/2009 06:04 PM, Maxim Levitsky wrote: >>> The LIRC kernel drivers are in a pretty good shape by now and all it >>> > > needs >>> > > is someone who can invest some time to post patches on LKML to get it >>> > > accepted. I know that Jarod plans to do this, but I guess he would >>> > > be glad >>> > > if someone could help. >> > >> > >> > Indeed. Most of the commonly used drivers are in pretty good shape >> > now, and I've got vacation coming up shortly, during which I plan to >> > submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, >> > lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I >> > will definitely need reviewers for the code at that time. Any drivers >> > not mentioned probably aren't being submitted, as they've had less >> > attention paid to them, and could really use a good in-depth technical >> > read-through and possibly some cleanups before they get sent in. >> > >> > So yeah, I'm actually planning another upstream submission attempt in >> > about 2 weeks. >> > > I got few notes: > > > * I foresee that every driver that uses LIRCCODE will be met with forks > and torches. > Devices that work with finite subset of remotes, and send keycodes, > really should be handled by a input driver. > (And this is the only case) > So maybe hold the lirc_i2c? That's probably prudent. > * Currently lirc_dev lacks support for transmitting, thus each and every > driver implements their own. Well, there's really only three drivers that support transmitting (if I'm thinking clearly), and they're all quite different (lirc_serial, lirc_mceusb and lirc_zilog), so I'm not sure how much shared code there would be. I suppose it could be worth merging anything that is shared into lirc_dev though. > Btw, the less drivers are submitted initially, the better. Yeah, my list got a little longer than I was initially imagining. Those are all the ones that I've personally worked on in recent months, and *know* first-hand are fully functional. I'm not opposed to limiting it to lirc_dev, lirc_imon, lirc_mceusb, lirc_zilog and maybe lirc_serial though to start out. Note that for lirc_imon, lirc_mceusb and lirc_streamzap, I'm thinking more and more that I'd like to add input device support to all of these. Their default mode of operation with no lirc client attached would be to send the keycodes for their default remotes via the input subsystem, but once an lirc client attaches, they'd send their data via the lirc interface. This way, stock remotes work out-of-the-box with no configuration, but you've still got the ability to use lircd for decoding everything, which I think is particularly important for receivers that support umpteen different IR protocols and remotes. See lirc_imon for an example of what I'm talking about. It actually *has* this behavior already, more or less, for the default remote's pad and mouse buttons. Rene Harder and I actually talked about extending lirc_imon this way several weeks back. The more I think about it, the more I like the idea, and want to carry it over to other drivers. > I don't even ask to submit mine, although I did test it against > checkpatch. Note that I didn't mean to suggest your driver wasn't ready, just that I'm not comfortable submitting it, as I've only briefly looked at the code, and couldn't answer any questions about it with much confidence. I'd definitely prefer to see *you* submit it, once we get the first foot in the door. :) > The core problem is the lirc_dev. As soon as it is accepted, drivers can > be sent/cleaned up one after another. Yup. > And, maybe redefine this: > > #define IRCTL_DEV_NAME "BaseRemoteCtl" I'm not particularly attached to that name or any other. Suggestions welcomed. Trivial detail though, and easy to fix if upstream demands it. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-09-06 00:08:00
|
On Fri, 2009-09-04 at 23:12 -0400, Jarod Wilson wrote: > On 09/04/2009 06:04 PM, Maxim Levitsky wrote: > >>> The LIRC kernel drivers are in a pretty good shape by now and all it > >>> > > needs > >>> > > is someone who can invest some time to post patches on LKML to get it > >>> > > accepted. I know that Jarod plans to do this, but I guess he would > >>> > > be glad > >>> > > if someone could help. > >> > > >> > > >> > Indeed. Most of the commonly used drivers are in pretty good shape > >> > now, and I've got vacation coming up shortly, during which I plan to > >> > submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, > >> > lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I > >> > will definitely need reviewers for the code at that time. Any drivers > >> > not mentioned probably aren't being submitted, as they've had less > >> > attention paid to them, and could really use a good in-depth technical > >> > read-through and possibly some cleanups before they get sent in. > >> > > >> > So yeah, I'm actually planning another upstream submission attempt in > >> > about 2 weeks. > >> > > > I got few notes: > > > > > > * I foresee that every driver that uses LIRCCODE will be met with forks > > and torches. > > Devices that work with finite subset of remotes, and send keycodes, > > really should be handled by a input driver. > > (And this is the only case) > > So maybe hold the lirc_i2c? > > That's probably prudent. > > > * Currently lirc_dev lacks support for transmitting, thus each and every > > driver implements their own. > > Well, there's really only three drivers that support transmitting (if > I'm thinking clearly), and they're all quite different (lirc_serial, > lirc_mceusb and lirc_zilog), so I'm not sure how much shared code there > would be. I suppose it could be worth merging anything that is shared > into lirc_dev though. What I think is that, in long term, lirc_dev support should get away from asking drivers to define their fops. Even a tiny wrapper over fops will be enough. Also, I think that set_use_inc, and set_use_dec are misnamed. I think that proper layout for driver operations might be: /* prepare hardware for work - replaces .set_use_inc */ int init(struct lirc_driver *drv) /* shutdown hardware - replaces .set_use_dec */ void deinit(struct lirc_driver *drv) /* receive buffer of data - replaces .add_to_buf */ int receive (struct lirc_driver *drv, struct lirc_buffer *buf) /* transmit a packet*/ int transmit (struct lirc_driver *drv, int* packet, int len) /* flash a led */ int flash_led(struct lirc_driver *drv, int flags); /* set range for for RX carrier. (-1,-1 means use wide receiver)*/ int set_rx_carrier(struct lirc_driver *drv, int low, int high); /* set TX carrier*/ int set_tx_carrier(struct lirc_driver *drv, int carrier); /* duty cycle settings - why we need RX duty cycle?*/ int set_rx_duty_cycle(struct lirc_driver *drv, int duty_cycle); int set_tx_duty_cycle(struct lirc_driver *drv, int duty_cycle); /* set recording mode*/ int set_rx_mode(struct lirc_driver *drv, int mode); int set_tx_mode(struct lirc_driver *drv, int mode); All 'settings' functions return 0 on success, and last set value is then stored in lirc_driver structure. Thus no need for _get functions. Also, on resume from low power state (ram/disk) lirc core calls these functions, to set up device again. Absence of functions indicate that device doesn't support this or that feature. Will be glad to hear your comments. > > > Btw, the less drivers are submitted initially, the better. > > Yeah, my list got a little longer than I was initially imagining. Those > are all the ones that I've personally worked on in recent months, and > *know* first-hand are fully functional. I'm not opposed to limiting it > to lirc_dev, lirc_imon, lirc_mceusb, lirc_zilog and maybe lirc_serial > though to start out. > > Note that for lirc_imon, lirc_mceusb and lirc_streamzap, I'm thinking > more and more that I'd like to add input device support to all of these. > Their default mode of operation with no lirc client attached would be to > send the keycodes for their default remotes via the input subsystem, but > once an lirc client attaches, they'd send their data via the lirc > interface. This way, stock remotes work out-of-the-box with no > configuration, but you've still got the ability to use lircd for > decoding everything, which I think is particularly important for > receivers that support umpteen different IR protocols and remotes. Nice idea, but I suspect you will need a RC6 decoding in kernel to decode default remote for lirc_mceusb? > > See lirc_imon for an example of what I'm talking about. It actually > *has* this behavior already, more or less, for the default remote's pad > and mouse buttons. Rene Harder and I actually talked about extending > lirc_imon this way several weeks back. The more I think about it, the > more I like the idea, and want to carry it over to other drivers. > > > I don't even ask to submit mine, although I did test it against > > checkpatch. > > Note that I didn't mean to suggest your driver wasn't ready, just that > I'm not comfortable submitting it, as I've only briefly looked at the > code, and couldn't answer any questions about it with much confidence. > I'd definitely prefer to see *you* submit it, once we get the first foot > in the door. :) Exactly! As soon as core is in, it will be trivial to submit drivers, and I will submit mine. > > > The core problem is the lirc_dev. As soon as it is accepted, drivers can > > be sent/cleaned up one after another. > > Yup. > > > And, maybe redefine this: > > > > #define IRCTL_DEV_NAME "BaseRemoteCtl" > > I'm not particularly attached to that name or any other. Suggestions > welcomed. Trivial detail though, and easy to fix if upstream demands it. > Sure, #define IRCTL_DEV_NAME "lirc" ? Best regards Maxim Levitsky |
From: Jarod W. <ja...@wi...> - 2009-09-12 04:51:54
|
I promised a reply today, so here's a quick go at it... Things are a bit busy right now with some massive changes taking place in my daily work, the kids getting back into school, hockey and soccer starting up for my son, gymnastics for my daughter, etc... :) On Sep 5, 2009, at 8:07 PM, Maxim Levitsky wrote: > What I think is that, in long term, lirc_dev support should get away > from asking drivers to define their fops. Simpler drivers would certainly be a good thing... > Even a tiny wrapper over fops will be enough. > Also, I think that set_use_inc, and set_use_dec are misnamed. Never was a big fan of those names myself, but they're just names, easy enough to change. > I think that proper layout for driver operations might be: > > > /* prepare hardware for work - replaces .set_use_inc */ > int init(struct lirc_driver *drv) > > /* shutdown hardware - replaces .set_use_dec */ > void deinit(struct lirc_driver *drv) > > > /* receive buffer of data - replaces .add_to_buf */ > int receive (struct lirc_driver *drv, struct lirc_buffer *buf) > > > /* transmit a packet*/ > int transmit (struct lirc_driver *drv, int* packet, int len) > > > /* flash a led */ > int flash_led(struct lirc_driver *drv, int flags); > > > /* set range for for RX carrier. (-1,-1 means use wide receiver)*/ > int set_rx_carrier(struct lirc_driver *drv, > int low, int high); > > /* set TX carrier*/ > int set_tx_carrier(struct lirc_driver *drv, int carrier); > > > /* duty cycle settings - why we need RX duty cycle?*/ > int set_rx_duty_cycle(struct lirc_driver *drv, int duty_cycle); > int set_tx_duty_cycle(struct lirc_driver *drv, int duty_cycle); > > > /* set recording mode*/ > int set_rx_mode(struct lirc_driver *drv, int mode); > int set_tx_mode(struct lirc_driver *drv, int mode); > > > > All 'settings' functions return 0 on success, and last set value is > then > stored in lirc_driver structure. Thus no need for _get functions. > > > Also, on resume from low power state (ram/disk) lirc core calls these > functions, to set up device again. > > Absence of functions indicate that device doesn't support this or that > feature. > > Will be glad to hear your comments. Sounds sane. Just a simple matter of code. And not breaking people's existing setups. ;) >> Note that for lirc_imon, lirc_mceusb and lirc_streamzap, I'm thinking >> more and more that I'd like to add input device support to all of >> these. >> Their default mode of operation with no lirc client attached would >> be to >> send the keycodes for their default remotes via the input >> subsystem, but >> once an lirc client attaches, they'd send their data via the lirc >> interface. This way, stock remotes work out-of-the-box with no >> configuration, but you've still got the ability to use lircd for >> decoding everything, which I think is particularly important for >> receivers that support umpteen different IR protocols and remotes. > Nice idea, but I suspect you will need a RC6 decoding in kernel to > decode default remote for lirc_mceusb? Ah, right, yes. This sort of goes hand in hand with what's apparently being discussed on the linux-input list (crap, I probably need to go hop on *another* mailing list...). It also goes along with some discussion on the linux- media list, about adding assorted shared decoding for remotes shipped with tv tuner cards to have them Just Work out of the box. Not sure if those two are connected, or if this is just such a hot topic right now, its being discussed all over... I'm personally okay with in-kernel decoding of the common protocols, as long as there's still a way to let lircd do it instead. If that initially means supporting both an input device and an lirc device at the same time, that seems like a reasonable compromise to me. Things could/would behave much like the imon driver, sending input events when no lirc clients are attached, and when they are, they send (or receive) data via their lirc device. In the long run, maybe this idea of sending raw IR codes out via input devices gets fleshed out and replaces the need for an lirc device, as David mentioned, but there isn't any fully functional code for that yet (as I understand it), and we already have a working solution here that a LOT of people depend on daily. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-09-08 20:55:32
|
Any update? On Sun, 2009-09-06 at 03:07 +0300, Maxim Levitsky wrote: > On Fri, 2009-09-04 at 23:12 -0400, Jarod Wilson wrote: > > On 09/04/2009 06:04 PM, Maxim Levitsky wrote: > > >>> The LIRC kernel drivers are in a pretty good shape by now and all it > > >>> > > needs > > >>> > > is someone who can invest some time to post patches on LKML to get it > > >>> > > accepted. I know that Jarod plans to do this, but I guess he would > > >>> > > be glad > > >>> > > if someone could help. > > >> > > > >> > > > >> > Indeed. Most of the commonly used drivers are in pretty good shape > > >> > now, and I've got vacation coming up shortly, during which I plan to > > >> > submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, > > >> > lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I > > >> > will definitely need reviewers for the code at that time. Any drivers > > >> > not mentioned probably aren't being submitted, as they've had less > > >> > attention paid to them, and could really use a good in-depth technical > > >> > read-through and possibly some cleanups before they get sent in. > > >> > > > >> > So yeah, I'm actually planning another upstream submission attempt in > > >> > about 2 weeks. > > >> > > > > I got few notes: > > > > > > > > > * I foresee that every driver that uses LIRCCODE will be met with forks > > > and torches. > > > Devices that work with finite subset of remotes, and send keycodes, > > > really should be handled by a input driver. > > > (And this is the only case) > > > So maybe hold the lirc_i2c? > > > > That's probably prudent. > > > > > * Currently lirc_dev lacks support for transmitting, thus each and every > > > driver implements their own. > > > > Well, there's really only three drivers that support transmitting (if > > I'm thinking clearly), and they're all quite different (lirc_serial, > > lirc_mceusb and lirc_zilog), so I'm not sure how much shared code there > > would be. I suppose it could be worth merging anything that is shared > > into lirc_dev though. > What I think is that, in long term, lirc_dev support should get away > from asking drivers to define their fops. > Even a tiny wrapper over fops will be enough. > Also, I think that set_use_inc, and set_use_dec are misnamed. > > I think that proper layout for driver operations might be: > > > /* prepare hardware for work - replaces .set_use_inc */ > int init(struct lirc_driver *drv) > > /* shutdown hardware - replaces .set_use_dec */ > void deinit(struct lirc_driver *drv) > > > /* receive buffer of data - replaces .add_to_buf */ > int receive (struct lirc_driver *drv, struct lirc_buffer *buf) > > > /* transmit a packet*/ > int transmit (struct lirc_driver *drv, int* packet, int len) > > > /* flash a led */ > int flash_led(struct lirc_driver *drv, int flags); > > > /* set range for for RX carrier. (-1,-1 means use wide receiver)*/ > int set_rx_carrier(struct lirc_driver *drv, > int low, int high); > > /* set TX carrier*/ > int set_tx_carrier(struct lirc_driver *drv, int carrier); > > > /* duty cycle settings - why we need RX duty cycle?*/ > int set_rx_duty_cycle(struct lirc_driver *drv, int duty_cycle); > int set_tx_duty_cycle(struct lirc_driver *drv, int duty_cycle); > > > /* set recording mode*/ > int set_rx_mode(struct lirc_driver *drv, int mode); > int set_tx_mode(struct lirc_driver *drv, int mode); > > > > All 'settings' functions return 0 on success, and last set value is then > stored in lirc_driver structure. Thus no need for _get functions. > > > Also, on resume from low power state (ram/disk) lirc core calls these > functions, to set up device again. > > Absence of functions indicate that device doesn't support this or that > feature. > > Will be glad to hear your comments. > > > > > > > > Btw, the less drivers are submitted initially, the better. > > > > Yeah, my list got a little longer than I was initially imagining. Those > > are all the ones that I've personally worked on in recent months, and > > *know* first-hand are fully functional. I'm not opposed to limiting it > > to lirc_dev, lirc_imon, lirc_mceusb, lirc_zilog and maybe lirc_serial > > though to start out. > > > > Note that for lirc_imon, lirc_mceusb and lirc_streamzap, I'm thinking > > more and more that I'd like to add input device support to all of these. > > Their default mode of operation with no lirc client attached would be to > > send the keycodes for their default remotes via the input subsystem, but > > once an lirc client attaches, they'd send their data via the lirc > > interface. This way, stock remotes work out-of-the-box with no > > configuration, but you've still got the ability to use lircd for > > decoding everything, which I think is particularly important for > > receivers that support umpteen different IR protocols and remotes. > Nice idea, but I suspect you will need a RC6 decoding in kernel to > decode default remote for lirc_mceusb? > > > > > > > See lirc_imon for an example of what I'm talking about. It actually > > *has* this behavior already, more or less, for the default remote's pad > > and mouse buttons. Rene Harder and I actually talked about extending > > lirc_imon this way several weeks back. The more I think about it, the > > more I like the idea, and want to carry it over to other drivers. > > > > > I don't even ask to submit mine, although I did test it against > > > checkpatch. > > > > Note that I didn't mean to suggest your driver wasn't ready, just that > > I'm not comfortable submitting it, as I've only briefly looked at the > > code, and couldn't answer any questions about it with much confidence. > > I'd definitely prefer to see *you* submit it, once we get the first foot > > in the door. :) > Exactly! > > As soon as core is in, it will be trivial to submit drivers, and I will > submit mine. > > > > > > > The core problem is the lirc_dev. As soon as it is accepted, drivers can > > > be sent/cleaned up one after another. > > > > Yup. > > > > > And, maybe redefine this: > > > > > > #define IRCTL_DEV_NAME "BaseRemoteCtl" > > > > I'm not particularly attached to that name or any other. Suggestions > > welcomed. Trivial detail though, and easy to fix if upstream demands it. > > > Sure, > #define IRCTL_DEV_NAME "lirc" ? > > > Best regards > Maxim Levitsky > > |
From: Jarod W. <ja...@wi...> - 2009-09-11 04:24:27
|
On 09/08/2009 04:55 PM, Maxim Levitsky wrote: > Any update? Sorry, been tied up w/other things... Will try to get in a proper reply tomorrow though. --jarod > On Sun, 2009-09-06 at 03:07 +0300, Maxim Levitsky wrote: >> On Fri, 2009-09-04 at 23:12 -0400, Jarod Wilson wrote: >>> On 09/04/2009 06:04 PM, Maxim Levitsky wrote: >>>>>> The LIRC kernel drivers are in a pretty good shape by now and all it >>>>>>> > needs >>>>>>> > is someone who can invest some time to post patches on LKML to get it >>>>>>> > accepted. I know that Jarod plans to do this, but I guess he would >>>>>>> > be glad >>>>>>> > if someone could help. >>>>>> >>>>>> >>>>>> Indeed. Most of the commonly used drivers are in pretty good shape >>>>>> now, and I've got vacation coming up shortly, during which I plan to >>>>>> submit at least lirc_dev, lirc_imon, lirc_mceusb, lirc_serial, >>>>>> lirc_streamzap, lirc_i2c and lirc_zilog to lkml for review again. I >>>>>> will definitely need reviewers for the code at that time. Any drivers >>>>>> not mentioned probably aren't being submitted, as they've had less >>>>>> attention paid to them, and could really use a good in-depth technical >>>>>> read-through and possibly some cleanups before they get sent in. >>>>>> >>>>>> So yeah, I'm actually planning another upstream submission attempt in >>>>>> about 2 weeks. >>>>>> >>>> I got few notes: ... -- Jarod Wilson ja...@wi... |
From: <li...@ba...> - 2009-09-11 05:50:23
|
Hi! Maxim Levitsky "max...@gm..." wrote: > Any update? I'm always a bit reluctant to change things that simply work. Maybe you can add some reasoning what would be the advantage of the change. [...] >> What I think is that, in long term, lirc_dev support should get away >> from asking drivers to define their fops. >> Even a tiny wrapper over fops will be enough. >> Also, I think that set_use_inc, and set_use_dec are misnamed. Yes, no problem renaming this. >> I think that proper layout for driver operations might be: >> >> >> /* prepare hardware for work - replaces .set_use_inc */ >> int init(struct lirc_driver *drv) >> >> /* shutdown hardware - replaces .set_use_dec */ >> void deinit(struct lirc_driver *drv) [...] >> /* flash a led */ >> int flash_led(struct lirc_driver *drv, int flags); Don't see where this could be used. [...] Christoph |
From: Maxim L. <max...@gm...> - 2009-09-11 13:56:46
|
On Fri, 2009-09-11 at 07:49 +0200, Christoph Bartelmus wrote: > Hi! > > Maxim Levitsky "max...@gm..." wrote: > > > Any update? > > I'm always a bit reluctant to change things that simply work. > Maybe you can add some reasoning what would be the advantage of the > change. I want to get rid of fops usage in lirc drivers. I think that callbacks like I proposed allow driver to recieve abstracted interface (and thin layer of abstraction can do error checking for example) It ca also ensure common behavior among drivers. Also, lirc interface is based on ioctls, thus every driver needs to implement code to verify input attributes. Also, with new interface, most of settings can be transparently stored in lirc_driver structure, thus allow to eliminate the need of GET_ support in each driver. I hope that will ease the inclusion of the lirc in kernel, and remove some lines of redundant code. Also there aren't many lirc drivers, so porting them all isn't a problem. Only problem, that I didn't yet look at, was how to pass transmit buffer to driver. I don't want to pass same pointer as ioctl receives, since it is a user pointer, so I need to copy it to buffer. This buffer can be ether preallocated or allocated each time. It would be great to reuse lirc_buffer_t for that. > > [...] > >> What I think is that, in long term, lirc_dev support should get away > >> from asking drivers to define their fops. > >> Even a tiny wrapper over fops will be enough. > >> Also, I think that set_use_inc, and set_use_dec are misnamed. > > Yes, no problem renaming this. > > >> I think that proper layout for driver operations might be: > >> > >> > >> /* prepare hardware for work - replaces .set_use_inc */ > >> int init(struct lirc_driver *drv) > >> > >> /* shutdown hardware - replaces .set_use_dec */ > >> void deinit(struct lirc_driver *drv) > [...] > >> /* flash a led */ > >> int flash_led(struct lirc_driver *drv, int flags); > > Don't see where this could be used. It is used now by issuing the LIRC_CAN_NOTIFY_DECODE Don't know if lirc uses this ioctl, but it can be used to flash a light on the receiver (I have no problem to give that another name, something like .notify_decode) Best regards, Maxim Levitsky |
From: <li...@ba...> - 2009-09-20 11:07:08
|
Hi! Maxim Levitsky "max...@gm..." wrote: [...] >> I'm always a bit reluctant to change things that simply work. >> Maybe you can add some reasoning what would be the advantage of the >> change. > I want to get rid of fops usage in lirc drivers. I'd like to do it in small steps. First one would be to change all drivers still implementing their own open() function and get rid of that. Then rename set_use_inc/set_use_dec. Still looking for a good name. Add a field for LIRC_GET_REC_RESOLUTION into the lirc_driver struct. Is this something you'd like to work on? Christoph |
From: Maxim L. <max...@gm...> - 2009-09-20 21:34:16
|
On Sun, 2009-09-20 at 13:04 +0200, Christoph Bartelmus wrote: > Hi! > > Maxim Levitsky "max...@gm..." wrote: > [...] > >> I'm always a bit reluctant to change things that simply work. > >> Maybe you can add some reasoning what would be the advantage of the > >> change. > > > I want to get rid of fops usage in lirc drivers. > > I'd like to do it in small steps. > First one would be to change all drivers still implementing their own > open() function and get rid of that. > Then rename set_use_inc/set_use_dec. Still looking for a good name. > Add a field for LIRC_GET_REC_RESOLUTION into the lirc_driver struct. > > Is this something you'd like to work on? Exactly! Best regards, Maxim Levitsky |
From: David H. <da...@ha...> - 2009-09-11 10:25:21
|
On Fri, September 4, 2009 16:50, Juan Jesús García de Soria Lucena wrote: > On 2009 01:45, Tony Bones wrote: >> >> Thanks for all the great info. It's failing at: >> >>> led_trigger_register_simple("cir-tx", &data->txtrigger); >> >> I'm looking into it with Tony in a private conversation and those parts aren't that interesting to the Lirc list... >> You bring up another point, this is kernel driver and does not work with >> lirc. I wonder why the author wrote this as a kernel driver instead of >> a lirc driver. So I'm wondering how this driver would then interact >> with an application like MythTV. Or even if it would be worthwhile >> (how much effort) to convert this to a lirc driver so it would just >> work everywhere lirc works. As a stop-gap measure for my driver, and any in-kernel driver which uses the input layer, you can use the inputlirc daemon which will translate input key events to lirc events. > <long-rant> <long-rant-reply> As you sent me a long rant I can only assume you'd like the favour to be returned in kind :) > I've searched a little bit into the mailing lists. > > It seems there are two camps about this all. "Input" guys just want > devices that return keys. This is what the patch you found does, at > the cost of decoding the RC-(5|6) protocol in a receiver-specific > driver. Well, I don't think that's accurate. The "Input" guys do not want an entire IR specific driver layer to be bolted on to the kernel in addition to the input layer. But they certainly seem willing to take patches to extend the Input layer with IR specific functionality. > And, moreover, > at the cost of restricting a perfectly generic receiver to a handful of > supported protocols (no custom/raw remotes allowed). Yes and no. The patch is the first generation of the driver. The input handling is currently limited to RC5/RC6/NEC. The hardware can decode any reasonable protocol but the wake-on-IR parts *are* limited to RC5/RC6/NEC by the hardware so while a more generic driver could support arbitrary remotes, you'd lose one of the key advantages of the hardware (power-on-from-S3/4/5) by using an exotic remote control. Anyways, the goal is to extend the input layer to allow it to report raw ir pulse-space timings to interested clients (which means that lirc-dev isn't necessary). See the posts I've made to linux-input with regard to IR_RAW. > At least, it seems this > patch allows (or at least it should allow) keymap configuration via > input-utils input-kbd. Yes it does. > Christoph's view (may he correct me if I'm wrong) is that it's not good to > tie perfectly generic receivers into specific protocols or remotes. His > work > in LIRC takes this approach and (most) drivers just report raw data > (pulse/space time lengths) to a user space daemon (lircd) that's able to > decode any protocol. It's even able to decode the signals of different > remotes with different protocols at the same time with any generic > (pulse/space length sending) IR receiver. And that could still be supported if the input layer got some additional capabilities (see IR_RAW above). > BTW, programs prepared to use LIRC directly talk to lircd via a socket, > instead of using input "keys". IIRC, LIRC has a devinput driver that can > read the actual keys (decoded key codes) of any input device (the IR > receiver in that patch, a real keyboard...) and translate them as a kind > of > IR remote that programs that know how to use LIRC can then use. > > In the same way, LIRC now has uinput support, that allows lircd to create > a > virtual input device (following the kernel input device interface) that > emits as key events after lircd has decoded them (be it from a generic > LIRC-supported generic receiver, or by forwarding/translating devinput > precooked codes). > > So far my only involvement with LIRC so far has been the wpc8769l driver > that I wrote by reverse engineering the thing in my laptop. It seems that > the driver you found the patch is for a hardware that shares a fair amount > of registers with mine. Probably both of them should be merged. Alas! Each > one lives on a different side of the fence, because mine is a generic > space/pulse one :-( After looking at your driver I agree that your driver and mine are prime candidates for a merge. I have docs from Intel which describe my hardware (specifically the wake-on-IR parts) which I can't share since I haven't received permission from Intel to do so. The rest (90% of the driver - the UART registers - which are the same in both our drivers) are fairly standard and documentation should be obtainable. We could certainly discuss a merger if you wish... > Without knowing too much about the input/LIRC debate, I think I'm with > Christoph about supporting a generic interface with only one point of > decoding supporting multiple protocols. In other case you'll have every IR > receiver driver doing its own decoding once and again. No, you'd have common IR decoders shared between drivers. > On the other hand, I prefer the decoding output to get to programs via > standard input-device events rather than a LIRC-specific protocol. The X > server understands input-device events. The Linux console understands them > too... Active focus issues (which application receives the keys you push) > are already handled more or less properly, while using the daemons and > interfaces native to LIRC requires you to configure a maze of switching > "modes" depending on which application you want to receive them (it's > MythTV > or Xine the one you wanted to "PLAY"?). Not to mention that every app needs to have keyboard-input and lirc-input code written. ... > So, if you ask me, I would go the LIRC way in the kernel with a minimalist > lircd daemon (just decode -> uinput), or even moving the minimalist > decoding > daemon into the kernel (some new generic any-protocol framework available > for all the drivers), providing user-space interfaces for the mapping of > remote codes to input device key codes, and for mapping input receivers to > virtual input devices. I've already outlined how I think a kernel API could look...see the thread at: http://marc.info/?t=124981207300001&r=1&w=2 > The other part that LIRC addresses is the sending of IR codes. I don't > have > any idea about whether it could or should fit into the input-dev > framework, > or it would be better to put it into a parallel send-only infrastructure. I think it could, and should, be implemented as part of the input layer. Note that the input layer already has a special-case API for dealing with force-feedback hardware (mostly additional ioctl's). > I would actually like to get some authoritative information on the current > status of this all and whether there are plans to unify things up. You're unlikely to get any authoritative info, different people have different opinions as to the best way to go forward...but the input people on the kernel side of things are (I believe) the gatekeepers that will get to decide in the end what goes into the kernel and what doesn't... > Perhaps > Christoph may provide some links or further info (if he has the time and > isn't infinitely bored by this saga). I can certainly sympathise with Christoph if he is bored by this saga. > </long-rant> </long-rant-reply> -- David Härdeman |