search

denysvitali / linux-on-pixel-c

Documentation on how to run a Linux Distro on the Google Pixel C (2015)
MIT License
60 stars 5 forks source link

Graphics Acceleration Is Missing #2

Open denysvitali opened 7 years ago

denysvitali commented 7 years ago

Currently Linux on Pixel C is missing GPU Acceleration, therefore the UI is laggy dmesg is available here 

[root@alarm /]# cat /var/log/Xorg.0.log
[   899.733] 
X.Org X Server 1.19.3
Release Date: 2017-03-15
[   899.733] X Protocol Version 11, Revision 0
[   899.733] Build Operating System: Linux 3.14.65-16-ARCH aarch64 
[   899.733] Current Operating System: Linux alarm 4.13.0-rc4+ #13 SMP PREEMPT Wed Aug 9 20:46:38 UTC 2017 aarch64
[   899.733] Kernel command line: cros_secure vpr=0x08000000@0xf6800000 earlycon
[   899.733] Build Date: 13 August 2017  04:10:10PM
[   899.733]  
[   899.733] Current version of pixman: 0.34.0
[   899.733]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[   899.733] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   899.733] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 16 12:00:35 2017
[   899.734] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   899.734] (==) No Layout section.  Using the first Screen section.
[   899.734] (==) No screen section available. Using defaults.
[   899.734] (**) |-->Screen "Default Screen Section" (0)
[   899.734] (**) |   |-->Monitor "<default monitor>"
[   899.734] (==) No monitor specified for screen "Default Screen Section".
        Using a default monitor configuration.
[   899.734] (==) Automatically adding devices
[   899.734] (==) Automatically enabling devices
[   899.734] (==) Automatically adding GPU devices
[   899.734] (==) Automatically binding GPU devices
[   899.734] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   899.734] (WW) The directory "/usr/share/fonts/Type1/" does not exist.
[   899.734]    Entry deleted from font path.
[   899.734] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi/".
[   899.734]    Entry deleted from font path.
[   899.734]    (Run 'mkfontdir' on "/usr/share/fonts/100dpi/").
[   899.734] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi/".
[   899.734]    Entry deleted from font path.
[   899.734]    (Run 'mkfontdir' on "/usr/share/fonts/75dpi/").
[   899.734] (==) FontPath set to:
        /usr/share/fonts/misc/,
        /usr/share/fonts/TTF/,
        /usr/share/fonts/OTF/
[   899.734] (==) ModulePath set to "/usr/lib/xorg/modules"
[   899.734] (II) The server relies on udev to provide the list of input devices.
        If no devices become available, reconfigure udev or disable AutoAddDevices.
[   899.734] (II) Loader magic: 0x1207d4d20
[   899.734] (II) Module ABI versions:
[   899.734]    X.Org ANSI C Emulation: 0.4
[   899.734]    X.Org Video Driver: 23.0
[   899.734]    X.Org XInput driver : 24.1
[   899.734]    X.Org Server Extension : 10.0
[   899.736] (++) using VT number 7

