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);
2. This assumes XRandR enumerates its screens in some deterministic
order. Maybe it does, I haven't looked.
I'm not sure what the problem is though---is there some significant
overhead I'm overlooking?
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
