Canonical has own Ubuntu driver for ALPS 73 03 28 devices

7 messages, 5 authors, 2016-06-21 · open the first message on its own page

Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Pali Rohár <hidden>
Date: 2016-06-18 23:43:52

I did not know about it since I found:

http://oem.archive.canonical.com/pool/public/o/oem-alps-touchpad-1521052-dkms/oem-alps-touchpad-1521052-dkms_1oem7_all.deb

If you are interested extracted patch is in attachment.

I do not understand it... Why Canonical is hidden and don't communicate
with rest of world? Otherwise touchpads could work out-of-box on non
Ubuntu systems too with mainline kernel.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Christoph Hellwig <hch@infradead.org>
Date: 2016-06-20 10:19:12

On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote:
I do not understand it... Why Canonical is hidden and don't communicate
with rest of world? Otherwise touchpads could work out-of-box on non
Ubuntu systems too with mainline kernel.
Because Canonical doesn't collaborate with the upstream community
in any meaninful way.  They've been a bad player since day 1 and will
always be.

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Pali Rohár <hidden>
Date: 2016-06-20 10:20:56

On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote:
quoted
I do not understand it... Why Canonical is hidden and don't communicate
with rest of world? Otherwise touchpads could work out-of-box on non
Ubuntu systems too with mainline kernel.
Because Canonical doesn't collaborate with the upstream community
in any meaninful way.  They've been a bad player since day 1 and will
always be.
It must be really frustrating for Ben and other people (me too) who in
last months working on ALPS patches to support that touchpad as we know
that Canonical already had some working code for that touchpad...

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2016-06-20 17:39:09

On Tue, Jun 21, 2016 at 01:29:41AM +0800, Anthony Wong wrote:
On 20 June 2016 at 18:20, Pali Rohár [off-list ref] wrote:
quoted
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote:
quoted
I do not understand it... Why Canonical is hidden and don't communicate
with rest of world? Otherwise touchpads could work out-of-box on non
Ubuntu systems too with mainline kernel.
It must be really frustrating for Ben and other people (me too) who in
last months working on ALPS patches to support that touchpad as we know
that Canonical already had some working code for that touchpad...
Hi Pali,

The fix in the DKMS package you referenced was not written by
Canonical but by ALPS, as it came from them I think it is reasonable
they send it to upstream, isn't it? As you can see the patch is non-trivial.

After we got the patch from ALPS, we had follow-up conversation a few
times with our contacts at Taiwan and asked if they would upstream it,
but unfortunately to no avail. I am as desperate as you if the fix
cannot land in mainline, which means many Linux users will not benefit
from it.  We also had opened this bug [1] for this particular issue,
there is nothing to hide. If there is any code written by us, we
happily submit them upstream.
Why couldn't you guys send it upstream yourselves?
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1571530
quoted
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
Because Canonical doesn't collaborate with the upstream community
in any meaninful way.  They've been a bad player since day 1 and will
always be.
This reminded me of this old thread [2]. How hard is it to run this
command in your kernel git tree?

    $ git log --pretty=oneline --author=canonical

[2] https://www.spinics.net/lists/linux-bluetooth/msg47286.html

Thanks,
Anthony
-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Pali Rohár <hidden>
Date: 2016-06-20 17:48:28

On Monday 20 June 2016 19:37:57 Dmitry Torokhov wrote:
On Tue, Jun 21, 2016 at 01:29:41AM +0800, Anthony Wong wrote:
quoted
On 20 June 2016 at 18:20, Pali Rohár [off-list ref] wrote:
quoted
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote:
quoted
I do not understand it... Why Canonical is hidden and don't
communicate with rest of world? Otherwise touchpads could
work out-of-box on non Ubuntu systems too with mainline
kernel.
It must be really frustrating for Ben and other people (me too)
who in last months working on ALPS patches to support that
touchpad as we know that Canonical already had some working code
for that touchpad...
Hi Pali,

