Chromium browser not going fullscreen thereby mouse events not working.

[Ashish S]

Hello,

We are in a process to port chromium os on one of our targets.

As the starting step we are trying to  run the chrome exe using the chromium os rootfs nfs mounted on our target specific rootfs which is based on 2.6x kernel.

The problem that we are facing is that the chrome browser is not recieving mouse events. The reason that we found is because the chrome that comes up on the target also comes up with its own desktop/window manager (if i am not wrong) [that green desktop that one can see on a full fledged chromium os].

So the browser itself expects the mouse coordinates to be referenced from the top left corner of this desktop like container that contains the actual chrome browser.. but the mouse events actually come from the display's top left corner.(the chrome browser container occupies somewhat the centre of the whole display space available).

So if we are able to maximise this chrome container in some way the mouse events issue will go away.. is there a way to tweak the dimensions of this chrome container/desktop/window manager or whatever it actually is?

Pls refer to the image..

the black portion is the actual screen space thats unoccupied by the green desktop/container. the chrome expects the mouse x,y from the top left corner of the green container.

Thanks.

[Pawel Osciak]

Hi Ashish,

Passing --aura-host-window-use-fullscreen to Chrome should help.

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Ashish S]

Hello Pawel,

Thanks for the help,

Upon using the --aura-host-window-use-fullscreen flag, i am getting an undefined reference :

chrome:symbol lookup error:chrome: undefined symbol: XFixesCreatePointerBarrier

To clarify, the crome exe that we are running on our target uses the Xserver that is provided by our own target image as we are executing it as a standalone exe from the chromefs mounted on nfs.

And there seems to be some fix chromium project might have applied to X as seen from the undefined error above and also  after looking at some of the makefiles..

"ui/aura/aura_unittests.target.mk:315: -lXfixes"

(and this libXfixes might be missing.. from our setup)

So is libXfixes an important requirement for running chromeos and thereby might be the reason for the mouse events problems that we are facing?

apart from that having a look at "ui/aura/root_window_host.h" what is the concept of rootwindow host? a comment there says..

/*RootWindowHost bridges between a native window and the embedded RootWindow.

// It provides the accelerated widget and maps events from the native os to

// aura*/

So keeping in line with screenshot i posted, is the bridge that it refers to,the one between the black window (which is native to our target ) and the aura window (embedded rootwindow)?

Is my understanding correct?

A little help in understanding this rootwindow concept ithink might help me.

Thanks for the support.

On Friday, 27 July 2012 21:22:03 UTC+5:30, Pawel Osciak wrote:

Hi Ashish,

Passing --aura-host-window-use-fullscreen to Chrome should help.

[Antoine Labour]

On Tue, Jul 31, 2012 at 11:36 PM, Ashish S <ash...@gmail.com> wrote:

Hello Pawel,

Thanks for the help,

Upon using the --aura-host-window-use-fullscreen flag, i am getting an undefined reference :

chrome:symbol lookup error:chrome: undefined symbol: XFixesCreatePointerBarrier

To clarify, the crome exe that we are running on our target uses the Xserver that is provided by our own target image as we are executing it as a standalone exe from the chromefs mounted on nfs.

And there seems to be some fix chromium project might have applied to X as seen from the undefined error above and also  after looking at some of the makefiles..

"ui/aura/aura_unittests.target.mk:315: -lXfixes"

(and this libXfixes might be missing.. from our setup)

So is libXfixes an important requirement for running chromeos and thereby might be the reason for the mouse events problems that we are facing?

apart from that having a look at "ui/aura/root_window_host.h" what is the concept of rootwindow host? a comment there says..

/*RootWindowHost bridges between a native window and the embedded RootWindow.

// It provides the accelerated widget and maps events from the native os to

// aura*/

So keeping in line with screenshot i posted, is the bridge that it refers to,the one between the black window (which is native to our target ) and the aura window (embedded rootwindow)?

Is my understanding correct?

A little help in understanding this rootwindow concept ithink might help me.

Thanks for the support.

Inside of Chrome, Aura keeps its own hierarchy of "windows" which are handled internally. aura::RootWindow is the top-level one.

RootWindowHost is what associates the RootWindow to a native windowing system handle, for example an XID with the X server (on linux or Chrome OS), or a HWND on win32. It also converts the native events (XEvents or win32 MSGs) to an internal representation inside of Aura.

What --aura-host-window-use-fullscreen does is that it makes the native window full-screen in the native window system.

HTH,

Antoine

[Daniel Erat]

On Tue, Jul 31, 2012 at 11:36 PM, Ashish S <ash...@gmail.com> wrote:

> Hello Pawel,
>
> Thanks for the help,
>
> Upon using the --aura-host-window-use-fullscreen flag, i am getting an
> undefined reference :
> chrome:symbol lookup error:chrome: undefined symbol:
> XFixesCreatePointerBarrier
>
> To clarify, the crome exe that we are running on our target uses the Xserver
> that is provided by our own target image as we are executing it as a
> standalone exe from the chromefs mounted on nfs.
>
> And there seems to be some fix chromium project might have applied to X as
> seen from the undefined error above and also after looking at some of the
> makefiles..
> "ui/aura/aura_unittests.target.mk:315: -lXfixes"
> (and this libXfixes might be missing.. from our setup)
>
> So is libXfixes an important requirement for running chromeos and thereby
> might be the reason for the mouse events problems that we are facing?

XFixes in an X11 extension that's included in the X.Org X server:
http://en.wikipedia.org/wiki/XFixes

Aura uses it for pointer barriers when multiple displays are connected
(and maybe for other things like cursor hiding).