Using Ozone and linux kernel framebuffer device

[Christian Schwarzgruber]

Hi,

I have a question regarding ozone and the Linux framebuffer device.
Our target device does not use a window manager like X11, Wayland etc..
Instead we wrote a Linux kernel patch to draw UIs with our  framework directly (more or less) to the Linux framebuffer device.
Now we want render websites on this targed device, however it seems it is not possibly to run Chromium or WebKit on this device without a window manager,
without modification in the chromium project.

I know that chromium embedded framework supports off-screen rendering, but again to compile chromium/cef for our arm Linux target platform we must also
compile GTK+, X11 etc. but that is far to big (overkill).

So my question is, would it be possibly to use ozone to write directly to the Linux framebuffer device without the need of GTK+ etc?

In our case X11 is definitely no solution, however Wayland would be if it can access the Linux framebuffer device.

Any info or help would be appreciated.

Thank you for your help!

[Michael Spang]

On Thu, May 22, 2014 at 7:43 AM, Christian Schwarzgruber
<c.schwarz...@gmail.com> wrote:
> Hi,
>
> I have a question regarding ozone and the Linux framebuffer device.
> Our target device does not use a window manager like X11, Wayland etc..
> Instead we wrote a Linux kernel patch to draw UIs with our framework
> directly (more or less) to the Linux framebuffer device.
> Now we want render websites on this targed device, however it seems it is
> not possibly to run Chromium or WebKit on this device without a window
> manager,
> without modification in the chromium project.
>
> I know that chromium embedded framework supports off-screen rendering, but
> again to compile chromium/cef for our arm Linux target platform we must also
> compile GTK+, X11 etc. but that is far to big (overkill).
>
> So my question is, would it be possibly to use ozone to write directly to
> the Linux framebuffer device without the need of GTK+ etc?

Yes, that is possible. Ozone builds don't have any dependency on GTK
or X11, and can render directly to hardware. You will need to write
code to present chromium's composited output to your framebuffer,
however.

If your device has DRM/KMS support, it is a bit easier since you you
can just use the "dri" ozone platform.

>
> In our case X11 is definitely no solution, however Wayland would be if it
> can access the Linux framebuffer device.

For wayland, you might need to port weston to your device or write
your own wayland compositor. After that, you should be able to use the
wayland support being built at https://github.com/01org/ozone-wayland

>
> Any info or help would be appreciated.
>
> Thank you for your help!

Michael

[Christian Schwarzgruber]

Hello Michael,

 

that are fantastic news.

 

> Yes, that is possible. Ozone builds don't have any dependency on GTK

> or X11, and can render directly to hardware. You will need to write

> code to present chromium's composited output to your framebuffer,

> however.

 

Do you know where those chromium specific stuff is, so I can read through the code?

 

> If your device has DRM/KMS support, it is a bit easier since you you

> can just use the "dri" ozone platform.

 

Well, if it hasn't support for DRM/KMS than we will definitely at those modules.

 

> > In our case X11 is definitely no solution, however Wayland would be if it

> > can access the Linux framebuffer device.

>

> For wayland, you might need to port weston to your device or write

> your own wayland compositor. After that, you should be able to use the

> wayland support being built at https://github.com/01org/ozone-wayland

 

If I understand this correctly, as you pointed out that we can directly render to hardware,

does this mean that we do not even need a window manager at all and we have "not" to

write code to tell chromium where it should present the composited output, when we

compile ozone with “dri” flag set.

 

 

I have also some generic question about building chromium/ozone with gyp (GYP is completely new to me).

When we build ozone will chromium also be build or do we have to link it some how,

or can this all be controlled through GYP_DEFINES?

 

Thank you so much for your help,

 

Best regards, Christian

 

[Robert Kroeger]

On Thursday, May 22, 2014, Christian Schwarzgruber <c.schwarz...@gmail.com> wrote:

Hello Michael,

 

that are fantastic news.

 

