Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 03, 2010 at 12:07:52PM -0700, Dmitry Torokhov wrote:
> On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> > On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > > Greg KH wrote:
> > > > 
> > > > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> > > > >> +Merge any device support needed from this driver into it
> > > > >> +Delete this driver
> > > > > 
> > > > > Huh?
> > > > > 
> > > > > Why not just add this driver to the kernel tree instead?  When the
> > > > > "promised" driver then eventually shows up (who is promising it?) then
> > > > > delete the thing.
> > > 
> > > The same reason as there were several wireless drivers in staging?
> > 
> > Ok, that's a good enough reason for me :)
> > 
> > > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > > > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > > > the other day, and OTOMH that was after discussions with Synaptics
> > > > where they said they were working on a "real" driver (a rather
> > > > complex RMI4 bus driver) and we believe they will fix that sooner
> > > > or later.
> > > > 
> > > > So, until sooner or later happens we thought we'd keep it in staging.
> > > > 
> > > > If you prefer both Alan and we can probably submit our patches for
> > > > inclusion in the proper place.
> > > > 
> > > > A side effect may be that the Synaptics RMI4 people may have trouble
> > > > to merge their driver into input/ since they may be requested to
> > > > refactor the existing drivers to use it rather than merging new stuff,
> > > > putting some burden on their shoulders.
> > > > 
> > > 
> > > No, they have not been requested to change any existing [in tree]
> > > drivers. They however been asked to convert to the driver core
> > > primitives instead of rolling their own infprastructure to implement
> > > devices and drivers binding.
> > 
> > If you don't object to this driver going in, and there is a path forward
> > in the future for it to be able to be removed, then I will be glad to
> > add it.
> > 
> > Can I add your Acked-by: to the patch for this?
> > 
> 
> Umm... I haven't looked in detail, but I think it is sane enough for
> staging... Much better than Alan's version that seemed to create a
> separate input device for every finger. Needs to depend on INPUT and
> probably regulators framework...  Probe function may call
> input_free_device() after calling input_register_device() which is not
> good.

Great, thanks for this.

> Basically staging is yours, you can add whatever you want to it ;)

Heh, well, I try to at least cooperate with the different subsystem
maintainers.  I don't need even more people pissed-off at me than I
normally get :)

I'll queue this up for .38.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux