Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - pocock

Pages: 1 [2] 3 4 ... 15
The change to 4k page size has now been proposed for Fedora 35

There is a discussion thread on the Fedora devel mailing list

If you have any feedback please contribute both on the mailing list and the change wiki

Even if you don't support the change, please feel free to contribute ideas to help make 64k more painless, I already put a few ideas in the thread


There is a test site at

I found it working from Debian / Firefox 78 on an x86 system

Using Debian / Firefox 78 on ppc64le, it gives the error about audio not being supported

I installed the User-Agent switcher plugin on the ppc64le system and tried changing the UA string to include x86_64, pretending to be x86.  This didn't work.

If JavaScript code checks the User-Agent (UA) string, does the User-Agent switcher plugin intervene correctly?

Is there anything else Zoom could be checking?

Operating Systems and Porting / Re: kernel config: page size 4k vs 64k
« on: February 03, 2021, 03:05:21 pm »

For POWER9, are you reporting the speed on a 4k kernel of a 64k kernel?

The i5 will have 4k kernel

How many memory channels on each system?

Do you watch the load on the CPU cores, for example, using top (press 1) or the GNOME System Monitor?  Does the test only use 1 core or does it use all available cores?

Notice that the POWER9 architecture is faster for tasks that can be split between all the cores.  Some applications only run on a single core.

I built a backport of the latest version of Jami for various architectures including ppc64le.  This is one of several ways to do chat and VoIP with no central server, more details on the official web site

These are distributed through the Debify repository

If you didn't use Debify already, you can add the repository with this command:

Code: [Select]
$ wget -O - | bash

and then you can get the latest Jami with:

Code: [Select]
sudo apt update
sudo apt install -t debify-buster-backports jami

and then launch it with this command:

Code: [Select]
$ jami-gnone

User Zone / Re: Slow gnome-shell animation effect
« on: January 28, 2021, 09:46:22 am »
I opened a case here in the bug tracker from GNOME for the delay when changing to the Activities Overview screen, it may be related.

As far as what it will take to convince Qt...well, that's another organization that has a long history of ignoring user requests.  If there's a way to patch Qt downstream based on the existing Chromium port, that's probably the best bet.

Do you know if anybody is actively pursuing this?

Do you know any sources of funding for work like this?

I'm personally happy to do things on an ad-hoc basis from time to time, such as the 4k page size issue.  But this feels like it could take a bit more effort, it may be more productive for somebody to get to know it and stick with it over the long term.  I've already worked on some proprietary Qt-based solutions, for example, I was in the Kondor+ development center when they were migrating to Qt around 2007/2008 and we are also using TelepathyQt in reSIProcate so I have some impression of the minimum effort involved.

What does that mean for the QtWebEngine support?

Many other things depend on it.

User Zone / Re: Rough edges and how I work around them (or not)
« on: January 25, 2021, 03:05:29 am »

ffmpeg botches gif creation when using palattes - standard (ugly) gif creation with ffmpeg is fine however
   same exact config + script works okay on x86

Can you please see if this is fixed by this update?

Please confirm the ffmpeg version you are using

I had some communication with the Blender and ffmpeg developers about issues with transparency

For example, the preview panel in Blender was corrupted and some input images or videos were corrupted in OBS

The root cause was in ffmpeg, it is fixed here.  The issue is also tracked in Blender.

I produced an updated version of my Debian backport of ffmpeg 4.3.1, it now includes both the POWER9 optimizations and the fix for this particular issue.  The version with the fix is ffmpeg_4.3.1-5~bpo10+2

If you already used packages from then you can simply do

Code: [Select]
apt install -t debify-buster-backports ffmpeg

If you did not already use it, you need to add the apt source before installing/upgrading your ffmpeg:

Code: [Select]
$ wget -O - | bash
apt install -t debify-buster-backports ffmpeg

For Fedora, I have now opened a change request to use the 4k kernel by default in Fedora 34.  There is a new thread for that

For Chromium: I'm not currently using Chromium on this platform, I did have a brief look at the issues related to qtwebkit but I have not returned to that yet.

I'm really glad we made progress on this issue.  I'm still trying to get an RX 6800 XT so I can try the same set of packages.

I already asked this question in the same Fedora thread and it was answered there.  It looks like an extra hassle for them but maybe they can be persuaded, after all, IBM now owns Red Hat.

The page size issue impacts multiple architectures, not only ppc64el.  If proponents of bigger page sizes are willing to invest in resolving it, there are developers who will step up to help and there are tools we can use to detect signs of these problems.  It is a bit like Covid contact tracing, if the right people act with the right tools, we can solve it but we also have other battles to fight too.

We had some discussions in fedora-devel about changing the default page size from 64k back to 4k

This could be done for Fedora 34 - I opened a change request under Fedora policy

How do people feel about this?

Does anybody want to take ownership of the Fedora change request?

Technically, only one line of code needs to change but there is some coordination to make sure everything in userland is rebuilt and to do some tests of the installer as a bare minimum.

Code: [Select]

I might be willing to take ownership of the change personally but if somebody else wants to take ownership, that will free up some of my time for other things.

It is also important to verify that other users are comfortable with this strategy: please feel free to comment through the Fedora mailing list.


Please try this for the firmware:

Code: [Select]

mkdir ~/firmware-20201022

cd ~/firmware-20201022


sudo dpkg -i *.deb

After replacing the firmware packages, you need to reboot

Pages: 1 [2] 3 4 ... 15