Re: [PATCH] media: Pinnacle 73e infrared control stopped working since kernel 3.17

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Tue, 24 Feb 2015 11:15:53 +0100
David Härdeman <david@xxxxxxxxxxx> escreveu:

> On 2015-02-24 11:08, David Cimbůrek wrote:
> >>> Hi,
> >>> 
> >>> I looked at this again and I still don't see why the order is 
> >>> important.
> >>> Plus the code looks like it does what it should be doing when using
> >>> RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and 
> >>> RC_SCANCODE_RC5.
> >>> 
> >>> Unfortunately I can't review this if I am not sure about it, and I 
> >>> don't
> >>> have the device to be able to properly test your patch.
> >>> 
> >>> Hopefully your print of the scancodes helps.
> >>> 
> >>> Luis
> >> 
> >> Hi,
> >> 
> >> unfortunately I don't understand the code very well but it really
> >> works like I described.
> >> 
> >> I tried to get debugging output from the
> >> dib0700_core.c:dib0700_rc_urb_completion() function:
> >> 
> >> deb_data("IR ID = %02X state = %02X System = %02X %02X Cmd = %02X %02X
> >> (len %d)\n",
> >>         poll_reply->report_id, poll_reply->data_state,
> >>         poll_reply->system, poll_reply->not_system,
> >>         poll_reply->data, poll_reply->not_data,
> >>         purb->actual_length);
> >> 
> >> And the output after my patch (and before commit
> >> af3a4a9bbeb00df3e42e77240b4cdac5479812f9!) looks like this:
> >> 
> >> [  282.842557] IR ID = 01 state = 01 System = 07 00 Cmd = 0F F0 (len 
> >> 6)
> >> [  282.955810] IR ID = 01 state = 02 System = 07 00 Cmd = 0F F0 (len 
> >> 6)
> >> 
> >> But without my patch the output looks after commit
> >> af3a4a9bbeb00df3e42e77240b4cdac5479812f9 like this:
> >> 
> >> [  186.302282] IR ID = 01 state = 01 System = 00 07 Cmd = 0F F0 (len 
> >> 6)
> >> [  186.415660] IR ID = 01 state = 02 System = 00 07 Cmd = 0F F0 (len 
> >> 6)
> >> 
> >> You can see that the content of "system" and "not_system" is really 
> >> switched...
> >> 
> >> Regards,
> >> David
> > 
> > Is there anything more I can do? Shall I provide some more debugging
> > outputs? There is no response nearly for two weeks...
> 
> Sorry, I'm just really busy.
> 
> The output that you gave (the actual scancodes that are generated) is 
> what I was looking for, not the keymap. If I remember correctly my patch 
> wasn't supposed to change the generated scancodes (or the keymap would 
> have to be changed as well).
> 
> The question is whether the right thing to do is to change back the 
> scancode calculation or to update the keymap. I'll try to have a closer 
> look as soon as possible (which might take a few days more, sorry).

I suspect we should change back the scancode calculation, as I think that
the scancode table is right, but I need to do some tests with some other
driver to be certain.

I have a few devices here that I can use for testing, including a PCTV
remote, just lacking the time.

> 
> Re,
> David
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux