Add a "--display-config static=<filename>" option #551
Conversation
AlanGriffiths
force-pushed
the
static-display-config
branch
from
c63a08a
to
22098ae
Compare
|
Example config: |
|
I know I originally said we don't need Also, we're printing |
I can change that to have card_id. (Or we can also do what xrandr does and only use the card number when it's not 0.) It's hard to do anything helpful as we can't tell the use which physical output they corresponds to.
Would it be clearer to be setting mode? E.g. We can simply add setting scale: |
|
+1 on setting To help the user a bit, could we add some kind of ID of the connected display in the comment? Or is it not helpful, especially when your display wall (as usual) is comprised of multiple displays of the same make/model? I think if we're not explicit about card/output in this we can just drop |
|
A new example: |
|
If we're going to have a configuration file, maybe we should use an actual configuration format? Any of JSON, TOML, or YAML would seem to be be fine choices. For JSON, For TOML there's nothing obvious in the archives, but the For YAML there's We seem to be using a lot of YAML in Canonical, maybe that's a reasonable choice? |
|
What's the format of "the config file" that can replace command-line options and env vars? |
https://www.boost.org/doc/libs/1_68_0/doc/html/program_options/overview.html#id-1.3.31.5.10 |
|
I've just remembered #293 - we should have orientation as an option. Also,experimenting with this: the Mir compositor isn't respecting scale. So that shouldn't be an option (yet). I'll make those changes. I don't have strong opinions about config file formats. Once we reach a consensus I'll implement it. |
|
I just wonder if it's desirable to split the config files then? Can the boost options be dynamic (for changing number of outputs)? |
|
The reason I split them was to facilitate having multiple display configs (e.g. docked and non-docked). But I guess that can also be done in a single file. I'll have to experiment a bit with the boost stuff to see exactly what's possible. (I've not actually used sections or repeated options.) |
|
@Saviq trying to answer your question about Boost.Options: Boost.Options needs to know the key names and option types before parsing the file. It isn't dynamic in that sense. OTOH Boost.Options doesn't need to be dynamic to support multiple outputs: it is entirely possible to parse multiple values for the same key. (We'd need to rework some mirserver code to expose that feature, but the parsing engine works OK with it.) That is we could have this in the ~/.config/miral-kiosk.config file: We could even have several display configuration section, provided we know the section names in advance. For example, However, in the supported format everything is key/value pairs. There no hierarchical structure (as you'd see in a yaml file). (The section name is just a shorthand for |
|
It looks like the INI format is too limiting, I'll write up a richer example of what I think we should ultimately support for this use case and let's decide how far we want to go in the first iteration. |
|
OK, I'll leave this up for discussion. |
|
@stephaneverdy, @jhodapp, @lool, @RAOF, @gerboland, @wmww This is me going to the extreme in the outlook of supporting robust kiosk/signage stories. RFC! FeaturesHere are the high-level features I think we should support with this long-term:
Config file formatA config format that I think could tackle this (remember this is taking it to the extreme, we'd be implementing this on an as-needed basis): inputs:
# a list of input devices matched by regular expressions of any of the below keys
# can match zero or more devices
- input-id: usb-Logitech_USB_Keyboard-event-kbd
# (/dev/input/by-id/*)
input-path: pci-0000:00:14.0-usb-0:1.3.2:1.0-event-kbd
# (/dev/input/by-path/*)
input-vendor: 046d # USB vendor ID
input-prod: c31d # USB product ID
# TODO: other means of matching input devices?
label: logitech-keyboard # for use in display/surface pinning below
- input-type: kbd
label: all-keyboards
- input-type: mouse
label: all-mice
- input-type: touch # TODO: what're the input types?
# the below would be defaults, overridden by pinning to surfaces / displays
displays: [my-display, other-display]
# spanning the bounding rectangle of the listed displays
# TODO: including those not listed, if they happen to fall
# into the bounding rect (?)
geometry: [0, 0, 3840, 2160] # [x, y, w, h]
# TODO: or, if touch devices report a default resolution
position: [0, 0] # [x, y]
size: [3840, 2160] # [w, h]
# TODO: what other input properties we should allow here?
layouts:
# keys here are layout labels (used for atomically switching between them)
# when enabling displays, surfaces should be matched in reverse recency order
my-layout: # the first layout is the default
displays:
# a list of cards matched by regular expressions of card-{path,serial,id},
# failure to match a single card should be an error
# omitted cards and outputs are disabled
- card-path: ^pci-0000:00.02.0$ # preferred, most stable (/dev/dri/by-path/*-card)
# remaining keys in the form <socket-type>-<output-id>
hdmi-0:
position: [0, 0] # required, [x, y]
label: my-display # used in surface / input pinning
mode: 1920x1080@60 # defaults to the preferred mode
resolution: [1920, 1080] # forces a resolution, takes precedence over mode
refresh-rate: 60.0 # forces a refresh rate, takes precedence over mode
scale: 1.0 # a float
orientation: normal # {normal, left, right, inverted}
reflection: normal # {normal, x, y, xy}
inputs: [all-mice] # inputs to pin to this display
hdmi-1: ~ # tilde (NULL in YAML) or omitting disables the output
- card-serial: ^1234ABCD$ # TODO: alternative, if possible to get (?)
displayport-0: # failure to match an output should be an error
label: other-display
position: [1920, 0]
inputs: [] # TODO: disables input on this display (?)
- card-id: 2 # last resort matching
# TODO: other means of matching a card?
surfaces:
# a list of surfaces matched by regular expressions on title, program (executable), client ID
# only matching surfaces will get mapped, new surfaces replace old ones
- title: ^The app$
program: ^/snap/app/\d+/app$
id: ^The client ID$
# TODO: other means of matching a surface?
position: [50, 50] # [x, y] TODO: could either coordinate be optional?
size: [200, 200] # [w, h] TODO: could either size be optional?
inputs: [all-keyboards]
- program: ^/snap/other-app/\d+/other-app$
display: my-display # this surface will get forced to the geometry of "my-display",
# takes precedence over position and size
inputs: [] # this surface receives no input
all-off: []xrandrBorrowing from bed… |
|
"First, implement a new capability in the simplest way you can think of that "could possibly work". Don't build a lot of amazing superstructure, don't do anything fancy, just put it in." - http://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork |
|
I put in a vote for |
If I actually type it then I use the newer -> format. But sometimes it gets written another way... |
|
I've had a play with this and, modulo me editing the wrong +many! |
Have patience, I've hacked this together to get some feedback on the config file. (Look how much that has changed!) There are some internals to clean up now (and some tests to write). |
src/miral/static_display_config.cpp
Outdated
| { | ||
| Node name_node; | ||
| Node config_node; | ||
| // No 'default' but there is only one - use it |
There was a problem hiding this comment.
I'd just error out if default layout wasn't there. But if you think that's better, WFM.
There was a problem hiding this comment.
@Saviq I have been using it as easy-to-implement behaviour that is compatible with my test files. But I can drop it now if we don't like it.
|
Having "slept on it" about I'm favouring Vis: |
|
We'll need a tie-breaker then ;) I really dislike this: My eyes are defaulting from this. |
|
How about: |
|
Do we need "default-layout" specifier at all? Can we not require at least one layout called "default", which is the default layout Mir uses? |
|
@gerboland Do we need "default-layout" specifier at all? Can we not require at least one layout called "default", which is the default layout Mir uses? That's what @Saviq advocates. I'm thinking an explicit default that can be amended easily might be easier to manage. |
|
It does make it easier to manage should there be a large number of layouts to choose from, but IMO most users will have max a couple of layouts. We can always add "default-layout" later if we see the need for it... |
|
@gerboland @AlanGriffiths I would consider changing the default layout more of a runtime option, so something along the lines of I would expect a grand majority to only ever have a single layout really. |
|
Providing additional options at runtime would suggest considering alternatives (or additions) to extending A |
|
@gerboland, @Saviq tests added, the implementation just has the stuff I think we've agreed: none of the stuff I want to add to set the default explicitly in the file. (If I get motivated I can PR that later.) |
|
bors r=Saviq |
551: Add a "--display-config static=<filename>" option r=Saviq a=AlanGriffiths Add a "--display-config static=\<filename\>" option. (Fixes #495) This reads the indicated file and tries to position the display outputs accordingly. If the file does not exist, or if actual outputs are not specified defaults are applied. The complete resulting layout is listed in the Mir "info" log. Note: Specifying a non-existent file is an easy way to get a template for editing. (As with other configuration options this can also be specified with environment variables or a config file.) Co-authored-by: Alan Griffiths <alan@octopull.co.uk> Co-authored-by: Alan Griffiths <alan.griffiths@canonical.com>
Build succeeded |
Add a "--display-config static=<filename>" option. (Fixes #495)
This reads the indicated file and tries to position the display outputs accordingly.
If the file does not exist, or if actual outputs are not specified defaults are applied.
The complete resulting layout is listed in the Mir "info" log.
Note: Specifying a non-existent file is an easy way to get a template for editing.
(As with other configuration options this can also be specified with environment variables or a config file.)