Touchscreen not working on Chromebook Pixel 2013 (R72 Special)

[owenrw]

Using Special Build R72-11316.B the touchscreen is not working on Chromebook Pixel (2013).

Running evtest doesn't list the touchscreen as an input device.

[ryanbin7]

@owenrw I'm running the latest vanilla build on the 2013 CB Pixel and the touchscreen works fine. Have you tried the vanilla build, or is there some reason you went for the special build? It doesn't give any additional functionality on the Pixel that I'm aware of.

[owenrw]

Apologies for the delayed response... I tried the vanilla build with the same issue.
It works fine in regular ChromeOS though.

I have since updated the firmware on the Pixel to be Mr Chromebox's Full UEFI ROM.

I can also report that the touchscreen doesn't work using the Mr Chromebox + Vanilla (or Special) combination.

[ryanbin7]

@owenrw I'm also running MrChromebox firmware and vanilla and (as I said) the touchscreen works fine, so I don't think it's an issue with Arnold's builds.

What's the output of evtest in crosh (mine is below).

crosh> evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0: Sleep Button
/dev/input/event1: Sleep Button
/dev/input/event2: Lid Switch
/dev/input/event3: Power Button
/dev/input/event4: Video Bus
/dev/input/event5: AT Translated Set 2 keyboard
/dev/input/event6: Atmel maXTouch Touchscreen
/dev/input/event7: Atmel maXTouch Touchpad
/dev/input/event8: HDA Intel PCH Front Line Out
/dev/input/event9: HDA Intel PCH Line Out
/dev/input/event10: HDA Intel PCH Front Headphone
/dev/input/event11: HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event12: HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event13: HDA Intel PCH HDMI/DP,pcm=8

[owenrw]

@ryanbin7 The touchscreen works (or worked) fine in ChromeOS before I installed Chromium.

Running evtest, I can see that the Touchscreen isn't listed, which is curious... I'm open to suggestions?

crosh> evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0: Sleep Button
/dev/input/event1: Sleep Button
/dev/input/event2: Lid Switch
/dev/input/event3: Power Button
/dev/input/event4: Video Bus
/dev/input/event5: AT Translated Set 2 keyboard
/dev/input/event6: Atmel maXTouch Touchpad
/dev/input/event7: HDA Intel PCH Front Line Out
/dev/input/event8: HDA Intel PCH Line Out
/dev/input/event9: HDA Intel PCH Front Headphone
/dev/input/event10: HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event11: HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event12: HDA Intel PCH HDMI/DP,pcm=8

[owenrw]

@ryanbin7 To provide a follow-up, I reinstalled both the stock firmware and the stock ChromeOS and the touchscreen does, in fact, work fine.

The output of evtest is:
crosh> evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Power Button
/dev/input/event2: Sleep Button
/dev/input/event3: Sleep Button
/dev/input/event4: Power Button
/dev/input/event5: Video Bus
/dev/input/event6: AT Translated Set 2 keyboard
/dev/input/event7: Atmel maXTouch Touchpad
/dev/input/event8: Atmel maXTouch Touchscreen
/dev/input/event9: HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event10: HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event11: HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event12: HDA Intel PCH Mic
/dev/input/event13: HDA Intel PCH Headphone

Are you using the full firmware from MrChromebox, or just using the legacy boot option?

[ryanbin7]

@owenrw I flashed the full firmware. I'm not sure why that would make a difference though. The driver for the touchscreen should get loaded with the kernel.

[owenrw]

@ryanbin7 I can confirm, having re-installed the full MrChromebox firmware and Vanilla 72.0.3626.122 that the touchscreen is not working and is absent, once again, from the evtest output.

As you note, if the driver should be being loaded, it isn't... so I think this is a bug in the build (although I don't know where to suggest...)

In case it makes a difference, I have the 64GB/LTE Pixel.

[ryanbin7]

@owenrw Are you installing Vanilla 72.0.3626.122 from this file: Camd64OS_R72-11316.B-Vanilla.7z currently up on the website? I also have 72.0.3626.122, but didn't install it directly from that file. I upgraded (using the dev server) from a previous version that was on the website back in January. I know Arnold changes that file when there are only minor updates, and I just checked the file sizes and they aren't the same, so the versions definitely are different.

