Re: CG14 in 8-bit color
Romain Dolbeau <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc |
|---|---|
| Message-ID | <CADuzgbrZNsuNnzReEGj-Sfdu+CmRt-jJoUKXBpnwb90CdoCc1Q@mail.gmail.com> |
Le ven. 3 déc. 2021 à 19:24, Michael <[email protected]> a écrit : > IIRC the tgx+ topped out at 1600x1200, according to its firmware. You can coerce a true TGX[+] into many alternatives resolutions to Sun's if you reprogram the clock generator & the control registers (you really want a + to get the extra memory). The problem is modern LCDs that are very restrictive on what they accept on their analog input, so finding a working match is not always easy. (some years ago I had done some experiments: <https://github.com/rdolbeau/SunTurboGX>). > No clue about the X11 issue, does it happen during framebuffer or > register access? Neither, it doesn't crash while accessing hardware in X11, that's part of why it's been a pain to diagnose. When using my own re-implementation of a cg6 or a cg3 (and the cg3 is a very passive and simple device), X11 works apparently fine (visually speaking), but after I exit X11 the kernel will crash sooner or later (this does not happen with a real cg6 of course, so it concerns literally just me! I don't have a real cg3 handy to triple-check). It happens even when my device is set to a lower resolution like 1024x768 or 1152x900. If I deliberately use swap while running X11, it apparently gets corrupted; if I use swap after leaving X11, a crash is guaranteed, and it's always in 'pv_syncflags4m' IIRC. As far as I can tell (but my knowledge of the NetBSD internals is very limited), it seems the kernel page table gets corrupted somehow when X11 is using my device instead of the 'real McCoy', and it doesn't make sense to me. I tried to faithfully replicate the ROM behavior in terms of what is left mapped when the kernel boots, the ROM is the only bit of SW that is not the same as when running a Sun cg6. The re-implemented cg3 is really puzzling, as cg3 reuses the console driver in X11. I can have 2k+ page-ins/page-outs per second to swap on my sdram-disk all day long with no issue when using only the console... It's only X11 that causes the issue. (the good news is that because of that bug I went back to working on the micro-sdcard support; it is now bootable, even if my NetBSD driver is still fairly slow and rough :-) ) Cordially, -- Romain Dolbeau