> I managed to get version 0.91 to compile with DJGPP and most of the > samples run OK.
Was this with no changes to makefiles? >However, when compiling 0.92 only a few samples still work. The 0.92 >snapshot does compile but the > samples do not work at all any more. Significant changes in drivers were starting to happen in 0.92, with the very major changes happening just after 0.92 was released. When you say "doesn't work" much more description is required to reply with anything meaningful. > Since the documentation describes Nano-X as a modular architecture, is it > possible to use the old drivers with the 0.92 versions? They have moved to > the depreciated directory. The code remains modular but major driver changes were made for speed gains. The older drivers were moved to deprecated because there was little use of the platforms in the last 5+ years, and noone was around for testing them. Simple movement of the drivers back won't work without porting the changed SCREENDEVICE structure members etc. You'll want to study the new vs the old before starting. > Why did you drop the code that supported these drivers and could it not be > made optional instead? In most cases, the older systems didn't support truecolor, and few are interested in palette support these days. Palette support is still there, but I tried to clean up the release and only include files that would compile. > Can I just replace the new fblinxx drivers with the old ones or has the > code also changed that used these? The new fblinxx drivers are a required part of the 0.92 and subsequent architectures, which now always use them to draw offscreen, then use the new driver blit functions to move/display bits rapidly. In the older architecture, all the drawing was attempted by the drivers, which ended up getting problematic as the requirement for alpha blending, differing-bits-per-pixel, and complete ROP implementations for all bpp drivers grew. Thus, the new architecture has standardized fblinxx drivers for all portrait mode drawing, with a new conversion blit implementation that works for almost all bpps. These are all handled internal prior to getting to the screen driver level. You need to implement a direct memory mapping, or a blit driver entry point in the older driver structure to allow the internal drawing to be displayed (required for fonts and images). > I have seen there is a member in the MWSCREENINFO structure: > MWBOOL fbdriver; /* true if running mwin fb screen driver*/ > What does Nano-X do if you set this to FALSE? That's an old kluge that will need to be moved. I think it was originally included for a way for clients to know whether there was a real framebuffer when being requested to map a window to a framebuffer for fast video display. It has no effect for the issues you're discussing. Regards, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
