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