Librem 13 psmouse patch for 3.1?

[Kyle Rankin]

Hi,

I am a recent Qubes convert and run it on a Librem 13 laptop. This laptop
is certified for Qubes and for the most part Qubes runs great on it. The
main missing piece at the moment is support for the multi-touch BYD
psmouse. The default psmouse kernel driver works, however you don't get
multi-touch (two-finger scrolling, palm detection, etc.).

The Purism team has created a custom patched kernel for Debian stretch that
works with the psmouse and I've taken their work and turned it into a more
generic DKMS package [1]. While this DKMS patch was tested against Debian
Stretch, someone on the list who already has experience with building the
Qubes kernel shouldn't have much trouble applying this patch.

I know 3.1 is about to hit a feature freeze, but I was hoping there may be
a chance that since this patch is relatively simple that someone could
review and apply it. I've attempted to do this based on some of the Qubes
kernel documentation but so far I haven't been successful in getting a
proper build environment set up. I was hoping someone with a bit more
experience building the Qubes kernel could help out and get this either in
time for 3.1, or as an addition to an "unstable" kernel.

Thanks,

Kyle Rankin

[1] https://github.com/kylerankin/psmouse-byd-dkms

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

For 3.1 it is too late to add any feature into existing package,
unfortunately. But if that DKMS module would work as "external" module,
a separate package, we can include it repository (but not installed by
default...). Actually I had this approach on my todo list, thanks for
doing that work! :)

A couple of questions about the status of the patches:
1. Do you know if it is complete, or still some in-development?
2. Is it going to be included in upstream kernel? Are the patches
already sent?

> [1] https://github.com/kylerankin/psmouse-byd-dkms

I'll check that. From what I see, there may be some problems in building
it as an external module, for example Makefile expects
CONFIG_MOUSE_PS2_BYD to be set. But hopefully those are minor problems.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWlbAyAAoJENuP0xzK19csvgkH/iFbpoKrJ+noSei6Hf6rqPtl
KigDLAOsAsQm7Ml5Rkc70WHUoogIAcUZwJ+bBWPoePnfrzapRcjxruQT3ob/xOsY
LXaQPZBl+XnxuVPlDxRhLS3c500KpPXd/dtUQyIyhTfXpabnRn3thzehhUAahJBo
onlZCZTTPxu92NpywqJQmKnHMqzUXVh5USryeZhJX6aPe+lwnMH8rD/XzmQx4zSW
51qFspAYgee4ALc1XPUlkZQ5lTOhOW6hiZFIqvrQ+eeKkI7JeRCaEfKJqTNr+vnR
1PPmmo5QUQJKcGOsPQjO/2IA3EcCO3pU1edMYmcDQOjsDiOC1v4ac2dhkaOr7hU=
=AVO5
-----END PGP SIGNATURE-----

[Kyle Rankin]

I'm happy to help! Based on how other DKMS modules work on Debian and
Fedora it should be possible to package it externally in which case it
could get triggered whenever the main kernel package updated. In that case
it might mean having to have a build environment within dom0. I'm less
clear on how to build DKMS-style modules from within dom0 on Qubes compared
to Debian.

>
> A couple of questions about the status of the patches:
> 1. Do you know if it is complete, or still some in-development?

It looks like the Purism team tweaked byd.c 17 days ago but apart from that
everything was last touched more than 2 months ago:

https://github.com/purism/linux/tree/master/data/drivers/input/mouse

> 2. Is it going to be included in upstream kernel? Are the patches
> already sent?

Last week a different developer seems to have submitted a separate kernel
patch to linux-input here:

https://patchwork.kernel.org/patch/7963851/

I know it didn't make it in 4.4 but I don't know when that patch might show
up in the mainline kernel.

>
> > [1] https://github.com/kylerankin/psmouse-byd-dkms
>
> I'll check that. From what I see, there may be some problems in building
> it as an external module, for example Makefile expects
> CONFIG_MOUSE_PS2_BYD to be set. But hopefully those are minor problems.
>

