Am 03.03.2016 um 21:56 schrieb Mauro Carvalho Chehab:
> Em Thu, 03 Mar 2016 20:22:35 +0100
> Heiner Kallweit <[email protected]> escreveu:
>
>> Am 03.03.2016 um 19:52 schrieb Mauro Carvalho Chehab:
>>> Em Thu, 03 Mar 2016 19:18:17 +0100
>>> Heiner Kallweit <[email protected]> escreveu:
>>>
>>>> Am 03.03.2016 um 12:28 schrieb Mauro Carvalho Chehab:
>>>>> This is an automatic generated email to let you know that the following
>>>>> patch were queued at the
>>>>> http://git.linuxtv.org/cgit.cgi/media_tree.git tree:
>>>>>
>>>>> Subject: [media] media: rc: nuvoton: support reading / writing wakeup
>>>>> sequence via sysfs
>>>>> Author: Heiner Kallweit <[email protected]>
>>>>> Date: Mon Feb 8 17:25:59 2016 -0200
>>>>>
>>>>> This patch adds a binary attribute /sys/class/rc/rc?/wakeup_data which
>>>>> allows to read / write the wakeup sequence.
>>>>>
>>>> When working on another module I was reminded not to forget updating
>>>> Documentation/ABI.
>>>> I think the same applies here. This patch introduces a new sysfs attribute
>>>> that should
>>>> be documented. I'll submit a patch for adding
>>>> Documentation/ABI/testing/sysfs-class-rc-nuvoton
>>>
>>> Good point.
>>>
>>> Another thing: wouldn't be better to use a text format? This would make
>>> esier to import from LIRC's irrecord format:
>>>
>>> begin raw_codes
>>>
>>> name power
>>> 850 900 1750 1800 850 900
>>> 850 900 1750 900 850 1800
>>> 850 900 850 900 850 900
>>> 1750 1800 800
>>>
>>> end raw_codes
>>>
>>> Regards,
>>> Mauro
>>>
>> Most likely this is possible, but it would mean that we need a parser /
>> generator
>> for this text format in the driver / kernel code. And I have my doubts that
>> parsing
>> an application-specific file format (that could change anytime) in kernel
>> code is
>> a good thing. Converting this format to raw binary data is better off in
>> userspace
>> I think. What's your opinion?
>
> I'm not telling that it should parse irrecord format, but, instead, to
> accept an ascii sequence of timings. The problem with raw binary data
> is that the format varies on big endian and long endian architectures,
> with doesn't seem to be nice to an API, as a data sequence recorded
> on one machine may not work on some other one.
>
The Nuvoton wakeup sequence is a number of bytes (bit 7 = pulse/space indicator,
bit 6..0 = length / 50us). It doesn't include any multi-byte numbers.
Therefore endianness doesn't affect us.
However I also like the idea of having a text format with pulses / spaces in us.
(as that's what utilities like mode2 display) It's easier for the user to deal
with.
I'll prepare an alternative patch using such a text format.
>>
>>>>
>>>> Rgds, Heiner
>>>>
>>>>> In combination with the core extension for exposing the most recent raw
>>>>> packet this allows to easily define and set a wakeup sequence.
>>>>>
>>>>> At least on my Zotac CI321 the BIOS resets the wakeup sequence at each
>>>>> boot
>>>>> to a factory default. Therefore I use a udev rule
>>>>> SUBSYSTEM=="rc", DRIVERS=="nuvoton-cir", ACTION=="add", RUN+="<script>"
>>>>> with the script basically doing
>>>>> cat <stored wakeup sequence> >/sys${DEVPATH}/wakeup_data
>>>>>
>>>>> Signed-off-by: Heiner Kallweit <[email protected]>
>>>>> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
>>>>>
>>>>> drivers/media/rc/nuvoton-cir.c | 85
>>>>> ++++++++++++++++++++++++++++++++++++++++++
>>>>> drivers/media/rc/nuvoton-cir.h | 3 ++
>>>>> 2 files changed, 88 insertions(+)
>>>>>
>>>>> ---
>>>>>
>>>>> [...]
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