> Yes, that is possible. Ozone builds don't have any dependency on GTK

> or X11, and can render directly to hardware. You will need to write

> code to present chromium's composited output to your framebuffer,

> however.

 

Do you know where those chromium specific stuff is, so I can read through the code?

For reference: https://code.google.com/p/chromium/codesearch#search/&q=Ozone&sq=package:chromium&type=cs

You would need to implement SurfaceFactoryOzone, use the PlatformOzone implementation to register it and provide an implementation of one of the ozone surface types as appropriate to your device.

 

 

> If your device has DRM/KMS support, it is a bit easier since you you

> can just use the "dri" ozone platform.

 

Well, if it hasn't support for DRM/KMS than we will definitely at those modules.

 

> > In our case X11 is definitely no solution, however Wayland would be if it

> > can access the Linux framebuffer device.

>

> For wayland, you might need to port weston to your device or write

> your own wayland compositor. After that, you should be able to use the

> wayland support being built at https://github.com/01org/ozone-wayland

 

If I understand this correctly, as you pointed out that we can directly render to hardware,

does this mean that we do not even need a window manager at all and we have "not" to

write code to tell chromium where it should present the composited output, when we

compile ozone with “dri” flag set.

Chrome compiled with dri=1 expects to run on and control the entire contents of the framebuffer. So, no window manager or server.

 

 

 

I have also some generic question about building chromium/ozone with gyp (GYP is completely new to me).

When we build ozone will chromium also be build or do we have to link it some how,

or can this all be controlled through GYP_DEFINES?

Ozone is a component of Chrome. Build Chrome. Or content_shell and the right gyp flags will drag along all the necessary dependencies.

http://www.chromium.org/developers/design-documents/ozone provides some sparse getting-started info for ozone specifically.

Rob.

[mo...@lukup.com]

Hello people,

Has anyone here completed CEF porting with ozone for linux framebuffer device? with aura or lite windowing systems?

We are evaluating whether to port
pretty old WebKitDFB codebase (and update it, already done the POC)

http://git.directfb.org/?p=libs/WebKitDFB.git;a=summary

or updated CEF at
https://github.com/kuscsik/chromiumembedded

on man- hour/complication requirements and system performance.

Any help/insight would be great...


Thanks!

[Alex Sakhartchouk]

Could you give us a bit more context on what you are ultimately trying to accomplish? Are you aiming for SW or HW rendering, etc.?

Our ozone platform drm is probably the closest to what you are trying to do. https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/ 

We render Chrome one buffer at a time and present it using libdrm. Aura is used in chrome, but there is no external window manager in the system. It's fairly battle hardened at this point as it's what we ship on a lot of ChromeOS devices.

On Fri, Jun 12, 2015 at 6:10 AM, <mo...@lukup.com> wrote:

Hello people,

Has anyone here completed CEF porting with ozone for linux framebuffer device? with aura or lite windowing systems?

We are evaluating whether to port
pretty old WebKitDFB codebase (and update it, already done the POC)

http://git.directfb.org/?p=libs/WebKitDFB.git;a=summary

or updated CEF at
https://github.com/kuscsik/chromiumembedded

on man- hour/complication requirements and system performance.

Any help/insight would be great...


Thanks!

We are here evaluating website rendering

On Thursday, May 22, 2014 at 5:13:13 PM UTC+5:30, Christian Schwarzgruber wrote:

--


*This message and any attachment are confidential and may be privileged or
otherwise protected from disclosure and solely for the use of the person(s)
or entity to whom it is intended. The contents is issued in confidence for
the purpose only for which it is produced. **If you have received this
message in error and are not the intended recipient, please notify the
sender immediately and delete this message and any attachment from your
system. If you are not the intended recipient, be advised that any use of
this message is prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.*


