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

[archsway]

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.

If the driver was in userspace, how would the keyboard, suspend, RTC, pstore etc. work?

[Guest]

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.

It's what's used in Google Assistant, Siri on mobile devices, and many other assistant devices. There's a special chip, that listens to the mic constantly, and only wakes when hotwords like "Ok Google" or "Hey Siri" are spoken. All of the processing is performed on device, to save power and coincidentally also helps in privacy (kind of).

[Guest]

"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.

RK3399 has Mali GPU, and the only open source driver is the Lima driver which is also reverse engineered like all of the other GPUs shipped on ARM devices. How is that any better than the PowerVR GPU?

[Guest]

If the driver was in userspace, how would the keyboard, suspend, RTC, pstore etc. work?

EC doesn't have to handle the keyboard, and there could be 2 distinct connections, one for things that are already done in kernelspace, other for things that never should be.

[Guest]

RK3399 has Mali GPU, and the only open source driver is the Lima driver which is also reverse engineered like all of the other GPUs shipped on ARM devices. How is that any better than the PowerVR GPU?

What's wrong with reverse-engineered drivers? Are you saying that using something like Nouveau is a bad idea, even if there were times when compatible Nvidia GPUs were the only ones that could be used with free software?

[cybertraveler]

Different topics, different articles.

For whatever it's worth: personally I am a big fan of how you make articles. They are just the write length for me. They make for pleasant casual reading. I tend to scroll down the Phoronix front page and open all the articles that interest me in new tabs and ignore the rest.

Obviously I can't speak for everyone. The person who you replied to obviously has their own preference.

I only want to read a long, wordy, article if I'm actually studying a topic in detail. I read Phoronix more to stay up to date, learn about new things and just enjoy reading about technological advancements (particularly in Open Source, GNU/Linux and software in general).

Thanks.

[timofonic]

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.

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.

Are there Open Source tools to generate, modify and load that language map? Are there Wake-On-Voice support/implementation on stuff like Coreboot/Libreboot/Das U-Boot/Barebox/RedBoot/etc.?

[archsway]

RK3399 has Mali GPU, and the only open source driver is the Lima driver which is also reverse engineered like all of the other GPUs shipped on ARM devices. How is that any better than the PowerVR GPU?

The RK3399 actually needs the Panfrost driver, not Lima.


As for why you should avoid PowerVR, look at this:

https://libv.livejournal.com/26972.html

tl;dr PowerVR doesn't have a reverse engineered driver, and very likely never will, and the coupling between components for the proprietary drivers (i.e. you can't mix and match versions) is even worse than everything else.

[archsway]

EC doesn't have to handle the keyboard, and there could be 2 distinct connections, one for things that are already done in kernelspace, other for things that never should be.

And how could that be done without increasing the hardware cost?

The whole point of Google making their own EC was so they could do as much as possible on one chip rather than having multiple microcontrollers for different things.

It's not like there is even that much code relating to Chromebooks in the kernel.

From a grep for files with 'cros' or 'chrome' in the name (the ignored files are documentation and device tree files):

      72 text files.
      72 unique files.
      20 files ignored.

github.com/AlDanial/cloc v 1.82  T=0.36 s (143.8 files/s, 61485.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               41           2440           2075          11230
C/C++ Header                     7            967           2660           2819
make                             4              5              8             32
-------------------------------------------------------------------------------
SUM:                            52           3412           4743          14081
-------------------------------------------------------------------------------

That's about a third of WireGuard (including the crypto stuff).

[Guest]

And how could that be done without increasing the hardware cost?

The whole point of Google making their own EC was so they could do as much as possible on one chip rather than having multiple microcontrollers for different things.

It's not like there is even that much code relating to Chromebooks in the kernel.

From a grep for files with 'cros' or 'chrome' in the name (the ignored files are documentation and device tree files):

72 text files.
72 unique files.
20 files ignored.

github.com/AlDanial/cloc v 1.82 T=0.36 s (143.8 files/s, 61485.0 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 41 2440 2075 11230
C/C++ Header 7 967 2660 2819
make 4 5 8 32
-------------------------------------------------------------------------------
SUM: 52 3412 4743 14081
-------------------------------------------------------------------------------

That's about a third of WireGuard (including the crypto stuff).

Sounds like the Sensor Hub concept that Google talked about a few years ago - it's been shipping on devices ever since then.