On 22.01.2014 21:10, Antti Seppälä wrote:
On 22 January 2014 18:29, Sean Young <sean@xxxxxxxx> wrote:
On Wed, Jan 22, 2014 at 05:46:28PM +0200, Antti Seppälä wrote:
On 21 January 2014 14:28, Sean Young <sean@xxxxxxxx> wrote:
On Mon, Jan 20, 2014 at 09:39:43PM +0200, Antti Seppälä wrote:
This patch series introduces a simple sysfs file interface for reading
and writing wakeup scancodes to rc drivers.
This is an improved version of my previous patch for nuvoton-cir which
did the same thing via module parameters. This is a more generic
approach allowing other drivers to utilize the interface as well.
I did not port winbond-cir to this method of wakeup scancode setting yet
because I don't have the hardware to test it and I wanted first to get
some comments about how the patch series looks. I did however write a
simple support to read and write scancodes to rc-loopback module.
Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?
This is needed for winbond-cir; I guess this should be another sysfs
file, something like "wakeup_protocol". Even if the nuvoton can only
handle one IR protocol, maybe it should be exported (readonly) via
sysfs?
I'm happy to help with a winbond-cir implementation; I have the hardware.
Sean
Nuvoton-cir doesn't care about the IR protocol because the hardware
compares raw IR pulse lengths and wakes the system if received pulse
is within certain tolerance of the one pre-programmed to the HW. This
approach is agnostic to the used IR protocol.
Your patch talks about scancodes which is something entirely different.
This should be renamed to something better.
I agree that for the nuvoton my choice of wording (scancode) was a
poor one. Perhaps wakeup_code would suit both drivers?
So with the nuvoton you program a set of pulses and spaces; with the
winbond you set the protocol and the scancode. I don't think there is
any shared code here. Maybe it's better to implement the wakeup
sysfs files in the drivers themselves rather than in rcdev, I guess that
depends on whether there are other devices that implement similar
functionality.
The code to be shared is the logic of creating, parsing and formatting
the sysfs file. In the end the drivers are only interested in getting
a bunch of values to write to the hardware.
I was thinking about adding another file (wakeup_protocol sounds good)
which would tell what semantics are used to interpret the contents of
wakeup_code file (rc6, rc5, nec or raw). Would this be a decent
solution?
The other alternative is to push the sysfs handling to individual
drivers. I'm ok with either way. Which one should I pursue?
RTL2832U supports also that function. Could you study it too at least
check that implementation will be suitable for it?
regards
Antti
--
http://palosaari.fi/
--
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