--

Kyle Rankin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Take a look here:
https://www.qubes-os.org/doc/managing-vm-kernel/
In section "Installing different VM kernel based on dom0 kernel" very
similar thing is done. Especially qubes-kernel-vm-support package does
contain DKMS-style module and qubes-prepare-vm-kernel tool does build
it.

Generally - it should work pretty the same. You need to have appropriate
kernel headers installed (kernel-devel package) and dkms itself of
course. Other things should be the same.

> > A couple of questions about the status of the patches:
> > 1. Do you know if it is complete, or still some in-development?
>
> It looks like the Purism team tweaked byd.c 17 days ago but apart from that
> everything was last touched more than 2 months ago:
>
> https://github.com/purism/linux/tree/master/data/drivers/input/mouse

And that commit almost doubled the size of byd.c, so not a minor change
(even if most of it is just adding some defines instead of open-coded
values).

> > 2. Is it going to be included in upstream kernel? Are the patches
> > already sent?
>
> Last week a different developer seems to have submitted a separate kernel
> patch to linux-input here:
>
> https://patchwork.kernel.org/patch/7963851/

Interesting, it looks to be a totally different implementation of a
driver for the same device. And BTW this one looks to have much cleaner
code (which doesn't mean it works better...). I'm curious if they know
about each other...

> I know it didn't make it in 4.4 but I don't know when that patch might show
> up in the mainline kernel.
>
> >
> > > [1] https://github.com/kylerankin/psmouse-byd-dkms
> >
> > I'll check that. From what I see, there may be some problems in building
> > it as an external module, for example Makefile expects
> > CONFIG_MOUSE_PS2_BYD to be set. But hopefully those are minor problems.
> >
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWldI+AAoJENuP0xzK19cskPoIAIwIl0d+WvrRY3x/pTSeTZVo
ilduhAXF/+x4Ut4zSBL8mVy8+Y1fhLDsg4dMmzOg9iZEdo9hyZXwDl3Kz32L6b5V
EtdnNsEfvhokYNKbrPx/VFwk8Wm1Da0TtEs+TOBBrfsrnkkjEP84gNSzt0nRuQjw
Se9QtqbnVGakXbCLO9SLA1n7SgCthi2aYEgeykHEKNeJUYSAZUZyD5RLqPEZmrIu
kRLoVfQudHGqYO6dhKxNW+XxC86VWAiLqiZrMxEeTtLRKhbt2Lmn/7QYsOIke1NE
Q0thYHTDpsZxz18714KqAJtCT/Pk4IAwdm6p2fNz775lr8D84q7PPnDC/OALNPk=
=7KnA
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Wed, Jan 13, 2016 at 05:27:40AM +0100, Marek Marczykowski-Górecki wrote:
> Take a look here:
> https://www.qubes-os.org/doc/managing-vm-kernel/
> In section "Installing different VM kernel based on dom0 kernel" very
> similar thing is done. Especially qubes-kernel-vm-support package does
> contain DKMS-style module and qubes-prepare-vm-kernel tool does build
> it.
>
> Generally - it should work pretty the same. You need to have appropriate
> kernel headers installed (kernel-devel package) and dkms itself of
> course. Other things should be the same.
>

I inspected qubes-prepare-vm-kernel and as you suggested it does just run
standard dkms commands. I did try that before and I continue to have the
same strange error. Unfortunately the errors are not all that helpful:

[user@dom0 src]$ sudo dkms build psmouse/byd-0.1

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area...
make KERNELRELEASE=4.1.13-8.pvops.qubes.x86_64 -C /lib/modules/4.1.13-8.pvops.qubes.x86_64/build M=/var/lib/dkms/psmouse/byd-0.1/build/src psmouse.ko....
Error! Build of psmouse.ko failed for: 4.1.13-8.pvops.qubes.x86_64 (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/psmouse/byd-0.1/build/ for more information.

[user@dom0 src]$ cat /var/lib/dkms/psmouse/byd-0.1/build/make.log
DKMS make.log for psmouse-byd-0.1 for kernel 4.1.13-8.pvops.qubes.x86_64 (x86_64)
Thu Jan 14 07:37:03 PST 2016
make: Entering directory `/usr/src/kernels/4.1.13-8.pvops.qubes.x86_64'
CC /var/lib/dkms/psmouse/byd-0.1/build/src/psmouse-base.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/synaptics.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/focaltech.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/byd.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/alps.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/elantech.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/logips2pp.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/lifebook.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/sentelic.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/trackpoint.o
CC /var/lib/dkms/psmouse/byd-0.1/build/src/cypress_ps2.o
LD /var/lib/dkms/psmouse/byd-0.1/build/src/psmouse.o
MODPOST 0 modules
make: Leaving directory `/usr/src/kernels/4.1.13-8.pvops.qubes.x86_64'

So it appears all of the object files are being created but the kernel
module itself is not. Unfortunately I'm not getting any good explanation
from the output as to why.

--
Kyle Rankin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

For me it looks like all that (psmouse) is configured as built-in, not a
module. Which obviously doesn't have sense for dkms build. Makefile
should place those objects (especially psmouse.o) in obj-m list, not
obj-y. This line:
obj-$(CONFIG_MOUSE_PS2) += psmouse.o

So CONFIG_MOUSE_PS2 would need to be set "m". It is "y" (built-in)...

This probably means that the whole plan to have it as a separate module
fails with the current kernel... Maybe switching psmouse to be a module
would be an option? If you want, I can build&upload such kernel to
"unstable" repository. Please let me know about that.
The other option would be renaming/splitting the driver so both can be
loaded and then dynamically selecting which one should be attached to
the actual device. But probably much more work.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWl8/uAAoJENuP0xzK19csGu0H/AgD37M8mS3Z6F3FMbTGhciq
efnyESskgWfZ8O4XhX2nOmn1GhuI/h29+11HPpS+T8BQAaAYMN9etqPn2L4uAo9o
EBm+c3ZJ+H7z6/jCBEBkyLBSfSu7D4Qj+ZRLtp3ZrlZk1Yodh7B6ylWNcSs97dgN
H4KLxQXIE+TCitiaf1vKdKWASHJ/OBZUJS8/uIkOfeDyknPitvniNIuD5ymqjQLK
WZHRY0z/zv0lM0SP6BD0JQXYt0tmfY+OllUqC5UEfU1NtTPMBIK4PQbK71slduCY
4SRc8C0sMw0a7/U8TZeMlcFH1C9R9rVIQFrwx6Bw/Xbey0YI/OrPfO5taSPvJMQ=
=fFGf
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Thu, Jan 14, 2016 at 05:42:24PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 14, 2016 at 07:52:58AM -0800, Kyle Rankin wrote:
> > So it appears all of the object files are being created but the kernel
> > module itself is not. Unfortunately I'm not getting any good explanation
> > from the output as to why.
>
> For me it looks like all that (psmouse) is configured as built-in, not a
> module. Which obviously doesn't have sense for dkms build. Makefile
> should place those objects (especially psmouse.o) in obj-m list, not
> obj-y. This line:
> obj-$(CONFIG_MOUSE_PS2) += psmouse.o
>
> So CONFIG_MOUSE_PS2 would need to be set "m". It is "y" (built-in)...

That makes a lot of sense and explains why it worked in Debian (psmouse is
a module there) and not here.

>
> This probably means that the whole plan to have it as a separate module
> fails with the current kernel... Maybe switching psmouse to be a module
> would be an option? If you want, I can build&upload such kernel to
> "unstable" repository. Please let me know about that.

If you are going to the trouble of changing and recompiling the kernel,
what do you think about applying the BYD patches (either the Purism one or
the other one we discussed earlier in the thread) to psmouse and leave it
as a built-in? As you can see from the patch that was submitted to
upstream, it ends touching a handful of files and only adds support to the
existing list of psmouse devices and doesn't remove anything. If you
already have a build mechanism in place to apply patches to your kernels
perhaps that's an option that would tide us over until BYD patches show up
in upstream.

Otherwise if you want to build a modular psmouse kernel and upload it to
unstable I would be happy to test it.

> The other option would be renaming/splitting the driver so both can be
> loaded and then dynamically selecting which one should be attached to
> the actual device. But probably much more work.
>
>

I've experienced some problems with the patched module when I've loaded the
unpatched psmouse module first and then loaded the patched one afterwards.
As long as only the patched psmouse module loads things are stable, though,
so I suppose if we went this route a user who wanted this module could
blacklist the other one.

--
Kyle Rankin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I worry here about updating the driver later. When it wasn't accepted
upstream (yet), it is still changing - tracking+updating the patch
there would be painful, at least given the whole kernel compile time.
Also when it wasn't accepted there, means that it may not been thoroughly
reviewed yet (at least to be sure to really not interference with other
drivers).

> Otherwise if you want to build a modular psmouse kernel and upload it to
> unstable I would be happy to test it.

Ok, kernel-4.1.13-8.1 is in qubes-dom0-unstable repo (together with
appropriate kernel-devel).

> > The other option would be renaming/splitting the driver so both can be
> > loaded and then dynamically selecting which one should be attached to
> > the actual device. But probably much more work.
> >
> >
>
> I've experienced some problems with the patched module when I've loaded the
> unpatched psmouse module first and then loaded the patched one afterwards.
> As long as only the patched psmouse module loads things are stable, though,
> so I suppose if we went this route a user who wanted this module could
> blacklist the other one.
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWl+GkAAoJENuP0xzK19csww4H/2oO5DcVGrihjouBQbjSmkPV
VCPiCBdQ7luZ9tdzeelghgH2jNyiR22uzHTmIu/TognP2j4SF8NCfLKlqVq5wEmR
IUOUbJ3rz8L+xgG7VHaCKzeVUns4+x18/tP2IGej4UFBIEB/a2C5BKFQJMEHJgW8
BfsU67rh6tAjdJFmsCVZtfsKOwCuJ9neUvlvEZNu6CahqDHD4xj/E1Cfv36uSsV6
Q7RTsrK4KtOQjjIxbx/1XmOCTNvZWajAPb9VrZzN8HZlojqqhgpQRJgbOztbak6O
Q0wnPKXYXH6At7rW6Zojin/O+olLaLZ7ifsCXj+898eQ0sRvMyYtBFRaz/9zl94=
=Cssj
-----END PGP SIGNATURE-----

[Kyle Rankin]

This kernel worked as expected. I was able to build and load the DMKS
psmouse module and now I get the same basic multi-touch functionality as
in the PureOS kernel. Thanks for your help.

> > > The other option would be renaming/splitting the driver so both can be
> > > loaded and then dynamically selecting which one should be attached to
> > > the actual device. But probably much more work.
> > >
> > >
> >
> > I've experienced some problems with the patched module when I've loaded the
> > unpatched psmouse module first and then loaded the patched one afterwards.
> > As long as only the patched psmouse module loads things are stable, though,
> > so I suppose if we went this route a user who wanted this module could
> > blacklist the other one.
> >

--

Kyle Rankin

[Kyle Rankin]

On Thu, Jan 14, 2016 at 11:26:15AM -0800, Kyle Rankin wrote:
> > Ok, kernel-4.1.13-8.1 is in qubes-dom0-unstable repo (together with
> > appropriate kernel-devel).
> >
>
> This kernel worked as expected. I was able to build and load the DMKS
> psmouse module and now I get the same basic multi-touch functionality as
> in the PureOS kernel. Thanks for your help.
>

Given that the DMKS module works with this kernel, would it be possible for
future kernels to make psmouse modular or otherwise would it be possible to
provide an alternate kernel each time? While I hope that the changes make
their way into the mainline kernel eventually, in the mean time it would be
nice if the eventual 4.1.13-9 and future kernels (such as whatever qubes
kernel will contain the patch for CVE-2016-0728) has modular psmouse.

--
Kyle Rankin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, the next kernel version probably will have this config change
applied. Just needs to check if it doesn't break anything (for example
installer).

As you've probably seen, I've also created rpm packaging of it. This way
it would be trivial to install the package out of yum repository (for
now - "qubes-dom0-unstable").

So, now the installation instruction would be:
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
kernel-4.1.13-8.1* kernel-devel-4.1.13-8.1* psmouse-byd-dkms

There are also some (minor?) issues with the driver itself (cc Jay Kuri
for that):
1. There are kernel messages about "unknown code detected". I've noticed
those:
- d7, 29 - no idea what was that
- 32 - two-finger click
- ce - three-finger click
- 2f - two-finger click at the bottom edge
2. Haven't managed to get middle-click in any way
3. Not possible (?) to re-enable touch-to-click (but disabled by default
seems to be ok)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWoo4XAAoJENuP0xzK19csrxIH/0itDYSbdTqnii7fy2g3uhYZ
Z/cel1Qrew+eWWG1jaZzNXGW+mS5Q5vZaq9GXgHIcMr6uj+yJ0T7ntG1AWsFitYC
xMRWIgLhvaZ3bCncQbAwGIA1cO8fMtV4fTqqH0t10G1rVLCdwz0LMT/vErQOreKM
sPSS37z/vmop/ouV0hSmGQvV2bh3ND9n24s2Qiw3uAwxtjfxfZw+evs5indDxLDJ
REfr8DE5gRcYG/IqMQUFVkpp3kOo4Inf9N3Nq4ih4R+lnMOhKob/L5M+LG/UaeUC
LKa3kWBtxwBfginHcCeUTQyTil3Wfgse7Jws0gcD07OQoiYNRp9iMRpY+VytUS8=
=McHg
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Fri, Jan 22, 2016 at 09:16:23PM +0100, Marek Marczykowski-Górecki wrote:
[snip]

> Yes, the next kernel version probably will have this config change
> applied. Just needs to check if it doesn't break anything (for example
> installer).
>
> As you've probably seen, I've also created rpm packaging of it. This way
> it would be trivial to install the package out of yum repository (for
> now - "qubes-dom0-unstable").
>
> So, now the installation instruction would be:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
> kernel-4.1.13-8.1* kernel-devel-4.1.13-8.1* psmouse-byd-dkms
>
> There are also some (minor?) issues with the driver itself (cc Jay Kuri
> for that):
> 1. There are kernel messages about "unknown code detected". I've noticed
> those:
> - d7, 29 - no idea what was that
> - 32 - two-finger click
> - ce - three-finger click
> - 2f - two-finger click at the bottom edge
> 2. Haven't managed to get middle-click in any way
> 3. Not possible (?) to re-enable touch-to-click (but disabled by default
> seems to be ok)
>

