Open mohawk2 opened 2 months ago
I tried that on my ubuntu 22 so far nothing with this line:
perl t/Object/Shaping.t font=FreeSerif
can you possibly check if your FreeSerif is this one?
$ fc-match FreeSerif-12
FreeSerif.otf: "FreeSerif" "Regular"
$ locate FreeSerif.otf | xargs -n 1 md5sum
524939c1572e22d1463002b3086548a0 /usr/share/fonts/opentype/freefont/FreeSerif.otf
If not, maybe I can spare effort upgrading or setting up a VM with v24, if you can put that otf here?
Also, if gc.bits.linePattern.aa is broken and PGPLOT plotting is broken, I'd guess that this has to do with Xorg/Xwayland's way to plot antialiased shapes, because Prima does the tesselation itself and only sends primitive shapes to X. The X backend rendeding is done either by full-on software using Xrender, but this is a piece by Keith Packard and his work is usually rock-solid. Or it is EGL/OpenGL-based by Eric Anholt, and it has a couple of nasty holes. I wonder if the same errors are present on Xvfb instead of the X-based display.
I found a laptop I could upgrade to v24, and fixed the font issue - but the line issue I couldn't reproduce. People on forums say that 24.00 is too alpha to make any conclusions, and recommend to wait for 24.01. The fact that there are line plotting problems also in PGPLOT, I'd strongly suspect some graphic driver issue. These days Xorg can run without a config, but you may want to create one where the backend is not EGL. Other than this, I'm not sure what to do about this problem
Thanks for merging the PR. I am assuming when you say "v24" you mean Ubuntu 24.04 LTS? They don't push it out to general release (which is when I saw it) until it's at the ".1" version, so that is not remotely alpha.
On reflection, I think the Gnuplot issue is as simple as it now putting its Wayland-related warnings on stdout (so the Perl driver can see it) instead of on stderr as before. That just means I need to fix the Perl driver to ignore that, like I had to when Gnuplot 6 changed its multiplotting stuff which I first saw on MacOS.
I agree that the issues I'm seeing with PGPLOT are Wayland-related, but I don't know what you mean about EGL etc. Could you link me to something so I can learn? Unfortunately, with PGPLOT being as currently "stable" (dead) as it is, my first option with that is not updating it to work with Wayland, though there are moves afoot to change that.
Turning to this actual issue: thank you for the patch you linked above, which has made the shape stuff pass again. The t/Object/GPState.t
error is still the same. If there's anything you need from me in debugging this, let me know.
I can only speculate about PGPLOT/Wayland problems, but I would definitely try both PGPLOT and GPState.t under XWayland, native XOrg, and Xvfb. Sure, there can be also some problem with Prima's tesselation, that causes line 217 to not draw any lines under AA mode, (the test bitmap displays only zeros, and there should be something else too). This one though can be tested with this code:
use strict;
use warnings;
use Prima;
my $d = Prima::DeviceBitmap->new(
size => [8,8],
type => dbt::Pixmap,
lineWidth => 2,
lineJoin => lj::Miter,
lineEnd => le::Square,
linePattern => lp::Dot,
rop2 => rop::NoOper,
antialias => 1,
);
$d->clear;
$d->polyline([2,2,6,2,6,6]);
$d = $d->image;
$d->type(im::BW);
$d->type(im::Byte);
$d = $d->data;
$d =~ tr/\x00\xff/* /;
print join("\n", split /(.{8})/, $d), "\n";
It should display two dots, each is made from 4 *'s. That's lp::Dot line pattern with line width=2. Let's see if this will be working under wayland, xorg, and xvfb
I had to fix the last line of your script since it was making spurious blank lines (the split
was splitting, returning the captured parens, but also the empty strings between those 8-char blocks) to:
print join "\n", $d =~ /(.{1,8})/g, "";
Under my Wayland on Ubuntu 24.04 (the only system I have easy access to) the updated script gives:
**
**
**
**
Yes that how it supposed to be ... and yet the test fails doing the same thing? Very strange... do you think if you will be able to condense the test script to some minimal version that can fail with the linepatterns? Since I cannot reproduce it may be the only way to figure out what's wrong there...
I've figured out what's the material difference between your test script on here, and the failing test. I used this to diagnose the state of the objects on entry to the check
function (and after it had run):
diag explain {map +($_=>scalar $d->$_), qw(size type lineWidth lineJoin lineEnd linePattern rop2 antialias)};
and it shows that it's when rop2
is rop::CopyPut
that the test fails because polyline
produces the same results with the different linePattern
s (both no result). I gather that's not widely true, but it is newly true under the Wayland I have now. It looks like this part of Prima::Drawable's POD is relevant here:
Usually, however, graphic devices support only a small part of the above set, limiting C<::rop> to the most important operations: Copy, And, Or, Xor, NoOp. C<::rop2> is usually even more restricted, and supports only Copy and NoOp.
A fix that I'm not sure about is at #123.
Very interesting, thank you! So if you could s/rop::NoOper/rop::CopyPut/ in the script above, it won't display the dots, but empty or solid lines? It would be interesting to condense this to some provable use case and possibly event send a bug report to the Xorg people
t/Object/GPExtra.t ..... 1/?
# Failed test 'fpi0m on layered.aa'
# at t/Object/GPExtra.t line 140.
# got: '4'
# expected: '1'
# Failed test 'fpi8c on layered.aa'
# at t/Object/GPExtra.t line 140.
# got: '4'
# expected: '3.5'
# Failed test 'fpifc on layered.aa'
# at t/Object/GPExtra.t line 140.
# got: '4'
# expected: '3'
# Looks like you failed 3 tests of 102.
t/Object/GPExtra.t ..... Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/102 subtests
t/Object/GPState.t ..... 1/?
# Failed test 'gc.bits.fillPatternOffset.aa'
# at t/Object/GPState.t line 204.
# got: '
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000'
# expected: anything else
# Failed test 'gc.bits.fillPattern.aa'
# at t/Object/GPState.t line 150.
# got: '
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000
# 0000000000000000'
# expected: anything else
# Looks like you failed 2 tests of 177.
t/Object/GPState.t ..... Dubious, test returned 2 (wstat 512, 0x200)
I see these errors when I install Prima 1.74 on Kali Linux which is identical to Debian 12 Testing. Any help is appreciated. I force install for now to move forward. Debian 11 does not have any errors in the tests.
Is it under wayland or pure x11?
Is it under wayland or pure x11?
Using loginctl
I see that the session type is x11.
I am running XFCE desktop on both versions of Debian. I see the process that's running and it is an Xorg.
Just tried under 24.04 x11, the bug is not there. I guess I need to start creating a standalone C program that does these graphics things, and if these fail too, report to the xorg people
found out that I've commented on the wrong issue. Anyway https://github.com/user-attachments/files/17702466/fpx-test.tar.gz is the C test I was talking about, if you could try to run it it would be great
On Kali Linux
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
On Debian 11 and Debian 12, Ubuntu 22.04 LTS
ffffffff ff7f7f7f ff000000 ffffffff ff7f7f7f ff000000
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ff7f7f7f ff000000 ffffffff ff7f7f7f ff000000
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
I do not have Ubuntu 24.04 LTS that runs X so cannot test there.
Thank you! I guess xrender is not accessible on Kali, but Prima doesn't detect that. What iso should I use to reproduce your setup? (Or if you can give me a temp access via ssh from karasik.eu.org's IP 194.255.205.168 that would be even better)
Kali Linux provides pre-configured VMs : https://www.kali.org/get-kali/#kali-virtual-machines that you can use. I would recommend this. I am running a 64-bit x86-64 Release 2024.3
with XFCE desktop environment on bare metal. I also run NVIDIA drivers for my displays, but I do not think they're relevant to the problem. Sadly, I dont have a static IP so cannot provide SSH access without using a tunnel or setting up a VPN into my LAN. but if you are unable to reproduce, then i will set it up via a jump box.
I have libx11-dev
and libxrender-dev
installed.
I'm afraid this has something to do with your NVIDIA setup. This is pure qemu x86_64:
it may well be the case. I ran the fpx
program on a Ubuntu 22 LTS with NVIDIA drivers and it worked just fine. so it is just this one setup that has a bug. no worries, the rest of Prima works fine for me. thanks.
It seems so... just to fill my curiousity, if you can run xclock -render
on your kali, would it display clock hands properly? (This is the xrender demo)
seems to work. when I do OpenGL tests i run glxgears
.
They were working fine, then I went and "upgraded" my Ubuntu from 22.04 LTS to 24.04 LTS. Now lots of plotting stuff is broken including PGPLOT, and also Prima is failing several tests: