Comments (12)
LOGUNIVPM
commented on May 18, 2024
An additional note: I have compiled the old version of Microwin and linked my application to it. The bug doesn't appear. I believe it's a regression in microwin.
from microwindows.
ghaerr
commented on May 18, 2024
Hello @LOGUNIVPM,
Thank you for your bug report!
I would say that if your previous application worked, and nothing was changed except the Microwindows library version, the problem is in Microwindows. One of the biggest things that changed between older and new versions is that the image copy functions (like GrCopyArea) moved from being performed on a pixel-by-pixel basis to using fast, low-level 'blit' routines instead.
The blit routines are dependent on the "image" attributes, especially pitch, for which a "conversion" blit may be performed - this is required when the source and destination image formats are not the same depth (and other reasons) and cannot be performed by the normal low level blitter.
Before we dive into that, I wonder why the pitch is different, since I'm presuming you're using GrReadArea or GrCopyArea to read screen bits into a buffer, then write them back out using GrCopyArea? It may be that the backup image (or buffer) being created is being assigned the wrong pitch, and subsequently the blit is failing. There should not be pitch differences between the buffers, IMO.
Can you post the code fragments of the copy out and copy back so we can take a closer look? Also, is there any way of actually checking the backup buffer to see whether its contents are correct, or whether they're already 0's?
Thank you!
from microwindows.
LOGUNIVPM
commented on May 18, 2024
Thank you for the prompt reply (and the amazing work with microwin).
These are the bites of code you need:
void LcdPopup(...) {
...
// backup of the raster
popup_rect.width += 8; // 3 white columns border
popup_rect.x = (LCD_WIDTH - popup_rect.width) >> 1;
popup_rect.y = (LCD_HEIGHT - popup_rect.height) >> 1;
popup_bck = GrNewPixmap(popup_rect.width, popup_rect.height, NULL);
GrCopyArea(popup_bck, gc, 0, 0, popup_rect.width, popup_rect.height,
w, popup_rect.x, popup_rect.y, MWROP_USE_GC_MODE);
...
}
void LcdPopupDestroy() {
...
// restore area
GrCopyArea(w, gc, popup_rect.x, popup_rect.y, popup_rect.width,
popup_rect.height, popup_bck, 0, 0, MWROP_USE_GC_MODE);
GrDestroyWindow(popup_bck);
}
I think they are self-explaining.
I have also tried to look at the memory. I have not been able to sort out the correct way to read the data from the memory. I have tried a clumsy attempt at writing the raster on the terminal by interpreting the memory area of the source and destination PSD in the following way, where ri is the row counter, co is the column counter and bi is the bit counter (I have a 1bit framebuffer, I am expecting microwin to use a bitfield notation, storing 8 pixels in 1 byte).
int ri,co, bi;
for (ri = 0; ri < height; ri++) {
for (co = 0; co < width/8; co++) {
for (bi = 0; bi < 8; bi++) {
printf((srcpsd->addr[co+ri*width] & (1 << bi)) == 0 ? " " : "#");
}
}
printf("\n");
}
Here is what I get (the image doesn't make sense but maybe it tells us something about the memory)
BACKUP PROCEDURE
SRC BEFORE COPY
########################################
##### ######## # # ## ## ####
# ## ## ## ### ### ## ### # #
# ###### # ##
########################################
# #### ### ##### #### #### ##
## # # ## ## # ##
## ## ### ###### ## ####
########################################
#### #### ## ## ## # ###### ######
# ## ## ## ## ## #### ## # ### ##
###### ###### ####### # ###
######################################
################ ############## ########
################################ ## #
############## ########## ####### ##
----------------
DST AFTER COPY
##### #
#
RESTORE PROCEDURE
SRC BEFORE COPY
##### #
#
----------------
DST AFTER COPY
########################################
##### ######## # # ## ## ####
# ## ## ## ### ### ## ### # #
# ###### # ##
########################################
# #### ### ##### #### #### ##
## # # ## ## # ##
## ## ### ###### ## ####
########################################
#### #### ## ## ## # ###### ######
# ## ## ## ## ## #### ## # ### ##
###### ###### #####
######################################
########
################################ ## #
## ##### ##
Hope this helps! Thank you
from microwindows.
ghaerr
commented on May 18, 2024
I'm in the midst of another project, but will try to help you get this solved until I can dive deep into it. I don't have a 1bpp system to test on either.
The GrNewPixmap is a variant of GrNewPixmapEx which can take an image format specifier, which I think for your system would be MWIF_1BPP. This routine then calls GdCreatePixmap which doesn't actually handle MWIF_1BPP, but should default to the screen display, since 0 is passed. That routine is in drivers/genmem.c, where you'll see it picks up the data_format and pixtype. It would be interesting to know what those values are. The rest of that routine allocates memory for the pixmap, then adjusts the image settings properly, which may not be the case. We don't know yet whether the problem is in the copy out, or copying back.
With regards to printing the image, I think your code is correct in that 1BPP images are stored as 8 bits per byte, but you may have to reverse the MSB and LSB order to display properly in your debug routine. That is, read from MSB to LSB for the 'bi' variable.
I don't quite understand your SRC/DST before and after copy; they seem the same. Lets get your debug routine to print the image properly and go from there.
from microwindows.
LOGUNIVPM
commented on May 18, 2024
Thank you. The old version of the library works for me, but let's see if I can help.
BTW I should point out that I needed to patch the source in order to make it work on this 1bit system. The old version of our framebuffer driver would reply to a query with different values, correctly handled by microwin, with the new linux driver I had to do the following (see the ifdef PATCH_LINUX_AXEL_UL):
/* set pixel format*/
if(visual == FB_VISUAL_TRUECOLOR || visual == FB_VISUAL_DIRECTCOLOR) {
switch(psd->bpp) {
case 8:
psd->pixtype = MWPF_TRUECOLOR332;
break;
case 16:
if (fb_var.green.length == 5)
psd->pixtype = MWPF_TRUECOLOR555; // FIXME must also set MWPF_PIXELFORMAT in config
else
psd->pixtype = MWPF_TRUECOLOR565;
break;
case 18:
case 24:
psd->pixtype = MWPF_TRUECOLORRGB;
break;
case 32:
psd->pixtype = MWPF_TRUECOLORARGB;
break;
default:
#ifdef PATCH_LINUX_AXEL_UL
if (psd->bpp == 1) {
EPRINTF("WARNING: 1BPP TRUECOLOR, forcing PALETTE mode\n");
psd->pixtype = MWPF_PALETTE;
break;
}
#endif
EPRINTF("Unsupported %d color (%d bpp) truecolor framebuffer\n", psd->ncolors, psd->bpp);
goto fail;
}
#if LINUX_SPARC
#define CG3_MMAP_OFFSET 0x4000000
#define CG6_RAM 0x70016000
#define TCX_RAM8BIT 0x00000000
#define TCX_RAM24BIT 0x01000000
switch (fb_fix.accel) {
case FB_ACCEL_SUN_CGTHREE:
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,CG3_MMAP_OFFSET);
break;
case FB_ACCEL_SUN_CGSIX:
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,CG6_RAM);
break;
case FB_ACCEL_SUN_TCX:
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,TCX_RAM24BIT);
break;
default:
EPRINTF("Don't know how to mmap %s with accel %d\n", MW_PATH_FRAMEBUFFER, fb_fix.accel);
goto fail;
}
#elif LINUX_BLACKFIN
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FILE,fb,0);
#elif UCLINUX
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,0,fb,0);
#ifdef PATCH_LINUX_AXEL_UL
printf("mmaping %d bytes to %s\n", psd->size, MW_PATH_FRAMEBUFFER);
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
#else
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
#endif
if(psd->addr == NULL || psd->addr == (unsigned char *)-1) {
EPRINTF("Error mmaping %s: %m\n", MW_PATH_FRAMEBUFFER);
goto fail;
}
Maybe this has to do with it?
from microwindows.
LOGUNIVPM
commented on May 18, 2024
I have tried to fix the printing of the area, still something wrong, but at least I can read some characters on screen. As you can see the backup copy is not working and the restored copy seems like the original but with mangled bits.
BACKUP
SRC BEFORE COPY
################################################
# ###### ## ## ### ## #### ### ## ######
# ## ## ## ## ## ## ## ## ## ##
#
# ## ## #### #### #### ###### #####
# ## ## ## ## ## ## ##### ####
# ## #### #### #### ###### #####
#
# ## ## ###### ## ## ##
# ###### ## ## ###### ###### ######
################################################
################################################
################# ## # # # # #####
################################################
#### # ## ## # # # # ## ####
#### #### ## #### # #### ### # # # ####
----------------
DST AFTER COPY
## ## ##
################ ########
# ##### # #######
RESTORE
----------------
SRC BEFORE COPY
Reading 16 rows, 6 cols(applied/8)
## ## ##
################ ########
# # ##### #######
----------------
DST AFTER COPY
################################################
## # ## #### ### ## #### ### ## ### #####
# ## ## ## ## ## ### ## ## ## #
#
## ### ## #### ## #### ###### #####
## # ## ## ## ## ## ##### ####
### ###### ## #### # ###### ####
#
## ### ##### ## # ## ##
### ### ### ## ###### ###### ######
################################################
################################################
################ ## ## # # ##### #
################################################
##### ## # # # # # ## # ####
## ##### ## ## # ###### ##### # # ####
from microwindows.
LOGUNIVPM
commented on May 18, 2024
Regarding the function GrNewPixmapEx, I can't see where is the format applied. It is defined like this in nano-X.h:
#define GrNewPixmap(width,height,pixels) GrNewPixmapEx(width,height,0,pixels)
The format argument is always zero
from microwindows.
ghaerr
commented on May 18, 2024
Thanks for the information. Yes, the new source tree will likely have to be patched with the PATCH_LINUX_AXEL_UL contents. Do you happen to have a copy of that patch, or could you generate that with a diff -urN from the original patched versions?
With regards to GrNewPixmapEx, yes, the format is passed as 0, which picks up the default case in drivers/genmem.c::GdCreatePixmap(). This will default to creating an offscreen image using the root screen's attributes by default. Since your above patch changes that to "psd->pixtype = MWPF_PALETTE", that could be the source of the problem.
If I could see the old full patch, I could submit a PR which tries to make this work.
Thank you!
from microwindows.
LOGUNIVPM
commented on May 18, 2024
Here is the diff
--- microwin/src/drivers/scr_fb.c 2021-09-13 15:31:39.475000999 +0200
+++ microwindows/src/drivers/scr_fb.c 2021-10-27 10:57:30.165026425 +0200
@@ -161,7 +161,7 @@
psd->pitch = fb_fix.line_length;
psd->size = psd->yres * psd->pitch;
- psd->flags = PSF_SCREEN;
+ psd->flags = PSF_SCREEN;
/* set pixel format*/
if(visual == FB_VISUAL_TRUECOLOR || visual == FB_VISUAL_DIRECTCOLOR) {
@@ -183,13 +183,6 @@
psd->pixtype = MWPF_TRUECOLORARGB;
break;
default:
-#ifdef PATCH_LINUX_AXEL_UL
- if (psd->bpp == 1) {
- EPRINTF("WARNING: 1BPP TRUECOLOR, forcing PALETTE mode\n");
- psd->pixtype = MWPF_PALETTE;
- break;
- }
-#endif
EPRINTF("Unsupported %d color (%d bpp) truecolor framebuffer\n", psd->ncolors, psd->bpp);
goto fail;
}
@@ -256,9 +249,6 @@
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FILE,fb,0);
#elif UCLINUX
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,0,fb,0);
-#elif PATCH_LINUX_AXEL_UL
- printf("mmaping %d bytes to %s\n", psd->size, MW_PATH_FRAMEBUFFER);
- psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
#else
psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
#endif
In config I created a new arch:
ARCH = LINUX-AXEL-UL
And in Arch.rules I created a new rule for this, with all the necessary directories and flags to cross-compile. In particular the define for the patch:
ifeq ($(ARCH), LINUX-AXEL-UL)
...
DEFINES += -DPATCH_LINUX_AXEL_UL
...
endif
from microwindows.
ghaerr
commented on May 18, 2024
Hello @LOGUNIVPM,
Thanks for the diff. It seems the only real change made is to force palette mode on an otherwise TRUECOLOR-reported frame buffer. The funny thing is that without that patch in the new version, one would think that the startup would fail with "Unsupported color ..." message. Since yours doesn't, I don't quite understand.
Nonetheless, patching the following into the open code from above would force the palette mode:
default:
+#if 1
+ if (psd->bpp == 1) {
+ EPRINTF("WARNING: 1BPP TRUECOLOR, forcing PALETTE mode\n");
+ psd->pixtype = MWPF_PALETTE;
+ break;
+ }
+#endif
EPRINTF("Unsupported %d color (%d bpp) truecolor framebuffer\n", psd->ncolors, psd->bpp);
It would be interesting to know the rootpsd->pixtype in the drivers/genmem.c routine where GdCreatePixmap is called from GrNewPixmapEx with a "0" format parameter, which would force the image to use the "root" display, which the above patch sets to palette mode correctly.
I'm not sure the above patch will change anything, but if you'd like to try it, I'd be happy to help debug why the new version isn't working. I'd also want to see the GrCopyArea code that reads the screen and replaces it, so I can better see what the application is doing.
Thank you!
from microwindows.
LOGUNIVPM
commented on May 18, 2024
Well, actually I made that patch because the program would end on "Unsupported color". With the patch, when psd->bpp == 1 (my case) I avoid failing and set MWPF_PALETTE instead, hopefully that is correct.
In reply to your question: these are the arguments to GdCreatePixmap:
GdCreatePixmap (rootpsd=0xafc90 <scrdev>, width=width@entry=10, height=height@entry=10, format=0, pixels=0x0, palsize=palsize@entry=0)
And this is the pixtype:
(gdb) p rootpsd->pixtype
$1 = 2
from microwindows.
ghaerr
commented on May 18, 2024
Hmmm, rootpsd->pixtype is 2, which means MWPF_PALETTE. So it sounds like that's not the reason I was guessing was a problem in GdCreatePixMap.
Perhaps we should look at the C routines that do the SRC and DST BEFORE/AFTER COPY. It seems the code is almost correct for displaying the source PIXMAP, but not quite. I can kind of see letters, but there still seems to be an issue, I can't quite tell what the correct characters are supposed to be in the image, that would help.
from microwindows.
Related Issues (20)
- Porting to sel4 HOT 1
- Window border glitches after resize HOT 4
- Next Update? HOT 2
- Error running nano-X on linux framebuffer HOT 1
- I am so confused! HOT 3
- Question on keyboard event devices in linux HOT 5
- Strange gtk 1.2.10 behaviors with nano-X HOT 5
- How to switch from 16bit to 32bit colors HOT 16
- endian.h HOT 4
- Present to the future challenge HOT 2
- cosmopolitan binaries experiment? HOT 4
- Doc has dead links
- Linker Error with GCC 11 HOT 5
- microwindows on 64bit ARM HOT 6
- NanoX on Microsoft Windows HOT 1
- Load and display bitmaps at runtime HOT 5
- 'ft2build.h' file not found HOT 1
- wasm: hide window content while dragging ? HOT 2
- Porting Nano-X to NuttX HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from microwindows.