*Internet correspondence is not secure and neither Lukup Media Pvt. Ltd.
nor the sender accepts responsibility for viruses or other forms of data
corruption caused by such. It is your responsibility to scan this e-mail
and any attachments for viruses. Neither Lukup Media Pvt. Ltd. nor the
sender does accept liability for any errors or omissions in the contents of
this message or attachments that arise as a result of e-mail transmission. *

[Mohit Kingra]

Hi Alex,

Ultimately, we are looking for the best html5 audio/video + canvas performance from a webkit/blink based platform on ARM.

We'd like to try HW rendering with CEF wrt WebKitDFB (we are currently doing SW rendering using DirectFB library).

We can use libdrm, ozone with dri but using Aura WM seems like overkill for our case, wouldn't it?

I would like to know the effort/performance cost in using a offscreen rendered bitmap from Ozone with a lighter windowing system e.g. lite based on directfb.

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure and solely for the use of the person(s) or entity to whom it is intended. The contents is issued in confidence for the purpose only for which it is produced. If you have received this message in error and are not the intended recipient, please notify the sender immediately and delete this message and any attachment from your system. If you are not the intended recipient, be advised that any use of this message is prohibited and may be unlawful, and you must not copy this message or attachment or disclose the contents to any other person.

[Alex Sakhartchouk]

Your best performance will definitely be with HW, especially because canvas is accelerated. 

As far as Aura goes, I suspect you are using Chrome to render just one page at a time, no tabs, windows or any of that, in which case Aura is mostly a no-op. If you look in the code at what it does in these situations, it amounts to a handful of simple layer manipulations for house keeping, but only the page content is actually rendered.

So if you want Chrome (or content_shell) to control the display while rendering in SW, ozone dri is probably your starting point. If you just want the buffers from Chrome that will go somewhere else, https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/test/ is a good place to look, it receives rendered buffers and writes them to file. You could change that to direct them wherever they need to go.

[Mohit Kingra]

Hi Alex,

So, I'm going to work with Aura first and see if fits our metrics, otherwise 'll use the buffers from chrome.

Thanks for all the info.

Cheers!

[edja...@gmail.com]

Hi Christian Schwarzgruber / Mohit Kingra ,

Is there any successful story implementing using ozone , Direct FB ?.

We are also looking for similar solution. We are going to try out this option.

Please share your thoughts.

[Robert Kroeger]

My presumption is that it should be comparatively easy to write a directfb backend for ozone. But... why would you want to? Why not write a backend for your hardware device? For example: ozone backends can be built for drm, hwc/gralloc, a dumb memory buffer etc.

[edja...@gmail.com]

Thanks

I already looked at the 'DRM' backend option. It can be built only with content_shell ,and it always runs at 800/600 resolution. I am looking at higher resolution. Except this the solution looks good.

Would there be any fix to increase the resolution?

[Daniel Nicoara]

That's not true; the DRM backend was primarily written for ChromeOS and contains all the necessary components to do display configuration. content_shell on the other hand is a basic implementation of the src/content module. It doesn't have the necessary hooks to do display configuration, hence the 800x600 window size. Also, that resolution is hard coded in content_shell since content_shell is used in unittests which expect a 800x600 window size.

You may want to either change content_shell based on your needs or look at building chrome with the chromeos=1 flag.

[edja...@gmail.com]

That's a good news..! Thanks a lot for clarification..!

I had final question before proceeding ,

Our requirement is to embed the browser for linux embedded platform without any display server. We would be looking at only major web rendering part.. other features, extensions & plugin supports not required now.
Initially i was looking at CEF3 ,where it provides stable API for embedding a browser. How ever ..It still relies on X server for window manager..and As per i heard Ozone Layer was not completely ported into CEF3.

The only option left with me is , content_shell with Ozone implementation.
content_shell was a basic browser generally created for testing the content module . Content shell would do the most what we require.. How ever Would it be stable enough like CEF3 ?.

[Daniel Nicoara]

I haven't played with CEF, so I can't comment on that, but content_shell should be stable.

