1195673 - 2.2R based dual display functionality for RedSquare

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Comment 1

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

# Given the timeline, let’s forget about having the multi-screen solution backporting Bug 1116089 to 2.2r as it requires many more platform dependencies

# To enable dual display in 2.2r, we’re open to let partner propose and implement workaround solution w/o bug 1116089

Comment 2

[Alexander]

Hi Wesley, please remove the following comment inserted by Bugzilla on my behalf:
"No longer blocks: 1178464".
I did not mean it, just wished to add myself to CC: list.

Thanks.

Comment 3

[David Flanagan [:djf]]

Here's a good description of two possible approaches from this bug, taken from email by Alexey Yakimov:


Architectural Approach:

From the architectural point of view we believe that support of the secondary screen will require modifications on all levels:

Gonk:

1)     Driver for the second display should be added. We guess that the easiest way is to ask ODM to provide the same interface as for the main display for simplicity;

2)     HAL should be modified to support multiple HW displays;

3)     Interface to Gecko should be extended to support multiple display instances.

Gecko:

            Gecko should be modified to provide required API for Gaia level. We assume that on Gaia level it should be a separate iframe and gecko engine should render content of this iframe to the appropriate framebuffer.

            We didn’t dig deep into this part yet, but it is being analyzed now.

Gaia:

As it was mentioned above we assume that it should be a separate iframe for the secondary screen, so the applications should be redesigned the way to render secondary screen content to this iframe.

This is a very high level overview of the changes which we believe need to be made in order to support dual screen. We expect Mozilla to provide a solid support for Gonk and Gecko level changes.

Alternatives:

There is an alternative solution which is also being considered internally. At the first glance it will require less changes than the approach described above, however from the architectural point of view it is less flexible and looks like a workaround.

It could be an application on Gaia level which will be responsible for drawing a canvas to be rendered to the secondary screen. Once the canvas is updated the application can take a bitmap from this canvas and send it directly to the display framebuffer through some intermediate chains in Gecko and Gonk. The simplicity of this solution is that almost no changes will be needed on Gecko level.

Comment 4

[David Flanagan [:djf]]

Here's my response to comment #3:

The architectural approach described seems roughly like the right way to proceed, and there is some work going on internally toward supporting multiple displays properly so that Gecko can render directly to them. That is primarily to support large external displays instead of small secondary displays, however, and it is not targeted at 2.2.

For Red Square, I think we will need to go with the alternative bitmap based solution.

We can make up just about any API we want for this. The API should have a way to query the pixel dimensions (and color depth maybe) of the external display, and should have a way to send a bitmap to be displayed, probably using the existing ImageData/CanvasPixelArray data structure.
It will be for certified apps only and probably will never be documented.  Hopefully we'll be able to do something better in the future.

Comment 6

[[e-mail]]

Attachment: RSq Back Screen Concept - initial UX ideas

Attachment provided by Lighthouse team containing initial UX concept ideas for the back screen.

Comment 7

[[e-mail]]

Qualcomm would like to understand the potential Gecko changes resulting from the Dual screen / Back Screen implementation. This will help QC decide if  GPU needed, or bitmap enough. In particular:

a) what kind of data is needed
b) how much data is sent

Action item from QC-Mozilla meeting 8th October: Ravi to discuss with David, OEMs.

Further design discussion should now be possible given the Back Screen Concept design (see Comment 6).

Comment 8

[[e-mail]]

On Thu, Oct 15, 2015 at 9:54 AM, Morpheus Chen <[e-mail]> wrote:

    Hi all,

    Just to remind that the Back screen proposal is the material for BD and PM team to discuss with OEM for a best hardware solution. That is, it's still in concept phase, so there might be still changes in the future.

    Hi Patrick and Ravi,

    Based on the UX schedule, the detailed UX spec for Back screen will start working on Nov 9. Hence, is that possible to lock down the hardware spec for Back screen before Nov 9? Thanks.

    Morpheus Chen

Comment 9

[Ravi Dandu]

For a particular question  bitmap or GPU (Comment 7) is needed, the data being discussed  is: 
 - Clock
 - Next Calendar Event
 - Weather
 - Notifications: incoming Call, Missed call, mesaage, meeting, reminder
 - Stock price
Is that data enough to make a decision? We can ballpark estimate the data throughput if needed.

Comment 10

[Patrick Hundal]

We are still working to determine a reference platform.  In the absence of this being decided by Nov 9, please use the 128x128 display, in color, as a reference.  This is the platform TCL has settled on, and is the phone closest to coming to market.

Patrick

(In reply to Tony Appleton from comment #8)
> On Thu, Oct 15, 2015 at 9:54 AM, Morpheus Chen <[e-mail]> wrote:
> 
>     Hi all,
> 
>     Just to remind that the Back screen proposal is the material for BD and
> PM team to discuss with OEM for a best hardware solution. That is, it's
> still in concept phase, so there might be still changes in the future.
> 
>     Hi Patrick and Ravi,
> 
>     Based on the UX schedule, the detailed UX spec for Back screen will
> start working on Nov 9. Hence, is that possible to lock down the hardware
> spec for Back screen before Nov 9? Thanks.
> 
>     Morpheus Chen

Comment 11

[BMO Automation]

Firefox OS is not being worked on