On Sat, Sep 13, 2014 22:57, Thomas Adam wrote: > On Sat, Sep 13, 2014 at 09:49:06PM +0100, Dominik Vogt wrote: >> On Sat, Sep 13, 2014 at 09:41:25PM +0100, Thomas Adam wrote: >>>> But I had already fixed the crash in the morning. Didn't you see >>>> the message? The one that said that "True == 0" in x and I >>>> checked a function returning True agains 1? >>> >>> I did---I've been running with it all day. :) >> >> Are you sure you really had an executable with the patch running? > > Yes, 100%. I always check with strings(1), etc. I'll keep an eye on > it, should it ever come back. > >> It's really crap that with xrandr you have to address monitors by >> name. Can't we restore all the old logic for the users of >> FScreen.[ch] and just sort the xrandr monitors in a way that >> matches the old numbering, i.e. 0 = global monitor and the rest in >> a constant order that doesn't change when new monitors are added? > > Maybe. But the problem there is two-fold: > > 1. Mapping existing Xinerama screens with their ordering to the _same_ > screens which XRandR reports (which we don't know, unfortunately); Perhaps this document would help to understand it better: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
> 2. This assumes XRandR enumerates its screens in some deterministic > order. Maybe it does, I haven't looked. Try 'xrandr --verbose' to get more information. This helps me to get some parts for gmgrandr - a GUI to handle monitor settings with FVWM. The tool isn't finished but displays the different information of attached displays. To be noted: the primary screen which can be set since xrandr 1.3 isn't ever the primary screen, e.g. on my Lenovo laptop the primary one isn't the LCD but the connected VGA! Normally it is the LCD but not ever :-/ -- Thomas -- -- -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -- Albert Einstein
