El 24 de abril de 2010 18:00, Lorenzo Ripani <sr.jackal@...> escribió:
> Hi Juan,
> I've just tried some things.
> Running mode2 would not affect the count of /proc/interrupts
> of lirc_wpc8769l and there's nothing else wich share the irq 4 . It always
> point to 0.
It seems the code isn't getting the interrupts :-(
> I give a look a the code in lirc_wpc8769l.c . The rc_wakeup_code and mask
> are different from what i found in my windows registry.
That shouldn't matter. I think it only refers to the key in the remote that
may be used to power the laptop up. In any case, IIRC, the values are
reversed or inverted somehow, and the remote supplied with your laptop might
be different from mine.
> I found a key in
> with this values:
> 02 18 80 ff 00 00 0c ff 04 0f 00 00 00 00
> Can be this the problem ?
Don't think so.
This happened with some other user too. It seems we aren't enabling the
hardware to generate its interrupts when data is received.
What follows is a piece of generic advice that could give us some clues, but
that didn't work in that previous case.
=============== begin of generic advice ==============
I've seen several cases where the DSDT ACPI table in the BIOS does
funny things depending on the "Windows Version" reported by the ACPI
Could you retry rebooting and passing the parameter
to the boot loader?
You could try with
In any case, if you want, you can dissasemble and send me your DSDT
table privately to see whether this might be a problem or not.
See the following link for instructions to DSDT disassembly:
I think iasl is available as a standard package for many distros, and
probably you won't need acpidump; just copying /proc/acpi/dsdt to
dsdt.aml in some temporary location could work.
=============== end of generic advice ==============
Other than that I have really no idea. We could compare windows drivers to
see mine and yours are the same, and then try to reverse engineer any
> Lorenzo Ripani
> 2010/4/22 Juan Jesús García de Soria Lucena <skandalfo@...>
> I got the code and checked there sources, and the debug option won't
>> activate any interesting message, I fear.
>> If you're compiling the driver from sources, you'd need to insert some
>> messages in the IRQ handling function, so that we can see whether we are
>> getting interrupts or not when receiving IR data.
>> Otherwise check in /proc/interrupts whether IRQ #4 is being shared with
>> any other device, and whether the interrupt count increases when you have
>> mode2 running and you use your remote on the receiver.
>> Best regards,
>> Juan Jesús.
>> El 22/04/2010 01:07, "Juan Jesús García de Soria Lucena" <
>> skandalfo@...> escribió:
>> Hi. I have no access to the code right now.
>> I think there was a debug module parameter that should enable more
>> detailed output. You could try that.
>> The messages about the IRQ being acquired and then released should match
>> the opening and closing of the device by the mode2 program. That seems to be
>> working, but the driver sends no output.
>> For now just check whether you get more information by activating the
>> debug parameter. I'll try to check the code and see whether it should be
>> logging interrupts too...
>> Best regards,
>> Juan Jesús.
>> El 13 de abril de 2010 13:02, Lorenzo Ripani <sr.jackal@...>
>> > Hi Juan,
>> > I've just tried this but still no signals. The receiver works because
>> i've succes...
> Lorenzo Ripani <sr.jackal@...>
Dream small if success is enough for you; dream big if you need to change