That's the only thing I can think of that would be different between yours and mine. I'm happy to attach the file I used if you want to give it a whirl.

[ryanbin7]

@owenrw Random thought looking at the evtest outputs from our machines: do you have some kind of external headset (mic/headphone plugged in)? Notice how our devices are listed differently (mine says line out, front line out and headset; yours says mic and headphone). If so, maybe that is causing some sort of conflict when it goes to load the drivers?

[owenrw]

@ryanbin7 No, nothing plugged in or attached.
I can confirm I'm using the file from March 10 on the website. I redownloaded it to check against the version I have on my machine and they are the same size and hash.

If you can wing over the file you used, I'll give that a go and report back.

[ryanbin7]

Nevermind that last comment; was looking at the evtest ouput from ChromeOS, not Chromium. Your Chromium output looks the same, except for the missing touchscreen. File is on its way (hopefully it lets me upload it here).

[ryanbin7]

@owenrw Had to upload it to google drive. Here you go:

Camd64OS_R72-11316.B-Vanilla.7z

[owenrw]

@ryanbin7 That doesn't work either, which is pretty frustrating. The touchscreen is never listed in evtest and touching the screen doesn't do anything.

Doing a little more digging, there are a couple of curious things in DMESG, which may (or not be related).

This is the first interesting thing:

[    0.360158] ACPI Warning: SystemIO range 0x0000000000000528-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x00000000000005
7F (\PMIO) (20170728/utaddress-238)
[    0.360166] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    0.360170] ACPI Warning: SystemIO range 0x00000000000004C0-0x00000000000004CF conflicts with OpRegion 0x0000000000000480-0x00000000000004
EB (\GPIO) (20170728/utaddress-238)
[    0.360175] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    0.360177] ACPI Warning: SystemIO range 0x00000000000004B0-0x00000000000004BF conflicts with OpRegion 0x0000000000000480-0x00000000000004
EB (\GPIO) (20170728/utaddress-238)
[    0.360182] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    0.360183] ACPI Warning: SystemIO range 0x0000000000000480-0x00000000000004AF conflicts with OpRegion 0x0000000000000480-0x00000000000004
EB (\GPIO) (20170728/utaddress-238)
[    0.360188] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    0.360189] lpc_ich: Resource conflict(s) found affecting gpio_ich.

The second interesting thing, which seems more likely to be related is this:

[    0.432236] atmel_mxt_ts 1-004b: GPIO lookup for consumer reset
[    0.432242] atmel_mxt_ts 1-004b: using lookup tables for GPIO lookup
[    0.432246] atmel_mxt_ts 1-004b: lookup for GPIO reset failed
[    0.472108] atmel_mxt_ts 1-004b: Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22
[    0.526204] atmel_mxt_ts 1-004b: Direct firmware load for maxtouch.cfg failed with error -2
[    0.539079] cros_ec_lpcs GOOG0004:00: bad packet checksum f2
[    0.541110] cros_ec_lpcs GOOG0004:00: MKBP not supported
[    0.543105] cros-ec-dev cros-ec-dev.1.auto: cannot get EC features: 0/1
[    0.543125] cros-ec-dev cros-ec-dev.1.auto: EC does not have accelerometers.
[    0.550099] atmel_mxt_ts 1-004b: Touchscreen size X2040Y1360

This seems to me to strongly suggest that the driver isn't loading, although i'm not clear why as the touchscreen definitely works under Stock everything.

What version of the MrChromebox firmware are you running? According to DMESG, I'm using:

[ 0.000000] DMI: GOOGLE Link/Link, BIOS MrChromebox-4.9 01/13/2019

[ryanbin7]

My boot messages look pretty similar to yours (see attached messages.txt).

One thing I noticed, after the final line in the logs you pasted (Touchscreen size X2040Y1360), is there another line about the touchscreen? Here's my next line:

INFO kernel: [ 0.626262] input: Atmel maXTouch Touchscreen as /devices/pci0000:00/0000:00:02.0/i2c-2/2-004a/input/input6

