On Mon, May 18, 2015 at 8:28 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > > On 15-05-15 15:09, Hans de Goede wrote: >> >> Hi, >> >> On 15-05-15 14:56, Josh Boyer wrote: >>> >>> On Fri, May 15, 2015 at 5:04 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >>> 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. > > > Josh, how are we going to move forward with this? > > As said I believe that for F-22 we want to backport the vmmouse driver > post GA, and we can best solve the issue of the vmmouse kernel vs > userspace driver with a Conflicts on the older version of the userspace > driver, does that sound like a plan? I'm going to enable it in rawhide today with the Conflicts in place. Assuming people don't come to my door with pitchforks because their VMWare guests don't work, I'll look at getting it into the F22 kernel later this week. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
