Re: local X server & gtk3 applications (also, netsurf in pkgsrc & pkgin w/ Dropbox)

[David Brownlee <abs%netbsd.org@localhost>]

On Thu, 10 Sep 2020 at 18:23, Romain Dolbeau <romain%dolbeau.org@localhost> wrote:
>
> Le jeu. 10 sept. 2020 à 18:37, David Brownlee <abs%netbsd.org@localhost> a écrit :
> > As a test case does the same thing happen if you run netsurf-gtk3 from
> > another box back to the sparc as a X display (and similarly the sparc
> > binary displaying on another box) - to confirm its a "gtk3 & 8 bit"
> > issue rather than a "gtk3 built on 32bit sparc" problem :)
>
> sparc binary to another I had tried, it was working (and the epitome
> of pointlessness I would think, running a web browser on a 2x90+2x125
> MHz HyperSPARC and using a E5-2690v4 has a dumb X Terminal :-) )

It can probably run qemu-sparc fast enough to five the SS20 a run for
its money :)

> The other way round, I don't have a netsurf-gtk3 handy; the one in
> raspbian is built again gtk2 (so I can indeed run netsurf on a RPi4
> and display to the SS20, that 'works'; I can't get to a website
> because that version is too buggy), and so is Debian's (although the
> next one in unstable will be gtk3, but I'm still on oldstable so
> unstable is a bit too modern for me ;-) ).
>
> I can also run firefox on the RPi4 with a remote on the SS20, but then
> the colors are all wrong. Not 24-on-8 bits wrong, but more
> I-don't-understand-endianess wrong, I would guess. x86 monoculture is
> a plague - most codes assume little-endian & working unaligned
> accesses...
>
> Thinking of it - emacs-gtk in raspbian is built against gtk3; I
> checked: some stuff works on the SS20 Xserver, but not the row of
> buttons - IIRC, that was the same issue I saw earlier with the native
> X11 build (I prefer xemacs anyway!), as emacs is built against gtk3 in
> current pkgsrc:

Given I had a netsurf-gtk3 to hand...

It turns out (in case its of any interest to anyone searching these
mail archives in the future :) if you take a standard NetBSD-9/amd64
install and tweak the xorg.conf:
- "Device" to have Driver "vesa"
- "Screen" to have DefaultDepth 8
It will happily fire up in glorious PseudoColor, at which point
netsurf-gtk3, meld & easytag (all gtk3 using) just show empty windows.
Firefox (because its firefox) works. When I say "works", it shows
content where different colours are represented in the right place,
but the colours... oh my, everything seems to be bright primary
colours, including what you would expect to be black and white. Adding
Visual "GrayScale" in the Depth 8 SubSection made firefox show in
shades of grey, but no change to the others.

Setting a DefaultDepth of 16 allowed everything to work (not directly
helpful, but a data point). Adding Visual "GrayScale" to the Depth 16
section had no effect.

Note this was done in a qemu nvmm VM with a fresh NetBSD-9 install as
I didn't want to interrupt a bunch of stuff I had active on my laptop,
and I ran the apps from the laptop across to the VM, which should not
have affected anything (particularly as th 16 bit depths worked).

So... I wonder if standard gtk3 apps require TrueColor or DirectColor visuals...

David