You are not logged in.
That was a bit more work than I initially thought it would be, but the audio is working now in linux-samus. There's some more documentation in the README, and I've submitted the package to AUR.
Offline
@tsowell
Consider to ask to adopt linux-chromebook instead of having separate package for the Pixel.
Offline
You're way more awesome than me. Well done, and thank you for your work so far.
Edit: That goes to basically everyone in this thread / forum, actually.
Last edited by TheCraiggers (2015-03-25 19:06:57)
Offline
tsowell, you are a god among men. Everything is working great!
One question, what is the best way to get sound to persist across reboots without having to run the "ALSA_CONFIG_UCM=ucm/ alsaucm -c bdw-rt5677 set _verb HiFi" command from the root of the directory every time?
Offline
@Hideaki, I use alsa-store.service and alsa-restore.service provided by alsa-utils: https://wiki.archlinux.org/index.php/Ad … nd_Systemd . It seems to work for everything except the master volume because of an issue with reading the master volume mixer control.
By the way, were you able to get suspend-on-lid-close working? I did some brief testing last night, and the only issue I noticed was a long delay sometimes because syncing to SD card is so slow.
Offline
@tsowell, sudo alsactl store did the trick, Thanks!
SD Card was totally the problem, I removed it and suspend on lid close works as expected.
I've been testing a few Type-C devices as well, Type-C Gigabit Ethernet adapter is working nicely, but I can't get the Type-C to HDMI cable to output anything, the monitor is detected in xrandr but nothing is displayed. I'll try the Type-C DisplayPort cable later to see if it works better.
Offline
Out of curiosity, did you guys set the GBB flags to enable SeaBIOS as default? If so, was disabling write-protect as big a pain in the ass as Google's device page suggests?
Offline
Out of curiosity, did you guys set the GBB flags to enable SeaBIOS as default? If so, was disabling write-protect as big a pain in the ass as Google's device page suggests?
I too am very interested in this. Just ordered my Pixel and I want to avoid the Ctrl-L hassle. I saw rumors that sometimes the write protect would be off because of say the screw was not fully tightened. Is there safe way to check if write protect is disabled before opening the device?
One thing I would like to know is what is minimally needed to avoid having the system wiped by mistake. Do we know what actions will cause a total drive wipe and stock reset? I don't like a scenario where an accidental keystroke on boot resets my whole machine.
Awesome work so far getting this working!
Offline
Another option is running Arch in a chroot, the same way Crouton (https://github.com/dnschneid/crouton) runs Ubuntu. I started https://github.com/gsf/archrome a while ago to try it out and liked it. I don't have a Pixel (yet!) but it's been tested on the Samsung and C720 chromebooks. PRs will be happily merged.
Offline
@gsf747 it's chroagh and it does works great.
@Razor X "# flashrom -V --wp-disable" should be safe enough as only tries to write to specific registers, notice that AFAIK this flag is supported only with Chrome/Chromium OS flashrom so it's highly recommended to do this in Chrome OS, if it didn't failed it means you disabled the software write protection (in other words the hardware write protection wasn't in effect).
You can confirm that software write protection is disabled with "# flashrom --wp-status", again, do this in Chrome OS, notice that this flag won't help you read the status of the hardware write protection (only a voltmeter can help with that).
p.s. this info already covered in the wiki at the custom firmware page and last time I read the GBB flags script I saw it does check with flashrom that the write protection is off before trying to write the flags but I would recommend testing the write protection status first before running the script.
Offline
I've been playing around with the Type-C ports some more, and I managed to get them to output video just fine, I'm not sur what I was doing wrong previously. 4K output over Google's Type-C to HDMI adapter works great!
Offline
@RazorX as far as I know, unless you're one of the lucky ones were the WP screw was left out or whatever, you're going to need to crack the case in order to get rid of the Scary White Screen (SWS). I was really, really hoping that they would have virtualized the WP screw like they did the dev switch by now. I can understand why they don't want to for security reasons, but what a pain in the ass this is. Especially on a pixel. Assuming the process to open the case is similar to the original Pixel, it's not at all "fun", and the case is never quite the same again...
It might not be so bad if Chromebooks didn't keep that switch in RAM, trashing your non-standard install upon empty battery.
Last edited by TheCraiggers (2015-03-30 18:02:36)
Offline
From what I've seen the new Pixel doesn't use the sticky glue stuff for the case so opening it should be better (I hope). I definitely don't want my system wiped unpredictably so I'll be going after that screw. Might still buy a suction cup and some professional plastic openers just to do it well. Plus I'll be sure to wear a grounding strap.
Offline
@tsowell
Finally had some spare time to mess with your scripts. Thanks a ton for your work on this. I wasn't able to get the AUR package to work (kept having compiler issues, up to and including an actual segfault in gcc) but the git version worked like a charm.
Offline
@Hideaki,
How were you able to get the DisplayPort adapter working? I've tried it in both USB-C ports, and my monitor is quite convinced that there is no signal coming from my computer.
Apparently the firmware in the adapter is flashed by ChromeOS. Is there any chance that you booted ChromeOS with the adapter plugged in? I'm wondering if you wound up initializing yours via ChromeOS by chance.
If not, I'm kind of at a loss for why it's not working for me.
Here's xrandr, with the cable plugged in:
Screen 0: minimum 8 x 8, current 2560 x 1700, maximum 32767 x 32767
eDP1 connected primary 2560x1700+0+0 (normal left inverted right x axis y axis) 272mm x 181mm
2560x1700 60.00*+
2048x1536 60.00
1920x1440 60.00
1856x1392 60.01
1792x1344 60.01
1600x1200 60.00
1400x1050 59.98
1280x1024 60.02
1280x960 60.00
1024x768 60.00
800x600 60.32 56.25
640x480 59.94
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Last edited by colemickens (2015-04-04 20:18:35)
Offline
Since my last post, I reinstalled Chrome OS, used the DisplayPort adapter successfully, reinstalled Arch and tried it again.
Still no luck. Maybe I should grab an HDMI adapter and give it a shot?
Offline
@colemickens
I've only tested the HDMI adapter under Arch and it worked pretty well. One strange thing I noticed that the monitor would only display an image if the adapter was plugged in a certain direction, otherwise I would be stuck in that same state you are in, in which the Pixel sees the correct EDID but the monitor receives no image. Maybe try to flip the Type-C plug?
I haven't tried the DP adapter recently. I have one at work, so I'll give it a try on Monday.
Offline
@colemickens
I've only tested the HDMI adapter under Arch and it worked pretty well. One strange thing I noticed that the monitor would only display an image if the adapter was plugged in a certain direction, otherwise I would be stuck in that same state you are in, in which the Pixel sees the correct EDID but the monitor receives no image. Maybe try to flip the Type-C plug?
I haven't tried the DP adapter recently. I have one at work, so I'll give it a try on Monday.
Hi, hope you don't mind a gentle ping to remind you to see if your DP adapter works.
Also, I'm not sure I'm seeing ANY indication from Linux that something has changed -- you mentioned seeing the right EDID, but I don't even think I'm getting that.
Thank you!
Offline
Hideaki wrote:@colemickens
I've only tested the HDMI adapter under Arch and it worked pretty well. One strange thing I noticed that the monitor would only display an image if the adapter was plugged in a certain direction, otherwise I would be stuck in that same state you are in, in which the Pixel sees the correct EDID but the monitor receives no image. Maybe try to flip the Type-C plug?
I haven't tried the DP adapter recently. I have one at work, so I'll give it a try on Monday.
Hi, hope you don't mind a gentle ping to remind you to see if your DP adapter works.
Also, I'm not sure I'm seeing ANY indication from Linux that something has changed -- you mentioned seeing the right EDID, but I don't even think I'm getting that.
Thank you!
I just finished testing it. I could not get any sort of output to come up over the Type-C to DisplayPort cable. Sorry about confusing you with the EDID bit. I was getting some behaviour on the Type-C to HDMI adapter in which I was receiving the correct EDID and xrandr was resizing my desktop to fit the external monitor, but not getting any output on said external monitor. I thought that that same behaviour was present on the Type-C to DP cable, but it is not, it simply does not see a monitor plugged in at all.
The Type-C to HDMI adapter continues to work for me, so long as it's plugged-in in a specific direction.
Offline
[inner quotes snipped for brevity]
I just finished testing it. I could not get any sort of output to come up over the Type-C to DisplayPort cable. Sorry about confusing you with the EDID bit. I was getting some behaviour on the Type-C to HDMI adapter in which I was receiving the correct EDID and xrandr was resizing my desktop to fit the external monitor, but not getting any output on said external monitor. I thought that that same behaviour was present on the Type-C to DP cable, but it is not, it simply does not see a monitor plugged in at all.
The Type-C to HDMI adapter continues to work for me, so long as it's plugged-in in a specific direction.
Interesting. I'm unfortunately at the extent of my debugging skills in this arena, and I'm not exactly full of ideas on where to ask for help next (other than #chromium on freenode). I might grab an HDMI adapter, but ultimately I'd really like to get the DP adapter working, so I can use MST to drive both of my monitors.
Thank you for confirming these details for me.
Last edited by colemickens (2015-04-06 23:45:49)
Offline
The usb-c to dp is working fine for me.
Offline
I narrowed it down a bit:
Linux + Dell monitor (with DisplayPort 1.2 / MST enabled) = BAD
Linux + Dell monitor (without DisplayPort 1.2 / MST enabled) = GOOD
ChromeOS + Dell monitor (with DisplayPort 1.2 / MST enabled) = GOOD
ChromeOS + Dell monitor (without DisplayPort 1.2 / MST enabled) = GOOD
edit: It's trickier than this:
If my Dell monitor has EVER been placed into DP1.2 mode, it must be factory reset in order to get video out from the adapter. (Which is a pain, because you can only access the menu to factory reset when there is signal out to the monitor).
Last edited by colemickens (2015-04-14 23:08:03)
Offline
Just got my pixel today and have a working install with LVM on LUKS. There is a lot more to customize, and I'll post here with more issues or tricks as I discover them. Once I get things working more I'll open it up to disable the write protect and start over.
One issue I ran into was a boot display issue. Basically the screen would stop output after "Welcome to GRUB". However, I figured out that GRUB loaded: if I press <enter>, wait, type my encryption passphrase, then press <enter>, it boots up fine.
By setting
GRUB_TERMINAL=console
in /etc/default/grub I get a normal GRUB menu I can interact with normally. However, once I select a boot option, I get
Loading Linux linux-samus ...
Loading initial ramdisk ...
The nothing else, but I can type my encryption passphrase and press <enter> to boot normally.
See here: https://i.imgur.com/u1BM54g.jpg
Any ideas?
Also, all the text is super tiny because of the high resolution: is there anyway to work at a "smaller" resolution that's not blurry? Maybe change the DPI or something? I'm not quite sure what the best approach here is.
Offline
Just got my pixel today and have a working install with LVM on LUKS. There is a lot more to customize, and I'll post here with more issues or tricks as I discover them. Once I get things working more I'll open it up to disable the write protect and start over.
One issue I ran into was a boot display issue. Basically the screen would stop output after "Welcome to GRUB". However, I figured out that GRUB loaded: if I press <enter>, wait, type my encryption passphrase, then press <enter>, it boots up fine.
By setting
GRUB_TERMINAL=console
in /etc/default/grub I get a normal GRUB menu I can interact with normally. However, once I select a boot option, I get
Loading Linux linux-samus ... Loading initial ramdisk ...
The nothing else, but I can type my encryption passphrase and press <enter> to boot normally.
See here: https://i.imgur.com/u1BM54g.jpg
Any ideas?
Also, all the text is super tiny because of the high resolution: is there anyway to work at a "smaller" resolution that's not blurry? Maybe change the DPI or something? I'm not quite sure what the best approach here is.
I also have graphical corruption after GRUB loads. I've not found anything to resolve it. GRUB loads, it boots the kernel, the screen flashes and a 1px tall multicolor flashes a few times at the top of the display and then systemd spits out some version info and boot continues.
GNOME will automatically turn on it's scaling functionality when it sees the Pixel's DPI. It's actually remarkably comfortable to use with the resolution doubled, now that the Dev versions of Chrome and Chromium support HiDPI as well. Plasma 2 / KF5 has some similar functionality, but it doesn't work nearly as well. For all other DEs, as far as I know, you have to just bump the font size and cross your fingers.
I'm running into another issue. Repeatedly, my Chromebook does not awake from sleep. Or awakes from sleep in a hung state. Or wakes up in my bag.
Worst of all, at times it appears to not power on, no matter what I do. If you get into this state, do the Three Finger Salute (Esc+Refresh+Power) and then when it prompts you to wipe it, just power it off again. Then it will boot normally the next time you press the power button. (Part of me wouldn't mind if it just shut off when I closed the lid instead of these awkward experiences like my original Pixel.)
Offline
Good to know it's not just me with the boot issue. I also had the weird colours at the top (obviously some distorted output). When I added that GRUB setting, the colours went away.
I haven't run into the sleep issue yet, but I haven't used it long enough to know.
For the scaling / fonts, I'll try bumping font sizes for my DE (awesome) and gtk apps, etc to see what I can do. I figured there might be some xrandr magic I could do, but if not, picking bigger fonts might just be better anyway.
I'm automating my entire system and user config in version control if anyone is interested:
https://github.com/razor-x/archrc
https://github.com/razor-x/dotfiles
Offline