* [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> that they say to fix by using a 16-bit mode. </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
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).