[Robert Kroeger]

Do you mean "will content_shell" run stably? Or is the API stable? The code runs many of Chrome's tests so is heavily exercised. The API is not changing very quickly but Chrome components make no API guarantees. You might find a watch list entry for content/public to be useful.

And your requirements sound like you should look into embedded content shell build target: it's content_shell without any test specific code.

 

[Praveen T]

Hi,

I know this is very old but would like to know if you are able to make chromium run with Linux frame buffers (without X11 or Wayland or with content_shell).

If not chromium, have you tried any other browser with frame buffers?

Please share the details if you got it working.

Regards,

Praveen

[Robert Kroeger]

It work(ed)

https://chromium.googlesource.com/chromium/src/+/master/docs/linux/ozone_drm.md is maybe a bit dated.  Updates/experience report would be welcome.

Rob.

--

Robert Kroeger
rjkr...@google.com

[Praveen T]

Thanks, is drm platform specific to chrome OS or will it work even with Linux buffers (sdl).

Praveen

[Robert Kroeger]

Should work with some appropriate tweaking on a modern Linux. 

--

Robert Kroeger
rjkr...@google.com

[Michael Spang]

It does not use the framebuffer driver aka "fbdev" (which is an old
thing), instead it uses DRM/KMS and gbm. Whether it works depends
mostly on whether your graphics driver supports those APIs.

[Praveen T]

Hi,

I have libdrm, libkms on the target device, and chromium-browser compiled with below build arg for chromium.

" FATAL:ozone_platform_drm.cc(90)] Check failed: false." 

Do I need to enable any other arguments to detect DRM?

is_official_build = false

target_cpu = "arm"

arm_version = 7

target_os = "linux"

arm_arch = "armv7-a"

arm_float_abi = "hard"

arm_fpu = "neon"

arm_tune = "cortex-a9"

arm_use_neon = true

arm_use_thumb = true

dcheck_always_on = true

enable_nacl = false

has_native_accessibility = false

is_chrome_branded = false

is_debug = false

is_official_build = false

ozone_auto_platforms = false

ozone_platform = "gbm"

ozone_platform_gbm = true

use_evdev_gestures = false

use_glib = false

use_gtk = false

use_ozone = true

use_pulseaudio = false

use_xkbcommon = false

use_cups = false

use_gio = false

use_kerberos = false

use_libpci = false

use_pulseaudio = false

use_udev = false

rtc_use_pipewire = false

v8_enable_lazy_source_positions = false

use_pangocairo = false

enable_basic_printing = true

use_system_minigbm = false

use_vc4_minigbm = true

use_x11 = false

Thanks,

Praveen

[Maksim Sisov]

Hi,

It seems like it tries to create a PlatformScreen, which is a
requirement on Linux, but this call is not expected on ChromeOS. See
https://source.chromium.org/chromium/chromium/src/+/master:ui/ozone/platform/drm/ozone_platform_drm.cc;l=89?q=ozone_platform_drm.cc&ss=chromium

> --
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ozone-dev+...@chromium.org.

--
Best Regards,
Maksim Sisov

[Praveen T]

Hi Maksim,

I am building chromium for the Linux environment and not ChromeOS.

Any details on why we get this error, is it not able to find the DRM module on the target board?

Any test code to test ozone and DRM without chromium? To confirm that Ozone is working fine on the board first.

Thanks,

Praveen

[Maksim Sisov]

Hi,

I saw your gn args and that's why I pointed that it tries to create a
PlatformScreen [1], which is a requirement for Linux builds, but is not
one for ChromeOS builds. Ozone/Drm is primarily used with ChromeOS,
which has different path compared to Linux, which always creates a
screen. I'm not much familiar with the ChromeOS and Ozone/Drm code and
cannot guide you how to fix that platform further. I tried to only say
why you get the error.

