Remapping the "Google Asistant" key as Super key on the Pixelbook

[nickjmeyer]

name: xenial-i3
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/xenial-i3...
crouton: version 1-20171109145451~master:35a16889
release: xenial
architecture: amd64
xmethod: xorg
targets: x11
host: version 9901.66.0 (Official Build) stable-channel eve 
kernel: Linux localhost 4.4.79-11650-ge987f76b729a #1 SMP PREEMPT Tue Oct 31 22:05:39 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/xenial-i3 as another instance is using it.

Please describe your issue:

With the new Pixelbook, we have an additional key. The new key is the dedicated Google Assistant key, but conveniently its located where the Super / Windows key would usually be. Is there any way to remap this key? I seems like Chrome OS intercepts the keystroke because xbindkeys -k doesn't pick up the key press.

Any ideas for how to get Chrome OS to pass that keystroke to crouton?

[markstos]

From within an X11 environment in Crouton on the Pixelbook, run this:

 xev 2>&1 | grep keycode

Then press the super/assistant key, then Control-C to cancel capture mode.. On a Dell XPS 13 running Ubuntu, here's what I capture:

state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,

What do you get on the Pixelbook? If nothing, this may just confirm that ChromeOS isn't passing the key on through to Crouton.

[markstos]

Have you checked your keyboard settings in ChromeOS to see if the Assistant key can be remapped like the Search Key could? See: https://www.howtogeek.com/265207/how-to-remap-the-search-key-on-your-chromebook/

Also try looking in one of these places:

chrome://settings/keyboard-overlay
chrome://extensions....then keyboard shortcuts

[nickjmeyer]

When running xev nothing shows up. I also checked dmesg for any "unknown key" messages, but I don't see anything there either. Chrome OS must not pass it through.

There is no option in settings to remap the key. Here are the only keys available in the Chrome OS settings.

I alos tried disabling the assistant thinking that maybe if it wasn't active, then the key might not get intercepted by Chrome OS. Sadly that didn't work either.

[markstos]

I opened a feature request with the Chromium project to support this. We'll see if it goes anywhere: https://bugs.chromium.org/p/chromium/issues/detail?id=784857

[DennisLfromGA]

@markstos,

Thanx for that feature request, I '*' it to keep an eye on it, hopefully, it'll get some traction.

-DennisL

[nickjmeyer]

Whoops. Looks like I accidentally closed this. Sorry about that.

@markstos Thanks for posting that request. Assuming it gets picked up, what does that process look like? I'm pretty new to the Chrome OS world. Does it get put into Chromium OS and then at some point google adds it to Chrome OS? I imagine that's typically a long timeline?

[markstos]

@nickjmeyer I think it could happen quickly if there were traction, where "quickly" might still be a couple months before a stable release, but we have to see what the response is. I understand it's also possible to dual-boot Chromebooks, like with ChromeOS and Ubuntu. I haven't read about someone doing it on the Pixelbook yet. If you ran Ubuntu that way, I presume Ubuntu would be able access the Assistant key and would not be surprised to find that the Assistant Key already sends a "Super" keypress in that context. As a prospective Pixelbook owner, that's the most likely way that I would use the device for now, as it would be too frustrating not to have a "Super" key when using Ubuntu via Crouton.

[DennisLfromGA]

The feature request is at Pri-2 but It's been 'assigned' so that's a good thing.

-DennisL

[markstos]

According to Chromium project docs, "assigned" means "in someone's work queue" and "Pri-2" means "P2 - Wanted for current milestone". So there's hope this could happen relatively soon, but a "want" is not a "need".

[nickjmeyer]

You have good timing. I was just looking up what those desginations meant.

This is awesome!

[DennisLfromGA]

I saw what 'assigned' means here: Bug Life Cycle and Reporting Guidelines But only saw a general reference to 'priorities' here: Chromium Bug Labels

Just wondering where @markstos found the 'project docs' ???

Very interesting, thanx, -DennisL

[markstos]

@DennisLfromGA, If you search for the phrase I pasted "P2 - Wanted for current milestone", it takes you right to the Triage Best Practices doc that I found.

[DennisLfromGA]

