allow cycling between different modes

Bug #315090 reported by wvengen on 2009-01-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Common behaviour of Fn-F7 keys on a laptop is to switch between three modes: built-in / external / clone. While disper auto-detects the attached displays, cycles like the one mentioned needs invocations of disper with different command-line options. It would be convenient to be able to bind a single disper-command to a hotkey and cycle through the desired modes.

wvengen (wvengen) wrote :
Changed in disper:
importance: Undecided → Wishlist
status: New → Confirmed
wvengen (wvengen) on 2009-02-16
Changed in disper:
assignee: nobody → wvengen
wvengen (wvengen) wrote :

A wrapper script that implements a toggle feature can be found at
Thanks, dino!

wvengen (wvengen) wrote :

A little information for implementing the cycling feature in disper.

== The idea from a user perspective ==
There will be an option to give ensembles of options through which disper will cycle. The current state is detected, and the next one activated. The exact notation is not finished, but it can be for example:
  # toggle between single, clone and extend
  disper --cycle "-s", "-c", "-e"
  # cycle through three monitors
  disper --cycle "-d CRT-0 -s", "-d DFP-0 -s", "-d DFP-1 -s"
When a configuration is requested for which no monitors are connected, that one is probably skipped. So the latter would behave as `disper --cycle "-d CRT-0 -s", "-d DFP-0 -s"` when DFP-1 is not connected. How exactly this should behave is still uncertain.

An alternative syntax might be
  # cycle between DFP-only, extend and secondary-only
  disper -s -d DFP-0 --cycle -e -d DFP-0,CRT-1 --cycle -S
so multiple ensembles would be separated by the option --cycle.

== What would be needed for development ==
1. Split off option parsing so that different option-ensembles can be parsed separately
2. Integrate into getopt parsing routines
3. Detect the current state (may be quite some work)
4. Compare the current state with the option-ensembles (probably quite some work)
5. Decide which option-ensembles are valid for the detected hardware state
6. Activate the next one in line

If you have suggestions or remarks, please feel free to make them. I don't have the time right now to get this done, but once the design is clear it will be easier to implement it step-by-step.

wvengen (wvengen) wrote :

(developer note:) current trunk has a reworked disper main that can run disper multiple times from the same python script with different arguments; this is one step to solving current bug (1. is done).

wvengen (wvengen) wrote :

Dear users, any preference for how to specify cycling on the command-line (see post #3) ?

Anders Aagaard (aagaande) wrote :

This one looks cleanest to me.
disper --cycle "-d CRT-0 -s", "-d DFP-0 -s", "-d DFP-1 -s"

Then again if you mix it with the last command specifying DFP-0,CRT-1 it becomes:
disper --cycle "-d CRT-0 -s", "-d DFP-0 -s", "-d DFP-1,CRT-1 -s"

Just thinking out of the box here, how about reading it from file/stdin?
echo "SINGLE CRT-0\n SINGLE DFP-0\n CLONE DFP-0,CRT-0" | disper --cycle?

Not sure it's better, just throwing the idea in there.

wvengen (wvengen) wrote :

Hi Anders, thanks for the idea, I hadn't thought of that.
Currently the best approach until seems to me:
* add the action --cycle (and -y?)
* add the option --cycle-stages="-e -d CRT-0, -s" comma-separated list of argument combinations
This allows one to set a default --cycle-stages in ~/.disper/config and use --cycle to cycle but still allow other invocations and override of the cycle stages from the command-line.
Still need a better word for '--cycle-stages'. Other options and reasons why still welcome!

Christoph Buchner (bilderbuchi) wrote :

I personally would model closely after the laptop Fn-F7 method, this is what users will expect as functionality. I think the most frequent one is cycling through: Single (laptop)->Mirror->Single (extern). I would suggest just adding Extended Desktop (i.e. disper -e) to the cycle (maybe as an option).
This would be perfect to be bound to the keystrokes (for my laptop it's Fn-F4 btw), or implementation as a Gnome-panel plugin. This also could contain a simple menu for configuring the cycle options (like many laptop manufacturers have a small applet to do configuration)

Christoph Buchner (bilderbuchi) wrote :

seems I spoke too hastily regarding the GUI - seems to be well underway (LP#619897) - although I can't find the package hinted at in comment #11...

wvengen (wvengen) wrote :

Hi Christoph, thanks for your comments. That would indeed be a sane default. This could be done by making "--cycle=-s,-c,-S" the default, which could still be overridden by ~/.disper/config and the command-line.

Adding a configuration dialog to the GUI would be useful. But we'll first release the applet :) I don't know why you can't access the code in bug#619897 comment#11 , you could try again and comment there what the problem was (or mail me directly).

sounds reasonable.
@code: seems i misunderstood, i can/could access the code alright, but from the word "package" i expected a .deb ubuntu package or ppa or something. I'll just wait for a proper release...

one additional comment: i don't know if there's a way to find out via the OS which key (combo) switches monitor configs on laptops (e.g. Fn-F*), but if there is it would be great if disper could automagically attach to this, so there's no more user config action necessary to attain the (imho) expected functionality (i.e. switch via key like in windows). don't know if that's easy or even possible to implement, so definitely wishlist.

wvengen (wvengen) wrote :

FYI: just committed default config file reading and initial crude shot at cycle functionality.

Automatically binding to Fn-F* key would be cool, no idea how to get that info.

xev is what you may be looking for (at least to get info about key-combos). if not automatically, you could prompt the user to press the key combo, intercept via xev, find out the keycode... doesn't work in all cases, though, some fn keys seem to be hardwired or whatnot.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers