[U-Boot] [PATCH] USB: add arrow key support to usb_kbd

[Marek Vasut]

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 at 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 ;-)

> 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