[00:49] <jbicha> duflu: good morning
[00:50] <jbicha> are you interested in merging mpv for the libva transition in bionic?
[00:51] <jbicha> also we had someone complaining about window decorations for mpv (but I don't use mpv) https://ubuntuforums.org/showthread.php?t=2376602
[00:57] <duflu> jbicha, maybe... and yeah lack of server side window decorations is a Wayland "feature" for now
[03:09] <JanC> jbicha / duflu: people can get window decorations for mpv on Wayland by adding a 'vo=x11' line in '~/.config/mpv/mpv.conf', which makes it use XWayland  :)
[03:09] <JanC> it's not perfect, but it works...
[03:10] <jbicha> that user claimed that he was sure he was using Wayland mpv with decorations on Arch
[03:14] <JanC> well, I switched from Wayland back to X11 because it has too many bugs still...
[03:16] <duflu> JanC, if I recall correctly that will disable hardware acceleration support. Because Xwayland only supports DRI3 and VAAPI only supports DRI2
[03:16] <duflu> So not an option we can recommend
[03:17] <JanC> hm, I think mpv said it was using vaapi, but I'm not 100% sure
[03:17] <duflu> JanC, interesting. Please do check
[03:17] <JanC> maybe only for decoding
[03:19] <duflu> JanC, or try just comparing CPU usage in 'top'
[03:19] <duflu> *and* try just comparing CPU usage in 'top
[03:19] <duflu> '
[03:20] <JanC> I might be totally wrong, but IIRC VAAPI can decode straight to video memory, or into a buffer, so possibly they use VAAPI for decoding, then copy to the screen buffer, or something?
[03:20] <JanC> which would of course cause higher CPU too
[03:23] <JanC> or they use OpenGL and VAAPI decodes into an OpenGL buffer (or whatever it's called)
[03:23] <JanC> duflu: if I remember next time I (have to) reboot I'll try
[03:24] <JanC> but I'm happy I don't have to reboot every 1-3 days as with Wayland  :P
[03:24] <JanC> on X11
[03:24] <duflu> JanC, yes all VAAPI use cases decode straight into video memory. At least the ones we use. There is no distinction there
[03:26] <duflu> One of the reasons why we never had hardware accelerated video decoding till 17.10 was that nobody knew or could tell if it was ON or OFF already. So I have tried to cover that here: https://wiki.ubuntu.com/IntelQuickSyncVideo
[03:27] <duflu> Essentially you should always have single digit CPU usage or close to it. If not, then something still needs improving
[03:28] <JanC> on Wayland the desktop gets unusably slow very quickly (sometimes after less than a day), and if I don't reboot myself in that case it hangs at some point with "Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!" errors in dmesg
[03:28] <JanC> (I still have to file a bug about that)
[03:29] <JanC> "hangs" = doesn't update the screen; apps keep running, as e.g. music keeps playing
[03:30] <duflu> JanC, OK that's a completely different topic.... if you find that relates to memory usage of the gnome-shell process then subscribe here: https://bugs.launchpad.net/bugs/1672297
[03:30] <ubot5> Launchpad bug 1672297 in gnome-shell (Ubuntu) "gnome-shell uses lots of memory, and grows over time" [High,Triaged]
[03:32] <JanC> I'm not sure what causes it (I switched to X11 to see if it was Wayland-only, and that was 8 days ago ;) )
[03:34] <JanC> I'll look at that bug and see if I can confirm it's related, but that was just to explain why I haven't been using Wayland while trying to get some work done :)
[03:38] <JanC> mpv has some "vaapi-copy" mode for hardware decoding ("copies video back into system RAM (Linux with Intel  GPUs only)" according to the manpage)
[03:38] <JanC> I'm not sure exactly what it does or how it works  :)
[03:39] <roasted> a 4k video with vaapi results in about 3% CPU usage on an i5 7200u processor
[03:39] <roasted> same video with vaapi-copy, 19%
[03:39] <roasted> no hardware accel (software only), ~60%
[03:40] <roasted> not to mention my battery life went from 18 hours (idle) to 14:30 using vaapi, and 7:30 using software accel (no hardware accel)
[03:41] <roasted> I was pretty certain I had window decorations working with mpv in Antergos + Wayland and was using gpu-context=wayland in my mpv.conf, but later I began to get errors when I launched mpv with gpu-context=wayland in mpv.conf
[03:42] <roasted> I have no idea if I was troubleshooting too much at once and messed up my interpretation or if I got updates later that made it different, I'm not sure.
[03:45] <duflu> Yes roughly speaking, vaapi is an order of magnitude more efficient than vaapi-copy, and vaapi-copy another order of magnitude more efficient than software
[03:45] <roasted> The only downside I've seen is some youtube videos impose heavy gray artifacts when using vaapi. Not all, but some.
[03:46] <roasted> https://i.imgur.com/kBd3wf1.png
[03:46] <roasted> for local videos, and most online videos, it's brilliant.
[03:47] <JanC> that looks like there might have been video corruption
[03:47] <roasted> could be. If I comment out vaapi lines in my mpv.conf and rerun the same video in mpv, it's fine.
[03:47] <JanC> I mean, dropped frames, or such
[03:48] <roasted> albeit with my proc zooming but it functions
[03:48] <duflu> roasted, I will try to look into the grey corruption this week
[03:48] <roasted> regarding the GTK3 patch, it was my understanding that the patch introduces SSD via a KDE Protocol, thus allowing Wayland and apps like MPV to coexist.
[03:49] <roasted> my confusion that sparked the forum post was the fact that I didn't see anything really change.
[03:49] <roasted> I can bounce over to my Antergos partition and re-test then. I've been meaning to take another look sometime tonight. But if it's broken there then it stands to reason it could be a waiting for upstream thing yet.
[03:50] <roasted> duflu: pardon my ignorance, are you an mpv dev? mpv packager for ubuntu?
[03:50] <duflu> roasted, presently jack of all trades, and specifically responsible for Ubuntu hardware acceleration across the board
[03:50] <roasted> ah. well. kudos. :) loving it.
[03:51] <duflu> Not an upstream mpv dev
[03:51] <duflu> roasted, cool. Me too. I think people fail to realize it's not just about using less power, but also that modern 4K videos are simply unplayable without it
[03:52] <duflu> (modern = H.265/HEVC)
[03:52] <roasted> yeah. I hear you. I've been less-than-thrilled by some projects (ahem, mpv) insistance on pushing forth software acceleration
[03:52] <roasted> I've shot a lot of 4k video over the last week and it's certainly a necessity at this point
[03:53] <duflu> Interestingly somewhat by luck it's a technology feature Ubuntu introduced at about the same time as Apple did in High Sierra
[03:53] <JanC> I guess the grey corruption stuff could also happen when VAAPI doesn't implement some decoder feature, or implements it incorrectly
[03:53] <roasted> duflu: if there's anything within the capabilities of a "pretty fluent end-user" that I can do to test or help out regarding this please ping me. :)
[03:54] <duflu> roasted, OK thanks. Actually if you have raw HEVC files from an iPhone 8/X or from a GoPro Hero6 I would like some for testing
[03:54] <roasted> duflu: FYI, that gray artifact stuff, I noticed it happening a lot on youtube's more popular/top charted/main page vevo videos. One of Taylor Swift's recent music videos was where I snapped that imgur shot.
[03:54] <roasted> well, dang. not an iphone user, and a gopro is on my christmas list. :(
[03:55] <roasted> I just have a moto g5 atm
[03:55] <duflu> Such is the modern era; everything is on YouTube and people don't share their actual files. So I haven't found any to test with
[03:56] <roasted> I don't even know anybody with an iphone, sans a few users on very old models
[03:56] <roasted> nothing recent though
[03:57] <JanC> roasted: probably important to know what video quality you were playing too...
[03:57] <JanC> as YT usually has many
[03:57] <roasted> JanC: playing? I'm not sure. I didn't set anything in particular in my mpv.conf
[03:57] <roasted> I wonder what mpv in 17.10 repos && what mc3man's PPA of mpv default to
[03:57] <JanC> IIRC mpv uses the highest by default
[03:58] <JanC> for some value of "highest"
=== Guest16249 is now known as RAOF
[03:58] <JanC> or maybe youtube-dl's default, which is that
[03:59] <roasted> could be. I'm not sure offhand. I recall seeing some flags to call specific qualities, though...
[04:00] <JanC> when run from the commandline, it can tell you the exact URL
[04:00] <JanC> which might be useful for duflu to get the same
[04:02] <JanC> (he can even download it then)
[06:44] <oSoMoN> good morning desktoppers
[06:47] <duflu> Morning oSoMoN
[06:50] <oSoMoN> hey duflu, good afternoon!
[07:14] <didrocks> good morning
[07:23] <oSoMoN> salut didrocks
[07:24] <didrocks> ça va oSoMoN ?
[07:24] <oSoMoN> bien, et toi?
[07:25] <didrocks> j'ai été au lit tout le week-end :/
[07:25] <didrocks> fièvre et rhino
[07:25] <didrocks> je commence tout juste à émerger
[07:34] <oSoMoN> ah merde, pas cool
[07:35] <didrocks> on survivra :)
[07:39] <oSoMoN> bon rétablissement!
[07:45] <didrocks> merci ;)
[07:48] <seb128> good morning desktopers
[07:48] <seb128> lut didrocks oSoMoN
[07:52] <jamesh> hi seb128
[07:53] <seb128> hey jamesh, how are you?
[07:54] <jamesh> good.  Went for another ride yesterday training for a charity bike ride later this month
[07:54] <jamesh> 60 km around the river
[07:56] <seb128> nice
[07:57] <jamesh> the charity ride is going to be 70 km, but should be a bit easier, going on roads and not having to stop as much
[09:02] <Guest86060> ahoy there
[09:02] <Guest86060> GOD
[09:02] <Guest86060> THIS AGAIN
[09:03] <Guest86060> i should fix that logon thing
=== Guest86060 is now known as Laney
[09:03]  * Laney tries to remember how to do that
[09:05] <jamesh> setting your nickserv password as the irc network password seems to be the most reliable option
[09:06] <Laney> nick:password
[09:06] <Laney> I remember, a couple of weeks ago I switched to the SSL certificate thing and it doesn't work properly for me
[09:06]  * Laney tries
[09:07] <Laney> seemed to work
=== pesari_ is now known as pesari
[09:24] <willcooke> morning all
[09:28] <jibel> morning willcooke
[09:30] <willcooke> hi jibel, wb
[09:30] <willcooke> good hols?  How did the move go?
[09:30] <jibel> holidays were fantastic. Sun and high temperature end of October is priceless
[09:31] <jibel> and the move is done, one more before next :)
[09:33] <willcooke> :)_
[09:37] <seb128> hey willcooke
[09:37] <seb128> lut jibel
[09:41] <Merlijn_S> I found a potentially critical issue: Ubuntu 17.10 fails to boot after a firmware update: https://github.com/rhboot/fwupdate/issues/86
[09:41] <oSoMoN> salut jibel !
[09:42] <Merlijn_S> I had this issue myself, and now another user has reported the same issue.
[09:42] <Merlijn_S> Bug in launchpad: https://bugs.launchpad.net/fwupd/+bug/1730343
[09:42] <ubot5> Launchpad bug 1730343 in gnome-software (Ubuntu) "firmware update breaks Ubuntu" [Undecided,New]
[09:43] <Merlijn_S> Sadly, there is no way to debug this issue because Ubuntu _still_ doesn't preserve logs from previous boot..
[09:43] <Merlijn_S> It might be a good idea to disable firmware update in the software center until this issue is resolved.
[09:45] <duflu> Hmm, I didn't know it was even an option to forget history. Seems we do (journalctl --list-boots)
[09:47] <Merlijn_S> The issue with forgetting history is reported here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188
[09:47] <ubot5> Launchpad bug 1618188 in ubuntu-meta (Ubuntu) "systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs" [Wishlist,Triaged]
[09:48] <Merlijn_S> The fix is incredibly simple, but they don't want to enable it because that might cause some logs to be written to disk twice.
[09:49] <Merlijn_S> max 2x disk space for logs seems like a small price to pay for the benefits of being able to debug fwupd, but that's another issue..
[09:50] <Merlijn_S> Can I do something else to get the desktop team's attention for the fwupd issue, or do they check this channel regularly?
[09:52] <duflu> Merlijn_S, they should mostly be here now (mostly in Europe)
[09:52] <Merlijn_S> Great, thx
[09:53] <duflu> Merlijn_S, although as is always the case, it's not that simple. It seems to be in the hands of the Ubuntu foundations people, not desktop :)
[09:53] <Merlijn_S> How do you mean?
[09:54] <duflu> And foundations sounds right. Foundations = internals, Desktop = graphical etc
[09:54] <Merlijn_S> oh, ok
[09:56] <duflu> Merlijn_S, try emailing Dimitri and Bryan directly, I recommend
[09:56] <duflu> Likely they just lost the email thread for the bug
[10:01] <Merlijn_S> Which Bryan are you talking about?
[10:02] <duflu> Merlijn_S, the only one mentioned in the bug :)
[10:03] <Merlijn_S> oh, ok, I searched the thread for "brian" instead of "bryan" xD
[10:18] <jbicha> good morning
[10:30] <willcooke> morning jbicha
[10:32] <jbicha> Merlijn_S: did you link to the wrong github issue for 1730343 ?
[10:34] <Merlijn_S> Yes, my bad!
[10:36] <Merlijn_S> jbicha: fixed, thanks!
[11:27] <Laney> Merlijn_S: what about pulling this bad update from the LVFS?
[11:28] <oSoMoN> seb128, do you know what keeps re-triggering the amd64 build for https://launchpad.net/ubuntu/+source/libreoffice/1:5.4.2-0ubuntu2 ?
[11:28] <oSoMoN> there's a consistent unit test failure for which I'm backporting a debian patch, rebuilding over and over won't help
[11:31] <jbicha> oSoMoN: I did a rebuild once on Saturday because sometimes LO has a one-time test failure, but other people have clicked the retry button since
[11:37] <oSoMoN> ack, so anyone please refrain from retrying that, I'll have another upload ready during the day
[11:42] <jbicha> I clicked Cancel on that build now
[12:01] <Merlijn_S> Laney: It's not caused by the update itself, it seems, it's more of a race condition in fwupd itself. The annoying thing is that I can't reproduce it by downgrading and upgrading again, but another user has it too, so it's obviously still happening..
[12:21] <seb128> oSoMoN, likely people who are unsure of the issue is transient or not and want to see the build green so do a retry to see
[12:21] <seb128> oSoMoN, I've been one of those :p
[12:22] <seb128> oSoMoN, I assumed that it failed to build realiably on amd64 you would have hit that issue before upload so that it meant that it's probably random
[12:22] <oSoMoN> seb128, yeah, looks like the issue is due to another update in the archive, although the upstream patch in debian doesn't elaborate on which
[12:23] <oSoMoN> it was building in my PPA before the upload
[12:23] <seb128> k
[12:23] <seb128> start of cycle fun :p
[12:23] <seb128> things keep changing under you
[12:24] <oSoMoN> what I don't understand though is that the new test build in my PPA which I uploaded 6+ hrs ago failed (for another reason apparently), and when I went back to it to see the log I saw that it had been restarted
[12:25] <oSoMoN> so now I don't have a build log, and I have to wait for another 6 hours
[12:25] <seb128> is that your own ppa?
[12:25] <seb128> or a team one?
[12:25] <oSoMoN> yes, my own
[12:25] <seb128> weird :-/
[12:25] <seb128> that's worth asking on #launchpad how that's possible
[12:26] <oSoMoN> and no, my other schizophrenic self didn't retry it
[12:26] <seb128> the one reason I could see if that they had an infra issue and decided to restart the build from everything that hit it
[12:26] <seb128> but I would ask on #launchpad, just feels weird to me
[12:26] <oSoMoN> yes, I'll do that
[12:34] <seb128> thanks
=== dobey_ is now known as dobey
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== pavlushka_ is now known as pavlushka
[16:21] <oSoMoN> seb128, so according to Colin, what happened in my
[16:21] <oSoMoN> PPA can happen if the build crashes the builder
[16:21] <oSoMoN> (stupid misplaced return key)
[16:22] <oSoMoN> or if LP looses connectivity to the builder for too long
[16:57] <seb128> oSoMoN, oh ok, good to know
[16:57] <seb128> I guess they consider it as a builder issue and auto retry in such cases?
[16:58] <oSoMoN> seb128, yeah, and when the builder crashes the logs can't be retrieved anyway, so it makes sense to trigger a new build
[17:37] <oSoMoN> have a good evening everyone!
=== alan_g is now known as alan_g|EOD
=== JanC is now known as Guest24940
=== Guest48995 is now known as fredp
=== fredp is now known as Guest25304
[20:47] <willcooke> night all