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(a)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...
>>>
>>> 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.