Jump to content

Photo

HOWTO: Bodhi on Samsung Chromebook


  • Please log in to reply
45 replies to this topic

#41 Seekamp

Seekamp

    Chromebook Wizard

  • Developer
  • 84 posts
  • LocationSouth Florida

Posted 02 March 2014 - 09:49 PM

Then does the driver require some trick to enable the acceleration? I am stuck with mesa's software rendering.

libGL error: failed to load driver: armsoc
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
When I try to run a game.

libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/tls/armsoc_dri.so
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so
libGL error: dlopen /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying ${ORIGIN}/dri/tls/armsoc_dri.so
libGL: OpenDriver: trying ${ORIGIN}/dri/armsoc_dri.so
libGL error: dlopen ${ORIGIN}/dri/armsoc_dri.so failed (${ORIGIN}/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib/dri/tls/armsoc_dri.so
libGL: OpenDriver: trying /usr/lib/dri/armsoc_dri.so
libGL error: dlopen /usr/lib/dri/armsoc_dri.so failed (/usr/lib/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: armsoc_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: armsoc
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so
After addition of the LIBGL_DEBUG=verbose flag.

I am not sure how you installed the driver. I will tell you the easiest way to do it, assuming you installed the recent Bodhi Chromebook image using the testing repository:
  • Download the X11 driver from here to either your home directory or ~/Downloads. Do not extract it. Leave it as a .tgz file.
  • Execute the command: sudo install_mali_x11. It will install the driver in a particular place and do needed links that, if not done, prevent the driver from being utilized properly
If you do that, to switch to the Mali libraries first use Ctrl-Alt-F1 to switch to a virtual terminal and log in. Then issue the command:
sudo switch_x11_libs mali

Now it is best to reboot.

Now, after rebooting, you can verify that it is using the Mali libraries by executing the command
es2_info
within a terminal window (like terminology)

You should also be able to use OpenGL compositing within e.

Regarding games, I haven't tried any. There are clearly limitations to the OpenGL support, especially with the Chrome OS 3.4.0 kernel being used. Also, there is no armsoc_dri.so, DRI support is built in. So if you install and set up the libraries properly, you can ignore warnings about that missing.
--Chris



A big thank you to everyone who contributes to Bodhi Linux


#42 Hirage

Hirage

    Member

  • Members
  • 3 posts

Posted 03 March 2014 - 12:25 PM

Everything in the quote may have been based on wrong assumption.

Thank you.
I am both happy and sad now.
Happy because I just did not know about those couple of steps and it looks like the working driver is just out my reach now.
I am sad because it looks like the instructions apply to the "wheezy" version of Xserver.

The following packages have unmet dependencies:
 xserver-xorg-video-armsoc : Depends: xorg-video-abi-12 which is a virtual package.
In my previous installation (I just reinstalled to clean up the system) I have forced installation of xserver packages from wheezy repo.

And I just realized one stupid mistake on my part - I did not do glxinfo | grep OpenGL in last - the most important one -.- .

After that I got display server flashing when I was moving the cursor around.

Now I think it was the Mali driver breakage thanks to some unmet dependency, that I was no longer in soft render...

Would it be a lot of effort to bump the video-armsoc up to compatibility with xorg-video-abi-14 or whichever is in jessie now? I believe it is a better path than having an outdated xserver.

Should I try to reproduce the broken desktop from my previous installation and get more diagnostic information? Any logs you would be interested in? Maybe you know which packages specifically should I downgrade to wheezy?

I just may not able to tap into the driver properly.
$ es2_info
[PLUGIN INFO] Plugin initializing
[PLUGIN DEBUG]  './override.instr_config' not found, trying to open the process
config file
[PLUGIN DEBUG]  './es2_info.instr_config' not found, trying to open the default
config file
[PLUGIN ERROR] Couldn't open default config file './default.instr_config'.
[PLUGIN INFO] No configuration file found, attempting to use environment
[PLUGIN INFO] CINSTR GENERAL: Output directory set to: .
[PLUGIN INFO] No instrumentation features requested.
EGL_VERSION: 1.4 Midgard-"r3p0-02rel0"
EGL_VENDOR: ARM
EGL_EXTENSIONS:
    EGL_KHR_config_attribs, EGL_KHR_image, EGL_KHR_image_base,
    EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_ARM_pixmap_multisample_discard,
    EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_renderbuffer_image,
    EGL_KHR_create_context, EGL_KHR_surfaceless_context,
    EGL_KHR_gl_texture_cubemap_image, EGL_KHR_image_pixmap
EGL_CLIENT_APIS: OpenGL_ES
GL_VERSION: OpenGL ES 3.0
GL_RENDERER: Mali-T604
GL_EXTENSIONS:
    GL_ARM_rgba8, GL_ARM_mali_shader_binary, GL_OES_depth24,
    GL_OES_depth_texture, GL_OES_depth_texture_cube_map,
    GL_OES_packed_depth_stencil, GL_OES_rgb8_rgba8, GL_EXT_read_format_bgra,
    GL_OES_compressed_paletted_texture, GL_OES_compressed_ETC1_RGB8_texture,
    GL_OES_standard_derivatives, GL_OES_EGL_image, GL_OES_EGL_image_external,
    GL_OES_EGL_sync, GL_OES_texture_npot, GL_OES_vertex_half_float,
    GL_OES_required_internalformat, GL_OES_vertex_array_object,
    GL_OES_mapbuffer, GL_EXT_texture_format_BGRA8888, GL_EXT_texture_rg,
    GL_EXT_texture_type_2_10_10_10_REV, GL_OES_fbo_render_mipmap,
    GL_OES_element_index_uint, GL_EXT_shadow_samplers, GL_KHR_debug,
    GL_EXT_occlusion_query_boolean, GL_EXT_blend_minmax,
    GL_EXT_discard_framebuffer, GL_OES_get_program_binary, GL_OES_texture_3D,
    GL_EXT_texture_storage, GL_EXT_multisampled_render_to_texture,
    GL_OES_surfaceless_context, GL_ARM_mali_program_binary
Right now everything in my system seems to fall back to swrast by mesa. Even after following your instructions. So now I am starting to think I need to launch programs with some env var set up in order to utilize the Mali driver. I have no idea how that var is supposed to look like, though.

Time passes...

Just found a proof for my latest theory.
https://bugs.launchp...596/comments/22
When run with --use-gl=egl, chromium-browser does report in chrome://gpu that GL_RENDERER=Mali-T604 .
Later I will try to make Flash use HW acceleration, but for now I have to log out to life.

#43 saturn

saturn

    Member

  • Members
  • 3 posts

Posted 30 April 2014 - 06:41 AM

It's my first post on the board and I want to say thank you to all the guys at Bodhi Linux for their great work. I've recognized that the official support for arm is dropped. Never the less I tried the chromebook image and the first impression is very positive. I have chrubuntu on the chromebook and the GUI of Bodhi Linux fits to my demands on such a device.

Whats the point? After a update and dist-upgrade the xorg system is broken, due to a incompatibility between the glx module and the x server.

What I've done:

1) download the installer under Chromeos
2) chmod +x the installer
3) start the installation: sudo bash XXXX.sh /dev/mmcblk1
4) installation and reboot went fine
5) configuration: locales, keyboard, timezone
5) update: sudo apt-get update & apt-get dist-upgrade with no errors
6) after reboot I'm in the cli and starting the xorg system (startx/ Enlightenment_start) stops with an error
7) xorg.0.log: version mismatch between glx and x server, major numbers are different (14 vs 15?)

Question:
1) my solution is to pin the xorg system before the dist-upgrade. Is this the right way to go?
2) Due to the fact that the support for armhf is dropped, will errors like this one be fixed in the near future?

Thank you in advance.

Kind regards

Alexander

#44 Jeff

Jeff

    Lead Developer

  • Developer
  • 12328 posts
  • LocationBloomington, IL

Posted 30 April 2014 - 12:50 PM

Unless seekamp finds time to try and fix this there won't be an update. Pinning xorg is a good solution.

#45 saturn

saturn

    Member

  • Members
  • 3 posts

Posted 30 April 2014 - 03:15 PM

Unless seekamp finds time to try and fix this there won't be an update. Pinning xorg is a good solution.



#46 saturn

saturn

    Member

  • Members
  • 3 posts

Posted 30 April 2014 - 03:17 PM

Thank you for your answer.

Alexander




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users