[PATCH 0/4] Input: Add INPUT_PROP_TOPBUTTONPAD device property to Fedora kernels

[Josh Boyer]

On Sat, May 10, 2014 at 01:39:24PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 05/10/2014 01:26 PM, Josh Boyer wrote:
> > On Sat, May 10, 2014 at 09:59:29AM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream 
> >> xorg-x11-drv-synaptics is relying on it as the one and only way to identify
> >> clickpads with top buttons (as found on all new lenovo laptops).
> >>
> >> Currently in Fedora we have a set of udev rules, which need to be
> >> expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD.
> >>
> >> Now that yet another Lenovo model has surfaced with this type of touchpad:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1096436
> >>
> >> I would like to move Fedora to the solution upstream is using. The first step
> >> for this would be to add these 4 patches to the Fedora kernels. I've also
> >> send them to stable, and Dmitry Torokhov and Greg KH are both ok with them
> >> going into stable. But Greg has a bit of a backlog atm.
> > 
> > They're already in rawhide, so I'm guessing you mean F20.
> 
> Yes.
> 
> > 
> >> For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one
> >> more model, since otherwise things will break for people not using the very
> >> latest Fedora kernel. Once these changes have been in Fedora kernels for
> >> a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream,
> >> making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update
> >> it for each new laptop model with such a touchpad.
> > 
> > I have no problems with the patches themselves, and I like the overall
> > plan, but adding them as patches right now seems pointless.
> > 
> > 1) They're already in rawhide
> > 
> > 2) They'll be in 3.14.y in a matter of weeks, if not sooner, which means
> > they'll be in F20 and F19 within that timeframe.
> > 
> > 3) You already have to extend the udev rules anyway for the existing
> > bugs.
> > 
> > 4) Even if they are added, by the time a kernel that contains them is
> > built and in updates-stable the patches will likely already be in
> > upstream stable.  Fedora kernel builds for stable releases are essentially
> > tied to the upstream stable release cycle, barring any major bug or CVE
> > fix.  So if these land in 3.14.4 upstream, then that will already be as
> > "fast" as I would expect.  If they land in 3.14.5, it's an extra week.
> > 
> > Unless I'm missing something, it seems like extra busy work to add them
> > as patches right now.  Waiting for an upstream stable release should
> > accomplish everything you want without too much additional delay.  If
> > they don't hit upstream stable at all for some reason, then it might
> > make more sense to add them to 3.14.y in Fedora.
> 
> Ok, I'll just wait for them to go into Fedora through the stable series
> then.

Ok.  I'll keep an eye on upstream stable and if they don't land in the
next release or two we can revisit.  Thanks for the work on this and the
video issues.  Much appreciated.

josh