Better docking / multimonitor support wrt xrandr settings

[tumbletree]

The problem you're addressing (if any) Transition from laptop (mobile) to laptop on the docking station is needlessly time-consuming and workflow-disruptive.

Qubes/xrandr reconfigures from laptop-in-dock to laptop-mobile automatically, just fine.

Returning to laptop-in-dock triggers Display, which requires several clicks, two dialog boxes ("Display" and "Advanced") and a manual click-and-drag to position laptop beneath the external monitor.

There is NO option to save configuration.

This is an inexcusable timesuck.

Describe the solution you'd like A VERY simple "save config" option. Easy to set, then never worry about it again, until such time as one needs to edit the settings (e.g. new setup, equipment).

Guiding principle: docking a laptop should take ZERO brain-space. Other things are more important.

There is a solution called autorandr, but I have no experience of it. Its not natively available by $ sudo qubes-dom0-update autorandr. I am not overly keen on installing something 'from outside' into dom0.

I now have an alias, but its still awkward (open terminal, type, close terminal). EDIT also now have panel launcher, which is better.

Where is the value to a user, and who might that user be?

USER: Anyone and everyone that uses a dock, or switches monitor arrangements.

1. VALUE: Productivity. a computer is a tool to do work with, not to do work on - (unless that's your job or hobby). The more invisible the workings, the better.

2. VALUE: Qubes has a lot of quirks and necessary inconveniences to achieve reasonable security. Fine. But inevitably they add to a cognitive load for using Qubes. Resetting the same monitor configurations for the N-th time adds to that load, (as does a couple of days fruitless searching for a solution) but brings nothing to security. Its a parasitic load.

3. VALUE: integrated usability / productivity measures promote security, since people are less likely to find risky shortcuts. In this case, its a motive to install an external package to dom0.

Describe alternatives you've considered

1. just dealing with it: but I've had enough of that.
2. create an alias for custom xrandr command, and launch terminal on docking.
3. make a keybinding or shortcut key in Setting Editors - not having any luck (just doesn't seem to work)
4. similar to 3, but using a panel launcher. Currently working well, but if xrandr were to throw an error and not display that part of the screen on the monitor, it wouldn't work.
5. tried to adapt these instructions, but not sure where to put in them to get it working in dom0. (nb - no, not using tiling) and not sure how to find the event (add new monitor) to make it work automatically.

Additional context Add any other context or screenshots about the feature request here.

Relevant documentation you've consulted quite a lot, mostly xfce-related material including its docs.

Related, non-duplicate issues A list of links to other bug reports, feature requests, or tasks in the qubes-issues tracker. Do not describe any other unreported bugs, features, or tasks here.

EDITED for clarity, detail.

[andrewdavidwong]

Are you sure that this is a Qubes-specific problem? I wonder if the same problem occurs on baremetal Fedora with Xfce4.

[tumbletree]

Andrew - no, I'm not at all sure its Qubes specific. I don't have the wherewithal to find a machine to test that with a baremetal Fedora installation.

dom0 runs on, what, Fedora 26? That's not a criticism, I understand that there's been a lot of development and security-work gone into this. But:

1. Maybe Fedora 32 - which is what I'd install on a machine if I was testing this - has these issues sorted?
2. Its worth noting that someone developed 'autorandr' to fill a need.

The problem with installing 'autorandr' is that, as you guys point out, installing into dom0 compromises the security of the Qubes model.

I'd also say its the same case with screen temperature modifiers, iirc.

These are important usability features. I'd say they get very close to essential for many users. We shouldn't have to compromise security to have a system that work smoothly.

[andrewdavidwong]

dom0 runs on, what, Fedora 26?

In Qubes 4.0, dom0 runs on Fedora 25.

Maybe Fedora 32 - which is what I'd install on a machine if I was testing this - has these issues sorted?

It is possible, but we won't know until someone tests it.

The problem with installing 'autorandr' is that, as you guys point out, installing into dom0 compromises the security of the Qubes model.

I'd also say its the same case with screen temperature modifiers, iirc.

These are important usability features. I'd say they get very close to essential for many users. We shouldn't have to compromise security to have a system that work smoothly.

Unfortunately, there's often a trade-off between security and convenience. However, it's important to keep certain things in mind:

• With each new Qubes release, the version of Fedora in dom0 is updated. For example, in Qubes 4.1, dom0 runs on Fedora 31. So, if you're willing to be a tester, it might be worth trying out 4.1.
• Although we urge caution when installing programs in dom0, it is not forbidden. If some piece of software is essential for you to have in dom0, and you trust it enough, you can install it (see here for more). This is a decision that each user has to make for themselves. Many users have decided to install select pieces of software in dom0.
• The advent of the GUI Domain promises to ameliorate many of these problems.

[fepitre]

On 2020-07-07 12:37, Andrew David Wong wrote:

dom0 runs on, what, Fedora 26?

In Qubes 4.0, dom0 runs on Fedora 25. https://www.qubes-os.org/doc/supported-versions/#dom0

Maybe Fedora 32 - which is what I'd install on a machine if I was testing this - has these issues sorted?

It is possible, but we won't know until someone tests it.

The problem with installing 'autorandr' is that, as you guys point out, installing into dom0 compromises the security of the Qubes model.

I'd also say its the same case with screen temperature modifiers, iirc.

These are important /usability/ features. I'd say they get very close to essential for many users. We shouldn't have to compromise security to have a system that work smoothly.

Unfortunately, there's often a trade-off between security and convenience. However, it's important to keep certain things in mind:

• With each new Qubes release, the version of Fedora in dom0 is updated. For example, in Qubes 4.1, dom0 runs on Fedora 31 https://www.qubes-os.org/doc/supported-versions/#dom0. So, if you're willing to be a tester https://www.qubes-os.org/doc/testing/, it might be worth trying out 4.1.

A little update is needed on the website. New 4.1 will run on Fedora 32.

• Although we urge caution when installing programs in dom0, it is not forbidden. If some piece of software is essential for you to have in dom0, and you trust it enough, you can install it (see here https://www.qubes-os.org/doc/software-update-dom0/#security for more). This is a decision that each user has to make for themselves. Many users have decided to install select pieces of software in dom0.
• The advent of the GUI Domain https://www.qubes-os.org/news/2020/03/18/gui-domain/ promises to ameliorate many of these problems.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/QubesOS/qubes-issues/issues/5923#issuecomment-654763012, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHKKJZU6PZVZMJ5WQV3ETLR2L3FXANCNFSM4OOUSVYA.

Best, Frédéric

[andrewdavidwong]

A little update is needed on the website. New 4.1 will run on Fedora 32.

Thanks, updated!

[tumbletree]

Thanks both for your responses. I will have a little time in the near future, and so I might look at trying 4.1.

Thanks again.

[UndeadDevel]

@tumbletree If this is still a problem for you, try setting a profile in the Display settings when the external monitor is connected and configured and also activate both options under "Connecting Displays"; for me on Qubes 4.2 this will automatically restore the previously set config when I connect the same monitor.