I received a pull request earlier from one of the maintainers of the
upstream patch so my DKMS module now incorporates some of the latest
enhancements in the BYD mouse driver and it also looks like that team and
the developer you referenced earlier in the thread are now collaborating on
the driver.

It would be great if you could rebuild the DKMS RPM based on the latest
driver at your convenience.

--
Kyle Rankin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Done, uploaded (as previously) to qubes-dom0-unstable repo. Installation
instruction is the same, except that kernel version have changed to
4.1.13-9* (you can simply use "4.1.*" which should also work in the
future).

It may be needed to call "sudo dkms autoinstall" to rebuild the module
after update.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWyvijAAoJENuP0xzK19csUwUIAIsmTlSKbCRubXrVCnzBvjYi
7RRY/0guamUzPAsNMa2Y0nAtrltREKcRJKbXwHC3z9amrUznALip2sMMg7WUwl6t
97IKj9JnBxFdy78rpgRbQpRLy2cmiBgySFBradFMLzlV3g/1ubQQ3nFrUQuwG8il
uOvl0I33wWlLVHz8UMvRhM7da/ngpYgJBrgtIbbVShGvb1wkFAJdr76h8SqMPALE
be/l8qM/VJqFKncaxMtzNYip8CCReBnktJt/l0O0+FSIRHw6Qyxsy+dFdqjwBUOk
ZdWI9vvB2Q6iIiUvk9QPNNGHCOJal1QfXR1z/s7pS0Ba7xjyD5HnNqqxXaQoZ3I=
=XvHU
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Mon, Feb 22, 2016 at 01:01:36PM +0100, Marek Marczykowski-Górecki wrote:
> Done, uploaded (as previously) to qubes-dom0-unstable repo. Installation
> instruction is the same, except that kernel version have changed to
> 4.1.13-9* (you can simply use "4.1.*" which should also work in the
> future).
>
> It may be needed to call "sudo dkms autoinstall" to rebuild the module
> after update.
>
>

