Hi,
On 18-05-15 03:25, Peter Hutterer wrote:
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?
We end up with 2 drivers poking at the same io-registers, so no good will
come of this.
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.
Regards,
Hans
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
