[RFC] improving exwm-randr

[fjl]

I'd like to improve exwm-randr so it fits my workflow better. At this time, the randr module allows one basic mode of operation where workspaces can be assigned to (named) outputs statically. This kind of works but I don't find it convenient. It would be nice if exwm-randr could just distribute workspaces on available outputs without having to configure anything.

When a new output comes up, it would just pick a workspace that is currently not displayed and show it there. The existing config variable could be used as a preference list, indicating which workspace should be chosen.

A new set of functions for managing outputs could be added:

exwm-randr-workspace-switch would select a different workspace on the current output. If the workspace is currently displayed somewhere else, this command would also move the current workspace to there (basically swapping them).

exwm-randr-disable-output would ensure that no workspace will be displayed on the given output. This is useful for cases where laptop lid is closed. It would be super nice to prompt for outputs interactively here.

exwm-randr-enable-output would be the opposite of the above command.

[ch11ng]

I think it's a good opportunity to improve the RandR module by removing its dependency on xrandr. The current implementation is damn simple and consists of only around 100 LOC, so I think it'd be easy to do this. We should keep it backward compatible by checking if exwm-randr-workspace-output-plist is set.

We need to work out a scheme of how to configure RandR outputs (including their geometries and whether some should be disabled) and where the workspaces should be put. Any ideas?

[medranocalvo]

Hello. I don't use multiple monitors at the moment. The behaviour you propose sounds similar to how XMonad used to manage workspaces in multiple displays. I found it quite sensible.

[zabbal]

I think RandR outputs could be configured automatically by smth like kscreen2 (in case of kde) or alike. I also find this proposal very similar to xmonad and hence a very good idea.

[bendlas]

I'd really like to see multi-monitor support improved. Are there any work-in-progress branches for this?

[ch11ng]

@bendlas I don't have any yet. Could you elaborate on the improvements you want?

[bendlas]

I need a way to move workspaces between outputs dynamically. In its simplest form that could just be the possibility to modify exwm-randr-workspace-output-plist at runtime to make it possible for the user to handle it anyway they want.

The look and feel I'm aiming for:

• When switching to a workspace, raise it to the output the workspace, I'm switching from, is located (similar to what's going on with buffers, when exwm-layout-show-all-buffers is t).
• Make it possible to send a workspace to a target output (maybe by switching w/ numeric prefix argument)
• Auto-create at least as many workspaces as there are outputs

I'm willing to help make this happen, but I have no experience with Xlib programming, let alone programming a WM.

[ch11ng]

@bendlas Thank you for the proposal! It seems what you only want is to make the currently static configuration method dynamic. It's of course viable but what I want is to also make other features like configuring RandR outputs possible. I'm a bit reluctant to implement the dynamic configuration feature first TBH.

[bendlas]

I was trying to thing of a minimal thing that I could use to experiment with and implement what I want, while leaving it on equal footing with alternative behavior.

Of course, from a designer's POV, that's pretty much a cop-out. OTOH, even for supporting a more declarative approach, the underlying Workspace to Output mapping would have to be dynamized, no?

Btw, there is, in fact, a completely alternative approach that crossed my mind and since you seem to be looking for such things, let me share it:

What if we have workspaces be separate entities from frames and map workspaces into frames? Exwm could then just keep a fixed frame per output and the user could display their workspaces however they like, subject only to the restriction of X buffers only being displayed in their most recently focussed containing frame.

Such a workspace module would have the advantage of being useful even outside of exwm (in fact, I have wanted such a thing even before becoming an exwm user), thus receiving wider attention and support.

[ch11ng]

@bendlas The concern is the potential change of public interfaces (something like exwm-randr-workspace-output-plist) which can be both confusing and annoying. So before implementing the dynamic mapping feature other features should at least be planned in advanced.

The "alternative approach" you proposed requires some fundamental changes in EXWM. I don't know if this is superior but it will unlikely happen in the near future.

[bendlas]

@ch11ng OK, it's good to know now, what you're aiming for. I do still think that a dynamic output-plist would be sufficiently data-driven to implement any other behavior on top, without requiring breakage, but yours is probably the better judgement.

FWIW, since the mapping is completely static right now, the dynamic mapping could start out as a completely separate module, that would just initialize from exwm-randr-workspace-output-plist, and thus retain complete compatibility per definition. The static plist mapping could then later be deprecated, if at all.

The "alternative approach" of workspaces being separated from frames just represents what would have been the least suprise to me. As far as I can tell, it should be functionally equivalent to dynamic output mapping anyway.

The only real alternative that comes to my mind, is to expand workspaces across multiple frames and thus switch all outputs at once, when switching workspaces. That's the way stumpwm does it but I do like the workspace-per-output approach of exwm much better. Especially since with dynamic mapping, stumpwm's behavior could be mimicked, but the reverse would be quite awkward.

