Menu
▾
▴
lirc-list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(29) |
Jul
(51) |
Aug
(40) |
Sep
(35) |
Oct
(58) |
Nov
(64) |
Dec
(70) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(111) |
Feb
(75) |
Mar
(85) |
Apr
(62) |
May
(56) |
Jun
(65) |
Jul
(67) |
Aug
(73) |
Sep
(46) |
Oct
(64) |
Nov
(55) |
Dec
(76) |
| 2002 |
Jan
(119) |
Feb
(74) |
Mar
(101) |
Apr
(128) |
May
(124) |
Jun
(138) |
Jul
(114) |
Aug
(63) |
Sep
(54) |
Oct
(135) |
Nov
(92) |
Dec
(127) |
| 2003 |
Jan
(129) |
Feb
(164) |
Mar
(129) |
Apr
(131) |
May
(181) |
Jun
(136) |
Jul
(118) |
Aug
(220) |
Sep
(116) |
Oct
(177) |
Nov
(206) |
Dec
(114) |
| 2004 |
Jan
(175) |
Feb
(222) |
Mar
(245) |
Apr
(209) |
May
(112) |
Jun
(104) |
Jul
(77) |
Aug
(115) |
Sep
(175) |
Oct
(141) |
Nov
(154) |
Dec
(190) |
| 2005 |
Jan
(198) |
Feb
(171) |
Mar
(164) |
Apr
(113) |
May
(104) |
Jun
(151) |
Jul
(107) |
Aug
(190) |
Sep
(142) |
Oct
(116) |
Nov
(113) |
Dec
(111) |
| 2006 |
Jan
(147) |
Feb
(103) |
Mar
(102) |
Apr
(75) |
May
(110) |
Jun
(82) |
Jul
(119) |
Aug
(77) |
Sep
(103) |
Oct
(188) |
Nov
(132) |
Dec
(155) |
| 2007 |
Jan
(169) |
Feb
(110) |
Mar
(113) |
Apr
(162) |
May
(107) |
Jun
(116) |
Jul
(159) |
Aug
(135) |
Sep
(135) |
Oct
(105) |
Nov
(96) |
Dec
(100) |
| 2008 |
Jan
(122) |
Feb
(93) |
Mar
(57) |
Apr
(80) |
May
(119) |
Jun
(85) |
Jul
(59) |
Aug
(73) |
Sep
(250) |
Oct
(146) |
Nov
(121) |
Dec
(72) |
| 2009 |
Jan
(193) |
Feb
(96) |
Mar
(102) |
Apr
(66) |
May
(99) |
Jun
(130) |
Jul
(206) |
Aug
(308) |
Sep
(117) |
Oct
(99) |
Nov
(170) |
Dec
(232) |
| 2010 |
Jan
(104) |
Feb
(127) |
Mar
(86) |
Apr
(111) |
May
(66) |
Jun
(44) |
Jul
(253) |
Aug
(120) |
Sep
(178) |
Oct
(220) |
Nov
(153) |
Dec
(157) |
| 2011 |
Jan
(80) |
Feb
(85) |
Mar
(129) |
Apr
(232) |
May
(236) |
Jun
(73) |
Jul
(53) |
Aug
(38) |
Sep
(23) |
Oct
(32) |
Nov
(25) |
Dec
(24) |
| 2012 |
Jan
(23) |
Feb
(43) |
Mar
(29) |
Apr
(50) |
May
(25) |
Jun
(15) |
Jul
(26) |
Aug
(26) |
Sep
(4) |
Oct
(10) |
Nov
(17) |
Dec
(18) |
| 2013 |
Jan
(12) |
Feb
(17) |
Mar
(15) |
Apr
(22) |
May
(29) |
Jun
(16) |
Jul
(15) |
Aug
(9) |
Sep
(45) |
Oct
(18) |
Nov
(21) |
Dec
(11) |
| 2014 |
Jan
(35) |
Feb
(34) |
Mar
(13) |
Apr
(14) |
May
(86) |
Jun
(23) |
Jul
(6) |
Aug
(18) |
Sep
(16) |
Oct
(36) |
Nov
(98) |
Dec
(62) |
| 2015 |
Jan
(27) |
Feb
(14) |
Mar
(5) |
Apr
(49) |
May
(27) |
Jun
(9) |
Jul
(11) |
Aug
(20) |
Sep
(26) |
Oct
(71) |
Nov
(2) |
Dec
(7) |
| 2016 |
Jan
(42) |
Feb
(3) |
Mar
(15) |
Apr
(34) |
May
(25) |
Jun
(39) |
Jul
(20) |
Aug
(85) |
Sep
(14) |
Oct
(82) |
Nov
(10) |
Dec
(34) |
| 2017 |
Jan
(29) |
Feb
(88) |
Mar
(78) |
Apr
(4) |
May
(7) |
Jun
(30) |
Jul
(4) |
Aug
(47) |
Sep
(14) |
Oct
(47) |
Nov
(5) |
Dec
(3) |
| 2018 |
Jan
(18) |
Feb
(13) |
Mar
(6) |
Apr
(8) |
May
(11) |
Jun
(1) |
Jul
(11) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
(23) |
| 2019 |
Jan
(5) |
Feb
(15) |
Mar
(11) |
Apr
(4) |
May
(15) |
Jun
(12) |
Jul
(4) |
Aug
(5) |
Sep
(14) |
Oct
(3) |
Nov
(10) |
Dec
|
| 2020 |
Jan
|
Feb
(5) |
Mar
(23) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2021 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(4) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(13) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
|
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(2) |
|
2
(11) |
3
(25) |
4
(26) |
5
(15) |
6
(15) |
7
(7) |
8
(2) |
|
9
(12) |
10
(17) |
11
(12) |
12
(4) |
13
(9) |
14
(3) |
15
(12) |
|
16
(12) |
17
(9) |
18
(11) |
19
(14) |
20
(15) |
21
(7) |
22
(6) |
|
23
(1) |
24
(7) |
25
(9) |
26
(3) |
27
(9) |
28
(13) |
29
(9) |
|
30
(5) |
31
(6) |
|
|
|
|
|
|
From: Jarod W. <ja...@wi...> - 2009-08-31 18:23:15
|
On Aug 31, 2009, at 1:02 PM, Christoph Bartelmus wrote: > Hi! > > Axel Thimm "Axe...@AT..." wrote: > [...] >> 0.8.4a builds fine on both, but 0.8.5 fails with >> >> RHEL5 (2.6.18 based): > > Fixed that one. Oh good, I started to look at that this morning, and quickly got sidetracked... I can confirm that fixes the lirc_dev build on RHEL5. > [...] >> RHEL4 (2.6.9 based): >> In file included from /builddir/lirc-0.8.5/drivers/lirc_dev/ >> lirc_dev.c:64: >> /builddir/lirc-0.8.5/drivers/lirc_dev/../../drivers/kcompat.h:388: >> error: >> conflicting types for 'kzalloc' include/linux/slab.h:101: error: >> previous >> declaration of 'kzalloc' was here /builddir/lirc-0.8.5/drivers/ >> lirc_dev/../. >> ./drivers/kcompat.h:388: error: conflicting types for 'kzalloc' >> include/linux/slab.h:101: error: previous declaration of 'kzalloc' >> was here > > This doesn't seem to be a 2.6.9 kernel. There's no kzalloc > declaration in > the original sources. The joy of Red Hat Enterprise Linux and backporting stuff for years and years. Looks like kzalloc was added fairly early on to the RHEL4 kernel. -- Jarod Wilson ja...@wi... |
|
From: <li...@ba...> - 2009-08-31 17:03:04
|
Hi! Axel Thimm "Axe...@AT..." wrote: [...] > 0.8.4a builds fine on both, but 0.8.5 fails with > > RHEL5 (2.6.18 based): Fixed that one. [...] > RHEL4 (2.6.9 based): > In file included from /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:64: > /builddir/lirc-0.8.5/drivers/lirc_dev/../../drivers/kcompat.h:388: error: > conflicting types for 'kzalloc' include/linux/slab.h:101: error: previous > declaration of 'kzalloc' was here /builddir/lirc-0.8.5/drivers/lirc_dev/../. > ./drivers/kcompat.h:388: error: conflicting types for 'kzalloc' > include/linux/slab.h:101: error: previous declaration of 'kzalloc' was here This doesn't seem to be a 2.6.9 kernel. There's no kzalloc declaration in the original sources. Christoph |
|
From: Jarod W. <ja...@wi...> - 2009-08-31 13:54:20
|
On Aug 31, 2009, at 8:16 AM, Anders Eriksson wrote: > ja...@wi... said: >> Was reasonably obvious why after reading over a bit of code... >> Setting the >> ir protocol requires a device with control urb endpoints, which >> the ffdc >> devices don't have. I've fixed the code in cvs so that it'll print >> a warning >> when someone tries to set the proto on a device that doesn't >> support it, and >> just fall back to imon proto. > > Hmmm. That's alarming. > > I've got an ffdc + Harmony525 and the only combo I got working > consistently > was in MCE mode. That is, ir_protocol=1 and install MCE emulation on > the > harmony. This is on a cvs lirc as of ca 3 weeks ago. > > Any testing needed? Yes, actually... Another user on the mythtv mailing lists mentioned this weekend that they had an ffdc device that they used exclusively in mce mode. It seems to be yet another case of SoundGraph putting the same device ID on wildly differing hardware. :\ *HOWEVER*, I believe the check added looks for a tx control endpoint, and if not found, then things fall back to imon proto. Since it appears your devices *does* have a tx control endpoint (lest the ir proto setting never would have took), it *should* still get past that check and behave as expected, but confirmation of that would be good. On a semi-related note, I'll add that I'm using my own imon receiver with a harmony 880 programmed as an Antec Veris or Antec Fusion remote or some such thing (i.e., native imon protocol), and its actually working quite well. Most keys repeat more than I'd like, but someone from the knoppmyth team is actually talking to Logitech about tightening up their Antec remote profile so this doesn't happen anymore. So currently, with the aid of a ~/.lircrc with some relatively high repeat= lines for each button, I can use both my harmony 880 and the stock RM200 remote simultaneously (just can't hold any buttons on the harmony for very long or I get extra repeats). -- Jarod Wilson ja...@wi... |
|
From: Anders E. <aer...@fa...> - 2009-08-31 13:02:57
|
ja...@wi... said: > Was reasonably obvious why after reading over a bit of code... Setting the > ir protocol requires a device with control urb endpoints, which the ffdc > devices don't have. I've fixed the code in cvs so that it'll print a warning > when someone tries to set the proto on a device that doesn't support it, and > just fall back to imon proto. Hmmm. That's alarming. I've got an ffdc + Harmony525 and the only combo I got working consistently was in MCE mode. That is, ir_protocol=1 and install MCE emulation on the harmony. This is on a cvs lirc as of ca 3 weeks ago. Any testing needed? /A |
|
From: Paul B. <peb...@gm...> - 2009-08-31 05:17:59
|
Jarod Wilson wrote: > On Sunday 30 August 2009 11:36:20 Paul Bender wrote: >> Christoph Bartelmus wrote: >>> Hi, >>> >>> there's a new pre-release for 0.8.6 online: >>> >>> http://www.lirc.org/software/snapshots/lirc-0.8.6pre2.tar.bz2 >> I ran into a problem compiling with kernel 2.6.31-rc8. It appears to be >> caused by ir_receiver_id in lirc_i2c being used before it is defined. I >> have attached a patch that fixes it for me. > > Bah. I made that same fix in my git tree and apparently forgot to add > it to cvs. Just committed it, thanks much. Thanks. Your commit fixes it for me. |
|
From: Calhoun, S. P. <ph...@ou...> - 2009-08-31 05:06:14
|
________________________________________ From: Jarod Wilson [ja...@wi...] Sent: Saturday, August 29, 2009 2:55 PM To: Calhoun, Patrick Cc: lir...@li... Subject: Re: mceusb gen1 transmit >Okay, so I get slightly better results using output #2, but something >still isn't quite right. I'm looping the transmitter back to the device >itself, and at least with #2, the receiver lights up on every transmit >attempt, so its always seeing *something*, but irw only registers a >correct key every once in a while. So we're inching closer, but still >not quite there yet... I haven't yet looked at debug spew to try to >make heads or tails of what's going on. Hrm. I was able to reproduce your problem looping transmitter back to receiver on the mceusb gen1. I noticed that if I tried doing irsend -#3 SEND_ONCE <remote> <key>, then 1 or 2 out of 4 transmissions usually arrived at the irw end of the setup. When I did my initial testing before I submitted the patch, I used a second mceusb gen1 device: one for transmitting, and one for receiving. This setup ran better than the feedback setup. I had the receiver end listening using mode2, and I piped that into a little perl script to parse the protocol for the particular remote I was using. I'd say I got 100% transmission success, and the few times a code was not recognized, I blame the perl program (and it's equivalent to too strict eps/aeps values). As far as irw goes, it looks like things work pretty well using the two-transceiver setup: # lircd -d /dev/lirc0 --output=/dev/lircd0 --pidfile=/var/run/lirc/lircd0.pid # lircd -d /dev/lirc1 --output=/dev/lircd1 --pidfile=/var/run/lirc/lircd1.pid # irw /dev/lircd1 & irsend -#3 -d /dev/lircd0 SEND_ONCE viera KEY_POWER 000040040100bcbd 00 KEY_POWER viera 000040040100bcbd 01 KEY_POWER viera 000040040100bcbd 02 KEY_POWER viera 000040040100bcbd 03 KEY_POWER viera Given these observations, it looks to me like the device enjoys transmitting XOR receiving; not both at once. I will defer to your experience since you have been working with these devices and drivers a bit more than I have. I noticed when I was doing some snooping, that the device can operate in BULK mode rather than INTERRUPT mode. Do you think there is a chance that changing to bulk mode could remedy this situation (if xmit & receive are competing for clock cycles, and only one interrupt service routine can run at a time)? (as an aside, although the viera codes seem to get received just fine by an mceusb, the transmissions still won't control my viera TV. I've had great results with other appliances and the mceusb gen1, though.) -Patrick |
|
From: Axel T. <Axe...@AT...> - 2009-08-30 19:44:37
|
Hi, 0.8.4a builds fine on both, but 0.8.5 fails with RHEL5 (2.6.18 based): /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function 'lirc_thread': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:196: warning: 'interruptible_sleep_on' is deprecated (declared at include/linux/wait.h:375) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function 'irctl_compat_ioctl': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:787: error: 'struct file' has no member named 'f_path' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:821: error: 'struct file' has no member named 'f_path' RHEL4 (2.6.9 based): In file included from /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:64: /builddir/lirc-0.8.5/drivers/lirc_dev/../../drivers/kcompat.h:388: error: conflicting types for 'kzalloc' include/linux/slab.h:101: error: previous declaration of 'kzalloc' was here /builddir/lirc-0.8.5/drivers/lirc_dev/../../drivers/kcompat.h:388: error: conflicting types for 'kzalloc' include/linux/slab.h:101: error: previous declaration of 'kzalloc' was here /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:90: error: field `buffer_lock' has incomplete type /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:109: warning: type defaults to `int' in declaration of `DEFINE_MUTEX' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:109: warning: parameter names (without types) in function declaration /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `init_irctl': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:122: warning: implicit declaration of function `mutex_init' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `lirc_thread': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:196: warning: `interruptible_sleep_on' is deprecated (declared at include/linux/wait.h:290) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `lirc_register_driver': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:317: warning: implicit declaration of function `mutex_lock' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:317: error: `driver_lock' undeclared (first use in this function) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:317: error: (Each undeclared identifier is reported only once /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:317: error: for each function it appears in.) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:424: warning: implicit declaration of function `mutex_unlock' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:439: warning: implicit declaration of function `class_device_destroy' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `lirc_unregister_driver': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:471: error: `driver_lock' undeclared (first use in this function) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `irctl_open': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:567: warning: implicit declaration of function `mutex_lock_interruptible' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:567: error: `driver_lock' undeclared (first use in this function) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `irctl_close': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:629: error: `driver_lock' undeclared (first use in this function) /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: In function `irctl_compat_ioctl': /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:785: warning: implicit declaration of function `_IOC_TYPECHECK' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:785: error: syntax error before "unsigned" /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:785: error: syntax error before ')' token /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:787: error: structure has no member named `f_path' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:821: error: structure has no member named `f_path' /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c: At top level: /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:968: error: unknown field `compat_ioctl' specified in initializer /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:968: warning: initialization from incompatible pointer type /builddir/lirc-0.8.5/drivers/lirc_dev/lirc_dev.c:109: warning: 'DEFINE_MUTEX' declared `static' but never defined -- Axel.Thimm at ATrpms.net |
|
From: Jarod W. <ja...@wi...> - 2009-08-30 17:01:14
|
On Sunday 30 August 2009 11:36:20 Paul Bender wrote: > Christoph Bartelmus wrote: > > Hi, > > > > there's a new pre-release for 0.8.6 online: > > > > http://www.lirc.org/software/snapshots/lirc-0.8.6pre2.tar.bz2 > > I ran into a problem compiling with kernel 2.6.31-rc8. It appears to be > caused by ir_receiver_id in lirc_i2c being used before it is defined. I > have attached a patch that fixes it for me. Bah. I made that same fix in my git tree and apparently forgot to add it to cvs. Just committed it, thanks much. -- Jarod Wilson ja...@wi... |
|
From: Paul B. <peb...@gm...> - 2009-08-30 15:36:27
|
Christoph Bartelmus wrote: > Hi, > > there's a new pre-release for 0.8.6 online: > > http://www.lirc.org/software/snapshots/lirc-0.8.6pre2.tar.bz2 I ran into a problem compiling with kernel 2.6.31-rc8. It appears to be caused by ir_receiver_id in lirc_i2c being used before it is defined. I have attached a patch that fixes it for me. |
|
From: Martyn W. <ma...@we...> - 2009-08-30 10:50:37
|
Christoph Bartelmus wrote: > Hi! > > Martyn Welch "ma...@we..." wrote: > [...] > >> A while back I integrated a simple "homebrew" IR receiver and >> transmitter on a MythTV box that both my partner and I have become >> rather attached to. One thing I have noticed is that, I assume due to >> the method used to control the timing for the pulses, video playback >> stutters a little when the remote is used. I doesn't happen when I use a >> wireless keyboard... >> > > LIRC does not use many cycles when receiving. Only on transmit it will use > the CPU a lot. > If the video stutters during receive, your system is on its limits > already. > > [...] > Probably, it's a 1.2GHz Via C7 currently running Mythbuntu 8.10 as a back and front end. This is about as fast as I think I can currently get and stay passive cooled, though I may be able to push it a bit more if I was to get an Atom, I don't know. I'd rather just offload some of the more real-time tasks... >> This raises a few questions: >> >> 1) Am I re-implementing something that's already done and I've just missed? >> > > Probably. Just try not to reinvent a protocol on the serial port. > Try using something existing like e.g. UIRT or Irlink. > > The problem is I haven't been able to track down and documentation that explains the protocol used by the UIRT or it's source code. I didn't know about the Irlink, I have a poke. I guess I might be able to work out some of it from the LIRC end of things, however I'm really not found of writing something to match a partially reverse-engineered spec. >> 2) Is this a reasonable approach or can you suggest a better one? >> 3) Is 1us accuracy a requirement or is some of this accuracy thrown away >> during signal detection (i.e. could I get away with being less accurate?) >> > > 100us should be enough. Most commercial receivers use 50us. The Streamzap > receiver even works with 256us. > Ok, so I guess I'm in the right ball park already, that's good to know. Cheers, Martyn |
|
From: <li...@ba...> - 2009-08-30 08:00:55
|
Hi! Martyn Welch "ma...@we..." wrote: [...] > A while back I integrated a simple "homebrew" IR receiver and > transmitter on a MythTV box that both my partner and I have become > rather attached to. One thing I have noticed is that, I assume due to > the method used to control the timing for the pulses, video playback > stutters a little when the remote is used. I doesn't happen when I use a > wireless keyboard... LIRC does not use many cycles when receiving. Only on transmit it will use the CPU a lot. If the video stutters during receive, your system is on its limits already. [...] > This raises a few questions: > > 1) Am I re-implementing something that's already done and I've just missed? Probably. Just try not to reinvent a protocol on the serial port. Try using something existing like e.g. UIRT or Irlink. > 2) Is this a reasonable approach or can you suggest a better one? > 3) Is 1us accuracy a requirement or is some of this accuracy thrown away > during signal detection (i.e. could I get away with being less accurate?) 100us should be enough. Most commercial receivers use 50us. The Streamzap receiver even works with 256us. Christoph |
|
From: Martyn W. <ma...@we...> - 2009-08-29 21:33:32
|
Hi All, I have been using LIRC on and off for quite a few years now and I'd just like to say that's for such a useful tool. A while back I integrated a simple "homebrew" IR receiver and transmitter on a MythTV box that both my partner and I have become rather attached to. One thing I have noticed is that, I assume due to the method used to control the timing for the pulses, video playback stutters a little when the remote is used. I doesn't happen when I use a wireless keyboard... This got me to thinking about implementing a microcontroller based receiver/transmitter to resolve the issue. I know about the UIRT hex files and schematics that can be found on the internet, however I haven't had much luck creating a reliable conf file using the hex files I can find for the UIRT and I haven't been able to track down the code. I'm also aware that I can probably buy something to do exactly what I want, but wheres the challenge in that?! So I started to play. :-) I currently have a PIC based circuit, connected to a serial port and a IR receiver. Looking at the LIRC website I noticed the description of the "LIRC_MODE_MODE2" protocol which I believe is used by lirc_serial. After a few hours playing around I have so far managed to get some verbose serial output which currently tracks the state of the IR signal to 0.1ms. I realize this as accurate as the 1us provided by dev_serial, but I think I might be able to get there with a bit more hacking. My aim currently is to be able to provide serial output as provided by the above mentioned mode and use a modified/simplified version of whatever uses the dev_serial kernel module. This will offload the tight timing requirements to the PIC, which I hope will stop the stuttering. This raises a few questions: 1) Am I re-implementing something that's already done and I've just missed? 2) Is this a reasonable approach or can you suggest a better one? 3) Is 1us accuracy a requirement or is some of this accuracy thrown away during signal detection (i.e. could I get away with being less accurate?) If I can get something working I'm planning to upload schematics, code, hex files and a description to either my website and/or I'd be happy for it to be added to the LIRC website/project. The PIC code is being written in C at this stage and compiled using SDCC. Yes, the code will be GPLed. I'd happily place the schematics and hex files under a suitable open source license as well. Martyn |
|
From: Jarod W. <ja...@wi...> - 2009-08-29 19:55:43
|
On Saturday 29 August 2009 15:20:54 Calhoun, Sean P. wrote: > > On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <ja...@wi...> wrote: > > > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > >> > >> Jarod Wilson wrote: > >>> Well, the first thing I was planning to do was try transmitting > >>> under > >>> Windows while snooping the traffic to see what packets were sent, > >>> then > >>> work from there... I got as far as plugging the thing into my laptop > >>> briefly while booted in Windows, saw that it loaded drivers, and > >>> that > >>> was as far as I got. If you've got snoops, feel free to hit me with > >>> them, and I can try to make heads or tails of them. > >>> > >> How about I do the grunt work and give you a patch instead? > > > > That's always VERY much appreciated. :D > > > > I'd suspected it might end up being a fairly trivial patch, but not > > *that* trivial. I was thinking we might have to deal with split > > outbound buffers similar to the contortions that have to be done for > > receiving, glad to see that's not the case, just some initialization > > differences. Good work! I'll give it a quick test here w/my own gen1 > > transceiver, and will then go ahead and merge it. For good measure, > > Can you add a developer's certificate of origin (Signed-off-by:) line > > for me? Just replying to this email w/it is sufficient. > > Sure: Regarding the patch I sent last night... > Signed-off-by: Patrick Calhoun <ph...@ou...> 2009-08-29 > > I will say that transmitter 2 works as expected, but transmitter 1 > only seems to fire for me when both transmitters are selected, not solo. Okay, so I get slightly better results using output #2, but something still isn't quite right. I'm looping the transmitter back to the device itself, and at least with #2, the receiver lights up on every transmit attempt, so its always seeing *something*, but irw only registers a correct key every once in a while. So we're inching closer, but still not quite there yet... I haven't yet looked at debug spew to try to make heads or tails of what's going on. -- Jarod Wilson ja...@wi... |
|
From: Calhoun, S. P. <ph...@ou...> - 2009-08-29 19:21:14
|
On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <ja...@wi...> wrote: > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: >> >> Jarod Wilson wrote: >>> Well, the first thing I was planning to do was try transmitting >>> under >>> Windows while snooping the traffic to see what packets were sent, >>> then >>> work from there... I got as far as plugging the thing into my laptop >>> briefly while booted in Windows, saw that it loaded drivers, and >>> that >>> was as far as I got. If you've got snoops, feel free to hit me with >>> them, and I can try to make heads or tails of them. >>> >> How about I do the grunt work and give you a patch instead? > > That's always VERY much appreciated. :D > > I'd suspected it might end up being a fairly trivial patch, but not > *that* trivial. I was thinking we might have to deal with split > outbound buffers similar to the contortions that have to be done for > receiving, glad to see that's not the case, just some initialization > differences. Good work! I'll give it a quick test here w/my own gen1 > transceiver, and will then go ahead and merge it. For good measure, > Can you add a developer's certificate of origin (Signed-off-by:) line > for me? Just replying to this email w/it is sufficient. Sure: Regarding the patch I sent last night... Signed-off-by: Patrick Calhoun <ph...@ou...> 2009-08-29 I will say that transmitter 2 works as expected, but transmitter 1 only seems to fire for me when both transmitters are selected, not solo. -Patrick > > -- > Jarod Wilson > ja...@wi... |
|
From: Jarod W. <ja...@wi...> - 2009-08-29 19:16:46
|
On Friday 28 August 2009 23:17:23 Jarod Wilson wrote: > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > > > > Jarod Wilson wrote: > > > Well, the first thing I was planning to do was try transmitting under > > > Windows while snooping the traffic to see what packets were sent, then > > > work from there... I got as far as plugging the thing into my laptop > > > briefly while booted in Windows, saw that it loaded drivers, and that > > > was as far as I got. If you've got snoops, feel free to hit me with > > > them, and I can try to make heads or tails of them. > > > > > How about I do the grunt work and give you a patch instead? > > That's always VERY much appreciated. :D > > I'd suspected it might end up being a fairly trivial patch, but not > *that* trivial. I was thinking we might have to deal with split > outbound buffers similar to the contortions that have to be done for > receiving, glad to see that's not the case, just some initialization > differences. Good work! I'll give it a quick test here w/my own gen1 > transceiver, and will then go ahead and merge it. For good measure, > Can you add a developer's certificate of origin (Signed-off-by:) line > for me? Just replying to this email w/it is sufficient. Hrm. I still don't seem to be getting anything transmitted by my own 1st-gen transceiver. It *could* be that the transmitter cable/led I hooked up to it isn't compatible, but its from a 2nd-gen transceiver, and works fine there (I don't have the original transmitter parts around here anywhere). Does looping back to your 1st-gen transceiver result in irw picking up the transmitted key codes? -- Jarod Wilson ja...@wi... |
|
From: <li...@ba...> - 2009-08-29 15:45:19
|
Hi, there's a new pre-release for 0.8.6 online: http://www.lirc.org/software/snapshots/lirc-0.8.6pre2.tar.bz2 This is a release candidate. 0.8.6 should be released soon. Please test. Changes since last release: 0.8.6pre2: 08/29/09 * added support for ENE KB3926 revision B/C/D (ENE0100) CIR port (found on some notebooks, e.g: Acer Aspire 5720G, HP Pavilion dv5) (Maxim Levitsky) * merged 1st-gen mceusb device support into lirc_mceusb2, renamed lirc_mceusb2 to lirc_mceusb * added support for putting iMON receviers into MCE/RC6 mode * added input subsystem mouse device support to iMON driver * improved iMON driver to handle dual-interface iMON devices via a single lirc device, reducing configuration complexity * added support for more iMON devices, including proper support for touchscreen iMON devices (Rene Harder) * improved iMON driver including touchscreen support * Linux input support added to lircmd * added support for IT8720 CIR port * moved default lircd, lircmd and lircrcd config file locations to /etc/lirc/lircd.conf, /etc/lirc/lircmd.conf and /etc/lirc/lircrc * moved lircd socket from /dev/lircd to /var/run/lirc/lircd * moved default pid file location from /var/run/lircd.pid to /var/run/lirc/lircd.pid * added support for XMP protocol Christoph |
|
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: Jarod W. <ja...@wi...> - 2009-08-29 04:11:33
|
On Thursday 27 August 2009 11:09:18 Ken Kolbly wrote: > Jarod, > I apologize for not updating you immediately when I got the new > information. > > My friend has an almost identical hardware setup (Same > motherboard, CPU and RAM, bought at the same time as mine. Same iMon > receiver.) and he had the same problem with the IR receiver. It was not a > big issue to him, because he was willing to use the keyboard to control his > box. However, for other reasons, earlier this week he "nuked-and-repaved" > his system, installing CentOS. The iMon was still getting claimed and he > did some research, discovering that the kernel "quirks" is apparently > broken in that version. CentOS 4 or 5? Pretty sure quirking works just fine in 5, and if it doesn't, then its a regression that ought to be fixed by Red Hat... > HOWEVER > > He also discovered that on my system, there were 2 digits switched on my > "quirks" command. "152c" vs. "15c2" > > I'm very annoyed with myself because I **SPECIFICALLY** checked for that > and STILL missed it! D'oh! > (I guess that proves that I am truly dyslexic!) > > Night before last, I corrected the error and lo and behold, usbhid no > longer claims my IR receiver! I feel much better now! Good deal. Maybe it was just 2.6.28 and 2.6.29 that were broken then. > That is as far as I got. Now I need to continue down-stream and get the > rest of Lirc working. In theory, that part should be easy... Though I still need to put a patch for the F10 2.6.27 kernel together, updating its lirc drivers to something that works with lirc 0.8.5+... :\ > I will keep you posted. Thank you for your support and guidance so > far. I'm sure I'll need more later! We'll be here... -- Jarod Wilson ja...@wi... |
|
From: Jarod W. <ja...@wi...> - 2009-08-29 04:07:51
|
On Tuesday 25 August 2009 18:40:45 Radu C wrote: > I noticed a very peculiar behaviour for lirc_mceusb2 on my systems. If I use > MCE IR receivers that a driven by lirc_mceusb2, if the dongle is in use (by > lircd or mode2 for example) and un pull it out of the USB port, the kernel > dies a painful death. And it seems to take your XFS data with it (ext3 is > more resilient). > > The process goes like this: > 0. Switch to a console (don't do this in X, for better effects) > 1. Plug in a lirc_mceusb2 receiver > 2. Start mode2 on the lirc device, and leave it running > 3. (Not necessary) press some keys on your remote to see that it works > 4. Pull the receiver out of the USB port > 5. Watch the kernel perform seppuku. > > On one of my laptops, the USB ports get so messed up that after reboot the > BIOS can't talk to them. It requires a second reboot to come to its senses. > > Repeatability: always > Operating system: Ubuntu 7.10, Ubuntu 9.04 (both of them) > Architecture: i386 (these CPUs to be exact: Pentium M, Core 2 Duo, Athlon 64 > X2 - in 32bit mode) > > Any ideas why this happens? Yes. > And how to fix it? Yes. I've seen this with lirc_streamzap myself, and suspected it was likely to affect lirc_mceusb too. Looking into it and fixing it is on my TODO list, just a matter of carving out the time to do it. -- Jarod Wilson ja...@wi... |
|
From: Jarod W. <ja...@wi...> - 2009-08-29 03:17:46
|
On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > > Jarod Wilson wrote: > > Well, the first thing I was planning to do was try transmitting under > > Windows while snooping the traffic to see what packets were sent, then > > work from there... I got as far as plugging the thing into my laptop > > briefly while booted in Windows, saw that it loaded drivers, and that > > was as far as I got. If you've got snoops, feel free to hit me with > > them, and I can try to make heads or tails of them. > > > How about I do the grunt work and give you a patch instead? That's always VERY much appreciated. :D I'd suspected it might end up being a fairly trivial patch, but not *that* trivial. I was thinking we might have to deal with split outbound buffers similar to the contortions that have to be done for receiving, glad to see that's not the case, just some initialization differences. Good work! I'll give it a quick test here w/my own gen1 transceiver, and will then go ahead and merge it. For good measure, Can you add a developer's certificate of origin (Signed-off-by:) line for me? Just replying to this email w/it is sufficient. -- Jarod Wilson ja...@wi... |
|
From: Patrick C. <ph...@ou...> - 2009-08-28 23:58:58
|
Jarod Wilson wrote: >> (drivers/lirc_mceusb/lirc_mceusb.c cvs revision 1.44) seem to totally >> BREAK transmission: >> >> 1170 request_packet_async(ir, ep_out, init2, >> 1171 sizeof(init2), MCEUSB_OUTBOUND); >> > > Well, the first thing I was planning to do was try transmitting under > Windows while snooping the traffic to see what packets were sent, then > work from there... I got as far as plugging the thing into my laptop > briefly while booted in Windows, saw that it loaded drivers, and that > was as far as I got. If you've got snoops, feel free to hit me with > them, and I can try to make heads or tails of them. > How about I do the grunt work and give you a patch instead? -Patrick |
|
From: Patrick C. <ph...@ou...> - 2009-08-28 23:12:31
|
The "little LED" is a transmitter, sometimes called "blaster." In fact, yours should contain a red visible light LED in addition to an infrared emitter. You do not need to plug this in unless you want to send signals FROM your computer. -Patrick Josu Lazkano wrote: > Hello, i have buy a IR receiver, it works with mceusb2 driver, it has > repeat on "irw" but this is other problem. > > This is the receiver: http://i32.tinypic.com/oghrwg.jpg . It has 2 holes. > > And it has a little LED, this one: http://i25.tinypic.com/2w24dn9.jpg > > I have to plug the little LED? What is the function of this little LED? > > Thanks for all. > > -- > Josu Lazkano > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 |
|
From: Josu L. <jos...@gm...> - 2009-08-28 23:00:30
|
Hello everybody!
I have a MCE receiver: ID 0471:0815 Philips eHome Infrared Receiver
I installed the mceusb2 driver and it works, but I have repeated keys on
irw:
$ irw
000000000000043a 00 up /tmp/lircd.conf
000000000000043a 01 up /tmp/lircd.conf
000000000000043a 02 up /tmp/lircd.conf
0000000000000c3a 00 down /tmp/lircd.conf
0000000000000c3a 01 down /tmp/lircd.conf
0000000000000c3a 02 down /tmp/lircd.conf
00000000000008ba 00 enter /tmp/lircd.conf
00000000000008ba 01 enter /tmp/lircd.conf
00000000000008ba 02 enter /tmp/lircd.conf
This is my configuration:
$ cat /etc/lirc/lircd.conf
# Please make this file available to others
# by sending it to <li...@ba...>
#
# this config file was automatically generated
# using lirc-0.8.3(default) on Fri Aug 28 22:01:15 2009
#
# contributed by
#
# brand: /tmp/lircd.conf
# model no. of remote control:
# devices being controlled by this remote:
#
begin remote
name /tmp/lircd.conf
bits 12
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100
header 2422 556
one 1226 561
zero 632 561
gap 44683
min_repeat 3
toggle_bit_mask 0x0
begin codes
up 0x43A
down 0xC3A
left 0x47A
right 0x87A
enter 0x8BA
end codes
end remote
$ cat /etc/lirc/hardware.conf
# /etc/lirc/hardware.conf
#
# Arguments which will be used when launching lircd
LIRCD_ARGS=""
#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD=false
#Don't start irexec, even if a good config file seems to exist.
#START_IREXEC=false
#Try to load appropriate kernel modules
LOAD_MODULES=true
# Run "lircd --driver=help" for a list of supported drivers.
DRIVER=""
# If DEVICE is set to /dev/lirc and udev is in use /dev/lirc0 will be
# automatically used instead
DEVICE=""
MODULES="lirc_mceusb2"
# Default configuration files for your hardware if any
LIRCD_CONF=""
LIRCMD_CONF=""
I remember that I had same problem with a input driver receiver and I
changed the "toggle_bit_mask" on the lircd.conf to "0x16000000" and it
woked, but now I can get working. I am using a Sony RM-ED006 remote.
How can I solve it?
Thanks for all and best regards.
--
Josu Lazkano
|
|
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: Jeremy Y. <jy...@um...> - 2009-08-28 21:43:45
|
Ubuntu PPA updated: https://launchpad.net/~jyoder/+archive/ppa <https://launchpad.net/%7Ejyoder/+archive/ppa> This is against CVS as of 4:35pm EST today and should work fine with the lirc_ene0100 module. Please check! NOTE: You have to install "lirc-modules-source" AND "lirc" to get the updated drivers. Either reboot after or run "sudo /etc/init.d/lirc restart" Jeremy Jarod Wilson wrote the following on 8/28/2009 5:16 PM: > On Aug 27, 2009, at 11:25 AM, Maxim Levitsky wrote: > > >> Here I prepared a update of my driver in your tree. >> I have also accidentally compiled it in the kernel binary, and found >> out >> that driver doesn't work. >> >> It appears that lirc_dev checks in few places that module owner isn't >> NULL, but it can be NULL is driver is compiled in. >> >> I have removed all these checks, and now my drivers works fine, while >> both lirc_dev and lirc_ene0100 are compiled in. >> > > Committed and pushed, thanks much. > > |
1 message has been excluded from this view by a project administrator.
