On 09.10.2017 10:44, Sean Young wrote: > 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 > > > Queued to drm-misc-next. Thanks Andrzej
