From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-qk0-f174.google.com ([209.85.220.174]:33744 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755697AbbFQW7q convert rfc822-to-8bit (ORCPT ); Wed, 17 Jun 2015 18:59:46 -0400 Received: by qkhu186 with SMTP id u186so35002389qkh.0 for ; Wed, 17 Jun 2015 15:59:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <3b967113dc16d6edc8d8dd7df9be8b80@hardeman.nu> References: <20150519203851.GC18036@hardeman.nu> <20150520182901.GB13624@hardeman.nu> <20150520204557.GB15223@hardeman.nu> <32cae92aa099067315d1a13c7302957f@hardeman.nu> <20150521194034.GB19532@hardeman.nu> <5418c2397b8a8dab54bfbcfe9ed3df1d@hardeman.nu> <3b967113dc16d6edc8d8dd7df9be8b80@hardeman.nu> Date: Thu, 18 Jun 2015 01:59:45 +0300 Message-ID: Subject: Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback From: =?UTF-8?B?QW50dGkgU2VwcMOkbMOk?= To: =?UTF-8?Q?David_H=C3=A4rdeman?= , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, James Hogan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-media-owner@vger.kernel.org List-ID: On 14 June 2015 at 02:44, David Härdeman wrote: > One idea that I've had in the back of my head for a long time is to use the > "flags" member of "struct rc_keymap_entry" in the new EVIOC[GS]KEYCODE_V2 > ioctl variant (see http://www.spinics.net/lists/linux-media/msg88452.html). > > If a RC_POWERON flag was defined, it could be used for that purpose... > Ooh, that approach would indeed provide a cleaner api for setting the wakeup scancode. I like the idea though I haven't really had the chance to try it out. > ... >> >> I'm sorry that the encoding functionality clashes with your intentions >> of improving the rc-core. I guess Mauro likes encoders more than >> improving rc-core fundamentals :) >> Kidding aside the fact that this series got merged might suggest that >> you and Mauro don't necessarily share the same views about the future >> and possible api breaks of rc-core. > > > If you've followed the development of rc-core during the last few years it > should be pretty clear that Mauro has little to no long-term plan, > understanding of the current issues or willingness to fix them. I wouldn't > read too much into the fact that the code was merged. > >> Tell you what, I'll agree to reverting the series. In exchange I would >> hope that you and Mauro mutually agree and let me know on: >> - What are the issues that need to be fixed in the encoding series >> prefarably with how to fix them (e.g. module load order ambiquity, >> whether a new api is needed, or switching to a more limited >> functionality is desired like you suggested then so be it etc.) >> - When is a good chance to re-submit the series (e.g. after >> ioctl/scancode/whatever api break is done or some pending series is >> merged or some other core refactoring work is finished etc.) >> >> Deal? > > > Mauro....wake up? I hope you're not planning to push the current code > upstream??? > Yeah, I'm also inclined to target for a longer term solution with this so the current patches can be reverted. I think I now also have enough information to go and respin the patches to utilize the new EVIOCSKEYCODE_V2 if and when that gets included in the rc-core. -- Antti