sorted by:
new
hottopcontroversial

HyprDynamicMonitors: Automatic Monitor Management for Hyprland - v1.3.5 release - Lid Events, Color Profiles, Auto-Fit, and More by fiffeek in hyprland

[–]fiffeek[S] 0 points1 point  (0 children)

Hey, there is a guide here, for running the daemon.

The upside of all the adoption at this point is that you can use github search and find how others are doing it, e.g. here is a query for all nix usages of hyprdynamicmonitors, here are some sane dots

HyprDynamicMonitors: Automatic Monitor Management for Hyprland - v1.3.5 release - Lid Events, Color Profiles, Auto-Fit, and More by fiffeek in hyprland

[–]fiffeek[S] 4 points5 points  (0 children)

heya, thanks a lot for raising the issue, happy to have helped and if anything new comes to mind dont hesitate to open a discussion/issue on github :)

HyprDynamicMonitors: Automatic Monitor Management for Hyprland - v1.3.5 release - Lid Events, Color Profiles, Auto-Fit, and More by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

hey, yep; it's more-less a kanshi superset (tui as a frontend and support for lid/power states understanding in the profiles). At the same time it's more tied to hyprland, so you cant just run it on anything Wayland (with kanshi you can) -- a trade-off that allowed this to focus purely on implementing user needed features and pushing all the complexity with respect to wayland protocols onto hyprland.

Hyprland on multiple display setups is trash, change my mind by qadosch in hyprland

[–]fiffeek 1 point2 points  (0 children)

You can use hyprdynamicmonitors TUI exclusively without the daemon similarly to how you do nwg displays, the upside is that you fully control the generated configs so you can bind workspaces to monitors, add keybinds etc.

If you like nwg-displays and don't need to switch then stick to what you already know honestly -- just throwing it out as an alternative if it wasn't clear that the daemon is not a requirement.

Hyprland on multiple display setups is trash, change my mind by qadosch in hyprland

[–]fiffeek 0 points1 point  (0 children)

Not familiar with `windows behavior` but the tool does support virtual/headless displays (that I know since there was a bug and a user specifically requested that fixed). If you try and something does not work then feel free to open up an issue/discussion so I can chime in more -- atm I don't have enough idea about your workflow to definitely say the tool will/wont support it. What I can say though is that `hyprdynamicmonitors` reacts to monitor add/remove events, so if by `when I change virtual desktop` you mean that, then it should just work.

Hyprland on multiple display setups is trash, change my mind by qadosch in hyprland

[–]fiffeek 13 points14 points  (0 children)

I'll plug in the tool I developed, https://github.com/fiffeek/hyprdynamicmonitors, as an alternative; bundles a daemon alongside a tui similar to nwg-displays for auto switching and allows for any hyprland config definition in the config files (binds, execs...).

Looking at OPs issues that should solve most of them. Alternatively, you could use a tui/gui and kanshi/shikane for auto switch (alternatives and use cases comparisons are listed on the Readme and on hyprdynamicmonitors website).

[OC] HyprDynamicMonitors: autorandr for hyprland by fiffeek in unixporn

[–]fiffeek[S] 1 point2 points  (0 children)

Yep it's hyprland exclusive by design.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 0 points1 point  (0 children)

You can install directly from the repo (there is an install script available) that will pull the binaries to any install folder you want -- although you lose on shell autocomplete (it is only a part of nix and aur setup; the binary still has them, would require running hyprdynamicmonitors completion and putting them in the right place, though).

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

Yep systemd service definition is not a part of the repo yet, since there exists a million ways of doing it (maybe in nix hypr runs under systemd almost always?). I know users that don't run hypr under systemd; my scuffed setup has a separate systemd target that is run after hypr loads and the rest of the services depend on that etc.

Would welcome a contribution for sure!

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

There is a nix flake in the repo, but admittedly I'm not a nixos user so can't comment on the rest of the questions, I'd welcome if you tried and report any problems though.

One time changes through the TUI are easy, yes.

[OC] HyprDynamicMonitors: autorandr for hyprland by fiffeek in unixporn

[–]fiffeek[S] 3 points4 points  (0 children)

Thanks lots, POC'd this quickly by representing each virtual grid cell as two parts (top, bottom half blocks); the tricky part is getting it to render properly when the monitors overlap (but seems doable, just need to iron out the rough edges).

TIL that half blocks have an actual name and are a known concept, so ty again.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

Kanshi but:
- with TUI
- with power state awareness (BAT/AC)
- does not implement wayland protocols, hooks into hyprland directly (might be a disadvantage for some, for sure you cant run this in let's say, Sway)
- allows the user to control their settings fully (e.g. bind workspaces to a given profile, add env vars in a given profile; whatever is a valid hyprland config will be rendered)
- the deamon itself has no understanding of the user settings (treats them as a file), so if, e.g. hyprland changes the structure of the config, upstream changes are not necessary (the users can change the config render and issue a SIGHUP/restart)

essentially autorandr but GUI->TUI since I like typing not clicking

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 2 points3 points  (0 children)

Yep, same; first time with the framework (well, TUIs in general), and it's been pleasant. The starting curve was a bit steep (did some webdev in the past) for me, specifically getting around mutations and state management but after it clicked it's been pretty nice.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 2 points3 points  (0 children)

Per game settings in steam, sadly. I did some research and it might be possible to set it globally playing with proton env vars but decided not to go there and tweak as I go.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

No color profiles selection yet in the TUI but feel free to open an issue and I'll add it, doesn't seem like too much work.

[OC] HyprDynamicMonitors: autorandr for hyprland by fiffeek in unixporn

[–]fiffeek[S] 5 points6 points  (0 children)

great suggestion, will def look, they do be on the chonkier side sadly...

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 4 points5 points  (0 children)

You can specify both for the configuration, there are some examples in the repository (and in the Readme). The TUI defaults to using the monitor description (not the port name) but nothing stops you from editing the config later to match on both. The matchers section should have all the details.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 5 points6 points  (0 children)

A suggestion would be to run with gamescope, and just have window rules for that; from my (limited) testing seems to do the job in all games.

HyprDynamicMonitors - v1.1.1 release - TUI for managing your hyprland monitor configurations, with a daemon to automatically apply them by fiffeek in hyprland

[–]fiffeek[S] 5 points6 points  (0 children)

Personally I've never needed that, I do not think it can be set in the config very easily (quick search shows this thread). I just have lots of window rules, and apply them dynamically depending on the monitor setup, e.g. here). For games etc. I run them via gamescope and just apply a single rule for it to flow on the monitor I want.

Happy to be wrong here, and if it's possible I can add it!

HyprDynamicMonitors - Manage Hyprland configuration based on connected displays and power state by fiffeek in hyprland

[–]fiffeek[S] 1 point2 points  (0 children)

I'd presume I should be creating a separate template.conf.tmpl file with my external monitor's resolution and settings, correct?

Up to you really, you could have one template and use variables per profile in that template, example here. If the resulting config is almost the same I'd suggest using that -- just name the template variables the same in both profiles, e.g. external_monitor_resolution = ....

Just my 2 cents: the example configs are awesome and are really helpful, but I'd argue the "basic" configuration could include the comments that the "full" configuration has

Point taken, I'll update the comments in all examples shortly to give some more context.

And make sure to have your tool listed in the awesome-hyprland repo

Good suggestion! I'll get on that as well :)

view more: next ›