nanogui: Thread: Screen driver development questions

Hi Greg,



I want to extend the scr_djgr screen driver with blit support. In general I understand that there shall be an area of offscreen memory where Nano-X will write the screen data to. When done it will either call xxxx_blit() in version 0.92 to write to the screen or xxxx_update() with the 0.93pre-snapshot version.




Where do I define the offscreen memory now? 




In the open function there is a psd->addr pointer. The scr_X11 driver makes a malloc to assign memory to psd->addr in the open function. However, the scr_svga driver sets this to null.

 

Both drivers also use gen_allocatememgc() to allocate a second PSD. The scr_svga driver apparently does not need gen_mapmemgc() or gen_freememgc() though to support blitting.




The function xxxx_blit() uses a source psd and a destination psd. The xxxx_update() function apparently just gets the source psd and then writes that data to the screen as the final destination. 



I guess somehow I have to define the offscreen memory for the source psd so I can blit the data to the screen i.e. the destination. Is that done with gen_allocatememgc() and do I have to set psd->addr to null in the open function then? Is gen_mapmemgc() required or can I drop that like the scr_svga driver? Is all this done differently with version 0.92 versus the snapshot version?




Georg

Georg -

Which version of Microwindows are you wanting to support?  The blit
architecture is entirely rewritten after the 0.92 version; thus your driver
will be completely different depending on whether you're running the
snapshot or 0.92.  In 0.92, you'll write a blit entry point that will move
bits from offscreen memory to the display, as well as handle many other
blit cases, such as copying memory to memory, and screen-to-screen
data.  In the snapshot, you will only have to implement the Update
entry point, which copies memory from offscreen to display, as
all the memory blits are handled internally.  I will answer your questions
below once I know the version you're running.

Regards,

Greg




I want to extend the scr_djgr screen driver with blit support. In general I 
understand that there shall be an area of offscreen memory where Nano-X will 
write the screen data to. When done it will either call xxxx_blit() in 
version 0.92 to write to the screen or xxxx_update() with the 
0.93pre-snapshot version.




Where do I define the offscreen memory now?




In the open function there is a psd->addr pointer. The scr_X11 driver makes 
a malloc to assign memory to psd->addr in the open function. However, the 
scr_svga driver sets this to null.



Both drivers also use gen_allocatememgc() to allocate a second PSD. The 
scr_svga driver apparently does not need gen_mapmemgc() or gen_freememgc() 
though to support blitting.




The function xxxx_blit() uses a source psd and a destination psd. The 
xxxx_update() function apparently just gets the source psd and then writes 
that data to the screen as the final destination.



I guess somehow I have to define the offscreen memory for the source psd so 
I can blit the data to the screen i.e. the destination. Is that done with 
gen_allocatememgc() and do I have to set psd->addr to null in the open 
function then? Is gen_mapmemgc() required or can I drop that like the 
scr_svga driver? Is all this done differently with version 0.92 versus the 
snapshot version?




Georg

I first tried to get a driver for the snapshot version to work and since I did not succeed with that I am trying version 0.92 now. Since the old driver works with partial success with 0.92 I think I better work with 0.92 now to get it to run.

Georg

> I want to extend the scr_djgr screen driver with blit support. In general 
> I understand that there shall be an area of offscreen memory where Nano-X 
> will write the screen data to.

Try copying one of the older screen drivers that had blit support, say
scr_svga.c (SVGA Library).  You will want to implement offscreen
to screen, as well as screen-to-screen support; SVGA only implemented
screen-to-screen (used when dragging windows when HAVEBLIT is defined).



>  When done it will either call xxxx_blit() in version 0.92 to write to the 
> screen or xxxx_update() with the 0.93pre-snapshot version.

The xxx_blit() routine will be called direction in 0.92 with address of 
either
screen memory or offscreen memory.  You're screen driver must allow
access to its memory buffers for this to work.  Your driver will basically
convert between the possibly different screen and offscreen data formats.


> In the open function there is a psd->addr pointer. The scr_X11 driver 
> makes a malloc to assign memory to psd->addr in the open function. 
> However, the scr_svga driver sets this to null.

SVGA lib sets psd->addr to NULL because it doesn't allow access to
any screen memory.  Thus only screen-to-screen copies (blits) are 
implemented.
Otherwise, psd->addr must be malloc'd and all sorts of extra handling
is required in order to keep the screen and psd->addr updated.  This is
not required in 0.93 and was a major reason for the architecture changes.
You can see the ugliness in 0.92 versions of the X11 driver, which are
greatly cleaned up in 0.93.  Basically, X11 had to both draw to the
screen AND keep an internal update of it's malloc'd psd->addr current
on every screen draw entry, drawpoint, drawhline, drawvline, blit etc.



> Both drivers also use gen_allocatememgc() to allocate a second PSD. The 
> scr_svga driver apparently does not need gen_mapmemgc() or gen_freememgc() 
> though to support blitting.