[   899.736] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[   899.737] (II) xfree86: Adding drm device (/dev/dri/card0)
[   899.742] (II) no primary bus or device found
[   899.742]    falling back to /sys/devices/platform/50000000.host1x/drm/drm/card0
[   899.742] (II) LoadModule: "glx"
[   899.742] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   899.751] (II) Module glx: vendor="X.Org Foundation"
[   899.751]    compiled for 1.19.3, module version = 1.0.0
[   899.751]    ABI class: X.Org Server Extension, version 10.0
[   899.751] (==) Matched modesetting as autoconfigured driver 0
[   899.751] (==) Matched fbdev as autoconfigured driver 1
[   899.751] (==) Assigned the driver to the xf86ConfigLayout
[   899.751] (II) LoadModule: "modesetting"
[   899.751] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   899.751] (II) Module modesetting: vendor="X.Org Foundation"
[   899.751]    compiled for 1.19.3, module version = 1.19.3
[   899.751]    Module class: X.Org Video Driver
[   899.751]    ABI class: X.Org Video Driver, version 23.0
[   899.752] (II) LoadModule: "fbdev"
[   899.752] (WW) Warning, couldn't open module fbdev
[   899.752] (II) UnloadModule: "fbdev"
[   899.752] (II) Unloading fbdev
[   899.752] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   899.752] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   899.758] (II) modeset(0): using drv /dev/dri/card0
[   899.759] (II) modeset(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[   899.759] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[   899.759] (==) modeset(0): RGB weight 888
[   899.759] (==) modeset(0): Default visual is TrueColor
[   899.759] (II) Loading sub module "glamoregl"
[   899.759] (II) LoadModule: "glamoregl"
[   899.759] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[   899.761] (II) Module glamoregl: vendor="X.Org Foundation"
[   899.761]    compiled for 1.19.3, module version = 1.0.0
[   899.761]    ABI class: X.Org ANSI C Emulation, version 0.4
[   899.761] (II) glamor: OpenGL accelerated X.org driver based.
[   899.872] (II) glamor: EGL version 1.4 (DRI2):
[   899.872] EGL_MESA_drm_image required.
[   899.873] (EE) modeset(0): glamor initialization failed
[   899.873] (II) modeset(0): ShadowFB: preferred NO, enabled NO
[   899.873] (II) modeset(0): Output DSI-1 has no monitor section
[   899.873] (II) modeset(0): EDID for output DSI-1
[   899.873] (II) modeset(0): Printing probed modes for output DSI-1
[   899.873] (II) modeset(0): Modeline "2560x1800"x60.0  304.42  2560 2640 2720 2800  1800 1804 1808 1812 (108.7 kHz)
[   899.873] (II) modeset(0): Output DSI-1 connected
[   899.873] (II) modeset(0): Using sloppy heuristic for initial modes
[   899.873] (II) modeset(0): Output DSI-1 using initial mode 2560x1800 +0+0
[   899.873] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[   899.873] (==) modeset(0): DPI set to (96, 96)
[   899.873] (II) Loading sub module "fb"
[   899.873] (II) LoadModule: "fb"
[   899.874] (II) Loading /usr/lib/xorg/modules/libfb.so
[   899.874] (II) Module fb: vendor="X.Org Foundation"
[   899.874]    compiled for 1.19.3, module version = 1.0.0
[   899.874]    ABI class: X.Org ANSI C Emulation, version 0.4
[   899.874] (==) Depth 24 pixmap format is 32 bpp
[   899.897] (==) modeset(0): Backing store enabled
[   899.897] (==) modeset(0): Silken mouse enabled
[   899.897] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   899.897] (==) modeset(0): DPMS enabled
[   899.897] (--) RandR disabled
[   899.909] (II) AIGLX: Screen 0 is not DRI2 capable
[   899.909] (EE) AIGLX: reverting to software rendering
[   899.913] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
[   899.915] (II) IGLX: Loaded and initialized swrast
[   899.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[   899.915] (II) modeset(0): Damage tracking initialized
[   899.915] (II) modeset(0): Setting screen physical size to 677 x 476
[   900.025] (II) config/udev: Adding input device hid-over-i2c 06CB:3370 (/dev/input/event0)
[   900.025] (**) hid-over-i2c 06CB:3370: Applying InputClass "libinput touchscreen catchall"
[   900.025] (II) LoadModule: "libinput"
[   900.026] (II) Loading /usr/lib/xorg/modules/input/libinput_drv.so
[   900.029] (II) Module libinput: vendor="X.Org Foundation"
[   900.029]    compiled for 1.19.3, module version = 0.25.1
[   900.029]    Module class: X.Org XInput Driver
[   900.029]    ABI class: X.Org XInput driver, version 24.1
[   900.029] (II) Using input driver 'libinput' for 'hid-over-i2c 06CB:3370'
[   900.029] (**) hid-over-i2c 06CB:3370: always reports core events
[   900.029] (**) Option "Device" "/dev/input/event0"
[   900.029] (**) Option "_source" "server/udev"
[   900.030] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) is tagged by udev as: Touchscreen
[   900.031] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) device is a touch device
[   900.031] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) device removed
[   900.064] (**) Option "config_info" "udev:/sys/devices/platform/7000c000.i2c/i2c-0/0-0020/0018:06CB:3370.0001/input/input0/event0"
[   900.064] (II) XINPUT: Adding extended input device "hid-over-i2c 06CB:3370" (type: TOUCHSCREEN, id 6)
[   900.064] (**) Option "AccelerationScheme" "none"
[   900.064] (**) hid-over-i2c 06CB:3370: (accel) selected scheme none/0
[   900.064] (**) hid-over-i2c 06CB:3370: (accel) acceleration factor: 2.000
[   900.064] (**) hid-over-i2c 06CB:3370: (accel) acceleration threshold: 4
[   900.065] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) is tagged by udev as: Touchscreen
[   900.065] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) device is a touch device
[   900.066] (II) config/udev: Adding input device hid-over-i2c 06CB:3370 (/dev/input/mouse0)
[   900.066] (II) No input driver specified, ignoring this device.
[   900.066] (II) This device may have been added with another device file.
[   900.067] (II) config/udev: Adding input device gpio-keys (/dev/input/event1)
[   900.067] (**) gpio-keys: Applying InputClass "libinput keyboard catchall"
[   900.067] (II) Using input driver 'libinput' for 'gpio-keys'
[   900.067] (**) gpio-keys: always reports core events
[   900.067] (**) Option "Device" "/dev/input/event1"
[   900.067] (**) Option "_source" "server/udev"
[   900.068] (II) event1  - (II) gpio-keys: (II) is tagged by udev as: Keyboard Switch
[   900.068] (II) event1  - (II) gpio-keys: (II) device is a keyboard
[   900.068] (II) event1  - (II) gpio-keys: (II) device is a switch device
[   900.068] (II) event1  - (II) gpio-keys: (II) device removed
[   900.088] (**) Option "config_info" "udev:/sys/devices/platform/gpio-keys/input/input6/event1"
[   900.088] (II) XINPUT: Adding extended input device "gpio-keys" (type: KEYBOARD, id 7)
[   900.089] (II) event1  - (II) gpio-keys: (II) is tagged by udev as: Keyboard Switch
[   900.089] (II) event1  - (II) gpio-keys: (II) device is a keyboard
[   900.089] (II) event1  - (II) gpio-keys: (II) device is a switch device
[   900.884] (II) modeset(0): Disabling kernel dirty updates, not required.
[   914.720] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) device removed
[   914.756] (II) event1  - (II) gpio-keys: (II) device removed
[   915.900] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) is tagged by udev as: Touchscreen
[   915.900] (II) event0  - (II) hid-over-i2c 06CB:3370: (II) device is a touch device
[   915.901] (II) event1  - (II) gpio-keys: (II) is tagged by udev as: Keyboard Switch
[   915.901] (II) event1  - (II) gpio-keys: (II) device is a keyboard
[   915.901] (II) event1  - (II) gpio-keys: (II) device is a switch device
denysvitali commented 6 years ago

