On Fri, Apr 8, 2011 at 12:21 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > The problem is that there isn't a "the keytable". There are many > many keytables. And a lot of different hardware. Testing all possible > combinations of hardware (both receiver side and remote side) is > next to impossible. We do what we can. Its unfortunate that your > hardware regressed in functionality. It happens, but it *can* be > fixed. The fix you provided just wasn't correct. The correct fix is > trivially updating drivers/media/rc/keymaps/<insert-your-keymap-here>. I think the fundamental failure here was avoidable. We introduced a new requirement that keytables included system codes, knowing full well that the vast majority of them did not meet the requirement. In fact, a quick scan through the first 20 or so keymaps show that even today only *HALF* of them are populated today. That means that half of the remote keymaps are also completely broken. This decision was doomed to fail. It basically said, "Yes, I know full well that I'm breaking most of the keymaps currently supported, but maybe some of those users will eventually report the issue and I'll make them provide an updated keymap which will eventually be merged upstream for others so that their remotes are no longer broken." We should have introduced a RC profile property indicating how many bits were "significant". Then for those remotes which didn't have the system code, we could have continued to match against only the key code. Then over time, as keymaps improved, those keymaps could be updated and the number of significant bits could be adjusted to indicate that the system code was present. This was a crappy call, and it was completely foreseeable. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
