LWN: Comments on "LC-Asia: An Android upstreaming update"

CCG on its way out?

jstultz — 2013-03-29T00:04:06+00:00

Yea, so this was maybe not as clear/precise in the summary. But CCG being removed is in part due to some of the discussions at Linaro Connect.

CCG, basically a modified version of the android gadget driver, was merged into staging, but the Android developers decided against moving to use it, and the upstream maintainers want to see a configfs based gadget instead. Thus the CCG driver had been effectively abandoned and developer efforts have been focused on the configfs gadget.

Mix in the fact that the functionfs gadget driver already can also be used for adb, and you get a bit of a mess as to what the right approach is going forward. (How many configurable composite gadgets do we need?)

That said, the configfs gadget driver has been slow-going in development, so if necessary it may be something Linaro would try to help along (rather then "taking over development").

CCG on its way out?

pebolle — 2013-03-21T08:52:19+00:00

> There is a desire to replace the Android gadget driver with the CCG
> ("configurable composite gadget") code that is currently in the staging
> tree, but CCG does not yet do everything that Android needs, and it
> appears to be unmaintained as well. There was talk in the session of
> Linaro possibly taking over the development of that driver in the future.

Note that, only two days after this article was published, Greg Kroah-Hartman removed CCG from the staging-next tree. See, for the first of two patches involved:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/stagi...

This is not in mainline yet, but it looks like CCG is on its way out.

LC-Asia: An Android upstreaming update

njwhite — 2013-03-14T12:01:12+00:00

What proportion of this good upstreaming work is being done by Google's android team? I'm glad they're generally making use of upstream once things are merged acceptably, but I'm not clear on whether it's the Google people themselves who are pushing in this direction.

Uptake by Android

epa — 2013-03-14T10:09:08+00:00

That's great news. I felt the article was a bit ambiguous, saying the work has 'made it possible' for the Android developers to use the mainline feature - which can mean that this has happened, but can also mean just that it's 'possible'.

Keyboard

khim — 2013-03-14T07:27:39+00:00

You are correct, of course: most US keyboards sacrifice Enter key to make Backspace larger (as if I'm obsessed with deleting stuff). My bad.

European keyboards sacrifice Left Shift size which is even worse: I can still hit small US-style Enter key with my little finger, but small Shift is a disaster since attention is usually on other hand. Ideally I want classic layout similar to this one (with two large Shifts, and large Enter L-shaped Enter) which is rare enough with 101-keys-layout keybords (nowadays they have 104 keys because Microsoft added three keys) and I'm yet to see even a single 102-keys-layout keyboard (with 105 keys) with all three.

Keyboard

mpr22 — 2013-03-13T22:08:18+00:00

*scratches head* Um, it's American keyboards that have the crippled one-row-high Enter key.

Keyboard

khim — 2013-03-13T21:31:58+00:00

I can scarcely begin to imagine how somebody thought this was a good idea, unless perhaps they had literally never seen a non-US keyboard or used a non-English language.

I'm pretty sure they have seen non-US keyboard and wondered just why this keyboard wastes valuable space and cripples Enter key just to introduce second backslash. Guy from Israel or Russia can do that just as easily as a guy from US, you know: it may surprise you but lots of languages don't need this 102ND key and for them it's just "#@^%%#@(*!@ second backslash".

LC-Asia: An Android upstreaming update

dvdeug — 2013-03-13T12:26:54+00:00

So we have CCG code being compiled by GCC. Maybe we should starting going to FLAs (four letter acronyms) (err, ETLAs, extended TLAs?)

Uptake by Android

corbet — 2013-03-13T12:09:57+00:00

This was mentioned twice in the article, but I probably should have made an even bigger deal of it: yes, the Android developers are making use of the mainline features as they become useful. The whole wakelock/suspend blocker fight has quietly come to an end, and nobody even noticed. It's great news, and a credit to both the Android and mainline camps, both of which have worked hard to reach this point.

Keyboard

tialaramex — 2013-03-13T11:42:56+00:00

As of the last time I was able to check current Android still arbitrarily merges device driver keyboard events for no discernible reason.

The scenario is an external (USB, Bluetooth) keyboard plugged into an Android device, European keyboards tend to have one extra key KEY_102ND compared to a US keyboard. The purpose of this key varies by layout but (of course) it's not just an identical copy of an existing key so it needs to be treated separately and Linux does so. Android takes the Linux kernel's internal key identifiers and lays its own equivalent yet different identifiers on top (presumably for some reason that made sense to the early Android developers). In the process it takes the "extra" key KEY_102ND and maps it to Android's backslash key, even though there's already such a mapping for KEY_BACKSLASH.

And that's doom. Despite having an extensive layout and remapping capability Android has already irrevocably broken these keyboards, because software on top of Android can't tell the two different keys apart. I can scarcely begin to imagine how somebody thought this was a good idea, unless perhaps they had literally never seen a non-US keyboard or used a non-English language.

LC-Asia: An Android upstreaming update

jstultz — 2013-03-12T21:48:58+00:00

So for wakelocks, the Android developers have already moved over to the same code upstream is using (they even backported it to their 3.4 kernel branch, and I believe Nexus4 & Nexus10 devices are already using it).

But your larger point is right, collaborating and getting buy in from the Android developers at Google is really important. We don't want to push code upstream to "solve their problems" and then find they won't or can't actually make use of it.

That said, sometimes what gets merged upstream is more of a base foundational framework and does not provide 100% coverage for their needs. In those cases we can still rework portions of their drivers to make use of the properly merged code, simplifying the delta.

In my mind, the best approach is an iterative one, slowly chipping away at the portions we can find agreement on, which allows for better understanding and discussion of the exact differences.

LC-Asia: An Android upstreaming update

jstultz — 2013-03-12T19:38:38+00:00

This is very true. For my talk, I did not cover the device specific android git trees, and instead I kept it limited to the common.git tree (which contains the changes required for every device).

LC-Asia: An Android upstreaming update

jstultz — 2013-03-12T19:12:13+00:00

Thanks for the great summary, Jon!

If folks want to also see the slides from the talk, they can be found here:
http://lca-13.zerista.com/files_user/attachments/9198/and...

LC-Asia: An Android upstreaming update

gregkh — 2013-03-12T19:11:02+00:00

Already merged, is in linux-next, will show up in the 3.10 kernel release.

LC-Asia: An Android upstreaming update

mlankhorst — 2013-03-12T18:21:22+00:00

merging sync driver sounds like fun

LC-Asia: An Android upstreaming update

epa — 2013-03-12T17:45:30+00:00

Rafael Wysocki's opportunistic suspend work, combined with a user-space emulation library, has made it possible for Android to move over to a mainline-based solution.

But are the Android developers going to do that? They might have different ideas about whether the solution blessed by the kernel developers is the right one for their needs.

LC-Asia: An Android upstreaming update

gnu — 2013-03-12T17:44:51+00:00

That's a great update.

Apart from the main Android patches, there are many vendor specific patches to Android. For example, for ICS, TI added a "dsscomp" driver. They chose not to use the DRM driver (perhaps it was not ready when ICS was in development) or the V4L2 driver. The net result is that the V4L2 output driver for OMAP4, which was perfectly working in the linux kernel in the 2.6.3x series, became unmaintained in the 3.x mainline and is not working till this date (even in the linaro's kernel tree).