Linux 5.5 Adding Wake-On-Voice Support - Capable On Some Chromebook Hardware

[phoronix]

Phoronix: Linux 5.5 Adding Wake-On-Voice Support - Capable On Some Chromebook Hardware

As part of the sound subsystem updates coming with the Linux 5.5 kernel is wake-on-voice capabilities with newer Google Chromebook device hardware...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Wake-On-Voice

[Danny3]

What is Wake-On-Voice ?
This looks to me like keeping the mike on even in sleep mode to listen for the wake up word, but I assume they care more about the spyware capability.
Hopefully I'm wrong.

[ThoreauHD]

I hope "Google, install GalliumOS" is an option.

[microcode]

What is Wake-On-Voice ?
This looks to me like keeping the mike on even in sleep mode to listen for the wake up word, but I assume they care more about the spyware capability.
Hopefully I'm wrong.

Yes, that is how computers listen, but by it's nature it is not really a useful bulk collection tool (since it would cost a noticeable amount of power to stream the audio off device).

[Cide]

Perhaps combine these kernel articles into 1? 5 separate linux 5.5 articles today.

[archsway]

"Ok Google, can you let me boot this time?"

"No Google, not into Chrome OS, can't you see that SD card with a "ChromeOS kernel" partition? I've set the priority flag on it just the way you like it."

"By the way, Google, why is there network activity to google.com when I'm not using Chrome OS and haven't got a browser open?"



I couldn't find any information on the MT6358, but the MT8183 uses a G72 GPU, which doesn't have good support in Mesa at the moment, AFAICT.

But whatever you do, stay away from the MT8173, which has PowerVR graphics.

Instead consider something with an RK3399 (a few Chromebooks, as well as the Pinebook Pro), which has pretty good GPU support in Mesa.

[Guest]

Shouldn't this be handled in user space? This sounds like a hardware manufacturer polluting the kernel. Make it communicate over some standard protocol that's easily used in user space, it should not be that hard. Kernel is not a dumpster for some random code.

[Michael]

Shouldn't this be handled in user space? This sounds like a hardware manufacturer polluting the kernel. Make it communicate over some standard protocol that's easily used in user space, it should not be that hard. Kernel is not a dumpster for some random code.

It needs to interact with the audio codecs and EC, so those bits need to be in the kernel. In user-space is the logic to load the language map and other bits into the kernel.

[Michael]

Perhaps combine these kernel articles into 1? 5 separate linux 5.5 articles today.

Different topics, different articles.

[Guest]

It needs to interact with the audio codecs and EC, so those bits need to be in the kernel. In user-space is the logic to load the language map and other bits into the kernel.

EC could be connected as a standard device over something like USB, SPI or whatever other interface that can be accessed from user space. This sounds like a bad design decision to me.