[1]
https://source.chromium.org/chromium/chromium/src/+/master:ui/ozone/platform/drm/ozone_platform_drm.cc;l=89?q=ozone_platform_drm.cc&ss=chromium

[Michael Spang]

This traditionally needed toolkit_views=false in the args and building
content_shell.

[Praveen T]

I am trying to run chromium on imx6ull SoM and Linux kernel, it is a single-core application processor without GPU. And with chromium ozone supporting GBM/DRM, X11, and Wayland;  without GPU is  GBM/DRM with Linux framebuffer the only option I have or can I run X11 or Wayland without GPU?

Please share your thoughts and suggestions.

[Michael Spang]

You have to run with wayland if you have no GPU. We removed DRM/KMS
software output a long time ago.

[Praveen T]

Hi,

Started weston on target using fbdev-backend and it creates a weston-desktop-shell on the LCD.

weston --device=/dev/fb0 --backend=fbdev-backend.so --tty=9

Now I tried running chromium but failed to initialize the platform.

Is there anything else I need to start for Chromium to detect the Wayland shell?

[/usr/chrome/chromium-way]# WAYLAND_DEBUG=1 ./chrome --no-sandbox  -enable-features=UseOzonePlatform -ozone-platform=wayland --disable-gpu

[549:549:0101/010611.359280:ERROR:file_util_posix.cc(933)] fallocate: Operation not supported (95)

[3972556.294]  -> wl_di...@1.get_registry(new id wl_registry@2)

[3972561.792]  -> wl_di...@1.sync(new id wl_callback@3)

[3972567.041] wl_di...@1.delete_id(3)

[3972567.457] wl_re...@2.global(1, "wl_compositor", 3)

[3972569.524]  -> wl_re...@2.bind(1, "wl_compositor", 3, new id [unknown]@4)

[3972570.694] wl_re...@2.global(2, "wl_subcompositor", 1)

[3972572.814]  -> wl_re...@2.bind(2, "wl_subcompositor", 1, new id [unknown]@5)

[3972576.308] wl_re...@2.global(3, "wl_scaler", 2)

[3972577.456] wl_re...@2.global(4, "wl_text_input_manager", 1)

[3972577.819] wl_re...@2.global(5, "wl_data_device_manager", 1)

[3972578.196]  -> wl_re...@2.bind(5, "wl_data_device_manager", 1, new id [unknown]@6)

[3972580.480] wl_re...@2.global(6, "wl_shm", 1)

[3972581.638]  -> wl_re...@2.bind(6, "wl_shm", 1, new id [unknown]@7)

[3972583.570] wl_re...@2.global(7, "wl_output", 2)

[3972585.378]  -> wl_re...@2.bind(7, "wl_output", 2, new id [unknown]@8)

[3972587.748] wl_re...@2.global(8, "wl_input_panel", 1)

[3972588.183] wl_re...@2.global(9, "wl_shell", 1)

[3972589.263] wl_re...@2.global(10, "xdg_shell", 1)

[3972590.522] wl_re...@2.global(11, "desktop_shell", 3)

[3972591.765] wl_re...@2.global(12, "screensaver", 1)

[3972593.660] wl_re...@2.global(13, "workspace_manager", 1)

[3972594.046] wl_re...@2.global(14, "screenshooter", 1)

[3972595.535] wl_ca...@3.done(0)

[3972596.862]  -> wl_di...@1.sync(new id wl_callback@3)

[3972598.545] wl_di...@1.delete_id(3)

[3972598.934] wl_o...@8.geometry(0, 0, 95, 54, 0, "unknown", "mxsfb-drmdrmfb", 0)

[3972601.260] wl_o...@8.scale(1)

[3972601.469] wl_o...@8.mode(3, 800, 480, 60000)

[3972603.413] wl_o...@8.done()

[3972603.594] wl_ca...@3.done(0)

[549:549:0101/010612.604013:ERROR:wayland_connection.cc(156)] No Wayland shell found

