Re: lirc_serial bugfix

[<li...@ba...>]

Hi!

Andrei Tanas "an...@un..." wrote:

>>> Christoph, I don't think the approach you've chosen for part 2 will
>>> work. Scenario: the last interrupt received before standby is pulse (I
>>> am not even sure if this makes any difference, it can probably be space
>>> just as well),
>>
>> It does not make any difference because pulse/space detection only
>> relies on the current state of DCD, not the previous state.
>>
> Line 808: dcd=(status & hardware[type].signal_pin) ? 1:0;
> It does rely on the previous state

I don't get your point. status is the current MSR register value, so dcd  
is the current pin state.

>>> then, after resume (which is very possible, even if the
>>> box is being woken up by IR, by the time kernel is initialized and we
>>> could process our interrupt, any IR activity will be gone), lasttv is
>>> reset with gettimeofday, however, if no interrupt is received in the
>>> next 15 seconds, the sense flag will still be flipped.
>>
>> If there is no activity the next 15 seconds, then the next signal
>> received definitely is a space and must be recognized that way.
>>
> Then the next signal definitely is a _pulse_ of course, right? How can
> you get a space when there was no activity?

Ok, the sentence above is mistakable.
Let's put it like this. What we see is the beginning of a pulse. That  
means that the time since lasttv was a space. The data that we push to  
upper layers at this point of time is a space.

>>> Why do you insist on keeping that code, I just don't see under what
>>> conditions it could be useful to "change our mind" on what type of
>>> receiver is being used, especially if it was passed as module parameter.
>>
>> If this condition still occurs, then it shows that there still is a bug
>> somewhere else or we do not understand what is really going on.

> What about the simple case when this is configured as module parameter?
> Why do we switch it in that case?

This code is a sanity check. In an ideal world it would never be  
executed. If you remove it, it would break things for people who use the  
wrong sense parameter without even knowing and for people who use  
autodetection which did not work correctly.

Even with your improved autodetection code it is perfectly possible to  
autodetect the wrong sense value.

[...]
> I've tested it, it fixed a real problem

I agree. That's why I proposed a fix for your problem.
Did it solve the problem or not?

> This autodetection code does not work properly in any case:

It's there since lirc-0.5.4 released in '99. If there were a fundamental  
problem with this code, it really should have appeared before.

Christoph