Am 03.03.2016 um 21:56 schrieb Mauro Carvalho Chehab: > Em Thu, 03 Mar 2016 20:22:35 +0100 > Heiner Kallweit <hkallweit1@xxxxxxxxx> escreveu: > >> Am 03.03.2016 um 19:52 schrieb Mauro Carvalho Chehab: >>> Em Thu, 03 Mar 2016 19:18:17 +0100 >>> Heiner Kallweit <hkallweit1@xxxxxxxxx> 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 <hkallweit1@xxxxxxxxx> >>>>> 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 <hkallweit1@xxxxxxxxx> >>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxx> >>>>> >>>>> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
