Analysis of the interaction between Chromium and Wayland-IVI-extension

Melatt Vythakkatt, Binoy (B.) mbinoy at
Mon Feb 20 09:29:33 EST 2017

Hello Jacobo,

Two points on the Ozone wayland multi window event.
1. If you are using multiple screens to run the different browser instance, the below link will be helpful to set the touch properly
2. In Ozone wayland probably you required to move the mouse cursor to the second window to get it focused, then you may able to get the events properly. It is observed that the implementation looks for mouse enter / leave for the focus handling.

Best regards,

-----Original Message-----
From: genivi-projects [mailto:genivi-projects-bounces at] On Behalf Of Friedrich, Eugen (ADITG/SW1)
Sent: Friday, February 17, 2017 7:37 PM
To: Jacobo Aragunde Pérez; eg-nw at; genivi-ivi-layer-management at
Cc: genivi-projects at
Subject: RE: Analysis of the interaction between Chromium and Wayland-IVI-extension

Hello Jacobo,

Thanks for the good and also for the bad news!

Please find some short comment below...

Best regards

Eugen Friedrich
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6921

> -----Original Message-----
> From: genivi-ivi-layer-management [mailto:genivi-ivi-layer-management-
> bounces at] On Behalf Of Jacobo Aragunde Pérez
> Sent: Freitag, 17. Februar 2017 14:21
> To: eg-nw at; genivi-ivi-layer- 
> management at
> Cc: genivi-projects at
> Subject: Re: Analysis of the interaction between Chromium and 
> Wayland-IVI- extension
> Hi again,
> some extra facts, after having tested a multi-seat configuration: I 
> configured two seats, each one with its own keyboard and mouse.
> * I can open two weston-terminals and assign each of the seats to one 
> surface, everything works as expected: terminals only receive input 
> from the devices that belong to their seat.
> * When I try with two Chromium surfaces (two browser windows), they 
> don't follow the expected behavior. Only one of the surfaces receives 
> input, even if you had assigned one seat to each surface.
[EF] Will Chromium open a new connection to wayland compositor  for every window?
If yes we should check if events are distributed to correct client. 
If not we should check if we have correct working ilm surface, e.g. it should be possible to change the visibility of those with LayerManagerControl tool

> I think we have studied enough multi-screen/multi-seat configurations 
> on GDP, and identified two situations where Chromium+Ozone-Wayland 
> don't work as expected. Plans for the next weeks include addressing these issues.
> Best,
> --
> Jacobo Aragunde
> Software Engineer at Igalia
> On 15/02/17 19:01, Jacobo Aragunde Pérez wrote:
> > Hi,
> >
> > I've been trying the LayerManager commands on the GDP to see the 
> > Wayland-IVI-extension interact with Chromium and other applications. 
> > I found that Chromium generally behaves just like other apps, 
> > therefore acting as expected with no other changes than what we have done so far.
> >
> > These are some facts that can be extracted from the tests:
> >
> > * Chromium surfaces can be placed anywhere on the available screens, 
> > despite Ozone-Wayland not implementing support for that [1]. I think 
> > this is because, when using the Wayland IVI extensions, the 
> > application is not aware of the actual screens, layers, etc. The IVI 
> > controller takes care of that.
> >
> > * Chromium takes and gives away the input focus according to 
> > LayerManager commands.
> >
> > * Keyboard focus can be given to one surface or to several at once; 
> > Chromium surfaces behave like other applications in this regard.
> >
> > * Pointer focus can be "stolen" from the surface that originally had it.
> > This happens when you click on a region that belongs to a different 
> > surface. This is expected behavior according to [2].
> >
> > * Chromium can steal the keyboard focus from another Chromium
> window.
> > When there are two Chromium surfaces, if they keyboard focus belongs 
> > to the first one and you click on the second, the second surface 
> > will effectively take the keyboard focus away. LayerManager will not 
> > be aware of the change, it will say the focus still belongs to the first surface.
> > This is probably an error that should be fixed.
[EF] this behavior is expected. There should be a trigger from Chromium to the HMI/Application controller and HMI/Application controller has to decide if the focus should be changed.
Typically  in the IVI environment Hardkey focus is always assigned to same application but of cause not always.

> >
> > I was unable to define different "seats" with their own input 
> > devices, but I have just found the advanced use instructions at [2]. 
> > Next steps will be defining and trying multiple seats, and fixing 
> > the undesired behavior about stolen keyboard focus.
> >
> > [1]
> > [2]
> >
> th+n
> ew+Input+Handling+APIs
> >
> > Best,
> >
> _______________________________________________
> genivi-ivi-layer-management mailing list 
> genivi-ivi-layer-management at
genivi-projects mailing list
genivi-projects at

More information about the genivi-ivi-layer-management mailing list