=== brainwash_ is now known as brainwash
[03:01] <Unit193> bluesabre: So I ran the 'get-pot.sh' script, merged the translations with the msgmerge tool, then diff'd the translation percent: http://paste.openstack.org/show/8OpGNiuGJXRNBIHUuIat/ it's a bit painful.
=== jphilips_ is now known as jphilips
[09:00] <jphilips> thunar taking up 1 cpu has happened to me twice in the last day :D
[10:30] <bluesabre> Unit193: so maybe we don't ship those translations yet, and install call for updates to them and get them out for 20.04.1?
[10:30] <bluesabre> s/install/instead
[10:33] -BottyMcBotFace:#xubuntu-devel- ::platform:: Update supported kernel packages @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=c0e59184d807f50ec6f89d3800758691fda1b601 (by Dimitri John Ledkov)
[17:00] -BottyMcBotFace:#xubuntu-devel- Reminder: Next meeting chair is Unit193
[18:49] <bluesabre> https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/-/commit/77468200d2e287ba041aed1e5c475f0958af4a5f :)
[20:18] <TJ-> Heads up about an Xorg regression affecting multi-monitors a recent upgrade caused; might not be specific to Xubuntu but affecting 6 new Lenovo E495's here Bug #1873895
[20:18] <ubottu> bug 1873895 in xserver-xorg-video-amdgpu (Ubuntu) "Regression: block staircase display with side-by-side monitors" [Undecided,New] https://launchpad.net/bugs/1873895
[20:19] <bluesabre> Thanks TJ-
[20:19] <TJ-> bluesabre: struggling to figure out how to further track it down; any suggestions as to what to attack welcome!
[20:21] <bluesabre> TJ-: We updated xfwm4 recently, not sure if that could be related
[20:22] <TJ-> bluesabre: let me review the package upgrade list!
[20:23] <TJ-> ooo!! xfwm4:amd64 (4.14.0-2ubuntu1, 4.14.1-0ubuntu1)
[20:24] <TJ-> so if we downgrade to 4.14.0-2ubuntu1 that would be a worthwhile test
[20:27] <bluesabre> Yes. I’d be curious about that. Somebody else mentioned the same issue, but their screenshot showed a completely normal desktop.
[20:28] <brainwash> the gitlab issue points to https://bugzilla.xfce.org/show_bug.cgi?id=16716
[20:28] <ubottu> bugzilla.xfce.org bug 16716 in General "don't use xpresent on AMD CARRIZO as it produces garbled screen" [Normal,New]
[20:29] <TJ-> that's where we started! in my bug report I linked to the amdgpu 'driver' bug though
[20:30] <TJ-> the bit  didn't understand is the mention of xpresent vs glx, and "...switched back to glx" 
[20:31] <brainwash> 4.14.1 uses xpresent when an AMD gpu is detected
[20:31] <brainwash> .0 used glx
[20:31] <TJ-> aha!
[20:32] <TJ-> thanks for the explanation. I'm not at the office but just realised I've a HDMI monitor and cable close to hand so I can test it now
[20:33] <brainwash> https://git.xfce.org/xfce/xfwm4/commit/?id=23900123ad8418149897a094d1096d6ecb984d3c
[20:42] <TJ-> It would help to test it still fails before downgrading! Didn't have the problem with the older package but just doing a full upgrade to test if it does fail here
[20:44] <brainwash> it's a last minute change for sure
[20:45] <brainwash> meaning that .1 was not tested much at all
[20:46] <TJ-> well grrrr, cannot reproduce!
[20:48] <TJ-> Got it!!
[20:49] <TJ-> The eDP is 192x1080, the external monitor here (at home)  is 1920x1200 and does not suffer
[20:49] <TJ-> At the office the external monitor(s) are 1680x1050 and suffer. I just switched the resolution of this HDMI monitor to 1680x105 and reproduced
[20:55] <bluesabre> No AMD gpu to test things with. Will be my next hardware purchase.
[20:58] <bluesabre> If you can confirm, we can probably patch that back out after reporting upstream
[20:58] <TJ-> Well, now we've got it where should I dig? I've updated the bug report with my observations about the resolution and my hypothesis as to WHY it occurs as it does; I need sleep but tomorrow we can have a crack at fixing it if I know which code to attack
[20:59] <TJ-> I don't think xfwm4 is at fault here so instead of reverting there, let's attack the driver itself
[20:59] <TJ-> bluesabre: which country are you in?
[21:04] <TJ-> basically, looks like the driver is trying to render 1920 pixels to 1680 display - we can try to measure the block width tomorrow to confirm
[21:08] <TJ-> I can work on it for now but if I get out of my depth I'm prepared to ship a loan E495 to one of you if you think you can get further
[21:34] <bluesabre> TJ-: US. I wouldn’t recommend shipping me anything currently, not sure if make reasonable progress.
[21:35] <TJ-> bluesabre: OK ... I'm looking at the driver... a bisect might get us somewhere based on this: $ gitlog | grep present: | wc -l => 20
[21:37] <TJ-> I suspect a636f42b496b0604ca00a144690ece61d1a88a27  present: Check that flip and screen pixmap pitches match
[21:50] <TJ-> looks like there's a series of incremental patches around flip/pitch in present that are suspect
[22:00] <xu-core-beta0tw> Core installer crashes in both VMWare and Virtual Box. Had no problem installing the Desktop ISO.
[22:03] <Unit193> Running the installer from the boot menu or the live desktop session?
[22:06] <xu-core-beta0tw> Both.
[22:07] <xu-core-beta0tw> Tried unchecking downloads and using safe graphics option, neither helped. Crash is always near the end of the install.
[22:08] <Unit193> OK, the boot menu option is unfortunately common, but live session isn't.  Did the installer complete, just crash at the end?  Do you have logs of what happened?
[22:15] <xu-core-beta0tw> No, never completed so I don't know if there's an install log. I'll try again and look.
[22:16] <Unit193> That'd be the logs in /var/log/installer/ and /var/log/syslog (ubiquity pushes everything to there..)
[22:22] <TJ-> I've noticed an apparent xf86-video-amdgpu 'pitch' problem in Xorg log. When using single output eDP 1920x1080 the log shows "=> pitch 7680 bytes" and  7680/4=1920. with ext monitor at 1920x1200 I see "=> pitch 15360 bytes" and 15360/4-1920=1920 BUT when ext monitor is at 1680x1050 I see " => pitch 14848 bytes" however 14848/4-1920=1792 NOT 1680 as would be expected
[22:25] <Unit193> TJ-: I may have missed it, did you end up trying downgrading xfwm4?
[22:26] <TJ-> Unit193: yes but that wasn't conclusive since I was testing with a 1920x1200 ext HDMI - didn't spot until later that the issue occurs with the 1680x1050 output
[22:26] <TJ-> Unit193: with the downgrade I didn't observe the issue BUT didn't test with the HDMI at 1680
[22:46] <xu-core-beta0tw> Couldn't find anything useful in the logs so tried the installer from the desktop again in Virtual Box and this time it installed. This was a fresh image, last time I installed from the desktop after the crash took me there. If I can replicate the crash again I'll let you know. Thanks for your help!
[22:47] <Unit193> xu-core-beta0tw: Hey, glad it seems to be working!