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 <ma...@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? 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot