
On Wed, Nov 07, 2012 at 05:18:27AM -0800, Marek Vasut wrote:
Dear Stephen Warren,
On 11/06/2012 03:56 PM, Marek Vasut wrote:
Dear Simon Glass,
Hi Marek,
On Tue, Nov 6, 2012 at 2:49 PM, Marek Vasut marex@denx.de wrote:
Dear Allen Martin,
Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P. Control characters are used instead of ANSI sequence because the queueing code in usb_kbd doesn't handle the data increase when one keypress generates 3 keycodes. The real fix is to convert this driver to use the input subsystem and queue
If it's the real fix, then why not go for the real fix right away? :-(
Because it's a fair chunk of work
Let's either do it properly or not at all ... if I let you do these semi- complete fixes, we'll end up with a stinking pile of crap like windows ...
Marek, I find this attitude a little ridiculous. If everything was fixed completely the first time around, there would be no work left to do; we'd just stop developing U-Boot. Equally, if this small addition to the USB keyboard code is so bad it can't be allowed since the whole driver must be re-written instead, why was the existing code allowed into U-Boot in the first place?
Because evil b*tch (=me) wasn't around in the first place ;-) Anyway ... I'll apply it (not because of your whining and stuff ... but because it's beneficial). Though, I'd be really glad if you invested time to rework the driver. Otherwise, it'll be me who'll end up doing the work and I'd prefer to delegate it to someone who brough the issue up sooner ;-)
Thanks Marek, I'd be happy to rework this driver if no one else wants to do it. I just can't sign up to do it right now as there are some tegra specific things (like USB gadget support, and enabling thumb) that are more important to me and my employer to do first, and I only work on u-boot on the side so I have limited bandwidth.
It sounds like we're all in violent agreement that moving the driver to the input subsystem is the right thing to do, and if someone is eager to work on it before I have a chance to I'm happy to review patches.
Incremental small patches are good; they allow small simple things to be implemented without causing massive disruption. That's great for locating any regressions.
Is there anything actually technically wrong with this specific patch? I would say no; it's very simple, non-invasive, low-risk, doesn't appear to introduce any long-term maintenance burden, doesn't completely prevent or remotely hinder reworking the USB keyboard support in the future, etc.
Best regards, Marek Vasut
-Allen