On Fri, May 15, 2015 at 5:04 AM, Hans de Goede hdegoede@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=8b...
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.
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. Is there really no way for this to be backwards compatible? I'm not opposed to backporting this eventually, but I think there's some work to do on the xorg side as well?
josh
Hi,
On 15-05-15 14:56, Josh Boyer wrote:
On Fri, May 15, 2015 at 5:04 AM, Hans de Goede hdegoede@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=8b...
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
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@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=8b...
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
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@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=8b...
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
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@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=8b...
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?
Regards,
Hans
On Mon, May 18, 2015 at 8:28 AM, Hans de Goede hdegoede@redhat.com 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@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=8b...
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
Hi,
On 18-05-15 14:33, Josh Boyer wrote:
On Mon, May 18, 2015 at 8:28 AM, Hans de Goede hdegoede@redhat.com 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@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=8b...
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.
That is great, thanks!
Regards,
Hans
On Mon, May 18, 2015 at 8:50 AM, Hans de Goede hdegoede@redhat.com wrote:
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.
That is great, thanks!
I just pushed this to F22 git. It will be in the next F22 kernel build.
josh
Hi,
On 27-05-15 15:59, Josh Boyer wrote:
On Mon, May 18, 2015 at 8:50 AM, Hans de Goede hdegoede@redhat.com wrote:
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.
That is great, thanks!
I just pushed this to F22 git. It will be in the next F22 kernel build.
Great, thanks you for doing this.
Regards,
Hans
kernel@lists.fedoraproject.org
-
Hans de Goede -
Josh Boyer -
Peter Hutterer