9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] trident cyber 9525 graphics glitches
@ 2021-09-05 17:30 lyndsay lastname
  2021-09-05 22:52 ` qwx
  0 siblings, 1 reply; 10+ messages in thread
From: lyndsay lastname @ 2021-09-05 17:30 UTC (permalink / raw)
  To: 9front

------sinikael-?=_1-16308630216640.2992016441892944
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

hi all,

sorry if this is out of place, i'm new to 9front and plan 9 in general. i'd 
appreciate it if you directed me to the appropriate venue for asking this 
question if this isn't the right one.

i'm trying to install 9front on an old toshiba satellite 2250cdt, which has 
a trident cyber 9525 gpu. it seems like that device is supported, as 
there's an entry for it in /lib/vgadb under the cyber938x controller, but 
i'm having some issues with this particular configuration seemingly not 
wanting to play nice with 9front and it's made it impossible to get the 
system up and running.

first of all, the vanilla /lib/vgadb does not have an entry with the right 
BIOS identifier for this device, so it wasn't giving me any graphical 
output regardless of the settings i chose at first. i was able to revise 
the cyber938x entry in /lib/vgadb to add the appropriate line (diff) and 
inject that into the install ISO, and it now does produce some output with 
`aux/vga -m xga -l 1024x768x16`. (it does not work with -m vesa.) this gpu 
technically supports 24-bit color modes, but vga dies telling me there's 
not enough memory if i try to use one, which is also a known problem on 
solaris that they say to fix by using a 16-bit mode.  

the issue now is that although i can get the display to load, the screen 
output is garbled. it properly renders the cursor, including its movement, 
and responds to my keyboard too, but everything else is totally broken. it 
IS clear where the things displayed on the screen are coming from, so it's 
not like it's just dumping nonsense from memory. i'll link two pictures 
showing what this looks like - the first is the initial screen the 
installer drops to where it asks for mouse type, the second is the default 
rio layout after hitting enter on that screen:

https://i.imgur.com/z9fauzt.jpeg

https://i.imgur.com/ND9THHP.jpeg

i have absolutely no idea how to fix this and i can't really find anything 
clear in the FQA. any suggestions?
------sinikael-?=_1-16308630216640.2992016441892944
Content-Type: text/html; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

<html><head></head><body><p>hi all,</p>
<p>sorry if this is out of place, i'm new to 9front and plan 9 in general. 
i'd appreciate it if you directed me to the appropriate venue for asking 
this question if this isn't the right one.</p><p>i'm trying to 
install 9front on an old toshiba satellite 2250cdt, which 
has a trident cyber 9525 gpu. it seems like that device is supported, as 
there's an entry for it in /lib/vgadb under the cyber938x controller, but 
i'm having some issues with this particular configuration seemingly not 
wanting to play nice with 9front and it's made it impossible to get the 
system up and running.</p><p>first of all, the vanilla /lib/vgadb does not 
have an entry with the right BIOS identifier for this device, so it wasn't 
giving me any graphical output regardless of the settings i chose at first. 
i was able to revise the cyber938x entry in /lib/vgadb to add the 
appropriate line (<a class="" 
href="https://pastebin.com/YQsyWZnH">diff</a>) and inject that into the 
install ISO, and it now does produce some output with `aux/vga -m xga -l 
1024x768x16`. (it does not work with -m vesa.) this gpu technically 
supports 24-bit color modes, but vga dies telling me there's not enough 
memory if i try to use one, which is also a <a class="" 
href="https://www.oracle.com/webfolder/technetwork/hcl/data/components/details/trident/sol_10_01_06/1291.html">known 
problem on solaris</a>&nbsp;that they say to fix by using a 16-bit 
mode.&nbsp;&nbsp;</p><p>the issue now is that although i can get the 
display to load, the screen output is garbled. it properly renders the 
cursor, including its movement, and responds to my keyboard too, but 
everything else is totally broken. it IS clear where the things displayed 
on the screen are coming from, so it's not like it's just dumping nonsense 
from memory. i'll link two pictures showing what this looks like - the 
first is the initial screen the installer drops to where it asks for mouse 
type, the second is the default rio layout after hitting enter on that 
screen:</p><p>https://i.imgur.com/z9fauzt.jpeg</p><p>https://i.imgur.com/ND9THHP.jpeg</p><p>i 
have absolutely no idea how to fix this and i can't really find anything 
clear in the FQA. any suggestions?</p></body></html>
------sinikael-?=_1-16308630216640.2992016441892944--

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-05 17:30 [9front] trident cyber 9525 graphics glitches lyndsay lastname
@ 2021-09-05 22:52 ` qwx
  2021-09-05 23:18   ` lyndsay
  0 siblings, 1 reply; 10+ messages in thread
From: qwx @ 2021-09-05 22:52 UTC (permalink / raw)
  To: 9front

Hi lyndsay,

> first of all, the vanilla /lib/vgadb does not have an entry with the right 
> BIOS identifier for this device, so it wasn't giving me any graphical 
> output regardless of the settings i chose at first. i was able to revise 
> the cyber938x entry in /lib/vgadb to add the appropriate line (diff) and 
> inject that into the install ISO, and it now does produce some output with 
> `aux/vga -m xga -l 1024x768x16`. (it does not work with -m vesa.) this gpu 
> technically supports 24-bit color modes, but vga dies telling me there's 
> not enough memory if i try to use one, which is also a known problem on 
> solaris that they say to fix by using a 16-bit mode.  

The device's pci did may be missing from /lib/vgadb simply because no one
has tested that particular device, but since you can at least get a picture,
it can be added, especially if modesetting with vesa doesn't work.


> the issue now is that although i can get the display to load, the screen 
> output is garbled. it properly renders the cursor, including its movement, 
> and responds to my keyboard too, but everything else is totally broken. it 
> IS clear where the things displayed on the screen are coming from, so it's 
> not like it's just dumping nonsense from memory. i'll link two pictures 
> showing what this looks like - the first is the initial screen the 
> installer drops to where it asks for mouse type, the second is the default 
> rio layout after hitting enter on that screen:

I think this is a bug either in vga(8) or elsewhere and it's not limited to
this driver.  My 380d with a neomagic gpu behaves similarly (sysinfo: [1]).
24bit modes cannot be enabled, though you could try the same command 2-3
times in a row, this sometimes works on these drivers despite the memory
errors, though probably without useful results.  I also had a garbled
picture, but only on the bottom of the screen, again indicating similar
memory issues.  Using a *lower resolution* works.  An even lower resolution
with 24bit color may have worked too, I don't remember.  The cursor is ok
probably because it's the hardware cursor, which is handled elsewhere
(someone please correct me if I'm wrong).

Hardware issue or bugs, there are no two ways of fixing it.  These drivers
are very old and no one has touched them since forever, mostly because no
one has really used 9front on hardware this old, and those who have haven't
arsed to fix them (sorry).  I could try to look at my 380d at some point if
it still even boots and the stupid pcmcia dongle works, but these are empty
promises.  If you'd like to try debugging this, we'll help however we can.

Hope this clears it up somewhat,

qwx

[1] http://plan9.stanleylieber.com/hardware/thinkpad/380d/2635-3au/sysinfo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-05 22:52 ` qwx
@ 2021-09-05 23:18   ` lyndsay
  2021-09-06  0:08     ` qwx
  0 siblings, 1 reply; 10+ messages in thread
