At work, we don't have a set workstation and therefore often change monitors (flex office). All the monitors are of the same brand and model however they all have a different hexadecimal number in their names, for example, three similar monitors will have those names:
Goldstar Company Ltd LG Ultra HD 0x0000EDE5Goldstar Company Ltd LG Ultra HD 0x0000E7C8Goldstar Company Ltd LG Ultra HD 0x00007FB9It is a burden to have to add all of them one by one. I'd like to be able to use a regex like so:
{
output "Goldstar Company Ltd LG Ultra HD .*" enable scale 2.0
}
One solution would be to simply match output names with
fnmatch(3). Another solution would be to allow users to match only a particular vendor, model or serial.
Note, we already support
*to match any output. Is that not enough for your use-case?
Unfortunately it is not enough for my use case because at home I have yet another monitor for which I need another conf. Unless the most specific names takes precedence, in which case I could make it work.
Using
fnmatchwould indeed be a good solution.
The first matching configuration will be picked, so specifying the home configuration first should work. It would be a good idea to document this behavior.
The only thing that makes me hesitate about
fnmatchis that your workplace has only one manufacturer/model of monitors "by chance". Maybe your workplace will buy a few monitors of the same brand as your home setup and this solution won't work anymore.
I think
fnmatchis an interesting approach.The only thing that makes me hesitate about fnmatch is that your workplace has only one manufacturer/model of monitors "by chance". Maybe your workplace will buy a few monitors of the same brand as your home setup and this solution won't work anymore.
Indeed it will not work every time. However, that leaves us the option to "group" profiles and do interesting things (until swaywm/wlr-protocols#68). I will open a PR in this direction. I let you the final decision.
The first matching configuration will be picked, so specifying the home configuration first should work. It would be a good idea to document this behavior.
In that case it's good for my case indeed! However, I still think it would be a nice feature to have. If two types of monitors existed at work, requiring different configuration each, then I would indeed need shell globbing.
I just had the use case at work where we now have a second kind of monitor (with only slightly changing names), needing another configuration. With globbing I can solve this problem with one block while without, I need a new block for each monitor.
Any update on this? A PR is ready to be merged, it seems to me that there are no obvious drawback for the flexibility it gives.
I also need this for work office, where we cycle workspaces and I now have ~10 config blocks for the same display model, with each of them having a different serial number at the end.
Hi! I happen to work in the same office Sweenu did (small world). We still only have two different models, and the usecase is the same. As far as this usecase goes (supporting two models), it's doable to duplicate a profile to support both models, but not really realistic to make a profile for each monitor. A regexp or a basic glob (e.g. with only a sigle *) or even prefix matching would suffice:
profile work-4k-hdr { output eDP-1 position 470,1598 output "LG Electronics LG HDR 4K 0x*" mode 3840x2160@59.997Hz scale 1.35 position 0,0 } profile work-4k { output eDP-1 position 470,1598 output "LG Electronics LG 4K 0x*" mode 3840x2160@59.997Hz scale 1.35 position 0,0 } profile home-2k { output eDP-1 position 320,1440 output "Goldstar Company Ltd 27GL850 912NTPC32536" mode 2560x1440@99.946Hz scale 1.0 position 0,0 }though the regexp route would be awesome:
profile work-4k { output eDP-1 position 470,1598 output "LG Electronics LG (HDR )?4K 0x[A-F0-9]{8}" mode 3840x2160@59.997Hz scale 1.35 position 0,0 } profile home-2k { output eDP-1 position 320,1440 output "Goldstar Company Ltd 27GL850 912NTPC32536" mode 2560x1440@99.946Hz scale 1.0 position 0,0 }Thanks for your work on kanshi!
This feature is becoming more important recently... I noticed after a
swaypackage update this week that the0x________serial of my display changed, breaking my configuration. Nothing else had changed (same HDMI port, same display, same everything). The usualHDMI-A-_numbered HDMI port names had been changing on me multiple times previously, which is why the make / model / serial display match seemed to be more "stable".However, this assumption has now been broken with recent updates to sway. Pattern matching would likely solve the issue of the "serial" part changing unexpectedly.
In my case, the
0x________serial part was the only thing that changed. I'm not sure why it did this inswaymsg -t get_outputs, but the display itself and EDID data have not changed at all.¯\_(ツ)_/¯
Likely because the serial number parsing code was buggy and fixed. Note, the other fields aren't stable either: in particular the vendor name is taken from a database, and database updates might change it.
Hi,
I am unearthing this issue to see whether you're interested in a minimum viable implementation. It allows for a trailing wildcard only to be able to ignore the most specific parts of the display name (in both OP's and my case, the serial number).
You can find it here: https://git.sr.ht/~tuetuopay/kanshi/commit/output-glob
@~emersion would you be interested in me sending this patch?
Fixed in 72d7979b7e88ba5fedfb30426c8b717eadfff127.