tag:blogger.com,1999:blog-9776847646678580732024-02-10T21:50:19.573+00:00/bɑs ˈtjɛ̃ no ˈse ʁɑ/ (hadess) | NewsBastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.comBlogger373125tag:blogger.com,1999:blog-977684764667858073.post-79222634440109728932024-02-09T14:42:00.003+00:002024-02-09T14:44:14.518+00:00New and old apps on Flathub<p><b>3D Printing Slicers</b><br /></p><p> I recently replaced my <a href="https://www.flashforge.com/product-detail/flashforge-adventurer-3-3d-printer" target="_blank">Flashforge Adventurer 3</a> printer that I had been using for a few years as my first printer with a <a href="https://bambulab.com/en/x1">BambuLab X1 Carbon</a>, wanting a printer that was not a “project” so I could focus on modelling and printing. It's an investment, but my partner convinced me that I was using the printer often enough to warrant it, and told me to look out for Black Friday sales, which I did. </p><p>The hardware-specific slicer, <a href="https://github.com/bambulab/BambuStudio">Bambu Studio</a>, was available for Linux, but only as an AppImage, with many people reporting crashes on startup, non-working video live view, and other problems that the hardware maker tried to work-around by shipping separate AppImage variants for Ubuntu and Fedora.</p><p>After close to <a href="https://github.com/bambulab/BambuStudio/pulls?q=is%3Apr+author%3Ahadess+">150 patches to the upstream software</a> (which, in hindsight, I could probably have avoided by compiling the C++ code with LLVM), I manage to “flatpak” the application and <a href="https://flathub.org/apps/manage/com.bambulab.BambuStudio">make it available on Flathub</a>. It's reached 3k installs in about a month, which is quite a bit for a niche piece of software.</p><p>Note that if you click the “Donate” button <a href="https://flathub.org/apps/com.bambulab.BambuStudio">on the Flathub page</a>, it will take you a page where you can <strike>feed my transformed fossil fuel addiction</strike> buy filament for repairs and printing perfectly fitting everyday items, rather than bulk importing them from the other side of the planet.<br /></p><p style="text-align: center;"><img alt="Screenshot" class="yarl__slide_image" draggable="false" src="https://dl.flathub.org/repo/screenshots/com.bambulab.BambuStudio-stable/1248x702/com.bambulab.BambuStudio-7c7f64448845439b3a88d4f2b28dd225.png" style="max-height: min(702px, 100%); max-width: min(1248px, 100%);" /><br /> </p><p style="text-align: center;"><i>Preparing a <a href="https://www.printables.com/model/285296-mini-gg-consolized-game-gear-ggtv">Game Gear consoliser shell</a></i><br /></p><p></p><p>I will continue to maintain the <a href="https://flathub.org/apps/com.flashforge.FlashPrint">FlashPrint slicer</a> for FlashForge printers, installed by nearly 15k users, although I <a href="https://github.com/flathub/com.flashforge.FlashPrint/pull/50">enabled automated updates</a> now, and will not be updating the release notes, which required manual intervention.</p><p>FlashForge have unfortunately never answered my queries about making this distribution of their software official (and fixing the crash when using a VPN...).<br /></p><p><b> Rhythmbox</b> <br /></p><p>As I was updating the <a href="https://flathub.org/apps/org.gnome.Rhythmbox3">Rhythmbox Flatpak on Flathub</a>, I realised that it just reached 250k installs, which puts the number of installations of those 3D printing slicers above into perspective.</p><p style="text-align: center;"><img alt="rhythmbox-main-window.png" class="gl-max-w-full" data-testid="image" height="276" src="https://gitlab.gnome.org/GNOME/rhythmbox/-/raw/master/data/screenshots/rhythmbox-main-window.png?ref_type=heads" width="400" /> </p><p style="text-align: center;"><i>The updated screenshot used on Flathub</i></p><p style="text-align: left;">Congratulations, and many thanks, to all the developers that keep on contributing to this very mature project, especially Jonathan Matthew who's been maintaining the app since 2008.<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com2tag:blogger.com,1999:blog-977684764667858073.post-10809383340210176222024-01-31T11:33:00.002+00:002024-01-31T11:33:42.840+00:00Re: New responsibilities<p> A few months have passed since <a href="https://www.hadess.net/2023/08/new-responsibilities.html">New Responsibilities</a> was posted, so I thought I would provide an update.</p><p></p><p><b>Projects Maintenance</b></p><p>Of all the freedesktop projects I created and maintained, only one doesn't have a new maintainer, <a href="https://gitlab.freedesktop.org/hadess/low-memory-monitor">low-memory-monitor</a>.</p><p>This daemon is what the <a href="https://developer-old.gnome.org/gio/stable/GMemoryMonitor.html">GMemoryMonitor</a> GLib API is based on, so it can't be replaced trivially. <a href="https://gitlab.gnome.org/GNOME/glib/-/issues/2931">Efforts seem to be under way</a> to replace it with systemd APIs.</p><p>As for the other daemons:</p><ul style="text-align: left;"><li><a href="https://gitlab.freedesktop.org/hadess/switcheroo-control/">switcheroo-control</a> got picked up by Jonas Ådahl, one of the mutter maintainers. I'm looking forward to seeing <a href="https://gitlab.freedesktop.org/hadess/switcheroo-control/-/merge_requests/68">this merge request</a> fixed so we can have better menu items on dual-GPU systems</li><li><a href="https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/">iio-sensor-proxy</a> added Dylan Van Assche to its maintenance team, assisting Guido Günther.</li><li><a href="https://gitlab.freedesktop.org/upower/power-profiles-daemon">power-profiles-daemon</a> is now maintained by Marco Trevisan. It recently got support for separate system and CPU power profiles, and <a href="https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_requests/137">display power saving features</a> are in the works.</li></ul><p>(As an aside, there's posturing towards <a href="https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-power-profiles-daemon-self-contained/94995">replacing power-profiles-daemon with tuned in Fedora</a>. I would advise stakeholders to figure out whether having a large Python script in the boot hot path is a good idea, taking a look at bootcharts, and then thinking about whether hardware manufacturers would be able to help with supporting a tool with so many moving parts. Useful for tinkering, not for shipping in a product)</p><p><b>Updated responsibilities</b></p><p>Since mid-August, I've joined the Platform Enablement Team. Right now, I'm helping out with maintenance of the Bluetooth kernel stack in RHEL (and thus CentOS).</p><p></p><p></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQ_PzvmL81pWXLelkdOQeYRfBo6-HgQN40mcxpLdqgnE6Ey_kutFN2FB0YqNpo7QvgAzAi8AjW39EltSAW3SfAykWcwZL7BemTbS_P4B0n6afZCKQpThl7prv8BY0dWGi14UdRpwW30izWTeOIKPVgulXCvF_8NXoqsCc1pE7dIKVbD4xPk6fV8e7MPjzqFaHmc_jdyw/s761/only-throw-bluetooth.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="343" data-original-width="761" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQ_PzvmL81pWXLelkdOQeYRfBo6-HgQN40mcxpLdqgnE6Ey_kutFN2FB0YqNpo7QvgAzAi8AjW39EltSAW3SfAykWcwZL7BemTbS_P4B0n6afZCKQpThl7prv8BY0dWGi14UdRpwW30izWTeOIKPVgulXCvF_8NXoqsCc1pE7dIKVbD4xPk6fV8e7MPjzqFaHmc_jdyw/s16000/only-throw-bluetooth.png" /></a></div>The goal is to eventually pivot to hardware enablement, which is likely to involve backporting and testing, more so than upstream enablement. This is currently dependent on attending some formal kernel development (and debugging) training sessions which should make it easier to see where my hodge-podge kernel knowledge stands.<p></p><p><b>Blog backlog</b></p><p>Before being moved to a different project, and apart from the usual and very time-consuming bug triage, user support and project maintenance, I also worked on a few new features. I have a few posts planned that will lay that out.<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-7270423564824671062023-08-14T10:31:00.003+01:002023-08-14T10:31:50.469+01:00New responsibilities<p><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">As part of the same process outlined in Matthias Clasen's <a href="https://lwn.net/Articles/933525/">"LibreOffice packages" email</a></span><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">, my management chain has made the decision to stop all
upstream and downstream work on desktop Bluetooth, multimedia
applications (namely totem, rhythmbox and sound-juicer) and
libfprint/fprintd. The rest of my upstream and downstream work will be
reassigned depending on Red Hat's own priorities (see below), as I am
transferred to another team that deals with one of a list of Red Hat’s
priority projects.</span></p><div aria-live="assertive" class="ace-line" id="magicdomid3"></div><div aria-live="assertive" class="ace-line" id="magicdomid4"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">I'm
very disappointed, because those particular projects were already
starved for resources: I spent less than 10% of my work time on them in
the past year, with other projects and responsibilities taking most of
my time.</span></div><div aria-live="assertive" class="ace-line" id="magicdomid5"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid6"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">This means that, in the medium-term at least, all those GNOME projects will go without a maintainer, reviewer, or triager:</span></div><div aria-live="assertive" class="ace-line" id="magicdomid7"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- gnome-bluetooth (including Settings panel and gnome-shell integration)</span></div><div aria-live="assertive" class="ace-line" id="magicdomid8"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- totem, totem-pl-parser, gom</span></div><div aria-live="assertive" class="ace-line" id="magicdomid9"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- libgnome-volume-control</span></div><div aria-live="assertive" class="ace-line" id="magicdomid10"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- libgudev</span></div><div aria-live="assertive" class="ace-line" id="magicdomid11"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- geocode-glib</span></div><div aria-live="assertive" class="ace-line" id="magicdomid12"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- gvfs AFC backend</span></div><div aria-live="assertive" class="ace-line" id="magicdomid13"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid14"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">Those freedesktop projects will be archived until further notice:</span></div><div aria-live="assertive" class="ace-line" id="magicdomid15"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- power-profiles-daemon</span></div><div aria-live="assertive" class="ace-line" id="magicdomid16"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- switcheroo-control</span></div><div aria-live="assertive" class="ace-line" id="magicdomid17"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- iio-sensor-proxy</span></div><div aria-live="assertive" class="ace-line" id="magicdomid187"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">- low-memory-monitor</span></div><div aria-live="assertive" class="ace-line" id="magicdomid189"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid388"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">I will not be available for reviewing libfprint/fprintd, upower, grilo/grilo-plugins, gnome-desktop thumbnailer sandboxing patches, or any work related to XDG specifications.</span></div><div aria-live="assertive" class="ace-line" id="magicdomid19"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid371"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">Kernel
work, reviews and maintenance, including recent work on SteelSeries
headset and Logitech devices kernel drivers, USB revoke for Flatpak
Portal support, or core USB is suspended until further notice.</span></div><div aria-live="assertive" class="ace-line" id="magicdomid21"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid181"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">All my <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WRHVGQBKKFU74CBO3CHIJC3Q5VEKH2AV/">Fedora </a></span><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z"><a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WRHVGQBKKFU74CBO3CHIJC3Q5VEKH2AV/">packages
were orphaned</a> about a month and a half ago, it's likely that there are
still some that are orphaned, if there are takers. RHEL packages were
unassigned about 3 weeks ago, they've been reassigned
since then, so I cannot point to the new maintainer(s).</span></div><div aria-live="assertive" class="ace-line" id="magicdomid23"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid24"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">If
you are a partner, or a customer, I would recommend that you get in
touch with your Red Hat contacts to figure out what the plan is going
forward for the projects you might be involved with.</span></div><div aria-live="assertive" class="ace-line" id="magicdomid25"><br /></div><div aria-live="assertive" class="ace-line" id="magicdomid26"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">If
you are a colleague that will take on all or part of the 90% of the
work that's not being stopped, or a community member that was relying on
my work to further advance your own projects, get in touch, I'll do my
best to accommodate your queries, time permitting.</span></div><div aria-live="assertive" class="ace-line" id="magicdomid26"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z"><br /></span></div><div aria-live="assertive" class="ace-line" id="magicdomid26"><span class="author-a-bpz78z48jz69zz85zrfz84zz76zz84zbz89zz65z">I'll try to make sure to update this post, or create a new one if and when any of the above changes.<br /></span></div>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com5tag:blogger.com,1999:blog-977684764667858073.post-26536174375361015082022-08-17T10:14:00.000+01:002022-08-17T10:14:12.393+01:00Speeding up the kernel testing loop<p>When I create kernel contributions, I usually rely on a specific hardware, which makes using a system on which I need to deploy kernels too complicated or time-consuming to be worth it. Yes, I'm an idiot that hacks the kernel directly on their main machine, though in my defense, I usually just need to compile drivers rather than full kernels.</p><p>But sometimes I work on a part of the kernel that can't be easily swapped out, like <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88b7381a939de0fa1f1b1629c56b03dca7077309">the USB sub-system</a>. In which case I need to test out full kernels.</p><p>I usually prefer compiling full kernels as RPMs, on my Fedora system as it makes it easier to remove old test versions and clearly tag more information in the changelog or version numbers if I need to.</p><p><b>Step one, build as non-root</b><br /></p><p>First, if you haven't already done so, create an <span style="font-family: courier;">~/.rpmmacros</span> file (<a href="https://github.com/rpm-software-management/rpm/issues/2153">I know</a>...), and add a few lines so you don't need to be root, or write stuff in <span style="font-family: courier;">/usr</span> to create RPMs.</p><p></p><p><span style="font-family: courier;">$ cat ~/.rpmmacros<br />%_topdir /home/hadess/Projects/packages<br />%_tmppath %{_topdir}/tmp</span></p><p></p><p>Easy enough. Now we can use <a href="https://fedoraproject.org/wiki/Building_a_custom_kernel">fedpkg or rpmbuild</a> to create RPMs. Don't forget to run those under “<span style="font-family: courier;">powerprofilesctl launch</span>” to speed things up a bit.</p><p><b>Step two, build less</b></p><p>We're hacking the kernel, so let's try and build from upstream. Instead of the aforementioned fedpkg, we'll use “<span style="font-family: courier;">make binrpm-pkg</span>” in the upstream kernel, which builds the kernel locally, as it normally would, and then packages just the binaries into an RPM. This means that you can't really redistribute the results of this command, but it's fine for our use.<br /></p><p> If you choose to build a source RPM using “<span style="font-family: courier;">make rpm-pkg</span>”, know that this one will build the kernel inside rpmbuild, this will be important later.</p><p> Now that we're building from the kernel sources, that's our time to activate the cheat code. Run “<span style="font-family: courier;">make localmodconfig</span>”. It will generate a .config file containing just the currently loaded modules. Don't forget to modify it to include your new driver, or driver for a device you'll need for testing.</p><p><b>Step three, build faster</b></p><p>If running “<span style="font-family: courier;">make rpm-pkg</span>” is the same as running “<span style="font-family: courier;">make ; make modules</span>” and then packaging up the results, does that mean that the “<span style="font-family: courier;">%{?_smp_mflags}</span>” RPM macro is ignored, I make you ask rhetorically. The answer is yes. “<span style="font-family: courier;">make -j16 rpm-pkg</span>”. Boom. Faster.</p><p></p><p><b>Step four, build fasterer</b></p><p>As we're building in the kernel tree locally before creating a binary package, already compiled modules and binaries are kept, and shouldn't need to be recompiled. This last trick can however be used to speed up compilation significantly if you use multiple kernel trees, or need to clean the build tree for whatever reason. In my tests, it made things slightly slower for a single tree compilation.<br /></p><p><span style="font-family: courier;">$ sudo dnf install -y ccache<br />$ make CC="ccache gcc" -j16 binrpm-pkg</span></p><p>Easy.</p><p>And if you want to speed up the rpm-pkg build:</p><p><span style="font-family: courier;">$ cat ~/.rpmmacros <br />[...]<br />%__cc ccache gcc<br />%__cxx ccache g++</span></p><p>More information is available in <a href="http://nickdesaulniers.github.io/blog/2018/06/02/speeding-up-linux-kernel-builds-with-ccache/">Speeding Up Linux Kernel Builds With Ccache</a>.</p><p><b><span style="font-family: inherit;">Step five, package faster</span></b></p><p>Now, if you've implemented all this, you'll see that the compilation still stops for a significant amount of time just before writing “<span style="font-family: courier;">Wrote kernel...rpm</span>”. A quick look at <span style="font-family: courier;">top</span> will show a single CPU core pegged to 100% CPU. It's <span style="font-family: courier;">rpmbuild</span> compressing the package that you will just install and forget about.</p><p><span style="font-family: courier;">$ cat ~/.rpmmacros <br />[...]<br />%_binary_payload w2T16.xzdio<br /></span></p><p>More information is available in <a href="https://insujang.github.io/2020-11-07/accelerating-ceph-rpm-packaging-using-multithreaded-compression/#3-accelerating-rpm-package-build">Accelerating Ceph RPM Packaging: Using Multithreaded Compression</a>.</p><p><b>TL;DR and further work</b></p><p>All those changes sped up the kernel compilation part of my development from around 20 minutes to less than 2 minutes on my desktop machine.<span style="font-family: courier;"><br /></span></p><p><span style="font-family: courier;">$ cat ~/.rpmmacros <br />%_topdir /home/hadess/Projects/packages<br />%_tmppath %{_topdir}/tmp<br />%__cc ccache gcc<br />%__cxx ccache g++<br />%_binary_payload w2T16.xzdio</span></p><p><span style="font-family: courier;"><br />$ powerprofilesctl launch make CC="ccache gcc" -j16 binrpm-pkg</span></p><p><span style="font-family: inherit;"><span>I believe there's still significant speed ups that could be done, in the kernel, by parallelising some of the symbols manipulation, caching the BTF parsing for modules, switching the single-threaded vmlinux bzip2 compression, and not generating a <span style="font-family: courier;">headers</span> RPM (<i>note</i>: tested this last one, saves 4 seconds :)</span></span></p><p><span style="font-family: inherit;"><span> </span></span></p><p><span style="font-family: inherit;"><span><i>The results of my tests. YMMV, etc.</i> <br /></span></span></p><p></p>
<style>
table, th, td {
border: 1px solid black;
border-collapse: collapse;
padding: 10px;
}
</style>
<table>
<tbody><tr>
<th>Command</th>
<th>Time spent</th>
<th>Notes</th>
</tr>
<tr>
<td>koji build --scratch --arch-override=x86_64 f36 kernel.src.rpm</td>
<td>129 minutes</td>
<td>It's usually quicker, but that day must have been particularly busy</td>
</tr>
<tr>
<td>fedpkg local</td>
<td>70 minutes</td>
<td>No rpmmacros changes except setting the workdir in $HOME</td>
</tr>
<tr>
<td>powerprofilesctl launch fedpkg local</td>
<td>25 minutes</td>
</tr>
<tr>
<td>localmodconfig / bin-rpmpkg</td>
<td>19 minutes</td>
<td>Defaults to "-j2"</td>
</tr>
<tr>
<td>localmodconfig -j16 / bin-rpmpkg</td>
<td>1:48 minutes</td>
</tr>
<tr>
<td>powerprofilesctl launch localmodconfig ccache -j16 / bin-rpmpkg</td>
<td>7 minutes</td>
<td>Cold cache</td>
</tr>
<tr>
<td>powerprofilesctl launch localmodconfig ccache -j16 / bin-rpmpkg</td>
<td>1:45 minutes</td>
<td>Hot cache</td>
</tr>
<tr>
<td>powerprofilesctl launch localmodconfig xzdio -j16 / bin-rpmpkg</td>
<td>1:20 minutes</td>
</tr>
</tbody></table>
Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-90017461464729160472022-02-05T17:29:00.000+00:002022-02-05T17:29:18.789+00:00“Videos” de-clutter-ification<p>(I nearly went with clutterectomy, but that would be doing our old servant project a disservice.)</p><p>Yesterday, I finally merged the work-in-progress branch porting totem to GStreamer's GTK GL sink widget, undoing a lot of the <a href="https://www.hadess.net/2011/04/totem-in-gnome-30-plans-for-32.html">work done in 2011</a> and <a href="https://www.hadess.net/2014/02/videos-is-here.html">2014</a> to port the video widget and then to finally make use of its features.</p><p>But GTK has been modernised (in GTK3 but in GTK4 even more so), GStreamer grew a collection of GL plugins, Wayland and VA-API matured and clutter (and its siblings clutter-gtk, and clutter-gst) didn't get the resources they needed to follow.</p><p></p><p></p><p></p><p></p><p style="text-align: center;"><img alt="Screenshot_from_2022-02-03_18-03-40" class="gfm js-lazy-loaded qa-js-lazy-loaded" data-canonical-src="/uploads/20eb1e9d7bf4aa213748c23c82c36406/Screenshot_from_2022-02-03_18-03-40.png" src="https://gitlab.gnome.org/GNOME/totem/uploads/20eb1e9d7bf4aa213748c23c82c36406/Screenshot_from_2022-02-03_18-03-40.png" /><i>A screenshot with practically no changes, as expected</i><br /></p><p></p><p>The list of bug fixes and enhancements is substantial:</p><ul style="text-align: left;"><li>Makes some files that threw shaders warnings playable</li><li>Fixes resize lag for the widgets embedded in the video widget </li><li>Fixes interactions with widgets on some HDR capable systems, or even widgets disappearing sometimes (!)<br /></li><li>Gets rid of the floating blank windows under Wayland</li><li>Should help with tearing, although that's highly dependent on the system</li><li><b>Hi-DPI support</b></li><li><b>Hardware acceleration</b> (through libva)</li></ul><p>Until the port to GTK4, we expect a overall drop in performance on systems where there's no VA-API support, and the GTK4 port should bring it to par with the fastest of players available for GNOME.</p><p>You can install a Preview version right now by running:<br /></p>
<div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"><span style="color: #888888;">$ flatpak install --user https://flathub.org/beta-repo/appstream/org.gnome.Totem.Devel.flatpakref</span>
</pre></div><p></p><p>and <a href="https://gitlab.gnome.org/GNOME/totem/-/issues">filing bug in the GNOME GitLab</a>.</p><p>Next stop, a GTK4 port!<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com1tag:blogger.com,1999:blog-977684764667858073.post-27460618194621975082021-10-20T13:12:00.002+01:002021-10-20T13:12:36.275+01:00PSA: gnome-settings-daemon's MediaKeys API is going away<div class="separator"><p style="margin-left: 1em; margin-right: 1em;"></p></div><p> In 2007, Jan Arne Petersen <a href="https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/989857cd9fa67aadb652da4233cf01f22ee34df9">added a D-Bus API</a> to what was still pretty much <a href="https://help.gnome.org/misc/release-notes/2.2/#rnmultimediakeys">an import into gnome-control-center</a> of the "acme" utility I wrote to have all the keys on my iBook working.</p><p></p><p>It switched the code away from remapping keyboard keys to "XF86Audio*", to expecting players to contact the D-Bus daemon and ask to be forwarded key events.</p><p> </p><p></p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><img src="https://help.gnome.org/misc/release-notes/2.2/figures/acme.png.en" style="margin-left: auto; margin-right: auto;" /></td></tr><tr><td class="tr-caption" style="text-align: center;"><i>Multimedia keys circa 2003</i><br /></td></tr></tbody></table><p></p><p>In 2013, we added support for controlling media players using <a href="https://specifications.freedesktop.org/mpris-spec/latest/">MPRIS</a>, as another interface. Fast-forward to 2021, and MPRIS support is ubiquitous, whether in free software, proprietary applications or even browsers. So we'll be <a href="https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/268">parting with the "org.gnome.SettingsDaemon.MediaKeys" D-Bus API</a>. If your application still wants to work with older versions of GNOME, it is recommended to at least quiet the MediaKeys API's unavailability.</p><p></p><p> </p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRXuXcdFhFY5Pn0Oi0CG1usWnvbUGTDdrXufhFhP0H38g-Gu6olBq1_amRGVUtqGbJyyfleZQMuFSNsflenJKXrW8yKjPrMmSZK3sprlNvpIj_X9mZmU9YlOoax9E0Q47C9IbgSMOOVlB_ZFM6/s599/Screenshot+from+2021-10-20+14-10-52.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="599" data-original-width="573" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRXuXcdFhFY5Pn0Oi0CG1usWnvbUGTDdrXufhFhP0H38g-Gu6olBq1_amRGVUtqGbJyyfleZQMuFSNsflenJKXrW8yKjPrMmSZK3sprlNvpIj_X9mZmU9YlOoax9E0Q47C9IbgSMOOVlB_ZFM6/s16000/Screenshot+from+2021-10-20+14-10-52.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><i>Multimedia keys in 2021</i><br /></td></tr></tbody></table> </p><p>TL;DR: Remove code that relies on gnome-settings-daemon's MediaKeys API, make sure to add MPRIS support to your app.<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-56568177703519803652021-08-05T15:50:00.013+01:002021-08-05T15:50:00.211+01:00power-profiles-daemon: Follow-up<div><p>Just about <a href="https://www.hadess.net/2020/09/power-profiles-daemon-new-project.html">a year after the original announcement</a>, I think it's time to see the progress on power-profiles-daemon.</p><p><i>Note that I would still recommend you read the up-to-date <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/main/README.md#why-power-profiles-daemon">project README</a> if you have questions about why this project was necessary, and why a new project was started rather than building on an existing one.</i></p><p> The project was born out of the need to make a firmware feature available to end-users for a number of lines of Lenovo laptops for them to be <a href="https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/">fully usable on Fedora</a>. For that, I worked with Mark Pearson from Lenovo, who wrote the initial kernel support for the feature and served as our link to the Lenovo firmware team, and Hans de Goede, who worked on making the kernel interfaces more generic.</p><p><b>More generic, but in a good way</b><br /></p><p> With the initial kernel support written for (select) Lenovo laptops, Hans implemented a more generic interface called <span style="font-family: courier;"><a href="https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html">platform_profile</a></span>. This interface is now the one that power-profiles-daemon will integrate with, and means that it also supports a number of Microsoft Surface, HP, Lenovo's own Ideapad laptops, and maybe <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/34">Razer laptops soon</a>.<br /></p><p> The next item to make more generic is Lenovo's "lap detection" which still relies on a custom driver interface. This should be soon transformed into a generic proximity sensor, which will mean I get to work some more on <a href="https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/">iio-sensor-proxy</a>.<br /></p><p><b>Working those interactions</b></p><p> power-profiles-dameon landed in a number of distributions, sometimes enabled by default, sometimes not enabled by default (sigh, the less said about that the better), which fortunately meant that we had some early feedback available.</p><p> The goal was always to have the user in control, but we still needed to think carefully about how the UI would look and how users would interact with it when a profile was temporarily unavailable, or the system started a "power saver" mode because battery was running out.</p><p> The latter is something that David Redondo's work on the "HoldProfile" API made possible. Software can programmatically switch to the <span style="font-family: courier;">power-saver</span> or <span style="font-family: courier;">performance</span> profile for the duration of a command. This is useful to switch to the Performance profile when running a compilation (eg. <span style="font-family: courier;">powerprofilesctl jhbuild --no-interact build gnome-shell</span>), or for gnome-settings-daemon to set the power-saver profile when low on battery.</p><p> The aforementioned David Redondo and Kai Uwe Broulik also worked on the <a href="https://pointieststick.com/2021/07/23/this-week-in-kde-power-profiles-and-a-more-polished-kickoff/">KDE interface to power-profiles-daemon</a>, as Florian Müllner implemented the gnome-shell equivalent.<br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXNV322ghUvE-p7LukUG39FhkFuNWLx6mWro2s8olMBipidJDgzpLtTsbjkUmOqCGaMOjiqjL2sKabnELw7Fo0ZC8FApiw3CsjlIScDn5hFkzJdOmyQnlTrCB_85Hkqi1xq1WufpXihySGf1Cy/s623/power-profiles.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="623" data-original-width="332" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXNV322ghUvE-p7LukUG39FhkFuNWLx6mWro2s8olMBipidJDgzpLtTsbjkUmOqCGaMOjiqjL2sKabnELw7Fo0ZC8FApiw3CsjlIScDn5hFkzJdOmyQnlTrCB_85Hkqi1xq1WufpXihySGf1Cy/s16000/power-profiles.png" /></a></div></div><div style="text-align: center;"><i>Promised by me, delivered by somebody else :)</i><br /></div><p></p><p> I took this opportunity to update the Power panel in Settings, which shows off the temporary switch to the performance mode, and the setting to automatically switch to <span style="font-family: courier;">power-saver</span> when low on battery.<br /></p><div><b>Low-Power, everywhere</b></div><div><br /></div><div> Talking of which, while it's important for the system to know that they're targetting a power saving behaviour, it's also pretty useful for applications to try and behave better.</div><div> </div><div> Maybe you've already integrated with <a href="https://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html">"low memory" events</a> using GLib, but thanks to Patrick Griffis you can be an event better ecosystem citizen and monitor whether the system is in "Power Saver" mode and adjust your application's behaviour.</div><div> </div><div> This feature will be available in GLib 2.70 along with documentation of useful steps to take. GNOME Software will already be using this functionality to avoid large automated downloads when energy saving is needed.<br /></div><div><br /></div><div><b>Availability</b></div><div><br /></div><div> The majority of the above features are available in the GNOME 41 development branches and should get to your favourite GNOME-friendly distribution for their next release, such as Fedora 35.<br /></div>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-19521232634351721642020-10-14T15:43:00.003+01:002020-10-28T11:20:00.486+00:00Sandboxing inside the sandbox: No rogue thumbnailers inside Flatpak<p> A couple of years ago, we <a href="http://www.hadess.net/2017/07/security-for-security-gods-sandboxing.html">sandboxed thumbnailers</a> using <a href="https://github.com/containers/bubblewrap">bubblewrap</a> to avoid drive-by downloads taking advantage of thumbnailers with security issues.</p><p> It's a great tool, and it's a tool that Flatpak relies upon to create its own sandboxes. But that also meant that we couldn't use it inside the Flatpak sandboxes themselves, and those aren't always as closed as they could be, to support legacy applications.</p><p> We've finally <a href="https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/92">implemented support for sandboxing thumbnailers within Flatpak</a>, using the <a href="https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-method-org-freedesktop-portal-Flatpak.Spawn">Spawn D-Bus interface</a> (indirectly).</p><p>This should all land in GNOME 40, though it should already be possible to integrate it into your Flatpaks. Make sure to use the latest gnome-desktop development version, and that the flatpak-spawn utility is new enough in the runtime you're targeting (it's been updated in the freedesktop.org runtimes <a href="https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/3653">#1</a>, <a href="https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/3654">#2</a>, <a href="https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/3655">#3</a>, but it takes time to trickle down to GNOME versions). Example JSON snippets:</p>
<div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"> {
<span style="color: #007700;">"name"</span>: <span style="background-color: #fff0f0;">"flatpak-xdg-utils"</span>,
<span style="color: #007700;">"buildsystem"</span>: <span style="background-color: #fff0f0;">"meson"</span>,
<span style="color: #007700;">"sources"</span>: [
{
<span style="color: #007700;">"type"</span>: <span style="background-color: #fff0f0;">"git"</span>,
<span style="color: #007700;">"url"</span>: <span style="background-color: #fff0f0;">"https://github.com/flatpak/flatpak-xdg-utils.git"</span>,
<span style="color: #007700;">"tag"</span>: <span style="background-color: #fff0f0;">"1.0.4"</span>
}
]
},
{
<span style="color: #007700;">"name"</span>: <span style="background-color: #fff0f0;">"gnome-desktop"</span>,
<span style="color: #007700;">"buildsystem"</span>: <span style="background-color: #fff0f0;">"meson"</span>,
<span style="color: #007700;">"config-opts"</span>: [<span style="background-color: #fff0f0;">"-Ddebug_tools=true"</span>, <span style="background-color: #fff0f0;">"-Dudev=disabled"</span>],
<span style="color: #007700;">"sources"</span>: [
{
<span style="color: #007700;">"type"</span>: <span style="background-color: #fff0f0;">"git"</span>,
<span style="color: #007700;">"url"</span>: <span style="background-color: #fff0f0;">"https://gitlab.gnome.org/GNOME/gnome-desktop.git"</span>
}
]
} </pre></div><p>
</p><p>(We also <a href="https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/93">sped up GStreamer-based thumbnailers</a> by allowing them to use a cache, and <a href="https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/94">added profiling information to the thumbnail test tools</a>, which could prove useful if you want to investigate performance or bugs in that area)</p><p><i>Edit: correct a link, thanks to the commenters for the notice</i><br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-7790029719585613742020-09-10T19:00:00.003+01:002020-09-10T19:00:04.377+01:00power-profiles-daemon: new project announcement<p>Despite <a href="http://www.hadess.net/2019/08/low-memory-monitor-new-project.html">what this might look like</a>, I don't actually enjoy starting new projects: it's a lot easier to clean up some build warnings, or add a CI, than it is to start from an empty directory.</p><p>But sometimes needs must, and I've just released version 0.1 of <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/">such a project</a>. Below you'll find an excerpt from the <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/master/README.md">README</a>, which should answer most of the questions. Please read the README directly in the repository if you're getting to this blog post more than a couple of days after it was first published.</p><p>Feel free to <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues">file new issues in the tracker</a> if you have ideas on possible power-saving or performance enhancements. Currently the only supported “Performance” mode supported will interact with Intel CPUs with P-State support. More hardware support is planned.<br /></p><p>TLDR; this setting in the <a href="https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/816">GNOME 3.40 development branch</a> soon, <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1877399">Fedora packages are done</a>, <a href="https://hadess.fedorapeople.org/power-profiles-daemon-docs/">API docs available</a>:</p><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM2gGQQPbXs4uzJXj2gHhVnQIEciBnsq1v3sbxWDMXUIpNZayJpeEwMJ9Xv6GaN6OwRyTFoegXZ6nsgPcrgDT2eIKSw-_KH27k4xPOh66-fvFmBKfUzlZJycu9HXLw0mZy-zxRHaQGbuktpPPa/s1032/power-modes.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="739" data-original-width="1032" height="560" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM2gGQQPbXs4uzJXj2gHhVnQIEciBnsq1v3sbxWDMXUIpNZayJpeEwMJ9Xv6GaN6OwRyTFoegXZ6nsgPcrgDT2eIKSw-_KH27k4xPOh66-fvFmBKfUzlZJycu9HXLw0mZy-zxRHaQGbuktpPPa/w781-h560/power-modes.png" width="781" /></a></div><p></p><p><span></span></p><a name='more'></a> <p></p><p>From the <a href="https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/master/README.md">README</a>:</p><h2 data-sourcepos="14:1-16:0" dir="auto">Introduction</h2>
<p data-sourcepos="17:1-22:19" dir="auto">power-profiles-daemon offers to modify system behaviour based upon user-selected
power profiles. There are 3 different power profiles, a "balanced" default mode,
a "power-saver" mode, as well as a "performance" mode. The first 2 of those are
available on every system. The "performance" mode is only available on select
systems and is implemented by different "drivers" based on the system or
systems it targets.</p>
<p data-sourcepos="24:1-26:75" dir="auto">In addition to those 2 or 3 modes (depending on the system), "actions" can be hooked
up to change the behaviour of a particular device. For example, this can be used
to disable the fast-charging for some USB devices when in power-saver mode.</p>
<p data-sourcepos="28:1-31:5" dir="auto">GNOME's Settings and shell both include interfaces to select the current mode, but
they are also expected to adjust the behaviour of the desktop depending on the mode,
such as turning the screen off after inaction more aggressively when in power-saver
mode.</p>
<p data-sourcepos="33:1-34:75" dir="auto">Note that power-profiles-daemon does not save the currently active profile across
system restarts and will always start with the "balanced" profile selected.</p><h2 data-sourcepos="76:1-78:0" dir="auto">Why power-profiles-daemon</h2>
<p data-sourcepos="79:1-81:32" dir="auto">The power-profiles-daemon project was created to help provide a solution for
two separate use cases, for desktops, laptops, and other devices running a
“traditional Linux desktop”.</p>
<p data-sourcepos="83:1-86:43" dir="auto">The first one is a "Low Power" mode, that users could toggle themselves, or
have the system toggle for them, with the intent to save battery. Mobile
devices running iOS and Android have had a similar feature available to
end-users and application developers alike.</p>
<p data-sourcepos="88:1-91:71" dir="auto">The second use case was to allow a "Performance" mode on systems where the
hardware maker would provide and design such a mode. The idea is that the
Linux kernel would provide a way to access this mode which usually only
exists as a configuration option in some machines' "UEFI Setup" screen.</p>
<p data-sourcepos="93:1-94:105" dir="auto">This second use case is the reason why we didn't implement the "Low Power"
mode in UPower, <a class="gfm gfm-issue has-tooltip" data-container="body" data-issue="13996" data-link-reference="true" data-link="true" data-original="as was originally discussed" data-placement="top" data-project="139" data-reference-type="issue" href="https://gitlab.freedesktop.org/upower/upower/-/issues/102" title="Add Low power mode toggle in D-Bus API">as was originally discussed</a>.</p>
<p data-sourcepos="96:1-99:33" dir="auto">As the daemon would change kernel settings, we would need to run it as root,
and make its API available over D-Bus, as has been customary for more than
10 years. We would also design that API to be as easily usable to build
graphical interfaces as possible.</p><h2 data-sourcepos="101:1-103:0" dir="auto">Why not...</h2>
<p data-sourcepos="104:1-107:15" dir="auto">This section will contain explanations of why this new daemon was written
rather than re-using, or modifying an existing one. Each project obviously
has its own goals and needs, and those comparisons are not meant as a slight
on the project.</p>
<p data-sourcepos="109:1-110:68" dir="auto">As the code bases for both those projects listed and power-profiles-daemon are
ever evolving, the comments were understood to be correct when made.</p>
<h3 data-sourcepos="112:1-112:93" dir="auto">
<a href="https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon" rel="nofollow noreferrer noopener" target="_blank">thermald</a>
</h3>
<p data-sourcepos="114:1-116:56" dir="auto">thermald only works on Intel CPUs, and is very focused on allowing maximum
performance based on a "maximum temperature" for the system. As such, it
could be seen as complementary to power-profiles-daemon.</p>
<h3 data-sourcepos="118:1-118:94" dir="auto">
<a href="https://github.com/redhat-performance/tuned/" rel="nofollow noreferrer noopener" target="_blank">tuned</a> and <a href="https://linrunner.de/tlp/" rel="nofollow noreferrer noopener" target="_blank">TLP</a>
</h3>
<p data-sourcepos="120:1-122:35" dir="auto">Both projects have similar goals, allowing for tweaks to be applied, for
a variety of workloads that goes far beyond the workloads and use cases
that power-profiles-daemon targets.</p>
<p data-sourcepos="124:1-128:48" dir="auto">A fair number of the tweaks that could apply to devices running GNOME or
another free desktop are either potentially destructive (eg. some of the
SATA power-saving mode resulting in corrupted data), or working well
enough to be put into place by default (eg. audio codec power-saving), even
if we need to disable the power saving on some hardware that reacts badly to it.</p>
<p data-sourcepos="130:1-133:64" dir="auto">Both are good projects to use for the purpose of experimenting with particular
settings to see if they'd be something that can be implemented by default,
or to put some fine-grained, static, policies in place on server-type workloads
which are not as fluid and changing as desktop workloads can be.</p>
<h3 data-sourcepos="135:1-135:63" dir="auto">
<a href="https://github.com/AdnanHodzic/auto-cpufreq" rel="nofollow noreferrer noopener" target="_blank">auto-cpufreq</a>
</h3>
<p data-sourcepos="137:1-140:45" dir="auto">It doesn't take user-intent into account, doesn't have a D-Bus interface and
seems to want to work automatically by monitoring the CPU usage, which kind
of goes against a user's wishes as a user might still want to conserve as
much energy as possible under high-CPU usage.</p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.comtag:blogger.com,1999:blog-977684764667858073.post-56134838407739392142020-09-10T16:47:00.000+01:002020-09-10T16:47:07.099+01:00Avoid “Tag: v-3.38.0-fixed-brown-paper-bag”<p>Over the past couple of (gasp!) decades, I've had my fair share of release blunders: forgetting to clean the tree before making a tarball by hand, forgetting to update the <span style="font-family: courier;">NEWS</span> file, forgetting to push after creating the tarball locally, forgetting to update the appdata file (causing problems on Flathub)...</p><p>That's where <a href="https://gist.github.com/hadess/cb34f3d7e1309f8abf7d24fda31452a2"><span style="font-family: courier;">check-news.sh</span></a> comes in, to replace the <span style="font-family: courier;">check-news</span> function of the autotools. Ideally you would:</p><p>- make sure your <a href="https://gitlab.gnome.org/GNOME/totem/-/blob/00c76d84fff2a88bfa57d528c9e565fcf1ecea79/.gitlab-ci.yml#L52">CI runs a <span style="font-family: courier;">dist</span> job</a></p><p>- always use a merge request to do releases</p><p>- integrate <span style="font-family: courier;">check-news.sh</span> to your meson build (though I would <a href="https://gitlab.gnome.org/GNOME/totem/-/blob/00c76d84fff2a88bfa57d528c9e565fcf1ecea79/meson.build#L226">relax the appdata checks</a> for devel releases)<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-41698323040272489312020-09-08T14:31:00.000+01:002020-09-08T14:31:34.400+01:00Videos in GNOME 3.38<p>This is going to be a short post, as changes to Videos have been few and far between in the past couple of releases.</p><p>The major change to the latest release is that we've gained <a href="https://gitlab.gnome.org/GNOME/Initiatives/-/issues/17">Tracker 3 support</a> through a grilo plugin (which meant very few changes to our own code). But the Tracker 3 libraries are incompatible with the Tracker 2 daemon that's usually shipped in distributions, including on this author's development system.</p><p></p><p>So we made use of the ability of Tracker to run inside a Flatpak sandbox along with the video player, removing the need to have Tracker installed by the distribution, on the host. This should also make it easier to give users control of the directories they want to use to store their movies, in the future.<br /></p><p>The release candidate for GNOME 3.38 is <a href="https://flathub.org/apps/details/org.gnome.Totem">available right now</a> as the stable version on Flathub.<br /></p>Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com2tag:blogger.com,1999:blog-977684764667858073.post-49822980240416646452020-05-04T16:52:00.002+01:002020-05-04T16:52:27.638+01:00Dual-GPU support: Launch on the discrete GPU automatically<span style="font-size: x-small;">*reality TV show deep voice guy*</span><br />
<br />
In 2016, we added a way to <a href="https://www.hadess.net/2016/10/dual-gpu-integration-in-gnome.html">launch apps on the discrete GPU</a>.<br />
<br />
<span style="font-size: x-small;">*swoosh effects*</span><br />
<br />
In 2019, we added a way for that to <a href="http://www.hadess.net/2019/12/dual-gpu-support-follow-up-nvidia.html">work with the NVidia drivers</a>.<br />
<br />
<span style="font-size: x-small;">*explosions*</span><br />
<br />
In 2020, we're adding a way for applications to launch automatically on the discrete GPU.<br />
<br />
<span style="font-size: x-small;">*fast cuts of loads of applications being launched and quiet*</span><br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhv1zsG3ti-FWj8ba-TwuJEmSMJ2siZr_3UmcrPcIOsK46rbBYJ_hMZJ78CqGCrsHMXr8E915GHXn-eo9Jn5DttO3zTpsb2hGRO9XAf18I_GwBZDGItb7exO0QX9smRV2ZlgcQqoiq-ZYBFFG6A/s1600/integrated-graphics-card.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="275" data-original-width="597" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhv1zsG3ti-FWj8ba-TwuJEmSMJ2siZr_3UmcrPcIOsK46rbBYJ_hMZJ78CqGCrsHMXr8E915GHXn-eo9Jn5DttO3zTpsb2hGRO9XAf18I_GwBZDGItb7exO0QX9smRV2ZlgcQqoiq-ZYBFFG6A/s1600/integrated-graphics-card.png" /></a></div>
<br />
<br />
Introducing the (<a href="https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/13">badly-named-but-if-you-can-come-up-with-a-better-name-youre-ready-for-computers</a>) “<i>PrefersNonDefaultGPU</i>” desktop entry key.<br />
<br />
From the <a href="https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys">specifications website</a>:<br />
<blockquote class="tr_bq">
If true, the application prefers to be run on a more powerful discrete GPU if available,
which we describe as “a GPU other than the default one” in this spec to avoid the need
to define what a discrete GPU is and in which cases it might be considered more powerful
than the default GPU.
This key is only a hint and support might not be present depending on the implementation.
</blockquote>
And support for that key is <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1226">coming to GNOME Shell soon</a>.<br />
<br />
<b>TL;DR</b><br />
<br />
Add “<i>PrefersNonDefaultGPU=true</i>” to your application's .desktop file if it can benefit from being run on a more powerful GPU.<br />
<br />
We've also added a <span style="font-family: "courier new" , "courier" , monospace;">switcherooctl</span> command to recent versions of <a href="https://gitlab.freedesktop.org/hadess/switcheroo-control/">switcheroo-control</a> so you can launch your apps on the right GPU from your scripts and tweaks.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com15tag:blogger.com,1999:blog-977684764667858073.post-65239001091449779462020-04-01T17:53:00.001+01:002020-04-01T17:53:27.363+01:00PAM testing using pam_wrapper and dbusmockOn the road to <a href="https://www.hadess.net/2019/08/libfprint-10-and-fprintd-090.html">libfprint and fprintd 2.0</a>, we've been fixing some long-standing bugs, including one that required porting our PAM module from dbus-glib to sd-bus, systemd's D-Bus library implementation.<br />
<br />
As you can imagine, I have confidence in my ability to write bug-free code at the first attempt, but the foresight to know that this code will be buggy if it's not tested (and to know there's probably a bug in the tests if they run successfully the first time around). So we will have to test that PAM module, thoroughly, before and after the port.<br />
<br />
<b>Replacing fprintd</b><br />
<br />
First, to make it easier to run and instrument, we needed to replace fprintd itself. For this, we used <a href="https://github.com/martinpitt/python-dbusmock/">dbusmock</a>, which is both a convenience Python library and way to write instrumentable D-Bus services, and wrote a <a href="https://gitlab.freedesktop.org/libfprint/fprintd/-/tree/master/tests%2Fdbusmock">template</a>. There are a number of <a href="https://github.com/martinpitt/python-dbusmock/tree/master/dbusmock/templates">existing templates</a> for a lot of session and system services, in case you want to test the integration of your code with NetworkManager, low-memory-monitor, or any number of other services.<br />
<br />
We then used this to write <a href="https://gitlab.freedesktop.org/libfprint/fprintd/-/blob/master/tests/test_fprintd_utils.py">tests for the command-line utilities</a>, so we can both test our new template and test the command-line utilities themselves.<br />
<br />
<b>Replacing gdm</b><br />
<br />
Now that we've got a way to replace fprintd and a physical fingerprint reader, we should write some tests for the (old) PAM module to replace sudo, gdm, or the login authentication services.<br />
<br />
Co-workers Andreas Schneier and Jakub Hrozek worked on <a href="https://gitlab.com/cwrap/pam_wrapper/">pam_wrapper</a>, an <span style="font-family: "Courier New", Courier, monospace;">LD_PRELOAD</span> library to mock the PAM library, and Python helpers to write simple PAM services. <a href="https://lwn.net/Articles/671094/">This LWN article</a> explains how to test PAM applications, and PAM modules.<br />
<br />
After fixing a few bugs in pam_wrapper, and combining with the fprintd dbusmock work above, we could <a href="https://gitlab.freedesktop.org/libfprint/fprintd/-/blob/master/tests/pam/test_pam_fprintd.py">wrap and test the fprintd PAM module</a> like it never was before.<br />
<br />
<b>Porting to sd-bus</b><br />
<br />
Finally, porting the PAM module to sd-bus was pretty trivial, a loop of 1) writing tests that work against the old PAM module, 2) porting a section of the code (like the fingerprint reader enumeration, or the timeout support), and 3) testing against the new sd-bus based code. The result was no regressions that we could test for.<br />
<br />
<b>Conclusion</b><br />
<br />
Both <a href="https://github.com/martinpitt/python-dbusmock/">dbusmock</a>, and <a href="https://gitlab.com/cwrap/pam_wrapper/">pam_wrapper</a> are useful tools in your arsenal to write tests, and given those (fairly) easy to use CIs in GNOME and FreeDesktop.org's GitLabs, it would be a shame not to.<br />
<br />
You might also be interested in <a href="https://github.com/martinpitt/umockdev">umockdev</a>, to mock a number of device types, and <a href="https://code.google.com/archive/p/mocklibc/">mocklibc</a> (which combined with dbusmock <a href="https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/46">powers polkit's unattended CI</a>)Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-91225242355045017892019-12-17T23:53:00.001+00:002019-12-17T23:53:19.492+00:00GMemoryMonitor (low-memory-monitor, 2nd phase)<b>TL;DR</b><br />
<br />
Use <a href="https://developer.gnome.org/gio/2.63/GMemoryMonitor.html">GMemoryMonitor</a> in glib 2.63.3 and newer in your applications to lower overall memory usage, and detect low memory conditions.<br />
<br />
<b>low-memory-monitor</b><br />
<br />
To start with, let's come back to <a href="https://www.hadess.net/2019/08/low-memory-monitor-new-project.html">low-memory-monitor</a>, announced at the end of August.<br />
<br />
It's not really a “low memory monitor”. I know, the name is deceiving, but it actually monitors memory pressure stalls, and how hard it is for the kernel to allocate memory when applications need it. The longer it takes to allocate memory, the longer the kernel takes to allocate it, usually because it needs to move memory around to make room for a big allocation, when an application starts up for example, or prepares an in-memory buffer for saving.<br />
<br />
It is not a daemon that will kill programs on low memory. It's not a user-space out-of-memory killer, and does not take those policy decisions. It can however be <a href="https://gitlab.freedesktop.org/hadess/low-memory-monitor/#kernel-out-of-memory-killer">configured to ask the kernel to do that</a>. The kernel doesn't really know what it's doing though, and user-space isn't helping either, so best disable that for now...<br />
<br />
As listed in low-memory-monitor's <a href="https://gitlab.freedesktop.org/hadess/low-memory-monitor/#other-implementations">README</a> (and in the announcement post), there were a number of similar projects around, but none that would offer everything we needed, eg.:<br />
<ul>
<li>Has a D-Bus interface to propagate low memory conditions</li>
<li>Requires Linux 5.2's kernel memory pressure stalls information (Android's <a href="https://android.googlesource.com/platform/system/memory/lmkd/">lowmemorykiller</a> daemon has loads of code to get the same information from the kernel for older versions, and it really is quite a lot of code)</li>
<li>Written in a compiled language to save on startup/memory usage costs (around 500 lines of C code, as counted by <span style="font-family: "Courier New", Courier, monospace;">sloccount</span>)</li>
<li>Built-in policy, based upon values used in <a href="https://android.googlesource.com/platform/system/memory/lmkd/+/refs/heads/master/lmkd.cpp#138">Android</a> and <a href="https://github.com/endlessm/eos-boot-helper/tree/master/psi-monitor">Endless OS</a></li>
</ul>
<b>GMemoryMonitor</b><br />
<br />
Next up, in our effort to limit memory usage, we'll need some help from applications. That's where <a href="https://developer.gnome.org/gio/2.63/GMemoryMonitor.html">GMemoryMonitor</a> comes in. It's simple enough, listen to the <a href="https://developer.gnome.org/gio/2.63/GMemoryMonitor.html#GMemoryMonitor-low-memory-warning"><span style="font-family: "Courier New", Courier, monospace;">low-memory-warning</span></a> signal and free some image thumbnails, index caches, or dump some data to disk, when you receive a signal.<br />
<br />
The signal also gives you a “<a href="https://developer.gnome.org/gio/2.63/GMemoryMonitor.html#GMemoryMonitorWarningLevel">warning level</a>”, with 255 being when low-memory-monitor would trigger the kernel's OOM killer, and lower values different levels of “try to be a good citizen”.<br />
<br />
The more astute amongst you will have noticed that low-memory-monitor runs as root, on the system bus, and wonder how those new fangled (<a href="https://github.com/freedesktop/xdg-app/commit/a640cd365bd21743165adedb00bd9fac981687b2">5 years old today!</a>) sandboxed applications would receive those signals. Fear not! Support for a portal version of GMemoryMonitor landed in <a href="https://github.com/flatpak/xdg-desktop-portal/commit/78cea78b84cb5825bcdf4ac623d9f4b0e81a08f9">xdg-desktop-portal</a> on the same day as in glib. Everything tied together with <a href="https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests">installed tests</a> that use the real xdg-desktop-portal to test the portal and unsandboxed versions.<br />
<br />
<b>How about an OOM killer?</b><br />
<br />
By using memory pressure stall information, we receive information about the state of the kernel before getting into swapping that'd cause the machine to become unusable. This also means that, as our threshold for keeping everything ticking is low, if we were to kill high memory consumers, we'd get a butter smooth desktop, but, based on my personal experience, your browser and your mail client would take it in turns disappearing from your desktop in a way that you wouldn't even notice.<br />
<br />
We'll definitely need to think about our <a href="https://gitlab.gnome.org/GNOME/glib/merge_requests/683">next step</a> in application state management, and changing our running applications paradigm.<br />
<br />
Distributions should definitely disable the OOM killer for now, and possibly try their hands at upstream some systemd <a href="https://www.freedesktop.org/software/systemd/man/systemd.service.html#OOMPolicy=">OOMPolicy</a> and <a href="https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=">OOMScoreAdjust</a> options for system daemons.<br />
<br />
<b>Conclusion</b><br />
<br />
Creating low-memory-monitor was easy enough, getting everything else in place was decidedly more complicated. In addition to requiring changes to glib, xdg-desktop-portal and python-dbusmock, it also required a lot of work on the glib CI to save me from having to write integration tests in C that would have required a lot of scaffolding. So thanks to all involved in particular <a href="https://tecnocode.co.uk/">Philip Withnall</a> for his patience reviewing my changes.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com5tag:blogger.com,1999:blog-977684764667858073.post-37517798765683355022019-12-13T16:13:00.004+00:002019-12-13T16:15:00.571+00:00Dual-GPU support follow-up: NVIDIA driver supportIf <a href="https://www.hadess.net/2016/10/dual-gpu-integration-in-gnome.html">you remember</a>, back in 2016, I did the work to get a “Launch on Discrete GPU” menu item added to application in gnome-shell.<br />
<br />
This cycle I worked on adding support for the NVIDIA proprietary driver, so that the menu item shows up, and the right environment variables are used to launch applications on that device.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1NfheuA9ohCgveb1Lg1G1ULfHJXyu2tC_RBpZ6kE4TwTuSsb_ZhaS-LZWw7GW5k4et6ZS1IFPPIImPMVzpJqXfxGksvIDP8QcPbylHTr1_cBhrHcUv7aqjqI0CP1kAD8Cg7qFK84glCdiF_E4/s1600/dual-gpu.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="739" data-original-width="1032" height="458" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1NfheuA9ohCgveb1Lg1G1ULfHJXyu2tC_RBpZ6kE4TwTuSsb_ZhaS-LZWw7GW5k4et6ZS1IFPPIImPMVzpJqXfxGksvIDP8QcPbylHTr1_cBhrHcUv7aqjqI0CP1kAD8Cg7qFK84glCdiF_E4/s640/dual-gpu.png" width="640" /></a></div>
<div style="text-align: center;">
<i>Tested with another unsupported device...</i></div>
<br />
<br />
<b>Behind the scenes</b><br />
<br />
There were a number of problems with the old detection code in <a href="https://gitlab.freedesktop.org/hadess/switcheroo-control/">switcheroo-control</a>:<br />
- it required the graphics card to use <span style="font-family: "courier new" , "courier" , monospace;">vga_switcheroo</span> in the kernel, which the NVIDIA driver didn't do<br />
- it could support more than 2 GPUs<br />
- and it didn't really actually know which GPU was going to be the “main” one<br />
<br />
And, on top of all that, gnome-shell expected the Mesa OpenGL stack to be used, so it only knew the right environment variables to do that, and only for one secondary GPU.<br />
<br />
So we've extended <a href="https://gitlab.freedesktop.org/hadess/switcheroo-control/blob/master/src/net.hadess.SwitcherooControl.xml">switcheroo-control and its API</a> to do all this.<br />
<br />
(As a side note, commenters asked me about the KDE support, and how it would integrate, and it turns out that KDE's code just checks for the presence of a file in /sys, which is only present when <span style="font-family: "courier new" , "courier" , monospace;">vga_switcheroo</span> is used. So I would encourage KDE to adopt the switcheroo-control D-Bus API for this)<br />
<br />
<b>Closing</b><br />
<br />
All this will be available in Fedora 32, using GNOME 3.36 and switcheroo-control 2.0. We might backport this to Fedora 31 after it's been tested, and if there is enough interest.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com3tag:blogger.com,1999:blog-977684764667858073.post-20076383218992654592019-08-21T11:57:00.000+01:002019-08-21T11:57:49.978+01:00low-memory-monitor: new project announcementI'll soon be flying to Greece for <a href="https://2019.guadec.org/">GUADEC</a> but wanted to mention one of the things I worked on the past couple of weeks: the <a href="https://gitlab.freedesktop.org/hadess/low-memory-monitor/">low-memory-monitor</a> project is off the ground, though not production-ready.<br />
<br />
low-memory-monitor, as its name implies, monitors the amount of free physical memory on the system and will shoot off signals to interested user-space applications, usually session managers, or sandboxing helpers, when that memory runs low, making it possible for applications to shrink their memory footprints before it's too late either to recover a usable system, or avoid taking a performance hit.<br />
<br />
It's similar to Android's <a href="https://source.android.com/devices/tech/perf/lmkd">lowmemorykiller daemon</a>, Facebook's oomd, Endless' <a href="https://github.com/endlessm/eos-boot-helper/tree/master/psi-monitor">psi-monitor</a>, amongst others<br />
<br />
Finally a <a href="https://gitlab.gnome.org/GNOME/glib/merge_requests/1005">GLib helper</a> and a Flatpak portal are planned to make it easier for applications to use, with an API similar to <a href="https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle/responding_to_memory_warnings">iOS</a>' or <a href="https://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int)">Android</a>'s.<br />
<br />
Combined with <a href="https://pagure.io/fedora-workstation/issue/98">work in Fedora to use zswap and remove the use of disk-backed swap</a>, this should make most workstation uses more responsive and enjoyable.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com6tag:blogger.com,1999:blog-977684764667858073.post-58382328699735481962019-08-08T14:53:00.000+01:002019-08-08T14:53:14.904+01:00libfprint 1.0 (and fprintd 0.9.0)After more than a year of work <a href="https://gitlab.freedesktop.org/libfprint/libfprint/-/releases">libfprint 1.0</a> has just been released!<br /><br />It contains a lot of bug fixes for a number of different drivers, which would make it better for any stable or unstable release of your OS.<br /><br />There was a small ABI break between versions 0.8.1 and 0.8.2, which means that any dependency (really just fprintd) will need to be recompiled. And it's good seeing as we also have a <a href="https://gitlab.freedesktop.org/libfprint/fprintd/-/releases">new fprintd release</a> which also fixes a number of bugs.<br />
<br /><a href="https://blogs.gnome.org/benzea/">Benjamin Berg</a> will take over maintenance and development of libfprint with the goal of having a version 2 in the coming months that supports more types of fingerprint readers that cannot be supported with the current API.<br /><br />From my side, the next step will be some much needed modernisation for fprintd, both in terms of code as well as in the way it interacts with users.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-46733608009053975632019-04-06T11:41:00.000+01:002019-04-06T11:41:59.722+01:00Developer tool for i18n: “Pseudolocale”While browsing for some internationalisation/localisation features, I found an <a href="https://developer.android.com/guide/topics/resources/pseudolocales">interesting piece</a> of functionality in Android's developer documentation. I'll quote it here:<br />
<blockquote class="tr_bq">
A pseudolocale is a locale that is designed to simulate characteristics of languages that cause UI, layout, and other translation-related problems when an app is translated.</blockquote>
I've now implemented this for applications and libraries that use gettext, as an LD_PRELOAD library, available <a href="https://github.com/hadess/gettext-pseudolocale">from this repository</a>.<br /><br /><br />
The current implementation can highlight a number of potential problems (paraphrasing the Android documentation again):<br />
<blockquote class="tr_bq">
- String concatenation, which displays as one message split across 2 or more brackets.<br />- Hard-coded strings, which cannot be sent to translation, display as unaccented text in the pseudolocale to make them easy to notice.<br />- Right-to-left (RTL) problems such as elements not being mirrored.</blockquote>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxyd6C4Wrh4Rj5B5rpDAg_ZAwh4c8AbSHr9v3A0nb-rxnhb7toiEpw7KxCO3wr0qUJuCM5YQFN365Q0UkmnalmuY10R46-u8wEmHWjwwZaDcPJMUUgFpDYQ86NBONkU9VihnM4gHsVWd73ns4/s1600/office-runner.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="422" data-original-width="820" height="328" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxyd6C4Wrh4Rj5B5rpDAg_ZAwh4c8AbSHr9v3A0nb-rxnhb7toiEpw7KxCO3wr0qUJuCM5YQFN365Q0UkmnalmuY10R46-u8wEmHWjwwZaDcPJMUUgFpDYQ86NBONkU9VihnM4gHsVWd73ns4/s640/office-runner.png" width="640" /></a></div>
<div style="text-align: center;">
<i>Our old friend, Office Runner</i> </div>
<div style="text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVvjlBTWYjWgHK32TzlM80xyBPWR0lQXmslyOmRa2i2KVf8Dyh8gOyEr7tP2hX5Vo8JOGlT7Db6Jl2TiKHd3vi68iLceEDZ-Nu-Xtws59GRB8YDWib7ioccTy8ZPIppgeqyqi-wkRhhblU_10I/s1600/interesting-test.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="64" data-original-width="940" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVvjlBTWYjWgHK32TzlM80xyBPWR0lQXmslyOmRa2i2KVf8Dyh8gOyEr7tP2hX5Vo8JOGlT7Db6Jl2TiKHd3vi68iLceEDZ-Nu-Xtws59GRB8YDWib7ioccTy8ZPIppgeqyqi-wkRhhblU_10I/s1600/interesting-test.png" /></a></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: center;">
<i>Testing brought some unexpected results :)</i></div>
Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com1tag:blogger.com,1999:blog-977684764667858073.post-89270720274744980602019-03-08T19:00:00.000+00:002019-03-08T19:00:04.439+00:00Videos and Books in GNOME 3.32GNOME 3.32 will very soon be released, so I thought I'd go back on a few of the things that happened with some of our content applications.<br />
<br />
<b>Videos</b><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqvrzlRKQCmbGuHnzXkH7IXY-jLOufR1UmPzGOvKHM_T6_pk_ik-rPpmyCkZxozdVdwg4G494W_ebAN-bFmlOcsd7mONTEvwLS6hgnxgFGsAGdguRKN_nbs55ygO8nAEjTWgUhgUCPPULIe8Et/s1600/org.gnome.Totem.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="256" data-original-width="256" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqvrzlRKQCmbGuHnzXkH7IXY-jLOufR1UmPzGOvKHM_T6_pk_ik-rPpmyCkZxozdVdwg4G494W_ebAN-bFmlOcsd7mONTEvwLS6hgnxgFGsAGdguRKN_nbs55ygO8nAEjTWgUhgUCPPULIe8Et/s200/org.gnome.Totem.png" width="200" /></a></div>
First, many thanks to Marta Bogdanowicz, Baptiste Mille-Mathias, Ekaterina Gerasimova and Andre Klapper who toiled away at updating <i>Videos</i>' user documentation since 2012, when it was still called “Totem”, and then again in 2014 when “Videos” <a href="http://www.hadess.net/2014/02/videos-is-here.html">appeared</a>.<br />
<br />
The other major change is that <i>Videos</i> is available, fully featured, from <a href="https://flathub.org/apps/details/org.gnome.Totem">Flathub</a>. It should play your Windows Movie Maker films, your circular wafers of polycarbonate plastic and aluminium, and your Devolver indie films. No more hunting codecs or libraries!<br />
<br />
In the process, we also fixed a large number of outstanding issues, such as accommodating for the <a href="https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement">app menu's planned disappearance</a>, moving the audio/video properties tab to nautilus proper, making the thumbnailer available as an <a href="https://gitlab.gnome.org/GNOME/totem-video-thumbnailer/">independent module</a>, making the MPRIS plugin work better and loads, loads mo.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://flathub.org/apps/details/org.gnome.Totem" style="margin-left: 1em; margin-right: 1em;"><img alt="Download on Flathub" height="66" src="https://flathub.org/assets/badges/flathub-badge-en.png" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>Books</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmnblRSd_gRSC5Sp54WzVpcGwnu1ifsBDJ0kfH6oRjIYpq4bmbx3MqyOxO8qdl6us7M2W0cgKX1Gl_IYCYKx5IQ8NAYjf5iuSIex-PUmL5soSoBW3XhgSZTbQB2D1GuRI5md-xQ1qhgqumNP4k/s1600/org.gnome.Books.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="256" data-original-width="256" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmnblRSd_gRSC5Sp54WzVpcGwnu1ifsBDJ0kfH6oRjIYpq4bmbx3MqyOxO8qdl6us7M2W0cgKX1Gl_IYCYKx5IQ8NAYjf5iuSIex-PUmL5soSoBW3XhgSZTbQB2D1GuRI5md-xQ1qhgqumNP4k/s200/org.gnome.Books.png" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
As <i>Documents</i> was removed from the core release, we felt it was time for <i>Books</i> to become independent. And rather than creating a new package inside a distribution, the Flathub version was updated. We also fixed a bunch of bugs, so that's cool :)</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://flathub.org/apps/details/org.gnome.Books" style="margin-left: 1em; margin-right: 1em;"><img alt="Download on Flathub" height="66" src="https://flathub.org/assets/badges/flathub-badge-i-en.png" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>Weather</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
I didn't work directly on <i>Weather</i>, but I made some changes to libgweather which means it should be easier to contribute to its location database.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Adding new cities doesn't require adding a weather station by hand, it would just pick the closest one, and weather stations also don't need to be attached to cities either. They were usually attached to villages, sometimes hamlets!</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The automatic tests are also more stringent, and test for more things, which should hopefully mean less bugs.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>And even more Flatpaks</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
On Flathub, you'll also find some applications I packaged up in the last 6 months. First is <a href="https://flathub.org/apps/details/net.sourceforge.Teo">Teo Thomson emulator</a>, <a href="https://flathub.org/apps/details/com.github.shonumi.gbe-plus">GBE+</a>, a Game Boy emulator focused on accessories emulation, and a way to <a href="https://flathub.org/apps/details/com.adobe.Flash-Player-Projector">run your old Flash games</a> offline.</div>
Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com2tag:blogger.com,1999:blog-977684764667858073.post-20991807964574679372018-12-14T16:04:00.000+00:002018-12-14T16:04:37.059+00:00The tools of libfprint<a href="https://fprint.freedesktop.org/">libfprint</a>, the fingerprint reader driver library, is <a href="https://gitlab.freedesktop.org/libfprint/libfprint/issues?milestone_title=1.0">nearing a 1.0 release</a>.<br />
<br />
Since <a href="https://www.hadess.net/2018/06/fingerprint-reader-support-second-coming.html">the last time I reported on the status of the library</a>, we've made some headway modernising the library, using a variety of different tools. Let's go through them and how they were used.<br />
<br />
<b>Callcatcher</b><br />
<br />
When libfprint was in its infancy, Daniel Drake found the NBIS fingerprint processing library matched what was required to provide fingerprint matching algorithms, and imported it in libfprint. Since then, the code in this copy-paste library in libfprint stayed the same. When updating it to the latest available version (from 2015 rather than 2007), as well as splitting off a patch to make it easier to update the library again in the future, I used <a href="https://github.com/caolanm/callcatcher">Callcatcher</a> to cull the unused functions.<br />
<br />
Callcatcher is not a "production-level" tool (too many false positives, lack of support for many common architectures, etc.), but coupled with manual checking, it allowed us to <a href="https://gitlab.freedesktop.org/libfprint/libfprint/blob/master/libfprint/nbis/update-from-nbis.sh#L107">greatly reduce the number of functions in our copy</a>, so they weren't reported when using other source code quality checking tools.<br />
<br />
<b>LLVM's scan-build</b><br />
<br />
This is a particularly easy one to use as its use is integrated into meson, and available through <span style="font-family: Courier New, Courier, monospace;">ninja scan-build</span>. The output of the tool, whether on stderr, or on the HTML pages, is pretty similar to Coverity's, but the tool is free, and easily integrated into a CI (once you've fixed all the bugs, obviously). We found plenty of possible memory leaks and unintialised variables using this, with more flexibility than using Coverity's web interface, and avoiding going through hoops when using its "source code check as a service" model.<br />
<br />
<b>cflow and callgraph</b><br />
<br />
LLVM has another tool, called callgraph. It's <a href="https://github.com/mesonbuild/meson/issues/4412">not yet integrated into meson</a>, which was a bit of a problem to get some output out of it. But combined with <a href="http://www.gnu.org/software/cflow/manual/cflow.html">cflow</a>, we used it to find where certain functions were called, trying to find the origin of some variables (whether they were internal or device-provided for example), which helped with implementing additional guards and assertions in some parts of the library, in particular inside the NBIS sub-directory.<br />
<br />
<b>0.99.0 is out</b><br />
<br />
We're not yet completely done with the first pass at modernising libfprint and its ecosystem, but we released an early Yule present with <a href="https://lists.freedesktop.org/archives/fprint/2018-December/001109.html">version 0.99.0</a>. It will be integrated into Fedora after the holidays if the early testing goes according to plan.<br />
<br />
We also expect a great deal from <a href="https://fprint.freedesktop.org/libfprint-dev/pt03.html">our internal driver API reference</a>. If you have a fingerprint reader that's unsupported, contact your laptop manufacturer about them providing a Linux driver for it and point them at this documentation.<br />
<br />
A number of laptop vendors are already asking their OEM manufacturers to provide drivers to be merged upstream, but a little nudge probably won't hurt.<br />
<br />
Happy holidays to you all, and see you for some more interesting features in the new year.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0tag:blogger.com,1999:blog-977684764667858073.post-8707036629839625932018-10-31T11:44:00.000+00:002018-10-31T11:44:04.804+00:00Pipewire Hackfest 2018Good morning from Edinburgh, where the <a href="https://www.yell.com/biz/fatty-owls-edinburgh-8740065/">breakfast contains haggis</a>, and the charity shops have some <a href="https://twitter.com/Micro_Repairs">interesting finds</a>.<br />
<br />
My main goal in attending <a href="https://wiki.gnome.org/Hackfests/PipeWire2018">this hackfest</a> was to discuss Pipewire integration in the desktop, and how it will eventually replace PulseAudio as the audio daemon.<br />
<br />
The main problem GNOME has had over the years with PulseAudio relate mostly to how PulseAudio was a black box when it came to its routing policy. What happens when you plug in an HDMI cable into your laptop? Or turn on your Bluetooth headset? I've heard the stories of folks with highly mobile workstations having to constantly visit the Sound settings panel.<br />
<br />
PulseAudio has policy scattered in a number of places (do a "git grep routing" inside the sources to see that): some are in the device manager, then modules themselves can set priorities for their outputs and inputs. But there's nothing to take all the information in, and take a decision based on the hardware that's plugged in, and the applications currently in use.<br />
<br />
For Pipewire, the policy decisions would be split off from the main daemon. Pipewire, as it gains PulseAudio compatibility layers, will grow a default/example policy engine that will try to replicate PulseAudio's behaviour. At the very least, that will mean that Pipewire won't regress compared to PulseAudio, and might even be able to take better decisions in the short term.<br />
<br />
For GNOME, we still wanted to take control of that part of the experience, and make our own policy decisions. It's very possible that this engine will end up being featureful and generic enough that it will be used by more than just GNOME, or even become the default Pipewire one, but it's far too early to make that particular decision.<br />
<br />
In the meanwhile, we wanted the GNOME policies to not be written in C, difficult to experiment with for power users, and for edge use cases. We could have started writing a configuration language, but it would have been too specific, and there are plenty of embeddable languages around. It was also a good opportunity for me to finally write the helper library I've been meaning to write for years, based on my favourite embedded language, Lua.<br />
<br />
So I'm introducing <a href="https://gitlab.gnome.org/hadess/anatole">Anatole</a>. The goal of the project is to make it trivial to write chunks of programs in Lua, while the core of your project is written in C (we might even be able to embed it in Python or Javascript, once introspection support is added).<br />
<br />
It's still in the very early days, and unusable for anything as of yet, but progress should be pretty swift. The code is mostly based on Victor Toso's incredible <a href="http://www.hadess.net/2014/02/extend-gnome-videos-with-lua.html">"Lua factory" plugin in Grilo</a>. (I'm hoping that, once finished, I won't have to remember on which end of the stack I need to push stuff for Lua to do something with it ;)Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com3tag:blogger.com,1999:blog-977684764667858073.post-54534758817582343292018-06-22T16:06:00.000+01:002018-06-22T16:06:02.471+01:00Thomson 8-bit computers, a historyIn March 1986, my dad was in the market for a Thomson TO7/70. I have the circled classified ads in <a href="http://www.abandonware-magazines.org/affiche_mag.php?mag=106&num=2548&album=oui">“Téo” issue 1</a> to prove that :)<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYliOvkGxN27bqz2DAZvQkaPPYp7qpvZpTsMRF-RbTxzGVf_lKu1b8yxParBo88zVi2u_me2CxyMaMGOf3BN_MvVBVeZ173sihUArcds-l_ZyRKUc3oc2tmr2XbQEmsjkq3TrpQcEgPh6PCXE_/s1600/F_to770-2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="467" data-original-width="1024" height="290" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYliOvkGxN27bqz2DAZvQkaPPYp7qpvZpTsMRF-RbTxzGVf_lKu1b8yxParBo88zVi2u_me2CxyMaMGOf3BN_MvVBVeZ173sihUArcds-l_ZyRKUc3oc2tmr2XbQEmsjkq3TrpQcEgPh6PCXE_/s640/F_to770-2.jpg" width="640" /></a><br />
<br />
<div style="text-align: center;">
<i>TO7/70 with its chiclet keyboard and optical pen, courtesy of <a href="http://mo5.com/musee-machines-to770.html">MO5.com</a></i></div>
<br />
The “<a href="https://fr.wikipedia.org/wiki/Plan_informatique_pour_tous">Plan Informatique pour Tous</a>” was in full swing, and Thomson were supplying schools with micro-computers. My dad, as a primary school teacher, needed to know how to operate those computers, and eventually teach them to kids.<br />
<br />
The first thing he showed us when he got the computer, on the living room TV, was a game called “Panic” or “Panique” where you controlled a missile, protecting a town from flying saucers that flew across the screen from either side, faster and faster as the game went on. I still haven't been able to locate this game again.<br />
<br />
A couple of years later, the TO7/70 was replaced by a TO9, with a floppy disk, and my dad used that computer to write an educational software about top-down additions, as part of a training program run by the teachers schools (“Écoles Normales” renamed to “IUFM“ in 1990).<br />
<br />
After months of nagging, and some spring cleaning, he found the listings of his <a href="https://github.com/hadess/inondation-d-additions">educational software, which I've liberated</a>, with his permission. I'm currently still working out how to generate floppy disks that are usable directly in emulators. But here's an early screenshot.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq6Tz_9FdE-nARocJCkaj1LszgO2e9eoZqX-UcipiDTudKeVZQ3_g3mQEsPPExz3NYDhtnd4_za8C_0Sj8-mNvcETSTvgjBrhdjWZXo2MDegbMFy4urx9EJVoF0zv6ep1qRNE-qqsy4O_dfHI8/s1600/teo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="464" data-original-width="704" height="262" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq6Tz_9FdE-nARocJCkaj1LszgO2e9eoZqX-UcipiDTudKeVZQ3_g3mQEsPPExz3NYDhtnd4_za8C_0Sj8-mNvcETSTvgjBrhdjWZXo2MDegbMFy4urx9EJVoF0zv6ep1qRNE-qqsy4O_dfHI8/s400/teo.png" width="400" /></a></div>
<br />
Later on, my dad got an IBM PC compatible, an <a href="http://www.old-computers.com/museum/computer.asp?c=182&st=1">Olivetti PC/1</a>, on which I'd play a clone of Asteroids for hours, but that's another story. The TO9 got passed down to me, and after spending a full summer doing planning for my hot-dog and chips van business (I was 10 or 11, and I had weird hobbies already), and entering every game from the “102 Programmes pour...” series of books, the TO9 got put to the side at Christmas, replaced by a Sega Master System, using that same handy SCART connector on the Thomson monitor.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
But how does this concern you. Well, I've worked with <a href="https://www.youtube.com/user/RetroManCave/videos">RetroManCave</a> on a <a href="https://youtu.be/HOhK9bgQo8g">Minitel episode</a> not too long ago, and he agreed to do a history of the Thomson micro-computers. I did a fair bit of the research and fact-checking, as well as some needed repairs to the (prototype!) hardware I managed to find for the occasion. The result is this first look at the history of Thomson.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/UPxQR2r6iVA/0.jpg" src="https://www.youtube.com/embed/UPxQR2r6iVA?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<br />
Finally, if you fancy diving into the Thomson computers, there will be an episode coming shortly about the MO5E hardware, and some games worth running on it, on the same YouTube channel.<br />
<br />
I'm currently working on bringing the “<a href="https://sourceforge.net/projects/teoemulator/">Teo</a>” <a href="https://github.com/flathub/flathub/pull/443">TO8D emulator to Flathub</a>, for Linux users. When that's ready, <a href="http://dcmoto.free.fr/programmes/_html/index.html">grab some games from the DCMOTO archival site</a>, and have some fun!<br />
<br />
I'll also be posting some nitty gritty details about Thomson repairs on <a href="https://twitter.com/Micro_Repairs">my Micro Repairs Twitter feed</a> for the more technically enclined among you.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com3tag:blogger.com,1999:blog-977684764667858073.post-77575264244367687092018-06-12T19:00:00.000+01:002018-06-12T19:00:10.750+01:00Fingerprint reader support, the second comingFingerprint readers are more and more common on Windows laptops, and hardware makers would really like to not have to make a separate SKU without the fingerprint reader just for Linux, if that fingerprint reader is unsupported there.<div>
<br /></div>
<div>
The original makers of those fingerprint readers just need to send patches to the libfprint Bugzilla, I hear you say, and the problem's solved!</div>
<div>
<br /></div>
<div>
But it turns out it's pretty difficult to write those new drivers, and those patches, without an insight on how the internals of libfprint work, and what all those internal, undocumented APIs mean.</div>
<div>
<br /></div>
<div>
Most of the drivers already present in libfprint are the results of reverse engineering, which means that none of them is a best-of-breed example of a driver, with all the unknown values and magic numbers.</div>
<div>
<br /></div>
<div>
Let's try to fix all this!</div>
<div>
<br /></div>
<div>
<b>Step 1: fail faster</b></div>
<div>
<br /></div>
<div>
When you're writing a driver, the last thing you want is to have to wait for your compilation to fail. We ported libfprint to <a href="http://mesonbuild.com/">meson</a> and shaved off a significant amount of time from a successful compilation. We also reduced the number of places where new drivers need to be declared to be added to the compilation.</div>
<div>
<br /></div>
<div>
<b>Step 2: make it clearer</b></div>
<div>
<br /></div>
<div>
While <a href="http://www.stack.nl/~dimitri/doxygen/">doxygen</a> is nice because it requires very little scaffolding to generate API documentation, the output is also not up to the level we expect. We ported the documentation to <a href="https://www.gtk.org/gtk-doc/">gtk-doc</a>, which has a more readable page layout, easy support for cross-references, and gives us more control over how introductory paragraphs are laid out. See the <a href="https://fprint.freedesktop.org/libfprint-stable/">before</a> and <a href="https://fprint.freedesktop.org/libfprint-dev/">after</a> for yourselves.</div>
<div>
<br /></div>
<div>
<b>Step 3: fail elsewhere</b></div>
<div>
<br /></div>
<div>
You created your patch locally, tested it out, and it's ready to go! But you don't know about <a href="http://git.fishsoup.net/man/git-bz.html">git-bz</a>, and you ended up attaching a patch file which you uploaded. Except you uploaded the wrong patch. Or the patch with the right name but from the wrong directory. Or you know git-bz but used the wrong commit id and uploaded another unrelated patch. This is all a bit too much.</div>
<div>
<br /></div>
<div>
We migrated our bugs and repository for both libfprint and fprintd to <a href="https://gitlab.freedesktop.org/libfprint/libfprint/">Freedesktop.org's GitLab</a>. <a href="https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests">Merge Requests</a> are <a href="https://gitlab.freedesktop.org/libfprint/libfprint/pipelines">automatically built</a>, discussions are easier to follow!</div>
<div>
<br /></div>
<div>
<b>Step 4: show it to me</b></div>
<div>
<br /></div>
<div>
Now that we have spiffy documentation, unified bug, patches and sources under one roof, we need to modernise our website. We used GitLab's CI/CD integration to generate our website <a href="https://gitlab.freedesktop.org/libfprint/fprint.freedesktop.org/">from sources</a>, including creating API documentation and <a href="https://fprint.freedesktop.org/supported-devices.html">listing supported devices from git master</a>, to reduce the need to search the sources for that information.</div>
<br /><b>Step 5: simplify</b><div>
<br /></div>
<div>
This process has started, but isn't finished yet. We're slowly splitting up the internal API between "internal internal" (what the library uses to work internally) and "internal for drivers" which we eventually hope to document to make writing drivers easier. This is partially done, but will need a lot more work in the coming months.</div>
<div>
<br /></div>
<div>
<b>TL;DR</b>: We migrated libfprint to meson, gtk-doc, GitLab, added a CI, and are writing docs for driver authors, everything's <a href="https://fprint.freedesktop.org/">on the website</a>!</div>
Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com3tag:blogger.com,1999:blog-977684764667858073.post-21711967265785819022017-12-15T15:57:00.001+00:002017-12-15T15:57:52.784+00:00More Bluetooth (and gaming) featuresIn the midst of post-release bug fixing, we've also added a fair number of new features to our stack. As usual, new features span a number of different components, so integrators will have to be careful picking up all the components when, well, integrating.<br />
<br />
<b>PS3 clones joypads support</b><br />
<br />
Do you have a PlayStation 3 joypad that feels just a little bit "off"? You can't find the Sony logo anywhere on it? The figures on the face buttons look like barbed wire? And if it were a YouTube video, it would say "No copyright intended"?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmLk9xxI3dIDwMRKWSdkVB2varzwHaiSl_psnzYaniKrLCZDH2c23lXyRvryft4hHuDn7-jOARWukvQwg1kibQQrkjsfcwZ_XxaIAw5M6R_9Ej6kTpvK5u8SQsvimrl86p3jaSvMhfaNFx1XCv/s1600/shanwan.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="329" data-original-width="522" height="201" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmLk9xxI3dIDwMRKWSdkVB2varzwHaiSl_psnzYaniKrLCZDH2c23lXyRvryft4hHuDn7-jOARWukvQwg1kibQQrkjsfcwZ_XxaIAw5M6R_9Ej6kTpvK5u8SQsvimrl86p3jaSvMhfaNFx1XCv/s320/shanwan.jpg" width="320" /></a></div>
<br />
Bingo. When plugged in via USB, those devices advertise themselves as SHANWAN or Gasia, and implement the bare minimum to work when plugged into a PlayStation 3 console. But as a Linux computer would behave slightly differently, we need to fix a couple of things.<br />
<br />
The first fix was simple, but necessary to be able to do any work: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-sony.c?id=492ca83c3d19fba1622164f07cd7b775596a7db2">disable the rumble motor that starts as soon as you plug the pad through USB</a>.<br />
<br />
Once that's done, we could work around the fact that the device isn't Bluetooth compliant, and <a href="https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/plugins/sixaxis.c?id=1629c39ededef07988a5403b27331e0e317f1e08">hard-code the HID service</a> it's supposed to offer.<br />
<br />
<b>Bluetooth LE Battery reporting</b><br />
<br />
<a href="https://en.wikipedia.org/wiki/Bluetooth_Low_Energy">Bluetooth Low Energy</a> is the new-fangled (7-year old) protocol for low throughput devices, from a single coin-cell powered sensor, to input devices. What's great is that there's finally a <a href="https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.battery_level.xml">standardised way for devices to export their battery statuses</a>. I've added support for this in BlueZ, which <a href="https://cgit.freedesktop.org/upower/commit/?id=ccb1b0ed96baf5937d1bc36d5b4b0c65eb873964">UPower then picks up</a> for desktop integration goodness.<br />
<br />
There are a number of Bluetooth LE joypads available for pickup, including a few that <a href="https://blogs.gnome.org/hughsie/2016/08/18/updating-firmware-on-8bitdo-game-controllers/">should be firmware upgradeable</a>. Look for "Bluetooth 4" as well as "Bluetooth LE" when doing your holiday shopping.<br />
<br />
<b>gnome-bluetooth work</b><br />
<br />
Finally, this is the boring part. <a href="https://blogs.gnome.org/benzea/">Benjamin</a> and I reworked code that's internal to gnome-bluetooth, as used in the Settings panel as well as the Shell, to make it use modern facilities like GDBusObjectManager. The overall effect of this is, less code, less brittle and more reactive when Bluetooth adapters come and go, such as when using airplane mode.<br />
<br />
Apart from the kernel patch mentioned above (you'll know if you need it :), those features have been integrated in UPower 0.99.7 and in the upcoming BlueZ 5.48. And they will of course be available in Fedora, both in rawhide and as updates to Fedora 27 as soon as the releases have been done and built.<br />
<br />
GG!Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com13tag:blogger.com,1999:blog-977684764667858073.post-10899436826479878152017-12-06T14:32:00.001+00:002017-12-06T16:06:08.197+00:00UTC and Anywhere on Earth supportA quick post to tell you that we finally added UTC support to Clocks' and the Shell's World Clocks section. And if you're into it, there's also <a href="https://en.wikipedia.org/wiki/Anywhere_on_Earth">Anywhere on Earth</a> support.<br />
<br />
You will need to have git master versions of libgweather (our cities and timezones database), and gnome-clocks. This feature will land in GNOME 3.28.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfl1tnHcEd_dnz-uYPpdHUv5cQuFlDwGHfC3dKOT67cX26jPJCv_I_epTXISKQR7GY3a-Q-SoJmKV8FCIfln_74xl4XyLj93nds-HvKGDOmiJB-c5uTj7vOhSk9QpSih4h4Xzz8CR8ZIT86WxB/s1600/gnome-clocks-UTC.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="802" data-original-width="911" height="351" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfl1tnHcEd_dnz-uYPpdHUv5cQuFlDwGHfC3dKOT67cX26jPJCv_I_epTXISKQR7GY3a-Q-SoJmKV8FCIfln_74xl4XyLj93nds-HvKGDOmiJB-c5uTj7vOhSk9QpSih4h4Xzz8CR8ZIT86WxB/s400/gnome-clocks-UTC.png" width="400" /></a></div>
<br />
<br />
Many thanks to Giovanni for coming up with an API he was happy with after I attempted a couple of iterations on one. Enjoy!<br />
<br />
<i>Update</i>: As expected, a bug crept in. Thanks to Colin Guthrie for <a href="https://git.gnome.org/browse/libgweather/commit/?id=8556440ac4cf515e70027cf24fb3d19e15ea43a3">spotting the error in the "Anywhere on Earth" timezone</a>. See <a href="https://en.wikipedia.org/wiki/Tz_database#Area">this section for the fun we have to deal with</a>.Bastien Nocerahttp://www.blogger.com/profile/14621847888418739807noreply@blogger.com0