Would it be possible to create an updated dkms RPM for 3.2rc1? I had hoped
that the newer kernel would have integrated the BYD module but it looks
like I'm back to the standard generic psmouse.

-Kyle

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I hoped for the same... Do you know any status on upstreaming this
patch? I've seen there was some attempt, but can't find the link just
now.

Anyway, we'll probably apply apply the patch to our kernel package (in
addition to uploading dkms package).

It's already tracked here:
https://github.com/QubesOS/qubes-issues/issues/2131

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXeWqZAAoJENuP0xzK19csWmMH/RzN7SS0ICJ+DEndplyPzE9W
8ebro+uYiNxKH0AaGNEBKSZ15pSmxPY0fTnNutj3eDIgofZiWZDpQyoDTsOlAxcv
9UsrhthznsTktO9KNhl38KdKc2/kshP58TqCReYpCTSfv+WI9+tIYaBeKoYadeCz
CicUJXtf/E8Ap+6lNtoNjkJQcfW5aP1NU60m55D0naGgRFq10HjyNnd0X3d9Ojvu
X5rZL+mkekzdVgw1vNB/iCOaZd/WXqKvp6OkVPZFTLPAuspNT54PuPuqqGIKgzGq
XfCdHNRKzAr4gV237gJU9Q9i+hLszfJ0OWl0Sq3xgQmFg4wAvuBTE7aOoUMEgdM=
=jl5H
-----END PGP SIGNATURE-----

