Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HiDPI Daemon Puts All Applications on a single Workspace #9

Open
LearnLinuxTV opened this issue Dec 29, 2017 · 4 comments
Open

HiDPI Daemon Puts All Applications on a single Workspace #9

LearnLinuxTV opened this issue Dec 29, 2017 · 4 comments
Labels

Comments

@LearnLinuxTV
Copy link

Reporter info

 * Distribution - Ubuntu 17.10 64-bit
 * Related Application and/or Package Version - system76-driver 17.10.11

Issue/Bug Description
Normally, when you are working with multiple displays, GNOME will move applications back to the monitor they were on when you reattach a display. With the HiDPI driver, all applications are placed on a single workspace, forcing the user to manually drag all the applications manually back to the desired workspace.

Steps to reproduce (if you know)
1.) Attach an external display
2.) Open several applications, but them on different workspaces
3.) Remove the external display, then reattach it
4.) All the applications you had open are now on a single workspace

Expected behavior
By default, GNOME will place applications back to the workspace they were on before disconnecting the display. The HiDPI driver circumvents this GNOME feature and forces users to do this manually.

@LearnLinuxTV
Copy link
Author

In speaking with Jeremy and working with him on reproducing this, we determined that this is a GNOME issue and is triggered when switching monitor configurations while also having the option enabled that utilizes workspaces only on the main display. This is a consequence of having to redo my monitor configuration manually due to the HiDPI daemon not remembering settings, but the underlying issue is GNOME-related and not specific to the HiDPI daemon.

Therefore, we can either close this, or keep it open to track this issue. Please let me know your thoughts.

@djordan2
Copy link
Contributor

This is a GNOME issue, but improvements to the HiDPI daemon reduce the need for manual configuration.

@brs17
Copy link
Contributor

brs17 commented Mar 19, 2018

@jlacroix82 So @djordan2 did what he could to make the HiDPI daemon work as nicely as it can with upstream GNOME. The appropriate thing would definitely be to file a bug upstream. Would you like to do that or shall I?

@brs17 brs17 added the upstream label Mar 19, 2018
@LearnLinuxTV
Copy link
Author

@jlacroix82 So @djordan2 did what he could to make the HiDPI daemon work as nicely as it can with upstream GNOME. The appropriate thing would definitely be to file a bug upstream. Would you like to do that or shall I?

I thought there was already a bug for this, I'm not able to find it right now but I'll look again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants