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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