@vartom Oh, I see!
I missed the run_autogen part. Thank you!

Unfortunately when I build the rootfs w/ the ld.so.conf.d entry I'm not able to run gdm / lightdm anymore. Therefore we can't use the latest mesa for whatever reason.

vartom commented 6 years ago

@denysvitali This is because the mesa /Xorg is falling. And without software rendering.

denysvitali commented 6 years ago

@vartom I know, but I still haven't figured out why it does fail. I'm also having troubles while building mesa on Travis CI. Once that's fixed I'll be able to release reproduceable rootfs.

vartom commented 6 years ago

@thierryreding Build the kernel from next-20180316, with it it got even worse. now even the kmscube broke down. img_20180317_160509 img_20180317_160535

denysvitali commented 6 years ago

@vartom Have you tried this kernel image?

vartom commented 6 years ago

@denysvitali No. I did not begin to merge. It was easier to add patches for smaug.

Ps How can you explain the need to get native vendor files that are not compatible and are not requested by the mainline kernel?

vartom commented 6 years ago

I want to reproduce the same result as in this message. I can not find what went wrong.

denysvitali commented 6 years ago

@vartom I use them here: https://github.com/denysvitali/linux-smaug/blob/linux-4.17-next/arch/arm64/configs/dragon_denvit_defconfig#L1131
The most important ones are nvidia/tegra210/xusb.bin and nvidia/tegra210/vic04_ucode.bin binaries. Without them I cannot get the device to boot

vartom commented 6 years ago

@denysvitali It's easier to add them once in the form of a patch.

In addition, most of these files are searched for under other names in other directories, for example https://github.com/denysvitali/linux-smaug/blob/bfc7ad6f09eba9fb1f06ea2da8803affd447bf12/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c#L132

denysvitali commented 6 years ago

@vartom Sure thing, but they still are proprietary files which we don't have any license for. Therefore I'm pretty sure they cannot be legally added to the project (there is a TOS that needs to be accepted)

vartom commented 6 years ago

@denysvitali https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware/+/master/nvidia/

mirh commented 6 years ago

You technically cannot intertwine them very much with the kernel, but that's why you have the apposite linux-firmware package for all the blobs. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.nvidia