Thanx @markstos, still refining my googling skilz. :-( At least you didn't point to it with LMGTFY, I deserved it. :-)

[rickybrent]

This sounds like a great idea; I don't mind having an assistant key, but right now it's dead in Xenial. :(

I think 784857 is a great feature request in its own right, but it won't actually help for this; Chrome OS can remap the search and ctrl keys and so on already and the chroot doesn't get the remapped versions.

The good news is that I don't think we need it, it's a valid (but fairly new) key in regular Linux too. :) This might fix itself depending on the distro you use, or at least get to the point where the more common tools can handle remapping it.

Running 'sudo evtest /dev/input/event3' from inside the chroot and pressing KEY_ASSISTANT shows us:

type 4 (EV_MSC), code 4 (MSC_SCAN), value d8;
type 1 (EV_KEY), code 583 (?),

Also, the menu key in the top right is KEY_CONTROLPANEL; it shows up with the correct input event code as well. (579 is 0x243 in hex; code 583 is likewise 0x247, which looks right. Oddly it doesn't show the names for either even though we should have KEY_CONTROLPANEL, at least.)

I tried using a custom hwdb (which I think is the proper way to do it) with no luck yet; I had better luck using python to hack at it though.

[nickjmeyer]

Ah interesting. I wasn't able to get it to show up with xbindkeys, but it looks like the chroot is still receiving the input. Is that right?

Whats the difference between what evtest is doing vs what xbindkeys is doing? Is evtest just listening to lower level hardware events?

[rickybrent]

Yep, that's exactly right -- xbindkeys only sees what Xorg sees, and Xorg can't see keycodes over 255 I suspect this would Just Work in Wayland -- not with xbindkeys -- but didn't test.

Remapping the keys with evdevremapkeys works nicely, but also remaps them in Chrome OS (you have to start it before you start X; example config here.) I'd rather not lose the Assistant key in ChromeOS just to use it inside the chroot, though.

[rickybrent]

I gave up on finding a better way (not sure there is one) and just wrote a wrapper around evdevremapkeys; if anyone's interesting you can grab it here. :) All it does is swap remaps depending on if you're in Chrome OS or X11 but it does the trick for me.

[DennisLfromGA]

@rickybrent,

Very nice, thanx!

Perhaps a pull request is in order to either make this a standalone crouton target or incorporate it into the existing keyboard target if feasible.

-DennisLfromGA

[markstos]

Looks very helpful! One suggestion for the docs. Where it says: run it as root before X11 grabs the keyboard, it would be helpful if a specific example or command was provided for this. Some interested users wouldn't be sure at which point "X11 grabs the keyboard", or how to automate running something before that.

On Sat, Jan 27, 2018 at 12:00 PM DennisL notifications@github.com wrote:

@rickybrent https://github.com/rickybrent,

Very nice, thanx!

Perhaps a pull request is in order to either make this a standalone crouton target or incorporate it into the existing keyboard https://github.com/dnschneid/crouton/blob/master/targets/keyboard target if feasible.

-DennisLfromGA

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dnschneid/crouton/issues/3505#issuecomment-360998192, or mute the thread https://github.com/notifications/unsubscribe-auth/AABk5Qc75-M4BEniv80vc7ZrYllX0kmvks5tO1Y_gaJpZM4QakG_ .

[DennisLfromGA]

To add to @markstos's suggestion, you have to very careful when running things in your chroot as root since it can mess up permissions.

Hope this helps, -DennisLfromGA

[rickybrent]

Welcome, and thanks too! I hadn't actually thought of making this into a proper pull request or target; it looks like Kali uses a bit of python, so it's not out of the question... hmm.

I added an installation script that sets up a virtual env and adds it to rc.local, keeping things automated. You definitely do have to be careful running things as root, but we need write access to /dev/uinput for this and changing the permissions or group there would effect Chrome OS and other chroots as well, so this might actually be the safer approach.

[rifaterdemsahin]

can this be implemented in pixel book 2?

[markstos]

@rifaterdemsahin, there are several within the Chromium project that seem interested in having the Assist key be re-mappable on all Chromebooks that have the key. You can see the bug report it here: https://bugs.chromium.org/p/chromium/issues/detail?id=784857 However, the bug report has been open since last November, and so far no related commits have appeared. There's hope that it could still be fixed directly in ChromeOS in time for the Pixelbook 2 launch, but we'll see.

[rifaterdemsahin]

Ahh I got pixel book 2 is not out yet. https://www.techradar.com/uk/news/google-pixelbook-2 i hope it comes to pixelbook as well

[StephanX]

@rickybrent Thanks a ton for your script, it works for me.

[gaustin]

This is generating a blank rc.local file for me. Any ideas what that means?

I did have to manually install wheel.

I would be fine having the assistant key remapped in both ChromeOS and Linux if that simplifies anything.

[gaustin]

Nevermind. I'm using crostini 🤦‍♂️

[spitfire55]

For those still waiting for an official solution from Google, the Chromium issue tracker has been updated from "Untriaged" to "Assigned". See https://bugs.chromium.org/p/chromium/issues/detail?id=784857#c38

[markstos]

The Chromium issue was assigned to someone who hasn't logged into the bug tracker in the past 41 days. It also still lakes a priority or a target milestone, but yes-- it's good to see some movement on the issue besides just comments.

[markstos]

Hey, this feature has landed in Chrome OS now. Look for it start to make it's way into Canary -> Dev -> Beta -> Stable, arriving in Stable in Chrome OS 73 or 74.

https://bugs.chromium.org/p/chromium/issues/detail?id=784857#c41

[nickjmeyer]

Very exciting!

On Wed, Feb 27, 2019, 5:37 PM Mark Stosberg notifications@github.com wrote:

Hey, this feature has landed in Chrome OS now. Look for it start to make it's way into Canary -> Dev -> Beta -> Stable, arriving in Stable in Chrome OS 73 or 74.

https://bugs.chromium.org/p/chromium/issues/detail?id=784857#c41

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dnschneid/crouton/issues/3505#issuecomment-468059075, or mute the thread https://github.com/notifications/unsubscribe-auth/AJM6c4QNzyL0hGzioktIwpOnOgsCRfjeks5vRwikgaJpZM4QakG_ .

[markstos]

It looks like it will start out behind a flag for now, but that's easy enough to deal with.