X11 1.20 and firefox 75 warning
From
Winston@21:1/5 to
All on Sat Apr 25 11:20:48 2020
What a mess: A couple days spent and still worse off, but at least
functional again...
Initially, the system was running X11 1.18 and Firefox 70, both of which
worked just fine.
A few days ago, I needed a program for a few minutes so I pkg install'ed
it. Doing so required upgrading firefox from 70 to 75, but firefox
upgrades have usually been OK. When I was done, I pkg remove'd the
program and pkg autoremove'd all the extra stuff it had dragged in. All
seemed fine so far.
When next I started firefox, it could only view local files and couldn't retrieve anything from the 'Net. Other programs could still access the
Net just fine, so it wasn't a DNS or connectivity problem.
So I figured there must be other stuff that needed to be upgraded, too.
I pkg remove'd firefox and autoremoved its other stuff, then reinstalled everything. No help.
So I went whole hog: pkg upgrade [everything, including xorg], but
without rebooting or quitting X11 1.18 yet. Firefox still wasn't able
to get anything from the Net.
So I shut down and rebooted. I then spent the next two days trying to
get X11 1.20 to work decently.
The VESA driver which had supported 1600x1200 just fine in 1.18 now
pretty much refuses to do anything except 640x480. I haven't even been
able to get it to do 1280x1024 which both the monitor and graphics chip support. According to the log file, even though some of the VESA
1600x1200 and 1280x1024 modes were marked with a '*' (which I believe
indicates they're acceptable modes) and even though it describes
"1600x1200" and "1280x1024" as built-in configurations, it later says:
Not using mode "1600x1200" (no mode of this name)
Not using mode "1280x1024" (no mode of this name)
and ends up at 640x480. Yes, other details probably matter and may be
causing "no mode", but it was working in 1.18. I at least found a way
to convince the graphic chip driver to do 1280x1024, so I'm not stuck
with 640x480, but even that was a struggle.
X11 gets started up the usual way, using startx which runs .xinitrc,
just as before. However, even after things have come up, they're not
quite right:
* The .xinitrc script calls xmodmap to do the standard (X11 1.20 man
page listed) commands to swap Caps Lock and Ctrl. It only half
worked: It left both Caps Lock and Ctrl as Caps Lock.
I found a workaround: As advertised, running xmodmap again undid the
swap. Running it a third time succeeded in swapping them. :-/
* The window manager's rc commands, which included various key bindings,
were only partially performed.
Workaround: tell the window manager to re-read its rc file.
Both of those are key binding issues. Maybe that's significant, IDK.
* The only good news is that Firefox is now once again able to get pages
from the 'Net. The bad news is that it spews lot of:
console.warn: services.settings: Could not determine network status.
Message: TypeError: gNetworkLinkService is undefined
as it does so. :-/
I'm posting this mostly as a warning to everyone else here that this
particular upgrade may not go smoothly. There may also be other issues
I haven't encountered yet.
I plan to read "man xorg.conf" yet again to see if there's something new
I need to be doing. Adding "Visual 1280 1024" didn't stop the VESA
driver from going to its 640x480 default, and "Visual 1600 1200" with
the graphic chip driver ends up creating a pan-and-scan desktop with
1280x1024 actual, which is interesting, in that it can do that, but
isn't what I'd like.
If I figure out anything useful, I'll follow up.
-WBE
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
From
Winston@21:1/5 to
All on Sun Apr 26 18:32:29 2020
I've done more tests.
* I've tried some BIOS changes and various xorg.config file things, but
haven't gotten the VESA driver to do anything except its fallback
640x480.
* Another new problem is display lag. There's now a lag of anywhere
from (I'm estimating, since these short times are hard to measure) 100
- 700 ms for even simple things like scrolling. I'm seeing this not
only in firefox, emacs, and other applications that manage their own
windows but also in one of my own applications that I'm certain didn't
change when I did "pkg upgrade" [all]. Page up/down operations that
used to be nearly instantaneous now take 200-400 ms to start, and the
delay seems to be proportional to the amount drawn (e.g., a page full
of text takes longer than a mostly empty page). In firefox displaying
a local file (where there's no network or script stuff on the page),
page up/down now happens piece by piece, the way you'd expect if there
were some huge load average (there's not) or being done over a slow
network connection.
It's hard to know for sure what's at fault, though, since I had to
switch drivers from VESA to one specific to the built-in graphics chip
on that system, and I don't have data from 1.18 regarding whether such
lag would have happened back then with that configuration.
I've now re-read xorg.conf and tried pretty much all the things I know
to try, so I guess I'll have to live with it until whatever all got
broken gets fixed. [Yes, the log indicates that MIT-SHM is enabled.]
At this point, based on this sample size of one, it looks like unless
you have to upgrade from xorg 1.18 to 1.20, don't, especially if you use
the VESA driver.
-WBE
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)