Also, I'm running an older version of MrChromebox:
INFO kernel: [ 0.000000] DMI: GOOGLE Link/Link, BIOS MrChromebox 08/27/2018

[owenrw]

Nothing more related to the touchscreen. The next line is adding the trackpad as input6:

[ 0.550261] input: Atmel maXTouch Touchpad as /devices/pci0000:00/0000:00:02.0/i2c-1/1-004b/input/input6

It seems like the difference / problem must be driven by the firmware, but whether it's a firmware or driver bug is unclear.

I wonder if the 08/27/2018 firmware is still available...

[ryanbin7]

Unfortunately, it doesn't look like it:

MrChromebox/scripts#73

I wish it was a file I could send you, but it runs directly from his script. You could try opening up an issue with him. He seems pretty responsive.

There's also the SeaBIOS firmware from John Lewis:

https://johnlewis.ie/custom-chromebook-firmware/rom-download/

For a comparison of the two, see this (from a GalliumOS page but applies here too):

https://wiki.galliumos.org/Firmware

I'm just reluctant to have you replace the firmware without being sure. Would hate to see you brick the thing.

[owenrw]

I've opened an issue with MrChromebox, so I'll see if he responds.

If not, I'll try and track down the older version of the ROM, and/or try with John Lewis' ROM and see if that works.

Hopefully I won't brick it, I'm thinking if I always restore to stock beforehand, rather than try and switch between firmwares, it may be more successful.

[ryanbin7]

Sounds like a good plan. Let me know how it goes and if you need me to test anything.

[owenrw]

@ryanbin7 It seems that MrChromebox doesn't think this is a bug, given that it works for him on Mint 19.1.

I also tried Mint 19.1, and the touchscreen works fine, which lends some credence to his view, however just because it works doesn't mean there isn't a bug somewhere. I mean, you're running a previous release and it works fine, I'm running the latest release and it doesn't, so there is a bug somewhere.

If we assume it's not a bug in the firmware, that means it's a bug in Chromium (however, I tried earlier editions of Chromium and it doesn't work in those either).

Can you try dumping the firmware from your Pixel and sending it to me? You should be able to do so with sudo /usr/sbin/flashrom -r <output.bin>

I tried flashing John Lewis' firmware, however it fails to flash either with his script or using Flashrom manually.

[ryanbin7]

Cool, didn't even know you could do that. Here you go:

OldMrChromebox

[owenrw]

Thanks for that. I flashed it and now I have a working touchscreen!

Although MrChromebox doesn't seem to think it's a firmware bug, there is definitely an issue somewhere as with the older firmware the touchscreen works fine.

[ryanbin7]

Great news! And glad I could help. Good to know about the firmware. I won't be upgrading mine anytime soon.

Happy touchscreening!

[owenrw]

In case you're curious, MrChromebox has identified the issue and is going to fix it in v4.10, when that becomes available.

Seems like it's a quirk of the hardware causing the issue, which is interesting, and good to get a resolution.

[ryanbin7]

@owenrw Thanks for letting me know about the firmware fix. Off topic: you've probably noticed that the Pixel keyboard backlight keys don't work in Chromium. If you haven't already found a workaround, a quick fix is to adjust the brightness from the command line:

sudo echo "0" > /sys/class/leds/chromeos::kbd_backlight/brightness

Just replace 0 with whatever you want the brightness to be. Max brightness is stored in /sys/class/leds/chromeos::kbd_backlight/brightness/max_brightness to give you the scale (mine is 100).

I never use the keyboard backlight and it drains the battery so I turn it off automatically at startup. To do that, just add a line to /etc/init//etc/init/pre-startup.conf (mine is attached for reference: pre-startup.zip).

[owenrw]

That's useful... I noticed that the backlight couldn't be controlled, so that's a pretty helpful command to note.

I'll probably turn it off on startup too, as I don't need it, and then alias the command in the shell on the off chance I need to use it in the dark.

[MrChromebox]

Although MrChromebox doesn't seem to think it's a firmware bug, there is definitely an issue somewhere as with the older firmware the touchscreen works fine.

found the issue, will be fixed in next firmware release (shortly after coreboot 4.10 is tagged)

[ryanbin7]

Thank you, @MrChromebox. Much appreciated!