Re: [RFC PATCH 0/4] rc: Adding support for sysfs wakeup scancodes

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

 



On 4 February 2014 19:54, Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> wrote:
> Em Thu, 23 Jan 2014 21:11:09 +0200
> Antti Seppälä <a.seppala@xxxxxxxxx> escreveu:
>
>> On 23 January 2014 00:01, Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> wrote:
>> > Not sure if you saw it, but there's already another patchset proposing
>> > that, that got submitted before this changeset:
>> >         https://patchwork.linuxtv.org/patch/21625/
>>
>> I actually didn't notice that until now. Seems quite a similar kind of
>> approach with even more advanced features than what I had in mind
>> (namely the scancode filtering and masking).
>>
>> However it looks like that patchset has the same drawback about not
>> knowing which protocol to use for the wakeup scancode as was pointed
>> from my patch.
>
> Well, the protocol is important only if there are two or more active
> RCs that produce the same IR code on different protocols.
>
> Also, from the sysfs description made by James, it seems clear to me
> that the protocol to be used is the current protocol.
>
> I think is an unlikely border case to have some hardware that supports
> more than one IR protocols enabled for the wakeup to work, so James
> patch looks ok on my eyes.
>
> Also, nothing prevents to add latter a wakeup_filter_protocol sysfs node
> to allow to filter the wakeup scancode to a protocol set different than
> the one(s) currently enabled.
>
>> I think I'll try to come up with a new patch addressing the comments
>> I've seen so far.
>
> I guess I'll merge James approach, as there are a pile of other patches
> depending on it. If we need latter to distinguish between current_protocol
> and the wakeup one, as I said, a latter patch can add a
> "wakeup_filter_protocol" sysfs node to specify it.
>
> Regards,
> Mauro

Hi Mauro.

How do you want to proceed with the nuvoton wakeup I initially set out to do?

To wake up with nuvoton-cir we need to program several raw ir
pulse/space lengths to the hardware and not a scancode. James's
approach doesn't support this.

To keep things simple maybe module parameters in my first patch
(http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg69782.html)
are then the best thing to do for nuvoton? Other drivers can probably
adapt to the suggested filter api.

-Antti
--
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