[00:17] well, it doesn't crash or corrupt any more, so that's something [00:18] in fact i think it's working perfectly :) [00:19] or not... it's not copying the pixmap [00:43] jjfrv8: Welcome back. [00:44] I was working on my desktop and knocked the cable out of my pi :) [01:00] Hey, is anyone around that I can ask about the wallpaper submission requests? [01:00] I want to make sure that I'm reading a requirement right "No branding assest like "Xubuntu logo" or text to permit use by derivative distributions [01:01] So explicitly no text on the wallpapers? [01:01] in general no text is best, since we can't really translate wallpapers ;) [01:02] makes sense [01:02] I was surprised at the "no xubuntu logo" requirement. I guess that's very considerate of them [01:02] yeah, we have downstreams that use xubuntu as a base, we don't want to overbrand [01:02] There seems to be no expression of a "submission limit" - anyone see any issues with me submitting multiple cantidates? [01:03] that's fine [01:03] I think we might restrict it to 1 next cycle though :) [01:03] yeah makes sense [01:03] awesome, thanks a lot [01:03] really appreciate it [01:03] thank you! [01:05] ah! it works! [01:05] it just doesn't redraw itself now [01:10] cool. this code now actually works with old style SETROOT wallpapers, and also works with xfdesktop without exploding... and also doesn't have any flickering [01:34] brainwash, ochosi: please test background branch on my xfwm4 repo... it should fix everything [01:35] you won't even see the wallpaper flicker if xfdesktop crashes, and if you kill it (5 times) you can even set the wallpaper with hsetroot etc [01:42] xfdesktop crashes? [01:52] crashes/is killed :) [01:54] eric_the_idiot: this whole epic thing has been about having the wallpaper stay the same from greeter startup to fully logged in... it's now possible, but i had to fix many bugs in the greeter, xfwm4, and xfdesktop :) [01:55] it all boils down to each one implementing http://www.eterm.org/docs/view.php?doc=ref#trans in a slightly different and incompatible way [01:55] any other patches for xfdesktop? [01:56] tomorrow, yes [01:56] see the post i just did on xfce-dev [01:56] will do [03:24] hello [03:25] Howdy. [08:53] morning evryone [08:53] evening ochosi [08:53] ali1234: that sounds great! [09:32] hullo [09:34] heya knome [09:35] updated the submissions page, as you'll have noticed [09:35] yep [09:36] also added that note with a link to the history [10:07] can you tell me how xfce in xubuntu provides the gtk-3.0 theme-name? [10:07] i'm not sure i follow... [10:07] i am trying awesome within xubuntu, but not all gtk(3)-apps use the correct theme although i have ~/.config/gtk-3.0/settings.ini [10:08] when i start the xubuntu-session, all apps have the correct theme, but not in awesome [10:08] koegs: how do you set your theme in awesome? [10:09] oh, and, let's take this to #xubuntu [10:09] ochosi: with ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini [10:09] ok, i wasnt sure because of the awesome-thingy :) [10:10] if it isn't suitable for #xubuntu because you have a non-default component, it isn't really suitable in #xubuntu-devel either [10:10] i mean, the question is fine, but by your logic... [10:12] yeah, not the best logic :D [15:01] good afternoon all [16:33] ali1234: screen corruption remains and light-locker behaves really odd (cursor jumps around occasionally) [16:34] and there seems to be a brief black screen flicker when xfdesktop launches [16:34] reinstall everything [16:49] ali1234: the black flicker is new since I've compiled the background branch like 30min ago [16:49] when does it happen? [16:49] exactly when xfdesktop launches, before the icons get displayed [16:52] replaced xfwm4, locked the screen and everything works, no screen corruption [16:52] no cursor jumping [16:54] replaced with what? [16:55] mutter [16:56] or even with the unpatched xfwm4 I guess [16:58] so what happens if you kill xfdesktop first? [17:01] it happened even if xfdesktop was not started at all [17:02] ali1234: sorry, i haven't been able to test your xfwm4 branch up to now, i'll try to get to it though [17:03] it's the background branch, right? [17:03] yes, already did some testing [17:04] but xfwm4 is somehow causing the screen corruption [17:05] and I've noticed a brief black flicker when xfdesktop launches [17:05] so what doesn't work for you now? [17:05] and that's it? [17:05] well, lets see if you can confirm this black flicker [17:05] yeah, am about to reboot.. [17:05] brb [17:07] i don't have any problems with the background branch [17:07] i mean there is a flicker, but that's xfdesktop [17:07] because i'm using the unpatched version from the 4.12 PPA atm [17:07] :D [17:08] ok, what about lightdm locking? [17:08] just normal locking or suspend-locking? [17:08] normal [17:08] k [17:08] and/or via "dm-tool lock" [17:09] totally fine [17:09] no problems whatsoever with that [17:09] ok :( [17:09] could be an amd issue [17:09] or i dunno [17:09] I start thinking the same [17:10] alternatively, how clean is your build/test-env? [17:10] no hints in any of the log files [17:10] or have you tried with the open drivers? [17:10] it's messed up one [17:10] well, it needs to work with the restricted one [17:11] but I'll test the open source one too [17:12] there should not be any flicker at all with the new code [17:13] and there should not be any theme issue [17:14] lets wait for ochosi to test the patched xfdesktop [17:14] ali1234: yeah, i have to switch back to the patched xfdesktop... [17:14] i didn't patch xfdesktop yet [17:14] the latest commit? [17:14] git [17:15] you should get one transition from the greeter wallpaper to the user wallpaper, and no flicker [17:15] i'll use git master of xfdesktop now [17:16] well yeah, you do need *that* patch i guess :) [17:16] i forgot about that one [17:16] ;) [17:16] brb [17:18] ok, so i do get a brief moment of corruption when xfdesktop loads the wallpaper [17:18] but there is no grey/white/black flicker [17:18] i'll try to log out and in again to see whether i can reproduce that [17:19] corruption? [17:19] could be the dualhead setup [17:19] cause my internal display is disabled at the greeter [17:19] so it flickers briefly when it enables the display with the session [17:20] and then it seems to draw the wallpaper a bit borked for a split second and then it's there correctly on the second monitor [17:20] i can try without the external monitor a bit later [17:20] yeah [17:20] gtg now, later [17:22] ah i know what that is [17:23] it's doing the operations int he wrong order - i had that problem in lightdm [17:35] i assume you're both familiar with double buffering... the problem is that xfdesktop doesn't do this [18:12] hmm [18:12] ali1234: is that easy to implement? [18:13] bbiab [19:32] XFreePixmap (dpy, pixmap); [19:32] wow, how did i never see that before [19:34] ali1234: what do you mean? [19:34] well, i thought all this time something else was freeing the pixmap out from under xfwm4 [19:35] but actually, xfwm4 does it [19:35] so making that copy is probably unneccesary [19:35] all it needs to do is NOT free the pixmap unless it created it [19:37] i'm going to push branches of xfwm4, xfdesktop, and greeter, all with syslog debugging (because order of operations is important) [19:37] then we can get to the bottom of this finally [19:39] sweet [19:40] just tried without the copy and it works [19:41] bbabl [19:45] wow, that turns the fix into a one liner [19:53] actually i bet that fix will fix everything... lol [19:54] i dunno. maybe it's never appropriate to free the pixmap [20:00] #xorg has the most users and the least amount of talk :/ [20:00] it fixes what? you said that everything was already working for you [20:01] yeah, but my "fix" is long winded and unneccessary [20:01] anyway just because it works for me doesn't mean the code is correct [20:01] Q i just asked on #xorg: is it valid to create a pixmap, then create a XRender picture from it, then free the pixmap, and carry on using the picture? http://paste.ubuntu.com/6486175/ [20:02] the answer to this question might explain why you still get corruption [20:03] apparently the answer is it's valid [20:46] ali1234: hm, there seems to be lots of back and forth, so were do you stand now? [20:47] well, i'm happy with xfwm4 [20:47] lol - I got completely lost some time last week ;) [20:47] i'm happy with gtk-greeter [20:47] i'm not happy with xfdesktop yet [20:49] the trouble is, because there is so much communication between them via atoms, a bug in one can mess up all the others [20:49] so you see corruption on the xfwm4 root tile, because xfdesktop passed a bad pixmap [20:49] or you see xfdesktop crash because xfwm4 called XFreePixmap() [20:49] and so on, so even if 2/3 have correct code, the whole thing can still exlode [20:50] right [20:50] it's just strange that a pixmap has to be passed around so much [20:52] it's prefectly reasonable when you understand it [20:53] the pixmap has to be shared because the greeter exits before the window manager starts [20:54] the mechanism that is used to share the pixmap between greeter and wm also is used by xfdesktop [20:54] but none of them used it properly, so they all fight each other [20:54] it's not strictly necessary to fix xfdesktop, but i don't like to leave stuff broken [20:54] what's broken there atm? [20:55] well it sets it sets the ESETROOT atom, which is like hanging a big sign around it's own neck which reads "Please kill me" [20:55] that's quite graphic :) [20:56] it keeps a reference to the pixmap it puts into the atom and reuses it later, after xfwm4 has freed it.... which is why it crashes [20:57] that is a bug of xfwm4, but... programs which do this should not set ESETROOT [20:57] but not messing with that atom isn't a solution? [20:57] no, using the atoms for message passing is absolutely fine [20:58] just as long as you do it correctly [20:58] yeah, but is the atom really needed in the desktop? [20:58] yes, because xfdesktop has no other way to tell the window manager what to render in the root tile [20:59] now the root tile is hardly ever visible, but that isn't the point [20:59] the code exists for this, but is broken [20:59] it shouldn't be broken [20:59] agreed [20:59] as i wrote on the ML, there's three ways to use the MONITOR_ROOT_PIXMAP code [21:00] not at all, all the time, or only at startup [21:00] i want all three to work, even if we only use one [21:00] do you know how to remove xfdesktop from the session startup? [21:06] if this code still doesn't work, it might be that we need to do some server grabs to keep things from happening at the same time [21:06] i already added that to the greeter, but xfwm4 might need it to [21:12] not sure, i think xfce4-session starts it [21:12] but you can remove it from there [21:12] ali1234: settings-manager > sessions > session [21:13] it's not in there in mine... [21:15] ok, bgfix2 branch, please test :) [21:15] i haven't added debugging yet, just doing that now [21:33] ali1234: i'm at it [21:35] do i need anything apart from the bgfix2 branch? [21:37] well, i;ve just done the debugging for lightdm-gtk-greeter and xfwm4, so hang on 1 second while i push it [21:38] right please test these branches: [21:38] ah ok [21:39] lp:~a-j-buxton/lightdm-gtk-greeter/experimental-debug [21:39] and bgfix2-debug for xfwm4 [21:39] so those two branches write some logs? [21:39] or how can i check the debugging stuff [21:39] yes, all logs go to /var/log/syslog [21:40] right, it'd be ideal if brainwash could test these, as he's the one seeing troublesome stuff [21:40] yeah, i need to add logging to xfdesktop too for that... gotta fork that on github first tho [21:40] also, there might be bugs in my logging code :) [21:40] that's what you're really testing at this point :) [21:42] hehe, fine :) [21:42] * ochosi puts on the guinea-pig t-shirt [21:42] so, in order to test, do this: tail -f /var/log/syslog [21:42] then try killing xfdesktop one time [21:43] then kill it 5 times and try "hsetroot -color \#ff00ff" - you should see the background change to purple [21:43] wait, first install the branches, then restart, then kill xfdesktop?[24;2~ [21:43] yeah, oviously you gotta install it all :) [21:43] anyway you should see stuff like "found pixmap" and so on [21:44] pastebin all that so i can check it makes sense [21:44] you should also see "set root pixmap" from lightdm-gtk-greeter, then when xfwm4 starts you should see it find the same pixmap XID [21:45] also stuff about GrabServer [21:47] ok, restarting now... [21:47] brb [21:50] ok, i'm back [21:50] just in time for patched xfdesktop [21:50] holy crap, xfdesktop won't go away [21:50] i mean it says "no process found" [21:50] but the wallpaper is still there [21:51] ah, that's xfwm4 then [21:51] the hsetroot command didn't work though [21:52] yeah :) [21:52] i mean the syntax doesn't work out :) [21:52] the wallpaper should remain even after xfdesktop is killed - that's the *whole* point :) [21:52] good, i guess that means that part is working [21:52] nice [21:52] oh sorry, hsetroot -solid ... [21:52] yeah, works [21:52] git://github.com/ali1234/xfdesktop [21:52] add that in to the mix please :) [21:53] and, gahh, my poor eyes! [21:53] terrible color-choice [21:53] back to black... [21:53] \#ff7f00 is nice orange :) [21:53] xfdesktop is still pushing [21:54] yeah, i was wondering why i received a message about pulling an empty repo :) [21:54] that's the problem with these old code-bases [21:54] lotsa history [21:54] and my connection is lame [21:54] well if you have a clone of it already you can just add my repo, it will only fetch the changes [21:54] git ftw... [21:55] yeah, it's pretty clever [21:55] git remote add ali1234 git://github.com/ali1234/xfdesktop && git fetch ali1234 && git checkout ali1234/master [21:55] i can't understand why they had to create bzr... [21:55] bzr can probably do this too, but i don't know how [21:56] ping me when the pushing is done [21:56] its done [21:56] cool [21:58] so i presume restarting xfdesktop is enough? [21:58] yeah, just kill it (if you did make install) [21:58] the greeter is the only one that is funny about that stuff [21:59] ok, done [21:59] the wallpapers are back [21:59] you should see it set the pxmap, then xfwm4 will pick up the new pixmap [21:59] Nov 27 22:58:46 legume xfdesktop[7665]: set root pixmap XID=0x3a00023 [21:59] Nov 27 22:58:46 legume xfwm4[1557]: display=:0.0, screen=0 - found pixmap 0x3a00023 [21:59] perfect [21:59] this is what should happen. the XID should match [22:00] it does indeed [22:00] need more syslog output? [22:00] only if you have corruption or anything like that [22:00] try locking the screen :) [22:00] no, eveything seems fine [22:00] ok :) [22:00] you should see that lightdm uses display:1.0 [22:01] and xfwm4 will not notice that pixmap change [22:01] yeah it does [22:01] yup, it doesn't [22:01] as it shouldn't since it's a different display [22:01] worked perfectly [22:01] so now we need brainwash to test this, then maybe we see why it corrupts [22:01] yup [22:01] although if it is a driver issue, we probably won't [22:02] perhaps not [22:02] but still [22:02] this is quite informative [22:02] if the log looks okay it can only really be a driver issue :( [22:02] fwiw, with all the messing around, the greeter doesn't seem to pick up my wallpaper anymore [22:02] it always seems to display one i haven't used for a while [22:02] yes, because xfdesktop and accountservice [22:02] yeah [22:03] but also when i switched back to the 4.12 PPA [22:03] it's picking up an old setting - the new xfdesktop uses different keys [22:03] oh [22:03] so the patch doesn't work anymore? [22:03] it's quite messed up for me, i think i need to clear out the settings [22:03] i haven't aplied the account service patch [22:03] never even looked at it [22:03] well, would be nice if that worked again here [22:04] will now revert to my tabwin branch again [22:04] there's still some work to do there [22:04] going to need to update it for the new xfdesktop [22:08] weird, i was using xfdesktop 4.11 before and i think it worked [22:09] probably picking out the old key/value [22:10] probably [22:10] my desktop settings seem quite oldish [22:10] think i'll clear them out [22:11] night all [22:12] night slickymaster [22:12] hi ochosi [22:12] brb... [22:16] i saw the corruption :( [22:16] i think i know why though [22:16] also got the missing gtk theme stuff [22:16] no idea at all what that's about [22:17] oh [22:17] i didn't get that [22:17] "Corruption", black and white lines by chance that go away? [22:17] no, just a slightly garbled version of my wallpaper for a split-second [22:18] yes, that's what i mean [22:18] it's because it sets the root pixmap *before* copying in the wallpaper [22:18] i had this problem in the greeter but fixed it [22:18] need to fix in in xfdesktop too [22:24] right, that sounds promising [22:25] so it'll be really smooth in the end [22:26] yeah, it's nearly there now... just needs the xfdesktop fixings now [22:30] ok, that was easy [22:31] https://github.com/ali1234/xfdesktop/commit/d88d5405d0b42334d1b1a14b509708f13813c434 [22:31] eric_the_idiot: ^ [22:33] brainwash: testing instructions: http://paste.ubuntu.com/6486852/ [22:34] elfy, at your disposal https://code.launchpad.net/~slickymaster/ubuntu-manual-tests/ubuntu-manual-tests/+merge/196989 [22:53] ali1234: ok, test results tomorrow, cannot access my test machine at the moment [22:53] ali1234: nice, all in all your patches really don't look like they hurt at all, they just remove the communication troubles between the components [22:53] right. i think i've made the code shorter overall too [22:54] got a really helpful piece of advice from #xorg: use XRenderCreateSolidFill instead of messing about with pixmaps [22:59] wowza, anyone ever heard of this before? http://gmc-holle.github.io/xfdashboard/ [22:59] hah... no [23:00] just read about it on the xfce-users ml [23:00] looks like a weird cross between unity and gnome-shell... my two "favourite" desktops [23:00] yeah, it's strange, the guy said he's a gnome3 refugee, but then again he seems to want gnome3... [23:01] and it uses clutter [23:01] lol [23:01] which might be important for the stuff he does, but eh...? [23:02] >.< [23:02] just makes me wonder why he doesn't just use gnome3 with some xfce components instead [23:02] or unity [23:02] does he use a distro that isn't ubuntu? [23:03] You can install Unity just fine on Arch. [23:03] yeah but not anywhere else [23:03] also, "just fine" is a bit of a stretch. there's one guy maintaining the whole unity stack [23:03] which is about 10x bigger than all of xfce