Adding config file feature

[Taha-Firoz]

As discussed on issue #201 having more control over the display on which the application is rendered on is important. In order to provide this feature it's important to have a config file since the values needed for specifying displays would be too long to easily specify in a command line argument.

Currently there are three possible formats for the config file we can take inspiration from:

@adera's proposed format

{
  "enableHwCursor": true,
  "windows": [
    {
      "drmdev": "/dev/dri/card0",
      "mode": "1920x1080@60p",
      "dimensions": "160x90",
      "framebufferSize": "960x540",
      "pixelformat": "RGB565"
    },
    { ... }
  ]
}

ivi-homescreen's config file

{
   "disable_cursor":true,
   "debug_backend":true,
   "accessibility_features":31,
   "view":{
      "bundle_path":"/home/joel/development/gallery/.homescreen/x86/release",
      "vm_args":["--no-serve-devtools"],
      "width":1920,
      "height":1280,
      "fullscreen":true
   }
}

QT's drm config file

{
    "device": "/dev/dri/card1",
    "hwcursor" : false,
    "outputs": [
        { "name": "DSI1", "mode": "800x1280", "primary": true },
        { "name": "Composite1", "mode": "off" } 
    ]
}

A few things to figure out before this features implementation can even start:

• What features do we need in the config file? (views, logging, card, rotation)
• To what depth should the features be allowed to be configured
• Should the config file have a preset path, and can that be customized via env_variables or command-line arguments?
• Will the config file eventually just feed into command-line arguments and be possibly overwritten in case explicit command-line arguments are passed?

[ardera]

So this is just a brainstorm of everything that comes to my mind: (just some ideas, supporting all this would be a huge task)

• displays (the real, physical displays that exist in hardware)
  • identified by the KMS device + connector name (/dev/dri/card0 and HDMI-A-1 for example)
  • but also allow non-KMS devices as well (iMX framebuffer API, fbdev, maybe custom display output variants?)
  • allow specifying:
    • video mode, maybe even precise timings for flickering area on the screen #226?
    • overscan (scanout borders)
    • physical dimensions
    • color mgmt / HDR / HDMI color range
    • each display should connect to 0 or 1 touchscreen input devices (/dev/input/eventX)
• views (the logical displays to we tell flutter about)
  • right now, a flutter instance can only have a single view
  • but there's work going on to allow it to have multiple views as well
  • allow specifying:
    • which displays to connect to (maybe allow 0 as well?)
    • framebuffer size
    • pixel ratio (even though this is fully determined by the physical dimensions, but sometimes you just want an easy way to force 1.0)
    • pixel format
    • framebuffer tiling / DRM format modifier
    • rotation or orientation
• flutter instances
  • a single flutter engine instance
  • connects to a single flutter view (right now) and a renderer
  • specified using app bundle path
  • allow specifying:
    • engine args
    • dart entrypoint, dart entrypoint args
    • accessibility features
• renderers
  • specifies how a flutter instance should render things
  • DRM device to use (maybe /dev/dri/card1)
  • GBM/EGL/GLES
  • GBM/Vulkan
  • iMX framebuffer API
  • software rendering (with or without GBM)

So in json that would look something like this: (just for demonstration)

{
  "displays": {...},
  "views": {...},
  "flutter instances": {...},
  "renderers": {...}
}

Anything I missed? I think we can go from this and cut stuff out that shouldn't be supported and simplify the structure till we reach something that's nice and simple like the qt EGLFS / ivi-homescreen config

For example since right now, a view can only have a single flutter instance and the other way around, so they don't need to be separate in the config (Or maybe they should, for future-compatibility?). Or the renderers are that trivial to specify that we can just specify them the flutter instance specification as well (as some "renderer-drmdev": "/dev/dri/card0" and a "renderer": "vulkan" entries)

[Taha-Firoz]

So basically the final json file I'm getting an idea for is, I don't really know a lot of in-depth stuff about display configurations so there will probably be some errors. Each value will be a string right, not many that are arrays.

{
  "displays": {
    "display-name": {
      "connector-name":"",
      "mode": "",
      "overscan": "",
      "dimensions": "",
      "resolution":"",
      "color": "",
      "ts-name": ""
    }
  },
  "views": {
    "view-name":{
      "display-name":"",
      "frame-buffer":"",
      "pixel-ratio": "",
      "pixel-format": "",
      "frame-buffer":{},
      "rotation": ""
    }
  },
  "flutter instances": {
    "engine-args":"",
    "accessibility":"",
    "dart":{
      "entrypoint":"",
      "args":""
    }
  },
  "renderers": {
    "renderer-drmdev": "/dev/dri/card0",
    "renderer": "vulkan"
  }
}

[ardera]

Sorry for the delay.

@Taha-Firoz I didn't really mean that exact layout, it was just a rough draft 😉 So lots of those fields you could leave away, or merge or rename if that fits better together with the toyota, sony or Qt EGLFS config. Or if you like the draft how I send it you can also implement it that way.