Hi Sean,
On Mon, Sep 13, 2021 at 08:26:49AM +0100, Sean Young wrote:
> On Sun, Sep 12, 2021 at 10:15:31PM +0000, Joaquín Alberto Calderón Pozo wrote:
> > Mantainers of the ir-kbd-i2c, althought I sent it to the debian bug report team, I consider to sent you also this patch (if it's the right way) to solve this bug.
> >
> > Thanks
> >
> > Package: src:linux
> > X-Debbugs-Cc: kini_calderon@xxxxxxxxxxx
> > Version: 5.10.46-4
> > Severity: important
> > Tags: patch
> >
> > Although I have a very old pci (not express) Hauppauge WinTV-HVR1110 DVB-T/Hybrid TV card with a remote control, I am still using it because has fully support and functionallity and it's hardware capable of play DVB-T HD streams.
> >
> > It has a very strange behaviour:
> >
> > -One is it has a slow response when I push a key, has a delay, and sometimes even no key response, nothing happens, as if never push a key.
> > -Other is when you hold a key, it start to begin the repeat key (characters like numerical) appears in the test app (kwrite) then, has a pause, stops to write characters, and begin the sequence again, writes some sequence, then stops... and so on. Even I noticed the repeat speed is a bit slow, compared to a keyboard key hold on.
> >
> > So... I began to investigates the causes and after two weeks of research, searchs on the web, I found the module affected and a solution.
> >
> > The module affected is ir-kbd-i2c.ko, this remote (rc5 protocol) uses this module as uinput (devinput) device, in resume as like an attatched keyboard. Resulting investigation in get noticed that this remote with rc5 protocol has 8hz of time frame when receiving the air gap code (rc5 procotol timing).
> >
> > Investigating the sources files in the kernel sources for try and fall, re-compiling the modules, get me to get noticed that the polling ir remote interval is 100ms which is 5hz, forcing this value to 125ms, re-compiling the module causes the remote to work normally as expecte, the response is like a real keyboard and the repeat sequence not only as speedy as a normal keyboard, but also hasn't got a pause in repetition. In resume, the problem is solved.
> >
> > Here is the patch:
> >
> > --- ir-kbd-i2c.original.c 2021-09-08 23:45:23.723210301 +0200
> > +++ ir-kbd-i2c.hauppauge.patched.c 2021-09-10 03:55:28.003529072 +0200
> > @@ -742,7 +742,7 @@
> > return -ENOMEM;
> >
> > ir->c = client;
> > - ir->polling_interval = DEFAULT_POLLING_INTERVAL;
> > + ir->polling_interval = 125;
> > i2c_set_clientdata(client, ir);
> >
> > switch(addr) {
> >
> > I am a experienced user, but not an experienced developer, also in editing/submitting bugs, I don't know if this is the right way to solve this, If the rest of brand remotes are affected for my solution, but for me, solved my problem in this particular case.
> >
> > I don't know where the value DEFAULT_POLLING_INTERVAL is get stablished or a way when detect a Hauppauge WinTV-HVR1110 DVB-T/Hybrid TV card to stablish 125ms instead of 100ms. As I said, I'm not an expert but experienced user.
>
> This change looks right to me, but it needs some changes:
>
> - The change needs to be made Hauppauge/Zilog specific by adding a line
> under the "case 0x71:" line below which sets the polling interval to 125.
> - The patch should be against current media kernel, not 5.10
> - Follow https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> - Add "Cc: stable@xxxxxxxxxxxxxxx" and the patch will trickle down into
> 5.10.
>
> Thanks
>
> Sean
>
> >
> > I don't know if this is the right package to post this bug. Thanks.
> >
>
> > --- ir-kbd-i2c.original.c 2021-09-08 23:45:23.723210301 +0200
> > +++ ir-kbd-i2c.hauppauge.patched.c 2021-09-10 03:55:28.003529072 +0200
> > @@ -742,7 +742,7 @@
> > return -ENOMEM;
> >
> > ir->c = client;
> > - ir->polling_interval = DEFAULT_POLLING_INTERVAL;
> > + ir->polling_interval = 125;
> > i2c_set_clientdata(client, ir);
> >
> > switch(addr) {
My understanding is that Joaquín would need some help to get the patch
submission as he is unexperienced to make it a proper patch for
inclusion in mainline, would you have enough time to bring this into
shape for him? I'm not familiar in this area to propose a proper
commit message myself. Joaquín confirmed though in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994050#32 that the
proposed changes seems to solve his issue.
Regards,
Salvatore
