9front - general discussion about 9front
 help / color / mirror / Atom feed
From: qwx@sciops.net
To: 9front@9front.org
Subject: Re: [9front] trident cyber 9525 graphics glitches
Date: Tue, 21 Sep 2021 11:17:49 +0200	[thread overview]
Message-ID: <F716F897D01D247067E27A99E740E34B@wopr.sciops.net> (raw)
In-Reply-To: <04dddd48-aaea-7d48-66d8-ffb6ae74520f@vivaldi.net>

> i have been trying to work further on this tc 9525 issue but i've run 
> into a couple stumbling blocks. i got the book by richard ferraro 
> recommended in vgadb(6) in order to figure out what i'm doing and while 
> i do intend to read at least the relevant parts, it is 1600 pages long 
> so i'm moving slowly. it also is slightly too old and only addresses 
> trident cyber editions up to 9430, which makes it hard to figure out 
> ironclad specifics for the 9525 (especially because according to 
> ferraro, the memory addressing especially differs significantly between 
> versions, so i cannot trust the information there to necessarily be 
> applicable to the 9525). could still maybe infer how it operates from 
> looking at the 3,000(!) lines of bloated terrible xorg code for this 
> driver alone but frankly, i would rather read the entire 1600 pages and 
> spend weeks reverse engineering the card all while lying on hot coals 
> than do that.
> 
> anyway i had the thought that i should test the graphics with a specific 
> monitor entry in vgadb before trying to slog through the book, because i 
> didn't try that before, only added the did. (correct me if this 
> definitely will not do anything to help; i'm still new to how this all 
> works.) i found an xserver configuration for the same card on a toshiba 
> laptop with the same resolution (not the exact same laptop though), so 
> i'm thinking it might work as a base - 
> https://www.sanpei.org/Laptop-X/Laptop-X/Toshiba_Satellite_4070CDT. 
> unfortunately the vgadb man page does not actually explain how to write 
> a monitor entry, since 6 key fields can, according to it, only be 
> explained by that book. i cannot find an explanation for those from the 
> skimming i've done and they don't seem self-explanatory, looking through 
> vgadb. anyone on this list happen to know where it explains 
> shb/ehb/ht/vrs/vre/vt in the book? or if you don't but you can explain 
> it that's great too.

I definitely don't think it's necessary to read this book
besides the section on the trident cards and *maybe* the display
memory timing section (7.7, pp 263-268), which is what the
manpage is probably alluding to for the timings, but it doesn't
really explain much.

I think your focus should be correlating the plan9 driver with
the description in the book and figuring out what is screwed up
in plan9's driver.  From my completely non-expert point of view,
the card is essentially correctly configured, except for memory.
Therefore, that is where you should look:  how is this
configured?  Where in the plan9 driver is the memory size
determined, or where is it set?  Is there an assumption that
breaks somewhere outside of the driver itself?  It might be the
case if the same thing happens with other drivers, like with the
neomagic one on my 380d.  Be wary of how x8/x15/x16/x24 modes
or color depths or w/e are handled, I don't think many people
use anything besides x32, igfx for instance doesn't support them.

If you suspect issues in the driver itself, you don't actually
need to read much of the xorg code.  Instead, look at all the
hardware registers that are defined (in headers or whatever),
check ones that might differ or be suspect, and grep, comparing
with our driver.  If you really don't want to look at the code
(and who could blame you), I'm not sure what you could do...
I can't find any datasheets, but you could try to find out
where the code came from, or maybe even find the patch/revision
that added support for this particular card...  but that would
be even more annoying.  There's also still the possibility of
just making vesa work instead.

As far as timings, I think you should ignore all of that.
These are in a way specific to the monitor, not the card.  For
standard resolutions on these old cards, I doubt it's much of
a problem to just use the basic timings in vgadb (the first
include= entries).  If they were wrong, your picture would be
misplaced, or fuzzy/distorted, etc.  For instance, if your
picture was offset to the right for some reason, you could
adjust the timings to correct it.  This isn't the case here.
Otherwise, aside from EDID information that vga(8) can see, I
don't know how to extract this information from plan9.  Like
the post unobe shared, in the past I had just booted some
livecd and used some x11 tool to check them.  Maybe cinap or
someone else would know...

> also, qwx, did my original vgadb patch go through ok or did it get lost? 
> i can try to send it again in the git format if you want.

Your patch was added in 87a823332f9eaa4ff1e72f8524f6e59d1cc4f407 :)
Thanks again!

I hope this helps a bit,

Cheers,
qwx

  parent reply	other threads:[~2021-09-21  9:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05 17:30 lyndsay lastname
2021-09-05 22:52 ` qwx
2021-09-05 23:18   ` lyndsay
2021-09-06  0:08     ` qwx
2021-09-06  0:53       ` lyndsay
2021-09-06 21:29         ` qwx
2021-09-21  4:11       ` lyndsay
2021-09-21  5:06         ` unobe
2021-09-21  9:17         ` qwx [this message]
2021-09-21 14:45           ` lyndsay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F716F897D01D247067E27A99E740E34B@wopr.sciops.net \
    --to=qwx@sciops.net \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).