The fix in the DKMS package you referenced was not written by
Canonical but by ALPS, as it came from them I think it is
reasonable they send it to upstream, isn't it? As you can see the
patch is non-trivial.

After we got the patch from ALPS, we had follow-up conversation a
few times with our contacts at Taiwan and asked if they would
upstream it, but unfortunately to no avail. I am as desperate as
you if the fix cannot land in mainline, which means many Linux
users will not benefit from it.  We also had opened this bug [1]
for this particular issue, there is nothing to hide. If there is
any code written by us, we happily submit them upstream.
Why couldn't you guys send it upstream yourselves?
For ALPS 73 03 28 touchpad it is probably too late now, see:
http://thread.gmane.org/gmane.linux.kernel.input/49651
quoted
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1571530
quoted
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
Because Canonical doesn't collaborate with the upstream
community in any meaninful way.  They've been a bad player
since day 1 and will always be.
This reminded me of this old thread [2]. How hard is it to run this
command in your kernel git tree?

    $ git log --pretty=oneline --author=canonical

[2] https://www.spinics.net/lists/linux-bluetooth/msg47286.html

Thanks,
Anthony
-- 
Pali Rohár
pali.rohar@gmail.com

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: Anthony Wong <hidden>
Date: 2016-06-20 17:55:28

On 20 June 2016 at 18:20, Pali Rohár [off-list ref] wrote:
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote:
quoted
I do not understand it... Why Canonical is hidden and don't communicate
with rest of world? Otherwise touchpads could work out-of-box on non
Ubuntu systems too with mainline kernel.
It must be really frustrating for Ben and other people (me too) who in
last months working on ALPS patches to support that touchpad as we know
that Canonical already had some working code for that touchpad...
Hi Pali,

The fix in the DKMS package you referenced was not written by
Canonical but by ALPS, as it came from them I think it is reasonable
they send it to upstream, isn't it? As you can see the patch is non-trivial.

After we got the patch from ALPS, we had follow-up conversation a few
times with our contacts at Taiwan and asked if they would upstream it,
but unfortunately to no avail. I am as desperate as you if the fix
cannot land in mainline, which means many Linux users will not benefit
from it.  We also had opened this bug [1] for this particular issue,
there is nothing to hide. If there is any code written by us, we
happily submit them upstream.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1571530
On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote:
quoted
Because Canonical doesn't collaborate with the upstream community
in any meaninful way.  They've been a bad player since day 1 and will
always be.
This reminded me of this old thread [2]. How hard is it to run this
command in your kernel git tree?

    $ git log --pretty=oneline --author=canonical

[2] https://www.spinics.net/lists/linux-bluetooth/msg47286.html

Thanks,
Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

From: One Thousand Gnomes <hidden>
Date: 2016-06-21 13:43:23

The fix in the DKMS package you referenced was not written by
Canonical but by ALPS, as it came from them I think it is reasonable
they send it to upstream, isn't it? As you can see the patch is non-trivial.
You published it on to milliosn of users, you'd think also mentioning its
existence upstream would have been easy enough.
After we got the patch from ALPS, we had follow-up conversation a few
times with our contacts at Taiwan and asked if they would upstream it,
but unfortunately to no avail. I am as desperate as you if the fix
cannot land in mainline, which means many Linux users will not benefit
from it.  We also had opened this bug [1] for this particular issue,
there is nothing to hide. If there is any code written by us, we
happily submit them upstream.
Other vendors and users regularly upstream driver code that lurks in
third party repositories or amidst the grues in the dark smelly corners of
the Android underworld. (and contrary to Christoph's comment Canonical are
angels compared with a lot of the Android world)

I can see why you wouldn't want to submit it if ALPS were
going to, but really - not even mentioning it upstream when there was
other work going on was unfortunate. A single Canonical email saying
"You might want to look at the ALPS driver at URL" would have saved all
the wasted effort.

It's also good common sense behaviour - in this case there is no API
difference but vendors who sit on stuff get burned when we merge an
alternative piece of code.

Alan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help