RE: [linux-usb-devel] Re: USB, HID, unexpected disappearances

[Dunlap, R. <ran...@in...>]

> >Linus isn't likely to move them without a patch file.
> 
> I have done that last Friday, didn't show up yet until test5-pre3. My 
> immediate reason is that I would like to use the input layer for the 
> CONFIG_ADB stuff, even if CONFIG_USB is not set and moving the input 
> drivers in their own dir seems to be the cleanest solution.

I'm using test5-pre3 and I don't see any such change.
Or you just mean that it's not there yet (?).


> > > >So linux-console discusses USB also?  Man, I have too much
> > > >email already.  :(
> > >
> > > Heh, then move the input drivers from drivers/usb to
> > > drivers/input where
> > > they belong. With a README file somewhere, the probability that
> > > bugs/problems will get reported to the right list should be
> > > somewhat higher
> >
> >Is Vojtech Pavlik working with linux-console on this?
> >(Yes, he's listed at http://linuxconsole.sourceforge.net/.)
> >
> >And does the input layer belong with linux-console?
> >That's not at all clear to me.
> 
> Well, all links I followed so far point to there in the end, 
> and the input layer CVS is hosted there too.

That's not a very convincing argument that input belongs
to linux-console IMO.  And there's nothing at
http://linuxconsole.sourceforge.net/ under Charter, Objectives,
Deliverables about a generic input layer.

I'm not fighting you for the input layer, but I would like
it to be clear where it belongs, even if that's by itself.
According to its web page, linux-console is about terminal
emulation (I would argue: no joysticks, tablets, etc. here),
multiple video cards, frame buffers, console scrolling, fonts,
keymaps (aha, input!, but only keyboard), text modes, and Unicode.

So is linux-console a client of the input layer or the provider
of the input layer?


> >However, I don't claim that it belongs inside drivers/usb
> >either (clearly they can work together, but a logical
> >input layer should be separate from the physical USB
> >drivers).
> 
> Agreed. And that setup is already realized in the input layer 
> CVS, so doing 
> the move now would greatly simplify further input driver 
> additions/merges during the 2.4 cycle.
> 
> Franz.

~Randy