awesome

Welcome to awesome bug tracking system.
Tasklist

FS#687 - Stop restarting on XRandR event

Attached to Project: awesome
Opened by Julien Danjou (jd) - Wednesday, 25 November 2009, 12:06 GMT
Last edited by Uli Schlachter (psychon) - Tuesday, 16 October 2012, 15:20 GMT
Task Type Feature Request
Category Core
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version git/master
Due in Version 4.0
Due Date Undecided
Percent Complete 0%
Votes 19
Private No

Details

awesome should emits proper signals and just change the screens array.
Comment by eurekafag (eurekafag) - Thursday, 26 January 2012, 19:18 GMT
Awesome endlessly restarts when I launch Warzone 2100 or any other game (Wesnoth or Braid, for example) in fullscreen with resolution different from the desktop one. If I start the game on any tag except the first, it changes the resolution, Awesome restarts, set the desktop resolution and goes to the first tag. When I switch to the tag where the game is it restarts again and so on. Launching on the first tag is even worse because an infinite loop is created with Awesome changing the resolution to desktop at each restart and the game changing it back to a different one when being focused.
There's no way to use fullscreen apps with different resolution at all. I'm using Debian, Awesome 3.4.11 and NVIDIA proprietary driver 290.10. And I guess those 14 more people have this annoying bug, too. Please, consider fixing it anytime soon. I've donated €20 already and I would donate even more if you plan to fix it. That's the only bug which really makes me mad because Awesome is just awesome leaving alone this glitch. Thanks for your efforts.
Comment by Justus Piater (piater) - Tuesday, 08 May 2012, 06:46 GMT
I often attach or detach an external monitor or beamer to my laptop using xrandr, and every time all my tags and window arrangements are messed up. I expect them all to unaffected. I assume that fixing this bug will take care of this. Looking forward to awesome 3.5!
The only nontrivial behavioral question concerns windows on a screen that is detached using xrandr. For me, these should be moved to the current tag and minimized (to avoid messing with the current window arrangement). Or they could be moved to their respective tags on the current screen. Perhaps they should keep their minimized/... state. Or they could be made floating to avoid disturbing the window arrangement. This behavior should clearly be configurable.
Comment by dodo (dodo) - Monday, 14 May 2012, 17:01 GMT
have here a workaround flying around which saves me a lot of the reorder pain: https://github.com/dodo/uzful/blob/master/restore.lua

(sorry for the bad doc)

ps works only in git/master
Comment by Namikaze Minato (Camusensei) - Monday, 21 January 2013, 11:39 GMT
dodo, I'm fine with the documentation (of restore.lua) missing, but can you please explain what it exactly does?
Not everybody has hours of boredom to understand someone else's code ^^

And if it does what I hope it does, I might be interested as well, hence my question.
And if I missed the documentation for that file, sorry :/
Comment by Edd Barrett (vext01) - Wednesday, 06 November 2013, 22:46 GMT
+1 for this fix.

I have a tablet hybrid laptop and I use xrandr extensively to rotate the screen. Every time I do so, awesome restarts. The window layouts are lost and I am taken to desktop 1.

Cheers
Comment by Edd Barrett (vext01) - Wednesday, 06 November 2013, 22:47 GMT
When I say "this fix" I mean -- a fix for awesome, not the restore.lua script.
Comment by Uli Schlachter (psychon) - Monday, 31 March 2014, 12:50 GMT
Branch which gets rid of screen indexes *and* adds dynamic screen detection (no screens available when rc.lua is parsed, only added later via a signal):

http://git.naquadah.org/?p=awesome.git;a=shortlog;h=refs/heads/remove_screen_index
Comment by Uli Schlachter (psychon) - Wednesday, 09 April 2014, 21:29 GMT
The attached program listens for RANDR events and prints the resulting configuration. Useful for (a) learning about the RandR protocol (b) seeing which events are generated (sadly, lots of state is thrown away instead of just changed) and (c) useful for debugging problems with how awesome handles these events in the future.

Loading...