[Kyle Rankin]

On Sun, Jul 03, 2016 at 09:42:18PM +0200, Marek Marczykowski-Górecki wrote:
> On Sat, Jul 02, 2016 at 09:48:06AM -0700, Kyle Rankin wrote:
> > On Mon, Feb 22, 2016 at 01:01:36PM +0100, Marek Marczykowski-Górecki wrote:
> > > Done, uploaded (as previously) to qubes-dom0-unstable repo. Installation
> > > instruction is the same, except that kernel version have changed to
> > > 4.1.13-9* (you can simply use "4.1.*" which should also work in the
> > > future).
> > >
> > > It may be needed to call "sudo dkms autoinstall" to rebuild the module
> > > after update.
> > >
> > >
> >
> > Would it be possible to create an updated dkms RPM for 3.2rc1? I had hoped
> > that the newer kernel would have integrated the BYD module but it looks
> > like I'm back to the standard generic psmouse.
>
> I hoped for the same... Do you know any status on upstreaming this
> patch? I've seen there was some attempt, but can't find the link just
> now.
>

According to the Linux kernel Github page the BYD driver was added in the
4.6 release:

https://github.com/torvalds/linux/tree/v4.6/drivers/input/mouse

There are a few different drivers for the BYD mouse going around
though--the one you used for Qubes bypasses the hardware multi-touch
support for a (in my opinion better) software-based approach. I'm not sure
which approach the driver in the kernel takes.

> Anyway, we'll probably apply apply the patch to our kernel package (in
> addition to uploading dkms package).
>
> It's already tracked here:
> https://github.com/QubesOS/qubes-issues/issues/2131
>
>

I think having a patch makes sense until things stabilize a bit more
between the different BYD module efforts and the upstream kernel.

-Kyle