From: Paul B. <peb...@gm...> - 2011-07-26 21:03:33
|
Obviously, the with the kernel already having ati_remote and ati_remote2 drivers along with the recent availability of the lirc_xbox driver, maintaining the lirc_atiusb driver as well becomes a duplication of effort. However, as I attempt to switch MiniMyth from using lirc_atiusb to using ati_remote, ati_remote2 and lirc_xbox, I have found that ati_remote has at least two bugs, has no listed maintainer in the MAINTAINER file and has not had any commits for over a year. The first bug (for which I have created a patch) is that it is incorrectly connected in the sysfs hierarchy (it makes the USB device no the the USB interface its parent). As a result, it is difficult (maybe impossible) to integrate it into udev. The second bug (for which I have not created a patch) is that it does not correctly generate key repeats. Instead of sending the code 2 (key repeat) for each repeat, it sends a code 1 (key down) followed by a code 0 (key up). As a result, it makes it impossible for userspace software to distinguish between a key repeat (holding down the key) and repeated key presses (repeatedly pressing and releasing the key) and difficult to integrate it into software that expects to see code 2 for repeats. Because of its repeat_delay and repeat_filter module parameters as well as its compiled in per-key kind=KIND_FILTERED flag, I believe that the ati_remote driver intended to identify and filter repeats. As there is no maintainer for the ati_remote driver and because these this driver is not part of v4l as are many other remotes, I am not sure who should receive these reports. Based on code inspection, I believe that ati_remote2 suffers from at first bug but not the second bug. However, as I do not have a device that uses the ati_remote2 driver, I cannot be sure. Before sending it to lkml, I was hoping to find out whether or not there was a more focused mailing list where I could send the patch for the first bug. Before creating a patch to fix the second bug in ati_remote and sending it to lkml, I was hoping to communicate with the person maintaining ati_remote so that I could find out whether my understanding is correct. Any help would be appreciated. |
From: Jarod W. <ja...@wi...> - 2011-08-03 15:32:32
|
On Jul 26, 2011, at 5:03 PM, Paul Bender wrote: > Obviously, the with the kernel already having ati_remote and ati_remote2 > drivers along with the recent availability of the lirc_xbox driver, > maintaining the lirc_atiusb driver as well becomes a duplication of effort. > > However, as I attempt to switch MiniMyth from using lirc_atiusb to using > ati_remote, ati_remote2 and lirc_xbox, I have found that ati_remote has > at least two bugs, has no listed maintainer in the MAINTAINER file and > has not had any commits for over a year. I'd go with "most recent patch authors" in git history as people to bug about any changes. And/or subsystem mailing lists. > The first bug (for which I have created a patch) is that it is > incorrectly connected in the sysfs hierarchy (it makes the USB device no > the the USB interface its parent). As a result, it is difficult (maybe > impossible) to integrate it into udev. > > The second bug (for which I have not created a patch) is that it does > not correctly generate key repeats. Instead of sending the code 2 (key > repeat) for each repeat, it sends a code 1 (key down) followed by a code > 0 (key up). As a result, it makes it impossible for userspace software > to distinguish between a key repeat (holding down the key) and repeated > key presses (repeatedly pressing and releasing the key) and difficult to > integrate it into software that expects to see code 2 for repeats. > Because of its repeat_delay and repeat_filter module parameters as well > as its compiled in per-key kind=KIND_FILTERED flag, I believe that the > ati_remote driver intended to identify and filter repeats. > > As there is no maintainer for the ati_remote driver and because these > this driver is not part of v4l as are many other remotes, I am not sure > who should receive these reports. linux-input and linux-media mailing lists hosted at vger.kernel.org are the most appropriate. Long-term, both ati drivers should be ported to rc-core, and in fact, there's someone who claims to have already done that for one of the two... -- Jarod Wilson ja...@wi... |
From: Steffen B. <ste...@go...> - 2011-08-04 08:30:09
|
2011/7/26 Paul Bender <peb...@gm...>: > Obviously, the with the kernel already having ati_remote and ati_remote2 > drivers along with the recent availability of the lirc_xbox driver, > maintaining the lirc_atiusb driver as well becomes a duplication of effort. > > However, as I attempt to switch MiniMyth from using lirc_atiusb to using > ati_remote, ati_remote2 and lirc_xbox, I have found that ati_remote has > at least two bugs, has no listed maintainer in the MAINTAINER file and > has not had any commits for over a year. > > The first bug (for which I have created a patch) is that it is > incorrectly connected in the sysfs hierarchy (it makes the USB device no > the the USB interface its parent). As a result, it is difficult (maybe > impossible) to integrate it into udev. As we started to use eventlircd in our coming release of yavdr - we faced similar tasks. https://github.com/yavdr/yavdr-remote/blob/master/udev/98-eventlircd-names.rules Granted, we have been going a more pragmatic way. > As there is no maintainer for the ati_remote driver and because these > this driver is not part of v4l as are many other remotes, I am not sure > who should receive these reports. linux-input , linux-media > Based on code inspection, I believe that ati_remote2 suffers from at > first bug but not the second bug. However, as I do not have a device > that uses the ati_remote2 driver, I cannot be sure. > > Before sending it to lkml, I was hoping to find out whether or not there > was a more focused mailing list where I could send the patch for the > first bug. linux-input , linux-media Currently focussed on the first. There is one pending patch to better support one remote (add mapping for another remote), and another patch improving "change key" remotes. ati-remote is rather unmaintained up to now as lirc_atiusb has been used by everyone. > Before creating a patch to fix the second bug in ati_remote and sending > it to lkml, I was hoping to communicate with the person maintaining > ati_remote so that I could find out whether my understanding is correct. Based on the response on the mentioned patches, nobody is maintainer - everyone hopes its to become rc-core driver soon. There has been rumors that Anssi Hannula started to port it - but i never seen confirmation of that. PS: Thanks for eventlircd - it enables a nice out of the box experience for some remotes already, hopefully more in the future. You can check above github project for our current status (if this is interesting for you) :) |