~edrex

Portland, Oregon

https://edrex.pdxhub.org

I'm a broad and knee-deep systems thinker. I like to be peripherally connected to many different communities, and look for opportunities to bridge gaps everywhere.

I'm a capable software tester, researcher, polyglot programmer, lazy operator, and documentarian.


#72 Feature: relative output positioning 2 years ago

Comment by ~edrex on ~emersion/kanshi

A downside is that kanshi's output config lines become a superset of sway's.

#72 Feature: relative output positioning 2 years ago

Ticket created by ~edrex on ~emersion/kanshi

As a user, I would like to include a resolution-independent fallback rule in my config that positions outputs relative to each other, to prevent overlapping.

This is possible under X11 via the xrandr(1) --output subflags --left-of, --below, --above, --right-of, however it's not quite feature complete since there's no way to specify alignment (eg left right or center for --below).

I'm not attached to any specific syntax (or this particular approach, if there's another way to provide a robust default for novel display sizes). Here's a proposal to start from:

profile docked {
  output "eDP-1" below "eDP-1" align "center" scale 2.000000
  output "DP-1" position 0,0 scale 1.000000
}

Here align (center, left, right, top, bottom) would only be valid if one of above, below, left-of, or right-of is specified.

I also considered overloading position to take a value like center,below("DP-1") but parsing into the values seems over complicated.

If kanshi itself could learn to do this, I would be satisfied with output config under wlroots (currently it is a daily headache manually setting output positions).

@emersion WDYT, in-scope for kanshi? Other ideas for how users could solve this problem?

I'd be open to working on this feature if there's interest.

#37 dmenu mode stale cache 4 years ago

Comment by ~edrex on ~scoopta/wofi

~scoopta oh, I was just checking on this and was surprised to see you've implemented it, thank you! 🎉 Tested latest with my custom dmenu sway nav scripts and no more zombie cache entries clogging the top 10. 🧟

#37 dmenu mode stale cache 4 years ago

Comment by ~edrex on ~scoopta/wofi

ah, i realized the cache is tracking previous selections, which is useful.

So the bug is that it's displaying cached items even if they aren't present in stdin (may effect other modes too).

#37 dmenu mode stale cache 4 years ago

Ticket created by ~edrex on ~scoopta/wofi

I was getting some weird results trying to use wofi with my dmenu-style i3 container nav script. Windows from a previous session showing up in the results. I noticed that if I ran just wofi -d with no stdin, the stale results still showed. I found wofi -d loads results from a cache and merges them with stdin. This doesn't seem right.

#7 support capture via wlr-export-dmabuf protocol 4 years ago

Ticket created by ~edrex on ~scoopta/wlrobs

If I read correctly, wlrobs is currently using wlr-screencopy-unstable-v1 for capture, which I assume is what's causing sway's CPU usage to spike when capturing. If I understand correctly, the export dmabuf protocol should allow for much more efficient capture.

#Refs

https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml

https://github.com/swaywm/wlroots/blob/ca45f4490ccce64bf7aa0985951319646b55d258/examples/dmabuf-capture.c

#6 obs crashed even though the plugin is loaded 4 years ago

Comment by ~edrex on ~scoopta/wlrobs

oops, above is different issue (missing preview, no crash)

#6 obs crashed even though the plugin is loaded 4 years ago

Comment by ~edrex on ~scoopta/wlrobs