[549:549:0101/010612.606966:FATAL:

Thanks,

Praveen

[Maksim Sisov]

Hi Praveen,

Indeed, the error log is a bit misleading. Chromium only supports
xdg_wm_base and zxdg_shell_v6 shell protocols.

From your logs, I can only see that xdg_shell protocol is announced on
your system. However, xdg_shell is an old and outdated shell protocol.

[Praveen T]

Hi Michael, Maksim, Robert,

I am able to run chromium on Embedded Linux target (without GPU) after upgrading to Weston5.

Chromium is able to run in kiosk mode and displaying the web pages in full screen.

Thanks for the support.

Praveen

[Praveen T]

Now I have the single web page application working on ARM SoC board.

But observing high CPU usage of 57% when opened a simple single web page, any suggestions or link on how to reduce the CPU usage?

Thanks,

Praveen

[Maksim Sisov]

Hi,

Can you please share your about://gpu?

[Praveen T]

Hi,

There is no GPU in the SoC, we are running on an ARM Application Processor Cortex A7.

Praveen

[Praveen T]

Hi,

When I try to open https pages or open http page with ethernet cable connected to the board, observing nssdb and ssl error.

[1131:1176:0421/073517.010367:ERROR:nss_util.cc(169)] Error initializing NSS with a persistent database (sql:/.pki/nssdb): NSS error code: -8023

[1131:1176:0421/073517.043708:ERROR:nss_util.cc(127)] Error initializing NSS without a persistent database: NSS error code: -8023

Calling _exit(1). Core file will not be generated.

[/usr/chrome/chromium-way]# [1154:1165:0421/073517.621988:ERROR:ssl_client_socket_impl.cc(947)] handshake failed; returned -1, SSL error code 1, net_error -3

[1154:1165:0421/073517.946008:ERROR:ssl_client_socket_impl.cc(947)] handshake failed; returned -1, SSL error code 1, net_error -3

Any suggestions on what can cause these error and how to fix them.

Thanks,

Praveen

On Tuesday, 30 March 2021 at 14:05:12 UTC+5:30 Praveen T wrote:

[Praveen T]

Hi,

We are trying to get touchscreen (tslib) integration with Chromium. 

Touchscreen device is detected under /dev/input/event0 and able to detect events. However, when running Weston and Chromium, we are not able to get the touch events detected by Chromium.

We tried --touch-events=enabled --touch_view flags but didn't work.

FYI, we tried with USB mouse, and with the option "--enable-wayland-ime", we are able to get USB mouse detected and keyboard working with chromium.

Can anyone please share the details on how to get the tslib(touch screen) integrated with Chromium?

Regards,

Thanks,

Praveen

[Maksim Sisov]

Hi,

All input devices are controlled by Wayland compositor. The compositor
is the one that announces capabilities and tell the client it can create
a wl_touch object that will receive touch events [1].

You can check what capabilities your Weston compositor has by running
weston-info app. It will show all supported protocols capabilities of
seats. For example, on my desktop (that doesn't have touchscreen), it
says -

interface: 'wl_seat', version: 5, name: 18
name: seat0
capabilities: pointer keyboard
keyboard repeat rate: 33
keyboard repeat delay: 500

So, if you have touch device, it should also be there.

[1]
https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/wayland/host/wayland_connection.cc;l=286?q=wayland_connection.cc&ss=chromium%2Fchromium%2Fsrc

* Usual work time - 08:00-16:00 (EEST).

[Praveen T]

Hi,

Please find below the weston-info details.

Don't see wl_touch interface.

interface: 'wl_compositor', version: 4, name: 1

interface: 'wl_subcompositor', version: 1, name: 2

interface: 'wp_viewporter', version: 1, name: 3

interface: 'wp_presentation', version: 1, name: 4

        presentation clock id: 4 (CLOCK_MONOTONIC_RAW)

interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 5

interface: 'zwp_pointer_constraints_v1', version: 1, name: 6

interface: 'zwp_input_timestamps_manager_v1', version: 1, name: 7

interface: 'wl_data_device_manager', version: 3, name: 8

interface: 'wl_shm', version: 1, name: 9

        formats: RGB565 XRGB8888 ARGB8888

interface: 'wl_seat', version: 5, name: 10

        name: default

        capabilities: pointer keyboard

        keyboard repeat rate: 30

        keyboard repeat delay: 300

interface: 'wl_output', version: 3, name: 11

        x: 0, y: 0, scale: 1,

        physical_width: 95 mm, physical_height: 54 mm,

        make: 'unknown', model: 'mxsfb-drmdrmfb',

        subpixel_orientation: unknown, output_transform: 270°,

        mode:

                width: 800 px, height: 480 px, refresh: 60.000 Hz,

                flags: current preferred

interface: 'zwp_input_panel_v1', version: 1, name: 12

interface: 'zwp_input_method_v1', version: 1, name: 13

interface: 'zwp_text_input_manager_v1', version: 1, name: 14

interface: 'zxdg_shell_v6', version: 1, name: 15

interface: 'wl_shell', version: 1, name: 16

interface: 'weston_desktop_shell', version: 1, name: 17

interface: 'weston_screenshooter', version: 1, name: 18

Thanks,

Praveen

[Maksim Sisov]

Hi,

wl_touch is not announced separately. It’s a capability of wl_seat. As I
can see it only has a keyboard and pointer. I think you need to figure
out why Weston doesn’t see your touch device (for example, if you open a
Weston-terminal, can it be controlled by your touchscreen?)

[Praveen T]

I got the touch working, it is to do with udev rules.

Now we are able to use touch driver for page navigation.

libinput-list-devices

Device:           fts_ts

Kernel:           /dev/input/event0

Group:            1

Seat:             seat0, default

Capabilities:     keyboard touch

Tap-to-click:     n/a

Tap-and-drag:     n/a

Tap drag lock:    n/a

Left-handed:      n/a

Nat.scrolling:    n/a

Middle emulation: n/a

Calibration:      identity matrix

Scroll methods:   none

Click methods:    none

Disable-w-typing: n/a

Accel profiles:   n/a

Rotation:         n/a

[Praveen T]

Hi

When I try to open https pages or open http page with ethernet cable connected to the board, observing nssdb and ssl error.

[1131:1176:0421/073517.010367:ERROR:nss_util.cc(169)] Error initializing NSS with a persistent database (sql:/.pki/nssdb): NSS error code: -8023

[1131:1176:0421/073517.043708:ERROR:nss_util.cc(127)] Error initializing NSS without a persistent database: NSS error code: -8023

Calling _exit(1). Core file will not be generated.

[/usr/chrome/chromium-way]# [1154:1165:0421/073517.621988:ERROR:ssl_client_socket_impl.cc(947)] handshake failed; returned -1, SSL error code 1, net_error -3

[1154:1165:0421/073517.946008:ERROR:ssl_client_socket_impl.cc(947)] handshake failed; returned -1, SSL error code 1, net_error -3

Any suggestions on what can cause these errors and how to fix them.

Thanks,

Praveen

[yunbo yu]

Hi, Praveen, Maksim, Michael, Robert:

I am interested in chrominum  and Iwant to run chromium on my device which just has arm64+linux(surpport framebuff) + root filesystem, not including any x-windows.

I really confused the relationship  between chrominum, ozon, waylan, and drm, ksm you metioned above.

Can you share your successful experience?

thanks

Bestwishes!

[Praveen T]

Hi,

1. Please bring up the wayland-weston#5 with a frame buffer as the backend.
   
2. This would display a default window on the LCD display.
3. Next we need to compile chromium with ozone platform support as Wayland (all others platforms disabled) and run on the target.

Please check the version compatibility of all the dependent modules/packages.

Regards,

Praveen