Hello, On Tue, 17 Dec 2024 21:28:08 +0100 Helge Deller <deller@xxxxxx> wrote: > > Full disclosure - I'm a NetBSD developer, I used some docs found on > > parisc.docs.kernel.org, this is my attempt at giving back / comparing notes. > > > > Recently I wrote native drivers for Visualize EG, HCRX and Visualize FX > > 4, they all support framebuffer access, basic acceleration, cursor > > sprite, and on the HCRX, 24bit colour. > > I assume you mean native drivers for NetBSD ? Yes. The hardware is quite weird so just posting the sources seemed the easiest way to document it. I'm well aware that our respective console subsystems are too different to port anything directly. > On Linux VisEG and HCRX are supported in graphics mode, and VisFX in > text mode only. > We do have drivers for VisFX in graphics mode too, one for fbdev > and the other for drm. Both are not upstreamed yet and have various > reasons why I haven't upstreamed them yet. > See branches at > https://github.com/hdeller/linux/tree/hp-visualize-fx-fbdev-2 We were the same way - there's a generic console driver that just uses STI calls for everything, with a little extra to put known hardware into fb mode, then run X on a dumb framebuffer. > > I also wrote an Xorg driver that > > supports whatever acceleration I could figure out, which is copy, > > fill and hardware cursor, on all of the above, except ROPs on > > Visualize FX. > > Maybe the VisFX driver sources from Sven Schnelle can give you some > idea. See github repo above. I looked at a proposed console driver, compared notes and made a bunch of additions, tried to keep my own code more or less compatible. Looks like an older version of the above. Also found some differences between my FX4 and his FX5 along the way. > > EG, HCRX etc. register functions are here: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/stireg.h > > PCI Visualize EG / Graffiti driver: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/gftfb.c > > > HCRX / hyperdrive: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/hyperfb.c > > > > Visualize FX stuff, mostly found by disassembling the STI ROM on my > > FX4, comparing notes with docs and hints found on > > parisc.docs.kernel.org, and a lot of experimentation: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/summitreg.h > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/summitfb.c > > > > The Xorg driver lives here: > > http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-ngle/dist/src/ > > > > Any chance this can get upstreamed? > I'm happy to test it on Linux. For now the driver is quite NetBSD-specific in the way it maps graphics devices. In order to support both PCI and GSC cards through the same driver with minimal hassle it just goes through NetBSD's console devices, maps fb and registers at fixed offsets and things like cursor sprite and colour maps are handled using ioctl()s because of the weird way the NGLE hardware wants them ( you basically write stuff into a buffer, then use the blitter(!) to move data to the actual registers, so we have to make sure nothing tries to use the blitter or access the fb while we do colour map updates... ) > > What I haven't been able to figure out so far: > > - how to do ROPs on Visualize FX. I can do colour expansion, STI > > colour change and plain fills and copies > > Here are the Linux VisFX drivers: > fbdev: > https://github.com/hdeller/linux/commit/87e03df1af93e8236b3c1b44e60c0fa2d6c995d5 > drm: > https://github.com/hdeller/linux/commit/3a5fc28d9e3d39e7e116b8acf0b028a3024d9c36 Nice, I wasn't aware of those! So, still no fb access. Well, I can help with that: #define VISFX_VRAM_READ_MODE 0xa0080c // this is a guess or, in HP speak, B2_SBA controls what you read in the fb aperture, in much the same way as B2_DBA controls what you write. Just like on HCRX, what we see and what the blitter sees is controlled by the same registers. B2_EN2D controls the fb aperture depth, 0xb0 gives you 8bit, 0xd0 32bit, at least on my FX4. Also, that's a *lot* of register definitions. Did someone get a hold of official headers? > > - access off-screen memory on HCRX. All we can mess with is > > 1280x1024 in both 24bit and the 8bit overlay. I'm sure the thing > > has more memory than that, but blitter ops wrap at those boundaries > > and FB reads return garbage. > > - off-screen memory on Visualize FX. STI reports 2048x2048 but > > what's actually accessible is screen width rounded up to the next > > multiple of 512 by screen height. There is a clipping register > > which STI sets to match the video mode but setting it to 2048x2048 > > does not allow access to anything else, blitter ops wrap like on > > HCRX. I *know* this thing has more memory than that. On the PCI EG > > we get full 2048x2048 no matter what mode we're in. > > - 24bit colour on the FX. I can switch the FB wndow to 32bit mode > > but that doesn't result in 24bit pixels being displayed. > > I have not hacked on it since quite some time ... :-( I only got started on hppa a year ago or so when I was able to get a C200 and then a C360 system board for relatively cheap - I've been writing drivers for weird and unusual graphics hardware for a long time, just not in hppa. have fun Michael
