IssueTracker

Project: chromiumos/third_party/kernel
Branch: chromeos-6.6
Author: Emilie Roberts <hadrosaur@google.com>
Link:      https://chromium-review.googlesource.com/6169942

CHROMIUM: termina: enable USB audio/MIDI devices

CHROMIUM: termina: enable USB audio/MIDI devices 
 
Allow for USB audio and MIDI devices to be used. USB MIDI and 
audio devices are able to be passed through to Linux in the 
standard ChromeOS settings, but kernel support was not enabled. 
 
This change enables the kernel flags needed for USB audio and 
MIDI sequencer support. 
 
BUG=b:260275869 
TEST=Install qjackctl: `sudo apt install qjackctl` 
  Start qjackctl: `qjackctl` 
  Press Start 
  Open Graph, notice there are no MIDI devices 
  Plug in USB MIDI device (like AKAI MPK mini Mk II) 
  In ChromeOS settings, share the USB device with Linux 
  Wait 5 seconds 
  Notice that the USB MIDI device now appears in qjackctl graph 
 
Change-Id: I4352a95e1ac7dbb60e9265c6e8e5550f57074a32 
Signed-off-by: Emilie Roberts <hadrosaur@google.com> 
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6169942 
Reviewed-by: maciek swiech <drmasquatch@google.com> 
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> 
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>

It should appear in M134 for devices with the 6.6 kernel on the ChromeOS Host (currently most Intel boards). Other devices should get it as their kernels uprev to 6.6+. Currently M134 is scheduled for the stable channel about mid-March.

Confirming your findings: the Acer 315-3H is an octopus board (FYI consumer names to device names here). It is currently on the 5.15 kernel so will not have MIDI support in linux at this time. Apologies, I actually thought octopus was already on 6.6 when I posted #16.

Kernel updates for the host are tied to the OS and there is not a way to update it independently of the system. Kernel uprevs are non-trivial and have a large impact on the overall system. This is an older device and octopus boards tend to have lower specs (celerons, 4gb RAM), so we need to be particularly careful with performance, battery life, etc. when uprevv'ing. (If you're interested in hacking, you could try to build your own "chromiumOS" image and try to get the 6.6 functional, but I don't recommend this unless you have some kernel hacking experience and know what building ChromeOS entails + the tradeoffs - including possibly ending up with a non/partially functioning OS).

I'm not sure when and if we will uprev octopus to 6.x. Likely we will at some point, but I don't know when. We uprevved to 5.15 about a year ago so I would not expect this sooner than a year or so from now. Apologies that I don't have a clearer schedule.

In the meantime, MIDI devices should still work on your Chromebook in the Web and under Android (ie. not under linux). If there are apps on those platforms that serve your needs that might be an option until a kernel upgrade happens. I know it's not the same as having a full JACK patchbay, but I hope it might solve some of your use cases.

I love linux and it's potential for music creation and production. Unfortunately using Linux on ChromeOS for music is not an ideal path, especially for developers targeting consumers. We conceived it with software development in mind, and although it is capable of doing more, that remains the primary focus. We can't commit to a timeline for a kernel uprev to support this feature in octopus. Personally, I wish we could support you better as a linux music software creator, and I hope your work continues there for the linux community, but on these devices linux won't support midi until a kernel uprev. I can understand the frustration.

I agree that building and customising ChromiumOS would be a potential path for an interested hobbiest, but not for end users.

For the record, I just tested MIDI on Android and Web with an AKAI MPK mini keyboard on octopus and it works with no extra configuration. I'm not sure if it's in scope for your development team, but if Android is a potential distribution platform, it might be worth exploring and MIDI will work on these devices. Some linux toolkits like QT have an Android build target and so may require only minimal porting. You'd also be able to distribute on the many Android tablets, foldables, and phones.

Project: chromiumos/third_party/kernel
Branch: chromeos-6.12
Author: Emilie Roberts <hadrosaur@google.com>
Link:      https://chromium-review.googlesource.com/6317135

CHROMIUM: termina: enable USB audio/MIDI devices

CHROMIUM: termina: enable USB audio/MIDI devices 
 
Allow for USB audio and MIDI devices to be used. USB MIDI and 
audio devices are able to be passed through to Linux in the 
standard ChromeOS settings, but kernel support was not enabled. 
 
This change enables the kernel flags needed for USB audio and 
MIDI sequencer support. 
 
BUG=b:260275869 
TEST=Install qjackctl: `sudo apt install qjackctl` 
  Start qjackctl: `qjackctl` 
  Press Start 
  Open Graph, notice there are no MIDI devices 
  Plug in USB MIDI device (like AKAI MPK mini Mk II) 
  In ChromeOS settings, share the USB device with Linux 
  Wait 5 seconds 
  Notice that the USB MIDI device now appears in qjackctl graph 
 
Change-Id: I4352a95e1ac7dbb60e9265c6e8e5550f57074a32 
Signed-off-by: Emilie Roberts <hadrosaur@google.com> 
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org> 
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6317135 
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>

Comment #25, note that the team member who works on this is OOO for a few days and may not respond for a little while. According to the comments above, yes, AGP 3.6.3 should include the fix.

Do you have repro steps? Just to help ensure that this is, in fact, the same issue reported here? There might be multiple paths to produce the same error, etc. etc. If you're certain it's the same issue as here, then repro steps will help us determine if we should reopen this. Otherwise, it might be best to file a new bug since this one seems to have quite a bit of history on it.

Meanwhile, there are 20 +1's on this bug. Can anyone else who was experiencing this report that it was actually fixed for them starting in 3.6.0?

Thanks! David

Hey David,

I think this may have regressed. I created a fork of the original sample project with AGP 4.1.2.

https://github.com/saadfarooq/Robolectric-Databinding-Lib

The Robolectric test fails with the same error. If kotlin-kapt plugin is removed, the test passes. But then the buildFeatures databinding config says If you plan to use data binding in a Kotlin project, you should apply the kotlin-kapt plugin.

So possibly something to do with kapt?

Ooof :) Hung, are you swamped? Would you be able to take a look?

Comment #27, in the meanwhile, it may be worth trying things out with a more recent version of AGP (e.g. using beta or canary) to see if this remains broken after 4.1.2, or if this was a temporary regression.

Hung: I meant to say, I reopned this bug, but if it ends up being a different cause, or just because this bug already has so much history, feel free to reclose it and create a new one.

I tried 4.2.0-beta05 and 7.0.0-alpha8 in Arctic Fox Canary 08 and the behavior is the same. Remove kapt, test passes. Added it back, get the NoClassDefFound error.

Thank you for the sample project! This issue was mentioned earlier at comment #20, 21, 23.

This is caused by https://youtrack.jetbrains.com/issue/KT-27404, originally reported at Issue 117145132.

Basically, when using kapt, users will need to add:

• kaptTest some-random-dependency for kapt to run annotation processing on unit test source code, which in this case will include the missing data binding classes.
• kaptAndroidTest some-random-dependency for kapt to run annotation processing on androidTest source code.

Please follow the Kapt bug above for progress on this issue.

@David: I'm closing this issue as this should ideally be fixed by the Kotlin Gradle plugin.

I can not sing google account