=== brainwash_ is now known as brainwash [09:14] Unit193: would you be interested in sponsoring catfish 1.4.10 into debian? [09:15] Sure, anything else to add? [09:15] (It's set to unreleased) [09:18] Unit193: nope, should be ready to go otherwise [09:21] OK, please commit and sign (perhaps after the ACK). I uploaded. [09:34] Unit193: much appreciated! [17:52] ochosi: i have 4.14.1 and it behaves exactly the same [17:55] also still got the thing where only two of my monitors go to sleep [17:56] if i do "xset dpms force off" then they all turn off [17:56] i think this rules out cable problems [17:57] although i notice there are three different levels: blank, sleep, off [18:06] hmm... i set power saving like this https://imgur.com/yf7ppYE.png [18:06] after 1 minute all monitors turn off, then 1 minute later one of them turns back on, then 1 minute later it turns off again [18:14] i tried setting each setting to 1 minute and the others to never, in all three cases all monitors switched off [18:17] it seems like whatever order the three settings are put in, the second one always causes 1 monitor to turn on [18:18] i tried swapping the outputs around and the same monitor still turns on so maybe it is the cable [18:20] "xset dpms force off && sleep 15s && xset dpms force off" does not make one monitor turn on though [18:32] hmm power manager is just calling DPMSSetTimeouts so this cannot be an xfce bug [18:39] yeah i reproduced it with just xset [19:29] i read the product descriptions of these cables really carefully and it turns out the cable that works is bi-directional, the one that doesn't work properly is not [19:29] i dont see why that would affect anything but i guess the not-bidirectional one is just rubbish [21:08] okay, on to the other problem... if i kill xfsettings then my monitors dont all turn off when i unplug one, and it turns on again when i plug it back in [21:08] and honestly this is how i want it to behave [21:09] also i found that this problem only happens with 3 or more monitors so i suspect it actually is a bug [21:15] ah, i think i found the problem [21:15] if i unplug my middle monitor it doesn't happen [21:15] he other two are identical [21:21] how do i get xfsettingsd to print the debugs? [21:26] ah i have to set an environment variable... okay [21:30] hmm okay so xfsettngsd is going bananas - whenever the monitors change it tries to reconfigure every monitor about 4 times [22:38] ali1234: ok, so i tried to read carefully, but what was the remaining problem? something after killing xfsettingsd? [22:39] the remaining problem is that when i unplug a monitor, xfsettings turns off all my monitors, permanently [22:39] that is very curious [22:39] i think i've never seen that at all so far [22:39] it has an extra check to never disable *all* monitors [22:40] so always at least one should remain, although that check may only be valid for laptops - would have to check in the code [22:41] yeah none of that is what happens [22:41] just a debug idea, have you tried to save a profile for the two remaining monitors? [22:41] that way it should know what to do when you unplug [22:41] what happens is it gets confused about what monitors are connected, then goes on a rampage disabling things, trying to re-enable things that no longer exist, and eventually just gives up when it has disabled everything [22:42] this is the debug output after i unplugged one monitor: http://paste.ubuntu.com/p/mp36hM584M/ [22:44] line 70 is where i plugged it back in, due to having a saved profile it eventually managed to restore the settings [22:48] and saving a profile for 2 monitors? [22:48] and yeah, urgh, doesnt look nice. i wonder though why it would fail to configure your monitors [22:51] well it thinks the screen is 1280x176, which is too small for any of the monitors to fit on [22:53] that's what randr is telling it though [22:53] i doubt that [22:53] well it surely doesn't invent the number :) [22:53] right, it didn't. 176 is the vertical position of some of the monitors, not the height [22:54] so somewhere there is a foo->y instead of foo->height or something [22:58] indeed helper->height seems to be off in your case [23:01] ok, so your analysis seems to match the code to some extent [23:02] it checks whether if any crtcs won't fit into the new screen and as the height is fairly low, it ends up disabling them all [23:03] and in xfce_displays_helper_set_screen_size your height seems to actually be helper->y [23:06] ali1234: would you mind adding this debug statement? http://dpaste.com/1F7QWWA [23:07] just to see if it all goes wrong in line 1267 of xfsettingsd/displays.c [23:08] building it [23:09] helper->height should be set 0 before this function is called [23:09] hang on let me log in to irc from my laptop [23:09] that's why i thought we probably don't need that value (and that's also in part what i don't understand about line 1267... cause 0 can hardly ever be MAX) [23:11] but then again, that code wasn't written by me and i have a hard time understanding some parts... [23:14] size=433x3200, pos=1200x1280 [23:15] wait [23:15] you messed up the printf :) [23:15] you have more arguments than formats [23:17] ah sure :) [23:17] i didn't test, sorry [23:17] http://paste.ubuntu.com/p/n2YgbQgZHs/ [23:18] luckily that's easily fixable [23:18] thats startup, before i do anything [23:18] the numbers are right there [23:18] total screen size looks ok there [23:20] http://paste.ubuntu.com/p/y9XHXsQJFZ/ then after unplug, the numbers are very wrong [23:22] i guess you can try to further debug line 1267 which (wrongly?) calculates height in your case [23:22] the problem is without being able to reproduce it's hard(er) [23:37] okay i found something [23:37] scalex and scaley are 0 [23:38] so width * scale = 0 [23:39] so helper->width becomes min(0, crtc->x) [23:43] i think i see the problem [23:43] when it starts up it loads all the properties from xfconf, including the scale [23:44] when it gets a change event it rebuilds the randr cache but does not set the scale on the new objects [23:45] if you have only onemonitor then it must be at pos=0,0 [23:45] this results in helper thinking the screen is 0x0 [23:45] there is probably a sanity check for this [23:45] however if you have twomonitors then one of them is not at 0,0, the position of this monitor ends up being how big helper thinks the screen is [23:45] this confuses it [23:50] when there is a matching profile itgets the scale from the profile [23:52] initializing the scale to 1.0 prevents it from doing weird stuff [23:54] sounds like a simple patch [23:54] yeah. not sure if it is entirely correct though [23:54] i'll make a bug report with the details [23:54] when i get out from under my desk [23:54] in what sense? that you set the scale to 1.0 initially? [23:55] brb [23:55] sure [23:56] so the problem is that https://github.com/xfce-mirror/xfce4-settings/blob/master/xfsettingsd/displays.c#L1266 scalex = 0 [23:56] scalex is initialized here https://github.com/xfce-mirror/xfce4-settings/blob/master/xfsettingsd/displays.c#L849 [23:57] that code only runs when loading a profile [23:57] the rest of the crtc is initialized here https://github.com/xfce-mirror/xfce4-settings/blob/master/xfsettingsd/displays.c#L1113 [23:57] but not the scale [23:57] so if there is no matching profile, you get scale = 0 [23:58] that messes up all the calculations [23:58] so the question is should list_crtcs initialize the scale to 1 [23:58] or should it try to fetch the real scale, and if so, from where? [23:58] now i write all this in a bug report :)