vartom commented 6 years ago

I really should try to build an arсhlinux with this package Package Details: mesa-git 18.1.0_devel https://aur.archlinux.org/packages/mesa-git/

A little information https://archlinuxarm.org/forum/viewtopic.php?f=49&t=12185&start=10#p57929

denysvitali commented 6 years ago

@vartom Good! We can try to makepkg during the rootfs build, and install it afterwards

vartom commented 6 years ago

Yesterday I did not manage to make the package. Perhaps we will wait for the release, if it includes support for tegra https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1014386-mesa-18-0-rc5-released-mesa-18-0-should-finally-be-out-on-friday

denysvitali commented 6 years ago

Unfortunately mesa-18 hasn't been tagged... yet. Let's wait for a release and see if it works.

vartom commented 6 years ago

@denysvitali this is not so important, in 18.0 there is still no support for tegra. I still can not assemble the installation package. All the time that something goes wrong. @denysvitali @Samt43 Can you try?

vartom commented 6 years ago

I can not find a solution to several errors. /usr/share/makepkg/util/pkgbuild.sh: line 69: /dev/fd/62: No such file or directory Another such error chmod: cannot access '/mnt/data/home/dima/Pc/rootfs/tegra-nouveau/out/target/aarch64/ArchLinuxArm/home/alarm/abs/mesa-full-tegra/pkg': No such file or directory ==> ERROR: A failure occurred in (). I create a pkg directory, during the execution of makepkg it is deleted and again gives an error that there is no this directory

PKGBUILD.txt

rakhenmanoa commented 6 years ago

Hi guys, i just wanted to know if one can use the tegra X1 linux driver https://developer.nvidia.com/embedded/dlc/l4t-jetson-tx1-driver-package-28-2-ga on pixel C. Thank you.

vartom commented 6 years ago

@rakhenmanoa As far as I know this driver can be used only with the appropriate kernel 28.2 (the driver in the kernel) for L4T from nvidia.

sharukins commented 6 years ago

Does the recently tagged mesa 18.1 RC support tegra?

q66 commented 6 years ago

yes, it appears to: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/tegra?h=mesa-18.1.0-rc1

as opposed to 18.0.1, which doesn't have the driver: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers?h=mesa-18.0.1

denysvitali commented 6 years ago

I'll try a new build tomorrow and report back the results 👍

rakhenmanoa commented 6 years ago

Hi guys, the group fail0verflow posted a Linux system for the Nintendo switch with accelerated graphics, there https://fail0verflow.com/blog/2018/shofel2/ Do you think it will work on Pixel C ?

denysvitali commented 6 years ago

Hey @rakhenmanoa! I noticed it too and I'm currently setting up the CI to generate a rootfs w/ the latest mesa, as suggested by @q66.

I'll report back soon: meanwhile you can check the build status here

q66 commented 6 years ago

@denysvitali btw, once the GPU stuff is confirmed working and Mesa 18.1 makes it into its package repository, I'll probably look into porting Void Linux arm64 onto my Pixel C (it frequently lies unused unless I'm traveling, I'd like to change that) - what's the current status of Bluetooth support? Still the same with latest 4.17-rc2 kernel as previously, i.e. not working? Additionally, is there any public discussion channel? (ideally on IRC)

denysvitali commented 6 years ago

@q66 Wonderful! I look forward to your contribution! I created the Linux On Pixel C Organization on GitHub and I plan to switch to it in the newr future, because this project isn't only mine.
If you want to be part of the organization I can add you as a member.

The current bluetooth support is being tracked in #10. At the moment the brcm4354 works just for the Wi-Fi (= Standard Bluetooth and BTLE doesn't work).

I haven't tried the latest 4.17-rc2 kernel, but I'm planning to. Theoretically speaking a kernel build is already ready (but not yet tested) here (and yes, that release name is ugly. I need to fix my CI)

There is currently no public discussion channel, but I've just created a Telegram group which can be found here
We can create an IRC channel on freenode and link the two. If you want to create it and moderate it you can do it :)

In the following hours I'll test the new kernel, and try to fix my CI. I'll then generate a better rootfs w/ the newest mesa 18.1

Hopefully I'll find some time to migrate / imolement the CI on the pixelc-linux organization.
Curently I'm using both Travis-CI and Jenkins (hosted at jenkins.ded1.denv.it). pixelc-linux members have the permissions to edit and run jobs on that istance as they wish

