Backporting vmmouse kernel support to Fedora-22 kernel ?

[Hans de Goede]

Hi,

On 15-05-15 14:56, Josh Boyer wrote:
> On Fri, May 15, 2015 at 5:04 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi Josh,
>
> Throwing kernel@ on CC.
>
>> I'm mailing you because of:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1214474
>>
>> Rather then hacking around the problem discussed there
>> (and then at one point in time needing to remove the hack).
>>
>> I would rather see us go straight to the final solution and
>> backport the new vmmouse kernel driver (vs the old crufty lets
>> bitbang from userspace driver still used today) to the F-22
>> kernel, this would involve cherry-picking this single commit:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8b8be51b4fd365ac5983e117be9d28f427a07b68
>>
>> This is not something which we should do for F-22 GA, but
>> it would be good to do this for one of the first kernel
>> updates after GA IMHO.
>
> I saw this driver come in during the 4.1 merge window, but it's
> disabled even in rawhide at the moment.  The Kconfig help text clearly
> says we need the 13.0.1 version of the userspace driver, and rawhide
> is only at 13.0.99.  F22 is at 13.0.0.

Right, so rawhide has 13.0.99 since like 5 minutes ago since I'm working
on this atm. The F-22 build has also just finished. My plan was to
put that out as a (post GA) update and then it will be in place
when the kernel gets the vmmouse driver backported.

As for 13.0.1 vs 13.0.99 there never was a 13.0.1 release, and the
13.0.99 release has the code to detect the kernel driver and then
not load the userspace driver.

> Additionally, I'm not sure we want to add a full Requires: in
> kernel.spec for that version, because it will force the xorg driver to
> be installed on all systems when most won't need it.  We could add an
> Obsoletes if the userspace driver is truly no longer needed when the
> in-kernel driver is present, but I'd need to know if that was actually
> true.

The userspace driver is no longer needed when the kernel driver is
in place, but currently xorg-x11-drivers has a requires on the userspace
driver. So I think a "Conflicts: xorg-x11-drv-vmmouse < 3.0.99" in
the kernel is the best solution.

I'll also discuss doing an update of xorg-x11-drivers for rawhide to drop
a bunch of obsolete input drivers with Peter.

> Is there really no way for this to be backwards compatible?

Nope the userspace driver directly bangs the hardware, the only fix to
stop it from doing that is to make it aware of the kernel driver, which
requires updating the userspace driver.

> I'm not opposed to backporting this eventually, but I think there's
> some work to do on the xorg side as well?

See above, I think that if I push out xorg-x11-drv-vmmouse 3.0.99 as
a F-22 update, and you add a Conflicts for older versions to the kernel
spec that we are then good to go.

Regards,

Hans