On Fri, May 15, 2015 at 03:09:18PM +0200, 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. what actually happens if we run the new module but an old userspace driver? the kernel commit message is a bit ambiguous here, the new driver is recommended but it's not clear what the effects are otherwise. if it works anyway, side-stepping or disabling the new device node, then everything still works as is anyway. I'm not fully convinced yet that we need the conflicts line (though it would send a nice and clear message). removing it from xorg-x11-drivers once the kernel module is available is the right thing to do, so ACK to that. Cheers, Peter _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
