From: Diego C. <die...@gm...> - 2006-08-04 08:54:47
|
Hi, I would like to compile radeonfb in my kernel but with specific timings as default in order to support a 15Khz arcade monitor. In other words I would like to do this but compiled in the kernel : modprobe radeonfb fbset -g 640 248 640 496 16 -t 69259 136 72 17 0 64 2 Can you help me or tell me who can help. Many thanks in advance. |
From: Antonino A. D. <ad...@gm...> - 2006-08-04 11:51:43
|
Diego CLAEYS wrote: > Hi, > > I would like to compile radeonfb in my kernel but with specific timings as > default in order to support a 15Khz arcade monitor. > > In other words I would like to do this but compiled in the kernel : > > modprobe radeonfb > fbset -g 640 248 640 496 16 -t 69259 136 72 17 0 64 2 > > Can you help me or tell me who can help. > Many thanks in advance. > Open drivers/video/modedb.c, then add your timings to static const struct fb_videomode modedb[] Boot with video=radeonfb:640x248. Tony |
From: James L. <ja...@ak...> - 2006-08-05 23:01:33
|
Can someone please explain the difference between these two display types? FB_VISUAL_TRUECOLOR FB_VISUAL_DIRECTCOLOR My frame buffer API, ezfb, works well with cards that are FB_VISUAL_TRUECOLOR, but not so well with cards that are FB_VISUAL_DIRECTCOLOR. http://www.akrobiz.com/ezfb/ Thanks! James. :o) |
From: Antonino A. D. <ad...@gm...> - 2006-08-05 23:48:51
|
James Lehman wrote: > Can someone please explain the difference between these two display types? > > FB_VISUAL_TRUECOLOR > FB_VISUAL_DIRECTCOLOR > > My frame buffer API, ezfb, works well with cards that are > FB_VISUAL_TRUECOLOR, but not so well with cards that are > FB_VISUAL_DIRECTCOLOR. > > http://www.akrobiz.com/ezfb/ Truecolor: pixel = red << offset | green << offset | blue << offset | alpha << offset; where red, green, blue, alpha are the actual values of each pixel component Directcolor: pixel = red_index << offset | green_index << offset | blue_index << offset | alpha_index << offset; where *_index's are the index to the Hardware LUT, ie: red = red_map[red_index]; Thusly: In Directcolor, you have to initialize the LUT first, by sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like Truecolor, then send a linear colormap where: {red|green|blue|alpha}_map[i] = i; In Truecolor, the color map need not be initialized. Tony Note: Each color component in struct fb_cmap are u16 in size, so the contents of the cmap must be duplicated in both bytes, ie: i = red; red <<= 8; red_map[i] = red; |
From: Antonino A. D. <ad...@gm...> - 2006-08-05 23:52:22
|
Antonino A. Daplas wrote: > James Lehman wrote: >> Can someone please explain the difference between these two display types? >> >> FB_VISUAL_TRUECOLOR >> FB_VISUAL_DIRECTCOLOR >> >> My frame buffer API, ezfb, works well with cards that are >> FB_VISUAL_TRUECOLOR, but not so well with cards that are >> FB_VISUAL_DIRECTCOLOR. >> >> http://www.akrobiz.com/ezfb/ > > i = red; > red <<= 8; > red_map[i] = red; Wrong pseudocode, should be: i = red; red |= red << 8; red_map[i] = red; Tony |
From: Antonino A. D. <ad...@gm...> - 2006-08-06 00:02:23
|
Antonino A. Daplas wrote: > James Lehman wrote: >> Can someone please explain the difference between these two display types? >> >> FB_VISUAL_TRUECOLOR >> FB_VISUAL_DIRECTCOLOR >> >> My frame buffer API, ezfb, works well with cards that are >> FB_VISUAL_TRUECOLOR, but not so well with cards that are >> FB_VISUAL_DIRECTCOLOR. >> >> http://www.akrobiz.com/ezfb/ > > Truecolor: > > pixel = red << offset | green << offset | blue << offset | alpha << offset; > > where red, green, blue, alpha are the actual values of each pixel component > > Directcolor: > > pixel = red_index << offset | green_index << offset | > blue_index << offset | alpha_index << offset; > > where *_index's are the index to the Hardware LUT, ie: > > red = red_map[red_index]; > > Thusly: In Directcolor, you have to initialize the LUT first, by > sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like > Truecolor, then send a linear colormap where: > > {red|green|blue|alpha}_map[i] = i; One more note, the above is fine if each color component is 8-bits in size (RGB888, for instance), but for RGB555, you have to downscale. So the untested code below will work better: red_map[i/(1 << (8 - red_length))] = i; red_map[i/(1 << (8 - 5))] = i; red_map[i/8] = i; Tony |
From: James L. <ja...@ak...> - 2006-08-06 02:55:23
|
Awesome! Thanks so much! I still have some tweaking to do, but I now have code that works for ATI, Nvidia and several others (DIRECTCOLOR). Before it really only worked well with Matrox (TRUECOLOR). The first thing that I notice is that if I run fbset before any of my code and set the fb to be 32 bits per pixel, then my code, at 32 bpp, looks perfect. But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32, it looks like the first 16 console colors have been written into the color map. No matter what, I'm successfully putting a picture into video cards that I had no luck with before! Thanks again! James. :o) ----- Original Message ----- From: "Antonino A. Daplas" <ad...@gm...> To: "Antonino A. Daplas" <ad...@gm...> Cc: "James Lehman" <ja...@ak...>; <lin...@li...> Sent: Saturday, August 05, 2006 8:02 PM Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR > Antonino A. Daplas wrote: > > James Lehman wrote: > >> Can someone please explain the difference between these two display types? > >> > >> FB_VISUAL_TRUECOLOR > >> FB_VISUAL_DIRECTCOLOR > >> > >> My frame buffer API, ezfb, works well with cards that are > >> FB_VISUAL_TRUECOLOR, but not so well with cards that are > >> FB_VISUAL_DIRECTCOLOR. > >> > >> http://www.akrobiz.com/ezfb/ > > > > Truecolor: > > > > pixel = red << offset | green << offset | blue << offset | alpha << offset; > > > > where red, green, blue, alpha are the actual values of each pixel component > > > > Directcolor: > > > > pixel = red_index << offset | green_index << offset | > > blue_index << offset | alpha_index << offset; > > > > where *_index's are the index to the Hardware LUT, ie: > > > > red = red_map[red_index]; > > > > Thusly: In Directcolor, you have to initialize the LUT first, by > > sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like > > Truecolor, then send a linear colormap where: > > > > {red|green|blue|alpha}_map[i] = i; > > One more note, the above is fine if each color component is 8-bits in > size (RGB888, for instance), but for RGB555, you have > to downscale. So the untested code below will work better: > > red_map[i/(1 << (8 - red_length))] = i; > red_map[i/(1 << (8 - 5))] = i; > red_map[i/8] = i; > > Tony > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Linux-fbdev-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > |
From: Antonino A. D. <ad...@gm...> - 2006-08-06 03:29:38
|
James Lehman wrote: > But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32, > it looks like the first 16 console colors have been written into the color > map. > Try switching the VC to KD_GRAPHICS mode before you run your app. Then switch it back to KD_TEXT on exit, ie: fd = open("/dev/tty0", FLAG); ioctl(fd, KDSETMODE, KD_GRAPHICS); Let me know if doing the above still writes the console palette to the cmap. That will be a bug. Tony |
From: James L. <ja...@ak...> - 2006-08-06 04:09:46
|
I'm not so sure there is a bug in the kernel or the drivers, but I can say for sure that this code gets called. I like to run frame buffer stuff like a high-res display server. I shell into the box from another computer and have both a regular shell console and the display that is native to the Linux box. If I shell in with another console session and do anything that would open and init the frame buffer, the problem disappears. I though I could get a screen shot of the problem, but doing that makes it go away! James. :o) //########################################################################## ## int ezfb_tty_graphics() { int ret = 1; if(0 > (tty = open(EZFB_TTY_DEVICE, O_RDWR))) { perror("\nezfb ERROR: " EZFB_TTY_DEVICE " open failed"); ret = 0; } else if(0 > ioctl(tty, KDGETMODE, &tty_mode_was)) { perror("\nezfb ERROR: " EZFB_TTY_DEVICE " get mode failed"); ret = 0; } else if( (KD_GRAPHICS != tty_mode_was) && (0 > ioctl(tty, KDSETMODE, KD_GRAPHICS))) { perror("\nezfb ERROR: " EZFB_TTY_DEVICE " set graphics failed"); close(tty); ret = 0; } else { printf("tty mode was "); switch(tty_mode_was) { case KD_TEXT : printf("KD_TEXT" ); break; case KD_GRAPHICS : printf("KD_GRAPHICS" ); break; default : printf("IMPOSSIBLE!" ); break; } printf("\n"); printf("tty mode set to KD_GRAPHICS\n"); fflush(stdout); close(tty); } return ret; } //########################################################################## ## int ezfb_tty_text() { int ret = 1; if(0 > (tty = open(EZFB_TTY_DEVICE, O_RDWR))) { perror("\nezfb ERROR: " EZFB_TTY_DEVICE " open failed"); ret = 0; } else if(0 > ioctl(tty, KDSETMODE, tty_mode_was)) { perror("\nezfb ERROR: " EZFB_TTY_DEVICE " reset mode failed"); close(tty); ret = 0; } else { printf("tty mode set to "); switch(tty_mode_was) { case KD_TEXT : printf("KD_TEXT" ); break; case KD_GRAPHICS : printf("KD_GRAPHICS" ); break; default : printf("IMPOSSIBLE!" ); break; } printf("\n"); fflush(stdout); close(tty); } return ret; } //########################################################################## ## |
From: Antonino A. D. <ad...@gm...> - 2006-08-06 23:44:32
|
James Lehman wrote: > I'm not so sure there is a bug in the kernel or the drivers, but I can say > for sure that this code gets called. Then it's a bug. Can you try removing fb_set_cmap() in driver/video/fbmem.c:fb_set_var()? If that still does not work, can you point me to a test app? Just to clarify, is this the sequence, or something near this? ... ioctl(KD_GRAPHICS); ... ioctl(FBIOPUT_VSCREENINFO); ioctl(FBIOPUTCMAP); ... ioctl(KD_TEXT); ... Tony |
From: James L. <ja...@ak...> - 2006-08-10 21:39:32
|
OK... I got distracted for a little while. I'm still not done yet. But I have found another ATI card and it identifies itself as fb->Fix.visual == 3 (FB_VISUAL_PSEUDOCOLOR). So far, it seems to work the same as FB_VISUAL_DIRECTCOLOR. James. :o) ----- Original Message ----- From: "James Lehman" <ja...@ak...> To: <lin...@li...> Sent: Sunday, August 06, 2006 10:17 PM Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR > I have a bit more work to do. I found that getting the color map right for > packed pixel mode, 565, was kind of tricky; as you had indicated. I also > realized that my code sort of relies on the fact that the color map is NOT > in use when the card is in bpp higher than 8. I use the color map to hold > shifted values from a palette bitmap file to get the colors onto the screen. > So I will have to rewrite that stuff; because with a direct color card, the > color map is always in use. I would love to send you a snapshot of my code. > It comes with a demo program that runs the video card through all sorts of > tests in every possible bpp. > > James. :o) > > > ----- Original Message ----- > From: "Antonino A. Daplas" <ad...@gm...> > To: <lin...@li...>; "James Lehman" > <ja...@ak...> > Sent: Sunday, August 06, 2006 7:42 PM > Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR > vs.FB_VISUAL_DIRECTCOLOR > > > > James Lehman wrote: > > > I'm not so sure there is a bug in the kernel or the drivers, but I can > say > > > for sure that this code gets called. > > > > Then it's a bug. > > > > Can you try removing fb_set_cmap() in driver/video/fbmem.c:fb_set_var()? > > If that still does not work, can you point me to a test app? > > > > Just to clarify, is this the sequence, or something near this? > > > > ... > > ioctl(KD_GRAPHICS); > > ... > > ioctl(FBIOPUT_VSCREENINFO); > > > > ioctl(FBIOPUTCMAP); > > ... > > ioctl(KD_TEXT); > > ... > > > > Tony > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > > opinions on IT & business topics through brief surveys -- and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Linux-fbdev-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Linux-fbdev-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > |
From: James L. <ja...@ak...> - 2006-08-07 02:21:51
|
I have a bit more work to do. I found that getting the color map right for packed pixel mode, 565, was kind of tricky; as you had indicated. I also realized that my code sort of relies on the fact that the color map is NOT in use when the card is in bpp higher than 8. I use the color map to hold shifted values from a palette bitmap file to get the colors onto the screen. So I will have to rewrite that stuff; because with a direct color card, the color map is always in use. I would love to send you a snapshot of my code. It comes with a demo program that runs the video card through all sorts of tests in every possible bpp. James. :o) ----- Original Message ----- From: "Antonino A. Daplas" <ad...@gm...> To: <lin...@li...>; "James Lehman" <ja...@ak...> Sent: Sunday, August 06, 2006 7:42 PM Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR > James Lehman wrote: > > I'm not so sure there is a bug in the kernel or the drivers, but I can say > > for sure that this code gets called. > > Then it's a bug. > > Can you try removing fb_set_cmap() in driver/video/fbmem.c:fb_set_var()? > If that still does not work, can you point me to a test app? > > Just to clarify, is this the sequence, or something near this? > > ... > ioctl(KD_GRAPHICS); > ... > ioctl(FBIOPUT_VSCREENINFO); > > ioctl(FBIOPUTCMAP); > ... > ioctl(KD_TEXT); > ... > > Tony > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Linux-fbdev-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > |
From: Sean D'E. <se...@de...> - 2006-08-06 04:24:39
|
On Sun, Aug 06, 2006 at 11:27:49AM +0800, Antonino A. Daplas wrote: > James Lehman wrote: > > But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32, > > it looks like the first 16 console colors have been written into the color > > map. > > > > Try switching the VC to KD_GRAPHICS mode before you run your app. Then > switch it back to KD_TEXT on exit, ie: > > fd = open("/dev/tty0", FLAG); > ioctl(fd, KDSETMODE, KD_GRAPHICS); > > Let me know if doing the above still writes the console palette to the > cmap. That will be a bug. > > Tony I have tried this, and no, KD_GRAPHICS does not seem to work, I think if you do not set to graphics mode while running, then you can restore the cmap by switching to graphics then text on exit. I have found also that matroxfb does not need to set the cmap but nvidiafb does. Does anyone know a use for directcolor other than gamma correction? thanks. |
From: Antonino A. D. <ad...@gm...> - 2006-08-06 23:44:01
|
Sean D'Epagnier wrote: > On Sun, Aug 06, 2006 at 11:27:49AM +0800, Antonino A. Daplas wrote: >> James Lehman wrote: >>> But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32, >>> it looks like the first 16 console colors have been written into the color >>> map. >>> >> Try switching the VC to KD_GRAPHICS mode before you run your app. Then >> switch it back to KD_TEXT on exit, ie: >> >> fd = open("/dev/tty0", FLAG); >> ioctl(fd, KDSETMODE, KD_GRAPHICS); >> >> Let me know if doing the above still writes the console palette to the >> cmap. That will be a bug. >> >> Tony > > I have tried this, and no, KD_GRAPHICS does not seem to work, I think if you do not set to graphics mode while running, then you can restore the cmap by switching to graphics then text on exit. > > I have found also that matroxfb does not need to set the cmap but nvidiafb does. > > Does anyone know a use for directcolor other than gamma correction? That's it. DirectFB also uses it to adjust saturation, brightness, etc in admininistrative mode. Tony |
From: James L. <ja...@ak...> - 2006-08-22 01:42:38
|
Hello everyone. I have just figured out how to get ATI and NVIDIA cards to work with my code. Now, when I use one of these cards, and I try to flip the screen pointer around inside of the defined virtual display area, by changing the x and y offsets, the screen goes blank. The monitor even flips to standby mode. With my Matrox cards, this doesn't happen and I can double buffer images in the video ram for animations. What's the deal? Can I set up the card so that it won't blank like that? Thanks! James. :o) |
From: Antonino A. D. <ad...@gm...> - 2006-08-22 09:44:07
|
On Mon, 2006-08-21 at 21:38 -0400, James Lehman wrote: > Hello everyone. > > I have just figured out how to get ATI and NVIDIA cards to work with my > code. Now, when I use one of these cards, and I try to flip the screen > pointer around inside of the defined virtual display area, by changing the x > and y offsets, the screen goes blank. The monitor even flips to standby > mode. With nvidia at least, try to limit you max xres_virtual to 2048 and the maximum yres_virtual to 4096. These cards may hang when you the virtual screen size exceeds those dimensions. Tony |