Tom,
runapp is at microwindows/src/runapp. Have you tried running ./runapp?
Regards,
Greg
> On Jul 2, 2019, at 12:47 AM, Tom wrote:
>
> I git cloned to my pi-zero and used the linux/framebuffer config and the make
> seemed to go well (I only saw one warning) but I cannot find runapp anywher
Tom,
I compiled it up a couple of years ago with no problems, IIRC. I can’t remember
if
I built it for Linux framebuffer or X11. I’ll help you if you want to give it a
spin,
I have a Pi at home should we need to debug something. You should start
with either of the Configs/config.linux* config fi
> Hi all,
>
> Has anyone succeded in compiling the nano-x git source code under a Ubuntu
> i386 distro? I'd appreciate any feedback.
It should compile and run using either the X11 or frame buffer
config files (config.x11 / config.fb*).
If you set the config file up, post any compiler errors to
Georg,
The scr_fb.c driver is an “umbrella” driver that interfaces with /dev/fb0,
and then loads a subdriver depending on the fb0 framebuffer format.
These subdrivers have update functions, and definitely use fast blitting.
This was the major focus of the rewrite I did several years ago, and
rem
>
> I want to draw a character to a pixmap. To get the dimensions for this pixmap
> I use the width of the character.
> After I create the Font using GrCreateFont() I use GrGetFontInfo()-Function
> for getting the character information.
> The drawing itself works. I only get the wrong character
>
> I do not want to change the nanox-config and my app because it is too much
> work.
> ( unfortunately I progged it static with a lot of static x-Y positions )
>
>
> Is it possible to let my app, demo-apps and nanox think it is working
> on a QVGA, but I manually patch the diplay-driver and s
Andreas,
What exact code are you using to create the pixmap?
Also what version of nano-X/mwin are you using.
You must use the function that specifies a pixel count that is large enough
for your text string. Do not specify a parent window, or that
window will be used for the default clip region.
>
> Is there any working support for Nano-X under Minix2?
> Just in case, support for any other 16-bit *nix?
It's been a long time, I think someone did a Minix port though.
I added support for a bare-bones hardware version that ran
on 80x86 processors in real mode.
>
> What I found is http:/
> Still not considering GitHub for the Nano-X project? Maybe it will get some
> additional attention and activity? Just for the source, the main web site
> can still be it's market place.
Yes, I think GitHub would be a great place for Nano-X. I'll start the process
of moving that forward.
Regards
>
> I am using the following source (diff for microwin is attached):
>
> micrown (Nano-X)
> nxlib latest git source
> LibVNCServer-0.9.9
> freetype-2.4.8
>
> The attached diffs contain changes to get VNC to link properly, but also some
> customization
> for my application (paths, no VNC passwd,
> I am using the latest source from the git repository and
> I am linked with the most recent Debian Squeeze stable
> release of libvncserver-dev 0.9.7+b1.
>
> This used to work fine, but I had to upgrade to the latest
> git to support UTF-8 and now the VNC is broken.
>
> Any thoughts where to lo
> how can I efficiently change the alpha value of all pixels in a pixmap?
> I want to do a fadein/-out effect. In a previous version I could do sth
> like this:
>
> GrCopyArea(trg, gc, 0, 0, w, h, src, 0, 0,
>MWROP_BLENDCONSTANT | (fadelevel & 0xFF));
>
> But this does not work anymore, since
Stefano -
You should be able to run with quite a bit less stack than 65k, although I
seem to remember some routines that may have auto-stack allocations
that are large. You will have to set the ALLOCA define in include/device.h
in order to have the system allocate large values from the heap.
Wi
I have not tried eCos using the current version of mwin. It would be nice
if you could look at the earlier patch and essentially change what is
required to make it run. Essentially, mwin runs fine on eCos but needs
a different startup set of procedures, as well as some fancy defines in nano-X.h
>
> I removed the code:
>
>
>
>/* anything change? */
>
>if (!changed)
>
>return 0
This should work fine (as it does). My only comment would
be that the driver buzz-loops while data is present, thus it
is theoretically possible to delay any other code from running
should th
> When I try to compile an X11 program with NXlib each time I run "./configure"
> it tells me that "X" does not exist.
>
> How can I change the "configure.in" file or some other relevant file so
> configure will accept NXlib as "Xlib"?
>
I generally suggest that instead of trying to replace X
The problem below is that your version of Freetype is not
matching the version number set in engine/font_freetype2.c.
I would suggest upgrading to a later version of freetype.
Regards,
Greg
On May 16, 2012, at 12:10 AM, wyang wrote:
> Hi all
>
> Could anyone see the below error messages abou
: Is this possible with Nano-X and FLTK? What version of FLTK
: with UTF-8 support is recommended for Nano-X?
It's been a while since I worked with FLTK, but I suggest
that you use the latest FLTK v1.x, and use it with
NXLIB. You may have to change some flags in the GrText
calls in NXLIB so that
: pixmap = *GrNewPixmap*(w, h, 0);
:
: *GrDrawImageToFit*(pixmap, *gc*, 0, 0, -1, -1, image[0]);
:
: How can I access the underlying pixel values?
GrReadArea(pixmap, ...)
-
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacke
:: I've been working on the Linux port to the Parrot Photo Frames ( code at
: http://github.com/Xalior/DF3120/ if anyone wants to poke about ) - and,
due
: to their restricted memory footprint, microwindows struck me a good option
: for a GUI but I've hit a dead end until I can download the latest
: GrNewWindowEx(GR_WM_PROPS_BORDER|GR_WM_PROPS_CAPTION|GR_WM_PROPS_CLOSEBOX,
: "arcdemo",
: GR_ROOT_WINDOW_ID, 0, 0, 250, 90, WHITE);
:
: but the window is placed quite a bit below the upper left corner and to
the
: right side of the screen or X Window. Just as if 0,0 is translated to
20,20
: by
: Would 'ApplicationMain' in the place of 'WinMain' not be more clear,
: as 'Win' is a little ambigious name in my view.
I didn't invent the names - they are exactly compatible with
Microsoft Win32 application programming interface. If
you change the names, then programs won't compile unchanged
: I working on running microwindows on a wireless router (E.g Linksys
WRT54GL). Please I would like your advice on how to run microwindows. I
thought to either;
: 1. Install
: it in the firmware image. Then when I update the image on the device ,
: microwindows will be in it and I can run
: If I (cross)build microwindows (full snapshot) for ARM and I try to use
the
: libraries for an application It get an unresolved error. Looking at
: lib/libmwin.so with nm gives:
:
: If I comment out the line in mwin/winmain.c where the call to WinMain
is
: made everything appears fine. (abou
: As far as I understand, the screen resolution and the pixtype have to be
set
: in the makefile and you compile the package to that settings.
No for both. The screen resolution is queried at runtime and
used dynamically. Likewise, the pixel type is queried at runtime
and a screen subdriver sel
: Then I found that FLTK 1.1.10 does display the fonts with Umlauts while
FLTK
: 1.3.0 does not. The reason is apparently that FLTK 1.1.10 loads an
iso8895-1
: font while FLTK 1.3.0 loads an iso10646-1 font. FLTK 1.3.0 is using UTF-8
: now.
In looking at this a little deeper, I can see that FLTK
: I followed your suggestions and found that both nano-x and NXlib do print
: Umlauts to the screen. What I had to do was to implement an IBM code page
: 850 to iso8859-1translation table in my keyboard driver. Then the Umlaut
: keys were displayed.
Good. Please send me your keyboard driver when
: Do you know why I have problems to get the characters above 127 to be
: displayed correctly? It does not show U-Umlaut, A-Umlaut etc. Also the
fonts
: example of FLTK shows question marks for these characters.
What does it show for these characters?
You've got a list of all sorts of things tha
: I do not get this font.alias file to work with fltk. This is my font.alias
: in the dejavu directory:
:
: !fixed "-misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-ascii-0"
: fixed DejaVuSans.ttf
: System DejaVuSans.ttf
: system DejaVuSans.ttf
: helvetica DejaVuSans.ttf
: courier DejaVuSans.ttf
: ti
Georg -
I've fixed XLoadFont and XListFonts in NXLIB and
everything should now work for you. I've tested with
FLTK 1.1.10 and 1.3.0, and fixed the following issues:
o fix XLoadFont special case handling of 'fixed' -> uses mwin SystemFixed
o add XListFonts handling of 'fixed', allows FLTK 1.3.0 t
Larry -
I would try a couple things: first, comment out just GrText and leave
in GrGetFontInfo, and see whether that fails.
Then, leave out GR_TFTOP and test.
The encoding flags for GF_TFASCII means that 'buf' is 7-bit
ascii characters, is it?
You might try just passing "a", 1 instead of buf, -1
Davide -
Looks good. Are you saying that Larry's problem was that
the upper level didn't properly handle reading the mouse
driver with the proper event, while this driver does?
Regards,
Greg
: Hi,
: I attach a patch with an updated driver and keyboard events driver.
: Now they autodetect the f
> I see mouse touch events coming from mou_event.c (the new driver instead
> of mou_touchscreen.c).
> I see mouse touch events coming from devmouse.c (GrReadMouse displays new
> x,y positions).
> But, nxcal, nxscribble do not show any mouse events or movement.
> Can you help me troubleshoot how
: if not running on top of X Windows is there support for international
: keyboards? I mean can Nano-x use any keyboard mapping files used by X
: Windows directly?
As you saw in nxlib/StrKeysyms.c, the keyboard mapping files
aren't coming from X11, but from Linux. Thus they will need
to be repl
: But it does not work for fltk as you can see below. I also do not know how
: to put the pattern -*-helvetica-medium-r-normal--* into the alias file.
Does
: NXlib also support quotation marks in font.alias files? These should be
used
: if there is a blank in the file description.
You should jus
: when I use an Xlib program with NXlib I had the problem, that I could just
: return to text mode when pressing the ESC key. Selecting X of the window
: terminated the program but left the screen in SVGA mode and sent the
: following console output to that so it could not be read.
:
: So I enabled
:I looked at the code in StrKeysym.c in NXlib. It seems that the function
: LoadKernelKeymaps(void) opens the keyboard as a file and reads all the
: keymaps from that using an ioctl() call. This will not work this way with
: DOS.
That code will have to be removed using #ifdef'd out for your
DOS p
> I read on the net that for truetype fonts you first have to run "ttmkfdir
> > fonts.scale" and then mkfontdir. Is that still correct or already
> outdated?
NXLIB doesn't read fonts.scale when searching for fonts, only
the fonts.dir and fonts.alias files. The information in fonts.dir
will sh
: The fonts.dir file in the fonts/freetype directory just contains a single
: zero. I downloaded that from your FTP site.
I'll add sample fonts.dir and fonts.alias files to the NXLIB
distribution with instructions. This was left out because
we're not including fonts at this time, but I'll point
: Where can I get a populated fonts.dir file?
The Linux command "mkfontdir" builds fonts.dir files
from font directories. Grep the net for directions.
The NXLIB fonts.alias and fonts.dir files exactly match
the capabilities found in modern Linux distributions.
Regards,
Greg
-
: I guess I found a bug with NXLIB: if you call xlistfonts with the pattern
: "fixed" NXLIB will return zero, i.e. it did not find that font.
Yes, that was changed in an earlier NXLIB version.
:
: To work around that I patched in FLTK 1.3.0 the file fl_font_x.cxx. In the
: "Fl_Fontdesc built_in_
> with fltk1110 there is first a xlistfonts call with
> "-*-helvetica-bold-o-normal--*" which is returned with NULL by NXLIB. Then
> fltk1110 makes a xloadfont call for the fixed font, assuming that this is
> always present.
> fltk130, however, calls xlistfonts again with the pattern "fixed". N
> I downloaded that and got it to run. However, there is no text displayed
> in the demos.
No text at all, or small text. Do previous versions of FLTK work
properly?
> findfont_nowild: fail
You need to look up the XLFD font spec that's being sent
to "X11" for processing. This should be in th
: Meanwhile I downloaded FLTK 1.1.10 and compiled that. Fluid did compile
too.
Does this version display text in the demos?
: I observed that you can get some very buggy keyboard input when you press
: the "^" or "`" key before another key. So ^e or è will result in "w", ^a
or
: à in "q".
Are
:I have compiled my apps with the -DNONETWORK=1 switch. They always cover
the
: whole screen. I would like to get a decorated window with Nano-X. How is
: this possible?
The window manager code is linked internal to the window server
when the config file setting NANOWM=Y is set. This should
allo
> I read in an old post that it would work with the kbd_ttyscan.c keyboard
> driver but not with the
> kbd_tty.c keyboard driver.
The former is a scancode driver that uses the values of the
keyboard scancodes and looks up the keycode values
from an internal table. The latter driver uses the OS-r
: I saw that the freetype 1 driver was deprecated recently.
I deprecated it because I didn't want to keep up two versions
of the freetype driver anymore. Of course, I didn't realize that
it used a C library feature your system doesn't have!
IIRC, the nano-X FT1 subdriver didn't support caching,
: Then I downloaded xclock.c to see if it would compile with libNX11.a.
: However, I get these error messages:
:
: gcc -I/djgpp/include/mwin -o xclock.exe
: xclock.c -lNX11 -lnano-X -lz -lfreetype
:
: e:/djgpp/tmp/ccMR4PGM.o:xclock.c:(.text+0x2fd): undefined reference to
: `_XtDisplayOfObject'
: When converting tux.gif to tux.bmp, this works fine in 16 color, and 24
: color mode, 256color mode shows wrong colors.
Not sure what conversion program you're using here, whether
this is a conversion problem or not.
: I can display dragon.bmp when
: converted to 16 color mode, but not in any
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 nano-X server will query the framebuffer for its size during
initializ
: 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 buildin
: 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
ad the old 0.91 nano-X binary, and
it will be OK.
(to be clear I can rebuild the 0.91 code in the same toolchain and it is
fine, not a build tool issue)
Thanks,
j. lopes
-Original Message-
From: Greg Haerr [mailto:g...@censoft.com]
Sent: Thu 5/26/2011 12:54 PM
To: Joseph Lopes; nanogui@l
Franco,
Try compiling up the tree and running the various
src/*.sh demo shell scripts to see whether fonts
work. Or is your issue just to do with adding internal
fonts to the system?
Regards,
Greg
Hello all,
I'm sorry if this is not the right place for this question. I started
experimenting
ll of this remains the same when I load the old 0.91 nano-X binary, and
it will be OK.
(to be clear I can rebuild the 0.91 code in the same toolchain and it is
fine, not a build tool issue)
Thanks,
j. lopes
-Original Message-
From: Greg Haerr [mailto:g...@censoft.com]
Sent: Thu
> 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 wan
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
bi
: --vnc libVNCserver{and client}-0.9.8 verified below
: #---make ends lile so:-
:
: make[3]: Circular /tmp/microwin-full-snapshot/src/lib/ <-
/tmp/microwin-full-
: snapshot/src/lib/ dependency dropped.
: Compiling demos/vnc/vncviewer/args.c ...
: Compiling demos/vnc/vncviewer/r
: I see there is a dejitter filter in devmouse.c. Is that filter
: redundant with the dejitter filter in tslib?
I think so. All of the dejitter code is contributed and I haven't
looked at it too much. You might try commenting out the internal
devmouse code and see what happens; it's supposed to
> define MWPIXEL_FORMAT MWPF_TRUECOLOR565 in mwtypes.h
What did you set MWPF_PIXELFORMAT to in the config file?
The above is supposed to be set in config only, not mwtypes.h.
> #if MWPIXEL_FORMAT == MWPF_PALETTE
colorval = GETPALENTRY(gr_palette, pixelval);
#else
: In version 0.92 the malpha demo did work, just the window title text was
: gone.
Yes, font drawing won't work without blit.
: The other samples which I qualified as not working just showed a black
: screen.
Which samples
:: I tried to write a new screen driver for DOS but that did not work
> 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 dr
: a) cpu -amd64, 64-bit cblfs linux, kernel-2.6.38.2
Microwindows is 64-bit clean for the nano-X api and
all nano-X applications, which I assume you're using.
Win32 applications using older constructs like SetWindowLong
have some issues with offsets and pointer lengths, but these
aren't portable
Derek -
Very cool! Sounds like the port went fairly smoothly.
I presume that the changes were fairly basic, using a simple
screen driver that uses the 16bpp linear fb subdriver, and
then just your new macros. I'd definitely like to see a
git diff -urN that I could use as a patch.
We may want
Georg -
Microwindows hasn't been tested with DJGPP for years, and
as of 0.92, it was officially deprecated. I don't have DJGPP
over here so I can't test your makefile changes. I would suggest
looking at the ChangeLog and going back to an older version
that was reported to be working for DJGPP.
: I want to use nano-x API to send some custom events to windows,
: like the SendMessage function in Windows API. But as far as I know,
: there are only GrInjectKeyboardEvent and GrInjectPointerEvent to
: achieve the similar effect, is there anyway to send arbitrary events
: to a window?
Yes, use
Albert Chen
E-mail: albert3_c...@askey.com.tw
TEL: 886-2-22287588 # 18019
FAX: 886-2-32349340
From: Greg Haerr [mailto:g...@censoft.com]
Sent: Thursday, March 10, 2011 2:05 PM
To: Albert3 Chen(陳堯山_Askey_TW); nanogui-...@linuxhacker.org;
nanogui@linuxhacker.org
S
Albert -
You'll need to read up or post on the FLTK list, as you're using the FLTK
toolkit to set up text and colors. Check to see that the colors are
in fact changing when running on FLTK/X11, instead of through the
NXLIB library. I have tested nano-X with FLTK 1.10 and all the FLTK
demos run
> I commented out the GsError in the GrSetFocus() (srcfunc.c in Nano-X
0.92) and that fixed the second issue. This always happened when closing
one of the windows so de-synchronization is possible.
I'll add both your fixes to the git repo. With the call to GsError
commented out, there should neve
> translateNXevent: unhandled update event subtype 6
> which is GR_UPDATE_ACTIVATE, when it closes one of the windows.
> It used to work with older FLTK (1.1.?) so this is a new event they
> added?.
Not sure what to say here, perhaps we should diff the lower level FLTK
routines between your two ve
0.92!
Regards,
Greg
This one change fixed my problem.
I am not sure if this is a 'correct' way to implement it and I leave
that up to you to decide.
Similar changes should also be considered in other functions.
Thanks,
Martin
-Original Message-
From: Greg Haerr [mailto:g...
: It should be easy to convert CreateRoundRectRgn to
: a GrRoundRect function, but I'm not familiar with
: Win32 API, and it seems that RECT in CreateRoundRectRgn
: is not the same with GR_RECT. Could someone tell me
: which structures and functions should be replaced?
This code may be a bit trick
like specialized
font draw code isn't currently handling raster ops like the
general blit code.
Regards,
Greg
I will look at it tomorrow.
Yes, I am running official 0.92 from Nov. 2010.
At the same time I also changed from freetype 1 to freetype 2
M.
-Original Message-
From:
> The line drawing works (XORes) but string printing does not XOR, just
> copies.
Martin, you're running the 0.92 official release from 11/2010 of
NXLIB and Microwindows, and line drawing XOR works, but
text drawing not, right?
The 0.92 release was cut in November from the June 2010
codebase, jus
: According to a quick review of XopenDisplay and some of the other small
: wrapper functions in nxlib-0.46, yet no remote x-servers are supported,
: only the local :0 server (and, hence, no DISPLAY environment variable be
: supported). Is this correct?
That's basically correct, primarily because
Hi Aleksey -
Just wanted to let you know I completed adding 1bpp pixmap
support into the git repository for Microwindows. You should
now be able to create 1bpp mono pixmaps using MWIF_PAL1
as the format to GrNewPixmapEx. These pixmaps can
be drawn to using all draw routines and font subdrivers.
This is a test of the mailing list is it working?
Greg
-
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org
: Is emulating Frame Buffers just on a memory array (for headless system)
: just "no problem" ?
Yep, no problem. The newer architecture allows the entire nano-X
system to run using a memory framebuffer. This is, in fact, how
the new X11 driver works. The X11 driver allocates some memory
that s
Hi,
There's been quite a bit of new work recently on the internals of
Nano-X, which are now running well enough to announce a preview
of this upcoming release, which is currently v0.93 in the git repository.
I have updated the website and there is also a snapshot tarball available:
ftp://microwi
Hi,
Nano-X Version 0.92 has been released from the git repository
source code as of June 11, 2010. This release has been a long time
in coming, and has a large variety of enhancements, speedups, and
bug fixes. It is available from the website or this link:
ftp://microwindows.org/pub/microwindow
> The gui runs upon FLTK 1.10 final. I have several modules where I can
> switch to. So my problem is that, when I switch from a subscreen to the
> main screen, a part of the area of one button is in the main screen is
> redrawn false. This area is exactly the area of the other button in the
> subs
: What do you think of adding cgit[1] to the website? It would really
: ease keeping track on the development.
Sounds like a great idea.
:
: Overall, the website would need a facelift (preferably with a
: developer log).
I agree. Anybody have any extra time perhaps to help
put up a new site,
: Does this socket support only the Graphics, or are Keyboard and Mouse
: events run through this (or another) socket, too ?
All events are run through the single socket.
Regards,
Greg
-
To unsubscribe, e-mail: nanogui-unsubs
: MY BOARD with Blackfin uCLinux DISPLAY,KEYBOARD,MOUSE
: - |---
: histogramming and | LAN | workstation with |
: data processing ---> nanoX | <-> | screen, keyboard |
: running under ucLinux
: Can Nano-X display on remote X-term, much like regular X would?
I assume you're asking whether the nano-X server and
an associated nano-X client application can run on seperate
computer systems, using the network to connect between them,
for display.
The current codebase uses UNIX sockets to co
I saved a copy a few years back. It's on the
microwindows.org source code web page, under
Compatible-Libraries -
ftp://microwindows.censoft.com/pub/microwindows/Compatible-Libraries/
Be forewarned, however that it needs a few tweaks to
compile. There may be a patch as well somewhere, I'd
have t
> I am trying to compile viewML with my toolchain and ARM based device.
These errors are all related to the changes between the very old
ViewML source code which used the gcc 2.96 compiler, and
the current toolchains in use today. ViewML hasn't been
updated in quite some time and is out of date
Hi guys -
It's been quite a while since I've communicated about what's
happening with our nano-X/Microwindows project and development
plans. As many know, other than having moved to a git repository
earlier this year, the website hadn't been updated in five years.
Prior to the beginning of this y
: The output window is not fully drawn. But if the mouse is moved only a
: rectangular box is drawn.
Your modifications for every entry point in fblin16.c will
do the job, but some of those entry points are calling
"standard" routines like genfillrect which will also need to
be modified. This is
: If you start it from a serial terminal nano-X gets confused and tries to
: grab the keyboard from the serial terminal. If you try to start it with
: init by adding an entry to rc2.d and init.d it starts but immediately
: quits. There is no entry in any of the logs that I can find that might
:
: I have nano-X working on my target hardware - an ARM machine using
: Debian. Nano works but gets mixed up with the cursor and keyboard when
: switching to/from a virtual terminal.
Set VTSWITCH=Y in the config file. You may also have to
set HAVETEXTMODE=Y (that's either in config include/devic
> Since fblin24.c is specifically for 24bit RGB I guess pixtype will
never be anything but MWPF_TRUECOLOR888, so just removing the assert
would do?
Yes - removing the assert is correct.
Regards,
Greg
-
To unsubscribe, e-mail:
: the assertion is incorrect for non-palettized video modes. I would just
: remove the asserts, or change it to
:
: assert(psd->pixtype != MWPF_PALETTE || c < psd->ncolors)
The above is incorrect, as the assert is in the fblin24 driver,
which is only used for non-palette 24 bit framebuffers.
I
: > static void linear24_drawpixel(PSD psd, MWCOORD x, MWCOORD y, MWPIXELVAL
c)
:
: and the assertion looks like:
:
: >assert (c < psd->ncolors);
:
: It seems like the PNG buffer is read as 32 bit values, but the
What version are you running?
The git repository should not have this issue. I
: This hardware comes with X Windows installed and uses the evtouch
: touchscreen driver. Can nano-X use this driver? If not, is one of the
: other nano-X supported drivers a good candidate for modifying? Has
: anyone else done this already?
I don't know anything about the evtouch software/hard
:I have two threads in my application. I have compiled microwindows with
: LINK_APP_INTO_SERVER=Y and THREADSAFE=Y . When I using GrGetWindowInfo
: in second thread , this thread is frozen . Why ? Is there any solution
: for this problem ?
The nano-X client/server protocol and client lib wasn't de
: I have several text fields that are updated on screen a couple of times
: a second. I find that the freetype font FreeSans.ttf doesn't paint the
: background except just a few pixels surrounding each character. This
: leaves artifacts of previous messages on the screen.
By default, most text
: Source Code : microwindows-full-0.91.tar.gz
You should use the latest source on the website,
microwindows-src-snapshot.tar.gz, the v0.91 is
quite old. This isn't the cause of your problem,
I don't think though.
: arm-linux-gcc -o sample1 sample1.c -I./include/microwin -L./lib -lnano-X
:
/usr/
: The above code yielded the black horizontal lines at the top of where
: the pixmap should have been XORed. I think this line was more than 1
: scan line, probably 2. I'll have to repeat the experiment before I can
: say for sure.
:
: In native mode, after changing the last arg in GrCopyArea t
: if ((Chart.OldPosition != NewPosition) || (oldpxm != newpxm ) ) {
: GrSetGCMode( gc, GR_MODE_XOR ) ;
: GrCopyArea( win, gc, Chart.OldPosition, DIAMONDYSTART+BORDER,
: 29, 37, \
: *oldpxm, 0, 0, GR_FALSE ) ;
: GrCopyArea( win, gc, NewPosition, DIAMONDYSTART
1 - 100 of 380 matches
Mail list logo