q66 commented 6 years ago

Alright. I created a #linux-on-pixel-c channel on freenode; if you want to get a relay bot in there or something, go ahead. I'll register the channel with chanserv in the meantime. And I guess it's a good idea to start looking into TWRP'ing my Pixel C and setting up Android tools (adb/fastboot) on my FreeBSD workstation and perhaps a Linux VM for building.

thierryreding commented 6 years ago

Everyone is welcome to join the #tegra channel on Freenode. Its focus is on upstream Linux development and most people involved with upstream Linux development on Tegra hang out there, so I it should be a good fit for what you're trying to achieve.

denysvitali commented 6 years ago

Btw, we now have a Telegram group which is linked to the #linux-on-pixel-c channel on Freenode. We'll discuss there about the project. Every progress we make will be published / described in the respective issue (on this project).

We'll eventually migrate to @pixelc-linux in the near future, in the meantime we'll keep the discussions here, on Telegram and on Freenode.

@thierryreding Thanks! I'll make sure to check out the #tegra channel!

vartom commented 6 years ago

The kernel 4.17-rc2 does not correctly display the image on the screen. Just like the kernel of Next-20180316, which I mentioned earlier.

denysvitali commented 6 years ago

@vartom What do you mean by "does not correctly display the image on the screen"? Are there glitches?
I personally tried w/ one of the recently tagged builds (for example this one) which use the Google provided tegra blobs, and it seems to work fine. Acceleration is still missing though because I wasn't able to build mesa 18.1 yet (I'm still having some problems w/ my Jenkins pipeline - I'll have to fix them when I have more free time)

vartom commented 6 years ago

the logs are displayed correctly. The problem manifests itself when the image forms a GPU. turn on the utility kmscube or take my rootfs with working acceleration.

vartom commented 6 years ago

@denysvitali I do not understand your persistence in using Google blobs. They will not work with the mainline kernel. Using them you will not get hardware video acceleration!

ps Conducted an elementary comparison of files by content. In the directory nvidia / tegra210 all files that are used by the mainline kernel (from Linux-firmware) are the same as those from Google. The files in the firmware / new file directory are the same as the files located in the firmware / nvidia / gm20b / gr / directory, but they have different names.

Perhaps the mainline kernel can use old blob names, or maybe not.

denysvitali commented 6 years ago

@thierryreding

This is the email that @vartom has wrote you today. I pasted it here with his permission in order to keep the discussion public, so that everyone can help / be helped.

Hello. I have already noted in the subject Graphics Acceleration Is Missing #2 that since the kernel is next from 03/16/18 the image has become spoiled on the screen. So I dropped some videos with a problem in the telegram group https://t.me/joinchat/AMCvfg2mCMNEQHJxvFzf2Q Today I found out for what patch this happens. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/tegra?id=4ae4b5c0dbaa499f2fd9215caac6e474c8dd477f I tested it in the kernel and in the kernel 4.17. Without this patch, the image remains normal. Could you double-check this patch and fix it?

cc/ @vartom, @q66, @nvidia

denysvitali commented 6 years ago

This is what happens: img_20180504_123827

PixelCUser commented 6 years ago

Hello denysvitli, Can you please put a package together for me that allows me to flash linux with gpu acceleration to my pixel c, in this forum post ive seen you get gpu acceleration to work so congrats on that, i would like to test your linux build for the pixel c, im not a linux developer or someone who can port linux to android like you 😄 but i just want to try linux on my tablet< Thanks :P

q66 commented 6 years ago

You will have to wait until our infra is properly up, I guess. Which hopefully shouldn't take long at this point...

PixelCUser commented 6 years ago

Ok cool, im currently actually installing the available build of linux for the pixel c but i ran in to a problem, the cache partition isn't big enough to store the latest rootfs tar

denysvitali commented 6 years ago

@PixelCUser Just copy the rootfs over /sdcard

Btw, please, let's not go off topic here. If you're having some troubles installing a Linux Distro on your Pixel C, feel free to open a new issue. This is specifically related to the graphic acceleration issues we're facing.

In a couple of days we'll probably have a better way to deliver updated versions of our rootfs and kernel images, so that it will be easier for everyone to install a Linux Distro on their Pixel C.
If you want to be informed about the changes, click "Watch" on this repo to be notified of all the changes, or join our Telegram group at https://telegram.me/pixelclinux / IRC channel on Freenode #linux-on-pixel-c

Edit: Fix Telegram Link, thanks @mirh