From: lyndsay @ 2021-09-05 23:18 UTC (permalink / raw)
  To: 9front

oh my god, i can't believe i didn't think of simply trying a lower 
resolution. i'm an idiot sometimes. the graphics DO in fact work fine, 
and it accepts 24-bit color, using a 640x480 resolution! i would 
definitely be interested in trying to debug and fix the issue at the 
source if you/others on the list are interested in helping with that, 
but i know that's a tall task and probably not a priority for most 
people, so just downscaling looks like it will work as a quick 
superficial fix.

thank you!!

On 9/5/21 4:52 PM, qwx wrote:
> Hi lyndsay,
>
>> first of all, the vanilla /lib/vgadb does not have an entry with the right
>> BIOS identifier for this device, so it wasn't giving me any graphical
>> output regardless of the settings i chose at first. i was able to revise
>> the cyber938x entry in /lib/vgadb to add the appropriate line (diff) and
>> inject that into the install ISO, and it now does produce some output with
>> `aux/vga -m xga -l 1024x768x16`. (it does not work with -m vesa.) this gpu
>> technically supports 24-bit color modes, but vga dies telling me there's
>> not enough memory if i try to use one, which is also a known problem on
>> solaris that they say to fix by using a 16-bit mode.
> The device's pci did may be missing from /lib/vgadb simply because no one
> has tested that particular device, but since you can at least get a picture,
> it can be added, especially if modesetting with vesa doesn't work.
>
>
>> the issue now is that although i can get the display to load, the screen
>> output is garbled. it properly renders the cursor, including its movement,
>> and responds to my keyboard too, but everything else is totally broken. it
>> IS clear where the things displayed on the screen are coming from, so it's
>> not like it's just dumping nonsense from memory. i'll link two pictures
>> showing what this looks like - the first is the initial screen the
>> installer drops to where it asks for mouse type, the second is the default
>> rio layout after hitting enter on that screen:
> I think this is a bug either in vga(8) or elsewhere and it's not limited to
> this driver.  My 380d with a neomagic gpu behaves similarly (sysinfo: [1]).
> 24bit modes cannot be enabled, though you could try the same command 2-3
> times in a row, this sometimes works on these drivers despite the memory
> errors, though probably without useful results.  I also had a garbled
> picture, but only on the bottom of the screen, again indicating similar
> memory issues.  Using a *lower resolution* works.  An even lower resolution
> with 24bit color may have worked too, I don't remember.  The cursor is ok
> probably because it's the hardware cursor, which is handled elsewhere
> (someone please correct me if I'm wrong).
>
> Hardware issue or bugs, there are no two ways of fixing it.  These drivers
> are very old and no one has touched them since forever, mostly because no
> one has really used 9front on hardware this old, and those who have haven't
> arsed to fix them (sorry).  I could try to look at my 380d at some point if
> it still even boots and the stupid pcmcia dongle works, but these are empty
> promises.  If you'd like to try debugging this, we'll help however we can.
>
> Hope this clears it up somewhat,
>
> qwx
>
> [1] http://plan9.stanleylieber.com/hardware/thinkpad/380d/2635-3au/sysinfo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-05 23:18   ` lyndsay
@ 2021-09-06  0:08     ` qwx
  2021-09-06  0:53       ` lyndsay
  2021-09-21  4:11       ` lyndsay
  0 siblings, 2 replies; 10+ messages in thread
From: qwx @ 2021-09-06  0:08 UTC (permalink / raw)
  To: 9front

> oh my god, i can't believe i didn't think of simply trying a lower 
> resolution. i'm an idiot sometimes. the graphics DO in fact work fine, 
> and it accepts 24-bit color, using a 640x480 resolution! i would 
> definitely be interested in trying to debug and fix the issue at the 
> source if you/others on the list are interested in helping with that, 
> but i know that's a tall task and probably not a priority for most 
> people, so just downscaling looks like it will work as a quick 
> superficial fix.

I doubt it occurred to me immediately either :)  Do compare drawing
performance between 16 and 24bit mode, one may be significantly faster
than the other for you.  Debugging over the ml is very slow, but I
would suggest comparing with linux or some other os to check if vesa
works there and if the drivers behave the same way, and if they don't,
1) tracing where vesa fails, and/or 2) tracing where the memory issue
comes from in the cyber938x.c drivers (/sys/src/9/pc/vgacyber938x.c
functions in cyber938xdev struct and
/sys/src/cmd/aux/vga/vgacyber938x.c) and reading the linux or w/e
driver...  Others may make smarter suggestions.

Please send a patch for whatever you modified (just /lib/vgadb?) :)

Cheers,

qwx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-06  0:08     ` qwx
@ 2021-09-06  0:53       ` lyndsay
  2021-09-06 21:29         ` qwx
  2021-09-21  4:11       ` lyndsay
  1 sibling, 1 reply; 10+ messages in thread
From: lyndsay @ 2021-09-06  0:53 UTC (permalink / raw)
  To: 9front

This is a multi-part message in MIME format.
--------------ED92217CFCC97BA67B1C1856
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

ok, sounds doable... i'll do some work on that tomorrow. i'm pretty sure=20
it would have been using vesa (1.0?) on windows xp, which was installed=20
on it before i demolished it to make room for plan 9, so i think there=20
*is* a way to get it working. apparently the source code for xp is out=20
there, so if linux fails me, there's that too!

i just modified /lib/vgadb, yep. i attached the patch and i did also try=20
to submit a pull request to the main repository but i have no idea if it=20
went through and my git on this pc is broken and has outdated=20
credentials anyway, so it might be better if someone who knows what=20
they're doing just commits it instead =F0=9F=98=85

- lyndsay

On 9/5/21 6:08 PM, qwx wrote:
>> oh my god, i can't believe i didn't think of simply trying a lower
>> resolution. i'm an idiot sometimes. the graphics DO in fact work fine,
>> and it accepts 24-bit color, using a 640x480 resolution! i would
>> definitely be interested in trying to debug and fix the issue at the
>> source if you/others on the list are interested in helping with that,
>> but i know that's a tall task and probably not a priority for most
>> people, so just downscaling looks like it will work as a quick
>> superficial fix.
> I doubt it occurred to me immediately either :)  Do compare drawing
> performance between 16 and 24bit mode, one may be significantly faster
> than the other for you.  Debugging over the ml is very slow, but I
> would suggest comparing with linux or some other os to check if vesa
> works there and if the drivers behave the same way, and if they don't,
> 1) tracing where vesa fails, and/or 2) tracing where the memory issue
> comes from in the cyber938x.c drivers (/sys/src/9/pc/vgacyber938x.c
> functions in cyber938xdev struct and
> /sys/src/cmd/aux/vga/vgacyber938x.c) and reading the linux or w/e
> driver...  Others may make smarter suggestions.
>
> Please send a patch for whatever you modified (just /lib/vgadb?) :)
>
> Cheers,
>
> qwx

--------------ED92217CFCC97BA67B1C1856
Content-Type: text/x-patch; charset=UTF-8;
 name="cyber9525.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="cyber9525.patch"

294a295
> 	0xC70C5="TVGA BIOS KTT 6.0"             # Cyber 9525 / Satellite 2250CDT


--------------ED92217CFCC97BA67B1C1856--

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-06  0:53       ` lyndsay
@ 2021-09-06 21:29         ` qwx
  0 siblings, 0 replies; 10+ messages in thread
From: qwx @ 2021-09-06 21:29 UTC (permalink / raw)
  To: 9front

> ok, sounds doable... i'll do some work on that tomorrow. i'm pretty sure 
> it would have been using vesa (1.0?) on windows xp, which was installed 
> on it before i demolished it to make room for plan 9, so i think there 
> *is* a way to get it working. apparently the source code for xp is out 
> there, so if linux fails me, there's that too!
> 
> i just modified /lib/vgadb, yep. i attached the patch and i did also try 
> to submit a pull request to the main repository but i have no idea if it 
> went through and my git on this pc is broken and has outdated 
> credentials anyway, so it might be better if someone who knows what 
> they're doing just commits it instead 😅
> 
> - lyndsay

Thanks, pushed your patch.  The easiest way for patches is to just send
them on the mailing list here like you see others doing, attached or
inline if your mail client doesn't garble them, preferably formatted as
with git/export or similar (see fqa 2.5 [1]).

I hate lawyershit, but if the winxp sources are from a leak or something,
it might be a bad idea to consult or copy code from them.  It's annoying,
but we should respect this legalshit to the best of our ability, just to
avoid any stupid trouble.  I'll let someone who understands this better
correct me.  I don't even know if windows nt sources are more readable
than linux ones...

Good luck!

qwx

[1] http://fqa.9front.org/fqa2.html#2.5

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-06  0:08     ` qwx
  2021-09-06  0:53       ` lyndsay
@ 2021-09-21  4:11       ` lyndsay
  2021-09-21  5:06         ` unobe
  2021-09-21  9:17         ` qwx
  1 sibling, 2 replies; 10+ messages in thread
From: lyndsay @ 2021-09-21  4:11 UTC (permalink / raw)
  To: 9front

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.

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.

thanks !

lyndsay

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-21  4:11       ` lyndsay
@ 2021-09-21  5:06         ` unobe
  2021-09-21  9:17         ` qwx
  1 sibling, 0 replies; 10+ messages in thread
From: unobe @ 2021-09-21  5:06 UTC (permalink / raw)
  To: 9front

Quoth lyndsay <lyndsay@vivaldi.net>:
> 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 cannot remember where I ran across a detailed description and
exploration of those fields, but you can find them online.  Hopefully
this will help:

http://9p.io/wiki/plan9/adding_a_monitor_to_vgadb/index.html


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-21  4:11       ` lyndsay
  2021-09-21  5:06         ` unobe
@ 2021-09-21  9:17         ` qwx
  2021-09-21 14:45           ` lyndsay
  1 sibling, 1 reply; 10+ messages in thread
From: qwx @ 2021-09-21  9:17 UTC (permalink / raw)
  To: 9front

> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9front] trident cyber 9525 graphics glitches
  2021-09-21  9:17         ` qwx
@ 2021-09-21 14:45           ` lyndsay
  0 siblings, 0 replies; 10+ messages in thread
From: lyndsay @ 2021-09-21 14:45 UTC (permalink / raw)
  To: 9front

thanks both! i can definitely read the trident section and just try to 
fix it based on that - hopefully it's accurate enough. also thanks for 
the wiki page unabe, i will keep that in my bookmarks, though it looks 
like i won't need it based on what qwx said.

qwx, the one thing that made me think it could also be a monitor issue 
is that there's some amount of display flickering, but that could also 
be due to memory, so i'll just take a look at the driver first. thanks!

lyndsay


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-09-21 15:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-05 17:30 [9front] trident cyber 9525 graphics glitches 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
2021-09-21 14:45           ` lyndsay

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ https://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git