[PATCH v4] drm/bridge/sii8620: add remote control support

[Sean Young]

Hi,

On Thu, Sep 21, 2017 at 12:46:04PM +0100, Sean Young wrote:
> On Mon, Sep 18, 2017 at 04:37:52PM +0200, Hans Verkuil wrote:
> > On 09/18/2017 04:15 PM, Maciej Purski wrote:
> > > Hi Hans,
> > > some time ago in reply to your email I described what messages does
> > > the MHL driver receive and at what time intervals.
> > > Regarding that information, do you think that a similar solution as
> > > in [1] is required? Would it be OK, if I just set REP_DELAY and REP_PERIOD
> > > to values, which I presented in my last email?
> > 
> > Based on the timings you measured I would say that there is a 99% chance that MHL
> > uses exactly the same "Press and Hold" mechanism as CEC. Since you already specify
> > RC_PROTO_BIT_CEC in the driver, it will set REP_DELAY and REP_PERIOD to the right
> > values automatically.
> > 
> > You will have to implement the same code as in cec-adap.c for the key press handling,
> > though. It's a bit tricky to get it right.
> > 
> > Since you will have to do the same thing as I do in CEC, I wonder if it would make
> > more sense to move this code to the RC core. Basically it ensures that repeat mode
> > doesn't turn on until you get two identical key presses 550ms or less apart. This
> > is independent of REP_DELAY which can be changed by userspace.
> > 
> > Sean, what do you think?
> 
> Yes, this makes sense. In fact, since IR protocols have different repeat
> times, I would like to make this protocol dependant anyway.
> 
> To be honest I find REP_DELAY of 500ms too long and REP_PERIOD of 125ms
> too short; IOW it takes too long for a key to start repeating, and once
> it starts repeating it is very hard to control. If I try to increase the
> volume with my remote it first hardly changes at all and then after 500ms
> the volume shoots up far too quickly, same thing when navigating menus.
> 
> CEC dictates a delay period of 550ms, which is not great for the user IMO.
> 
> Anyway I'll have a look at this over the weekend.

I have started on this, but I haven't gotten it in a state where I'm
happy to submit it. I hope to have it ready for v4.15; in the mean time,
there is no reason to block this patch on this.


Sean