These are complicated by the discussion above.  Use the gen_xxx routines
unless you're going the complex X11-style route.


> The function xxxx_blit() uses a source psd and a destination psd. The 
> xxxx_update() function apparently just gets the source psd and then writes 
> that data to the screen as the final destination.

The Update function is not implentend in 0.92.  When you move to a 0.93
driver, it will be the only function required, and all the above discussion
of extra copying etc, will be no longer required.



> I guess somehow I have to define the offscreen memory for the source psd 
> so I can blit the data to the screen i.e. the destination. Is that done 
> with gen_allocatememgc() and do I have to set psd->addr to null in the 
> open function then? Is gen_mapmemgc() required or can I drop that like the 
> scr_svga driver?

The simplest case is when the screen memory can be directly accessed, then 
use gen_xxx
routines.  Otherwise, go the X11 route with custom handlers for everything, 
and
complex entry points that draw and copy.

> Is all this done differently with version 0.92 versus the snapshot 
> version?

Yep!

Regards,

Greg







Georg

Hi Greg,

thank you for your post. I have to say after you explained how complex the 
blit support with a screen driver for 0.92 would be I tried to write one for 
the Snapshot version. I used MWPF_TRUECOLOR565 and got it to work! The 
samples work just as they did before with 0.91.

On the other hand, could you please explain how to get the printf, dprintf, 
eprintf, fprintf commands to write to a file? If these would print/write to 
STDOUT, I could redirect them on the start of the program. The changes I 
tried in the error.c files did not seem to work.

I also tried to set HAVE_FILEIO=1 but that did not seem to cause a file to 
be opened and the messages were still send to the screen. What is the name 
of that file and how do I open it?

When should I set -DHAVE_FPRINTF=1?

Georg

: thank you for your post. I have to say after you explained how complex the
: blit support with a screen driver for 0.92 would be I tried to write one 
for
: the Snapshot version. I used MWPF_TRUECOLOR565 and got it to work! The
: samples work just as they did before with 0.91.

Great!  Perhaps we'll have to resurrect support for DJGPP, based on
your contributions.

: When should I set -DHAVE_FPRINTF=1?

This should be set when you're compiling for any system that
has fprintf. Look in include/device.h and you'll see that EPRINTF
and DPRINTF will use fprintf(stderr, ....).  Otherwise, the system
will use calls to GdError.

:
: On the other hand, could you please explain how to get the printf, 
dprintf,
: eprintf, fprintf commands to write to a file? If these would print/write 
to
: STDOUT, I could redirect them on the start of the program. The changes I
: tried in the error.c files did not seem to work.

Looks like you need to change stderr to stdout in the device.h defines
above.



:
: I also tried to set HAVE_FILEIO=1 but that did not seem to cause a file to
: be opened and the messages were still send to the screen. What is the name
: of that file and how do I open it?

HAVE_FILEIO just allows various nano-X functions to be compiled in
that assume a file system.  This should be set for your system.

Regards,

Greg

Actually I wrote two drivers, one using libgrx20 and another one using VESA 
directly. I am willing to contribute my screen drivers and makefiles with an 
application note for DOS. So you can really resurrect Microwindows for DOS.

Currently I try to implement other pixeltypes in the driver and to get my 
makefiles into shape. When I have done that I will send you a ZIP file. 
Probably I will have to ask some more questions to get done though.

Georg 

: Actually I wrote two drivers, one using libgrx20 and another one using 
VESA
: directly. I am willing to contribute my screen drivers and makefiles with 
an
: application note for DOS. So you can really resurrect Microwindows for 
DOS.

Is this for 0.92 or 0.93pre?  If the latter, are you building a 32-bit
version for DOS using DJGPP?  I think that the code size is way
too large without built-in protected mode....  right?

Are you running DOS for testing, or actually using it in some
embedded environment...  or is this all for FUN!!??


:
: Currently I try to implement other pixeltypes in the driver and to get my
: makefiles into shape. When I have done that I will send you a ZIP file.
: Probably I will have to ask some more questions to get done though.

Sounds good.

Regards,

Greg

Hi Greg,

the screen drivers work with version 0.93pre or "snapshot" as I refered to 
it up to now.

DJGPP always works in 32bit protected mode DOS and therefore can use a lot 
of memory. If there is no DPMI server running it will load its own DPMI 
server to operate. Therefore it can run large code.

I currently did the port of the 0.93pre version to DOS out of interest. I 
hope to make a great GUI available for DOS programmers and embedded projects 
based on DOS.

Georg 

I wonder if you have to compile a Nano-X application for a fixed screen 
resolution using e.g. -DSCREEN_WIDTH=1024 in the makefile or if you can set 
the resolution when starting the program or maybe while it is running.

The launcher.sh file looks like that:

bin/nano-X -x 1024 -y 768 & bin/launcher bin/launcher.cnf

So this looks like the resolution is set after the program is compiled.

Georg