[bendlas]

ad the original thread on how to configure the outputs in the first place: I don't think that exwm should inherently deal with that (any more than the current hook to call xrandr or similar). That's the job of the display-manager, isn't it? I'm comforable with using xrandr directly (e.g. when attaching a beamer) and people who aren't can use gnome-control-center or any of the other graphical tools.

In my view, exwm should only read the randr state and use that as an input to it's workspace-output mapping. Semi-automatically discovering and configuring outputs, while retaining manual configurability seems like a real piece of work to me and it should not hold up our ability to use already configured outputs well.

Of course, if workspace-output mapping was moved into core, exwm-randr could be used to develop a configuration system for the outputs themselves, but entangling output mapping and output configuration feels like a layering violation to me.

[bvk]

@bendlas

I have the following dynamic exwm-xrandr configuration which is working (somewhat) reasonably for me. I primarily use external monitor at work and home. But at work I connect the monitor using a HDMI cable where as at home I connect the monitor using DisplayPort cable. So, I need to be able to switch displays dynamically after I resume my laptop from sleep. Here is my configuration:

;; Enable two xrandr outputs one named 'default' and another named 'other'.
(defun my-exwm-xrandr-enable (default other)
  (start-process-shell-command
   "xrandr" nil (concat "xrandr --output " other " --right-of " default " --auto")))

;; Enable only one xrandr output named 'default' by disabling others.
(defun my-exwm-xrandr-disable (default)
  (start-process-shell-command
   "xrandr" nil (concat "xrandr --output " default " --auto")))

;; Update exwm-randr-workspace-output-plist with two outputs named
;; 'default' and 'other'.  If the 'other' output is same as 'default'
;; then all workspaces will be redirected to the 'default' output.
(defun my-exwm-xrandr-config (default other)
  (setq exwm-randr-workspace-output-plist
	(progn
	  (setq result (list 0 default))
	  (setq index 1)
	  (while (< index exwm-workspace-number)
	    (setq result (append result (list index other)))
	    (setq index (1+ index)))
	  result)))

;; Dynamically find the active xrandr outputs and update exwm
;; workspace configuration and enable xrandr outputs appropriately.
(defun my-exwm-xrandr-hook (default)
  (let* ((connected-cmd "xrandr -q|awk '/ connected/ {print $1}'")
	 (connected (process-lines "bash" "-lc" connected-cmd)))
    (cond ((member "DP1" connected)
	   (progn (my-exwm-xrandr-config default "DP1")
		  (my-exwm-xrandr-enable default "DP1")))
	  ((member "DP2" connected)
	   (progn (my-exwm-xrandr-config default "DP2")
		  (my-exwm-xrandr-enable default "DP2")))
	  ((member "HDMI1" connected)
	   (progn (my-exwm-xrandr-config default "HDMI1")
		  (my-exwm-xrandr-enable default "HDMI1")))
	  ((member "HDMI2" connected)
	   (progn (my-exwm-xrandr-config default "HDMI2")
		  (my-exwm-xrandr-enable default "HDMI2")))
	  (t (progn (my-exwm-xrandr-config default default)
		    (my-exwm-xrandr-disable default))))))

(setq exwm-randr-screen-change-hook
      (lambda () (my-exwm-xrandr-hook "eDP1")))

Note that "eDP1" display refers to the Laptop display output. My laptop has two DisplayPort outputs (DP1 and DP2) and two HDMI outputs (HDMI1 and HDMI2). When external monitor is connected above configures workspace-0 to laptop display and all other workspaces to the external monitor; otherwise configures all workspaces to the laptop display, i.e., when no monitor is connected.

I still face some problems -- like external monitor is not detected -- frequently, in which case I use kill-emacs to restart the X session.

@ch11ng

Is there a way I can dynamically send ScreenChangeNotify event to exwm, perhaps using a key-binding?

[ch11ng]

@bvk Do not use start-process-shell-command as the commands can be executed out-of-order. Use something like shell-command instead.

Is there a way I can dynamically send ScreenChangeNotify event to exwm, perhaps using a key-binding?

The event is generated by X server when it detects something changes. Why would you need that?

[bvk]

Thanks for the shell-command suggestion. I didn't know about that.

I noticed that exwm doesn't call exwm-randr-screen-change-hook when I disconnect the HDMI cable (but DisplayPort cable works just fine). I was hoping if I can generate ScreenChangeNotify event manually, exwm will invoke exwm-randr-screen-change-hook which will update xrandr outputs as necessary.

Currently I run xrandr -q command (through a keybinding) every time after I disconnect the HDMI cable and it seems to trigger the exwm screen change hook.

[ch11ng]

Only X server is responsible for generating that event. I have no HDMI port to produce the problem but could you tell if the hook is run but failed to configure the screen when you disconnect the HDMI cable?