Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Geert U. <ge...@li...> - 2002-12-30 10:32:46
|
Wouldn't it make sense to make the fb_{fillrect,copyarea,image} parameters of
the fb_ops.fb_{fillrect,copyarea,image}() operations const? This would protect
us against side effects when reusing the fb_{fillrect,copyarea,image} structs
without reinitializing their contents (as is currently done by the logo drawing
code in fbcon_show_logo() on SMP).
Of course this means that we have to modify the clipping code, which currently
just modifies the passed structure.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2002-12-29 21:22:24
|
cfb_imageblit() takes care of clipping, but forgets to update fb_image.data if
fb_image.d[xy] was changed.
BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
If these calls are accessible from user space through ioctl() (if anyone really
wants to do that?!?), I guess the answer is yes. For calls from kernel space,
I'd say it's not necessary since calling them with out-of-range parameters is a
bug anyway.
So we could move the clipping to the generic ioctl() handling in fbmem.c, if we
ever want to provide that functionality. Or is there a too high speed penalty
for graphics chips that do implement clipping in hardware?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2002-12-29 20:09:24
|
Did anyone actually test fbcon_set_logo() on monochrome hardware?
I admit I haven't tried it myself yet (still fighting with amifb), but this
looks more reasonable:
- Use index i*8+j instead of i*2
- Replace conditionals by straight code without branches (bit 7 of needs_logo
is either 0 (normal) or 1 (reverse), and perhaps we should kill the default
case?).
The second part is an indentation fix.
BTW, most of the new fbdev code looks really ugly in vim with `let
c_space_errors=1', due to the exorbitant use of superfluous whitespace
characters.
--- linux-2.5.53/drivers/video/console/fbcon.c Tue Dec 10 13:41:40 2002
+++ linux-geert-2.5.53/drivers/video/console/fbcon.c Sun Dec 29 20:54:30 2002
@@ -2631,12 +2632,12 @@
case 1:
case ~1:
default:
- for (i = 0; i < (LOGO_W * LOGO_H)/8; i++)
- for (j = 0; j < 8; j++)
- logo[i*2] = (linux_logo_bw[i] & (7 - j)) ?
- ((needs_logo == 1) ? 1 : 0) :
- ((needs_logo == 1) ? 0 : 1);
-
+ for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
+ u8 d = linux_logo_bw[i];
+ for (j = 0; j < 8; j++, d <<= 1)
+ logo[i*8+j] = ((d ^ needs_logo) >> 7) & 1;
+ }
+
break;
}
}
@@ -2668,8 +2669,8 @@
* be set to 1.
*/
static int __init fbcon_show_logo(void)
- {
- struct display *p = &fb_display[fg_console]; /* draw to vt in foreground */
+{
+ struct display *p = &fb_display[fg_console]; /* draw to vt in foreground */
struct fb_info *info = p->fb_info;
struct vc_data *vc = info->display_fg;
struct fb_image image;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Antonino D. <ad...@po...> - 2002-12-29 16:13:08
|
On Mon, 2002-12-23 at 21:04, Michael Kaufmann wrote: > Antonino has also answered to my question. And he said that there is nothing > i can do, because user apps will directly acces the framebuffer via read/write > or nmap. I can only patch the console and the show _logo to write the data > mirrored to the videobuffer (a lot of work). > So my user apps (like nanoX or directfb/GTK+) must know about the mirrored > display and should write the picturedata mirrored in the framebuffer. > > I'm know a litte bit amazed about a rotation feature in next versions. Does > this mean, that the buffer where user apps (or also the console) are writing > there picture data is not directly the videobuffer anymore? Or how does this > rotation feature works? I think the rotation hooks are console specific. > > I think it would be a good feature to have 'something' between the framebuffer > and the physical videobuffer to be able to manipulate the picture data (like That is the job of fb libraries. You can use X (which already has support for rotation, so mirroring should be easy to add), or modify DirectFB. > rotation, mirroring, etc.). But i don't know how this peace of software > should detect, changed data in the 'framebuffer' to e.g. mirror in the > videobuffer? Writing the whole buffers from time to time whould be a very > bad solution (performance). You can probably implement something similar to a shadow framebuffer. You expose this instead of the actual framebuffer (fix->smem_start, and info->screen_base), then just refresh the contents of the actual framebuffer, say during vsync. You will have to set up a vsync irq_handler or something similar. Tony |
|
From: Antonino D. <ad...@po...> - 2002-12-29 15:13:31
|
On Sun, 2002-12-29 at 09:16, James Simmons wrote:
>
> > The text is written as if it's thinking about handling 64-bit
> > unsigned long, but it doesn't. The tables that map bits to
> > pixels are completely unprepared for this.
> >
> > I thought about widening the tables, but I thought they'd get
> > unreasonably large. There's no reason not to go ahead and
> > handle this 32-bits at a time.
>
> I thought the tables would come back to haunt us. The only reason the
> tables where introduced was for speed enhancements. I reason the code is
> extra complex was so you could pass 64 bits of data across the bus. I
> still like to see that happen still. What do you think?
>
Only fast_imageblit() should be affected. color_imageblit() and
slow_imageblit() will not be affected.
fast_imageblit() is used only for 8, 16 and 32 bpp. We can remove
fast_imageblit() and just use slow_imageblit() for all color depths, but
it will suffer a significant slowdown.
Or we can change fast_imageblit() to always access the framebuffer
memory 32-bits at a time. The attached patch should fix this.
Tony
diff -Naur linux-2.5.42/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.42/drivers/video/cfbimgblt.c 2002-12-29 14:44:04.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2002-12-29 14:44:23.000000000 +0000
@@ -88,11 +88,13 @@
#if defined (__BIG_ENDIAN)
#define LEFT_POS(bpp) (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp) (32 - bpp)
#define NEXT_POS(pos, bpp) ((pos) -= (bpp))
#define SHIFT_HIGH(val, bits) ((val) >> (bits))
#define SHIFT_LOW(val, bits) ((val) << (bits))
#else
#define LEFT_POS(bpp) (0)
+#define LEFT_POS32(bpp) (0)
#define NEXT_POS(pos, bpp) ((pos) += (bpp))
#define SHIFT_HIGH(val, bits) ((val) << (bits))
#define SHIFT_LOW(val, bits) ((val) >> (bits))
@@ -223,25 +225,25 @@
}
static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long fgcolor, unsigned long bgcolor)
+ u32 fgcolor, u32 bgcolor)
{
int i, j, k, l = 8, n;
- unsigned long bit_mask, end_mask, eorx;
- unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
- unsigned long tmp = (1 << bpp) - 1;
- unsigned long ppw = BITS_PER_LONG/bpp, ppos;
- unsigned long *dst;
+ u32 bit_mask, end_mask, eorx;
+ u32 fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+ u32 tmp = (1 << bpp) - 1;
+ u32 ppw = 32/bpp, ppos;
+ u32 *dst;
u32 *tab = NULL;
char *src = image->data;
- switch (ppw) {
- case 4:
+ switch (bpp) {
+ case 8:
tab = cfb_tab8;
break;
- case 2:
+ case 16:
tab = cfb_tab16;
break;
- case 1:
+ case 32:
tab = cfb_tab32;
break;
}
@@ -263,17 +265,17 @@
k = image->width/ppw;
for (i = image->height; i--; ) {
- dst = (unsigned long *) dst1;
+ dst = (u32 *) dst1;
for (j = k; j--; ) {
l -= ppw;
end_mask = tab[(*src >> l) & bit_mask];
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
if (!l) { l = 8; src++; }
}
if (n) {
end_mask = 0;
- ppos = LEFT_POS(bpp);
+ ppos = LEFT_POS32(bpp);
for (j = n; j > 0; j--) {
l--;
if (*src & (1 << l))
@@ -281,7 +283,7 @@
NEXT_POS(ppos, bpp);
if (!l) { l = 8; src++; }
}
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
}
l -= pad;
dst1 += p->fix.line_length;
@@ -337,7 +339,7 @@
if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index &&
bpp >= 8 && bpp <= 32 && (image->width & 7) == 0)
- fast_imageblit(image, p, dst1, fgcolor, bgcolor);
+ fast_imageblit(image, p, dst1, (u32) fgcolor, (u32) bgcolor);
else
slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
}
|
|
From: James S. <jsi...@in...> - 2002-12-29 01:17:39
|
> The text is written as if it's thinking about handling 64-bit > unsigned long, but it doesn't. The tables that map bits to > pixels are completely unprepared for this. > > I thought about widening the tables, but I thought they'd get > unreasonably large. There's no reason not to go ahead and > handle this 32-bits at a time. I thought the tables would come back to haunt us. The only reason the tables where introduced was for speed enhancements. I reason the code is extra complex was so you could pass 64 bits of data across the bus. I still like to see that happen still. What do you think? |
|
From: James S. <jsi...@in...> - 2002-12-29 00:29:00
|
I applied your changes. |
|
From: James S. <jsi...@in...> - 2002-12-28 22:39:17
|
Here are a bunch of fixes and driver updates for the fbdev layer. The patch applies against 2.5.53. You can also do a bk pull at bk://fbdev.bkbits.net:8080/fbdev-2.5 The diff is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz CREDITS | 1 Documentation/fb/intel810.txt | 272 +++ MAINTAINERS | 2 arch/m68k/kernel/head.S | 34 arch/m68k/kernel/m68k_defs.c | 16 drivers/char/vt.c | 2 drivers/video/Kconfig | 68 drivers/video/Makefile | 20 drivers/video/aty/atyfb_base.c | 33 drivers/video/aty128fb.c | 102 - drivers/video/cfbcopyarea.c | 2 drivers/video/cfbimgblt.c | 15 drivers/video/chipsfb.c | 572 ++------ drivers/video/console/Kconfig | 36 drivers/video/console/Makefile | 38 drivers/video/console/dummycon.c | 6 drivers/video/console/fbcon-sti.c | 289 ---- drivers/video/console/fbcon.c | 304 ---- drivers/video/console/fbcon.h | 17 drivers/video/console/font.h | 53 drivers/video/console/font_6x11.c | 2 drivers/video/console/font_8x16.c | 2 drivers/video/console/font_8x8.c | 2 drivers/video/console/font_acorn_8x8.c | 3 drivers/video/console/font_mini_4x6.c | 2 drivers/video/console/font_pearl_8x8.c | 2 drivers/video/console/font_sun12x22.c | 2 drivers/video/console/font_sun8x16.c | 2 drivers/video/console/fonts.c | 2 drivers/video/console/mdacon.c | 24 drivers/video/console/newport_con.c | 2 drivers/video/console/sti.h | 289 ---- drivers/video/console/sticon.c | 390 ++++- drivers/video/console/sticore.c | 1132 +++++++++++----- drivers/video/controlfb.c | 37 drivers/video/fbmem.c | 364 ++++- drivers/video/fbmon.c | 334 ++++ drivers/video/i810/Makefile | 22 drivers/video/i810/i810.h | 300 ++++ drivers/video/i810/i810_accel.c | 513 +++++++ drivers/video/i810/i810_dvt.c | 308 ++++ drivers/video/i810/i810_gtf.c | 275 ++++ drivers/video/i810/i810_main.c | 2245 +++++++++++++++++++++++++++++++++ drivers/video/i810/i810_main.h | 205 +++ drivers/video/i810/i810_regs.h | 274 ++++ drivers/video/igafb.c | 100 + drivers/video/offb.c | 5 drivers/video/radeonfb.c | 38 drivers/video/riva/fbdev.c | 310 +++- drivers/video/riva/nv_type.h | 58 drivers/video/riva/riva_hw.c | 128 + drivers/video/riva/riva_hw.h | 110 + drivers/video/riva/riva_tbl.h | 99 + drivers/video/riva/rivafb.h | 7 drivers/video/skeletonfb.c | 220 ++- drivers/video/sstfb.c | 2076 ++++++++++++------------------ drivers/video/sstfb.h | 68 drivers/video/sticore.h | 5 drivers/video/stifb.c | 136 - drivers/video/tdfxfb.c | 11 drivers/video/tgafb.c | 1544 +++++++++------------- drivers/video/vga16fb.c | 70 - drivers/video/vgastate.c | 7 include/linux/fb.h | 10 include/linux/font.h | 53 include/linux/pci_ids.h | 37 include/video/radeon.h | 144 +- include/video/tgafb.h | 210 +++ 68 files changed, 9296 insertions(+), 4765 deletions(-) MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@in...> - 2002-12-28 18:20:50
|
> > Strange, it's defined in drivers/video/fbmem.c in my copy of 2.5.53. > > Ah. It's not exported, so fbcon as a module fails. > Not sure how I missed it with a grep... That problem is fixed already in the latest BK tree. I will push today the most recent fixes. |
|
From: James S. <jsi...@in...> - 2002-12-28 18:07:46
|
On Sat, 28 Dec 2002, Geert Uytterhoeven wrote: > Doesn't this look better? Yes. Applied. |
|
From: James S. <jsi...@in...> - 2002-12-28 17:45:59
|
> I got link errors due to a missing fb_blank function. The best > I can figure is that you were intending to call the fb_blank > fbops hook. Certainly that seems to work. > > I'm not sure how no one else ran into this. Okay that is weird. Yes it was suppose to call fb_blank the function.This function exist in fbmem.c and it is even exported for modular fbdev drivers. |
|
From: Jon S. <jon...@ya...> - 2002-12-28 00:39:19
|
I'm looking into running framebuffers on multiple video adapters. My current setup has an ATI AGP Radeon 9000 as the primary adapter and a ATI PCI Rage128 as the secondary. The Rage128 driver won't load in this config. So the first thing I did was to add my board's id to it, PD. Now I'm at the point where the expansion ROM isn't enabled and the adapter isn't initialized. Should I add code to aty128fb to enable the ROM and execute the initialization code (like X does)? What the overall policy towards framebuffers initializing secondary adapters? ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Richard H. <rt...@tw...> - 2002-12-27 23:55:44
|
On Sat, Dec 28, 2002 at 12:25:58AM +0100, Geert Uytterhoeven wrote: > Strange, it's defined in drivers/video/fbmem.c in my copy of 2.5.53. Ah. It's not exported, so fbcon as a module fails. Not sure how I missed it with a grep... r~ |
|
From: Richard H. <rt...@tw...> - 2002-12-27 23:53:34
|
If you do bk, please pull from bk://are.twiddle.net/tga-2.5 That will get these two tga changesets, plus the three other generic fb patchlets I've sent over the last couple of days. Otherwise, there's the bare patches in the attached exports. I realized after the fact that I committed these in the wrong order for easily separating out, but I was pulling in bits from three other trees into my sandbox, so it did make things easier to have them committed. Anyway, enough rambling. This is a large-scale rewrite for the new FB API based on the skeletonfb.c driver. It's been tested on the ZLXp-E1 in my as200. It's definitely a big improvement over not compiling. r~ |
|
From: Geert U. <ge...@li...> - 2002-12-27 23:53:11
|
Doesn't this look better?
--- linux-2.5.53/drivers/video/console/Makefile Fri Dec 20 11:42:38 2002
+++ linux-geert-2.5.53/drivers/video/console/Makefile Sat Dec 28 00:51:12 2002
@@ -10,30 +10,16 @@
# Font handling
font-objs := fonts.o
-ifeq ($(CONFIG_FONT_SUN8x16),y)
- font-objs += font_sun8x16.o
-endif
-ifeq ($(CONFIG_FONT_SUN12x22),y)
- font-objs += font_sun12x22.o
-endif
-ifeq ($(CONFIG_FONT_8x8),y)
- font-objs += font_8x8.o
-endif
-ifeq ($(CONFIG_FONT_8x16),y)
- font-objs += font_8x16.o
-endif
-ifeq ($(CONFIG_FONT_6x11),y)
- font-objs += font_6x11.o
-endif
-ifeq ($(CONFIG_FONT_PEARL_8x8),y)
- font-objs += font_pearl_8x8.o
-endif
-ifeq ($(CONFIG_FONT_ACORN_8x8),y)
- font-objs += font_acorn_8x8.o
-endif
-ifeq ($(CONFIG_FONT_MINI_4x6),y)
- font-objs += font_mini_4x6.o
-endif
+font-objs-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
+font-objs-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
+font-objs-$(CONFIG_FONT_8x8) += font_8x8.o
+font-objs-$(CONFIG_FONT_8x16) += font_8x16.o
+font-objs-$(CONFIG_FONT_6x11) += font_6x11.o
+font-objs-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
+font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
+font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
+
+font-objs += $(font-objs-y)
# Each configuration option enables a list of files.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <Gee...@so...> - 2002-12-27 23:27:31
|
On Fri, 27 Dec 2002, Richard Henderson wrote:
> I got link errors due to a missing fb_blank function. The best
> I can figure is that you were intending to call the fb_blank
> fbops hook. Certainly that seems to work.
>
> I'm not sure how no one else ran into this.
Strange, it's defined in drivers/video/fbmem.c in my copy of 2.5.53.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2002-12-27 23:20:57
|
On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> On Fri, Dec 27, 2002 at 12:05:38PM +0100, Geert Uytterhoeven wrote:
> > On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> > > On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
> > > > Petr is expressing his political view. It has nothing to do with technical
> > > > arguments. In fact I place a bet. I will port the matrox driver and it
> > > > will have the same functionality as the previous driver except for text
> > > > mode support. If I can't do it I will not only revert the changes but I
> > >
> > > Yes. Without text mode support. But without textmode support that driver is
> > > of no use for me because of it is not compatible with VMware then.
> >
> > What exactly in the new fbdev API is preventing you from having text mode
> > support?
>
> Problem is that in new framework driver does not get in touch with characters.
Oops, I forgot about that...
> It gets only prepared bitmap passed to imageblit callback (because of fbcon_putcs
> unconditionally calls accel_putcs, which does character -> bitmap conversion). Of
> course it is possible to convert bitmap back to character number, but it is very
> time consuming, and it looks illogical to me first convert character number to its
> graphic image, and then convert graphic image back to character number... Not even
> talking about 9x16 character cell.
>
> Next problem is that fbdev driver is no more notified (if I understand code correctly)
> about font changes, so it even cannot upload correct font into the hardware, and
> so it must rely on accel_putcs at the time of character print.
So we need to find a way to provide putcs() and font operations by a fbdev,
without sucking in the whole fbcon layer.
Basically you need putcs(), which is really just a simple way to do multiple
image blits in one call, and set_font(), right? And if the fbdev doesn't
provide those, we must fallback to accel_putcs().
James (and Petr, of course), what do you think? And I guess this will make
Davem happy as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Richard H. <rt...@tw...> - 2002-12-27 23:18:54
|
The text is written as if it's thinking about handling 64-bit
unsigned long, but it doesn't. The tables that map bits to
pixels are completely unprepared for this.
I thought about widening the tables, but I thought they'd get
unreasonably large. There's no reason not to go ahead and
handle this 32-bits at a time.
I've isolated this choice to two defines at the top of the
file, WORD and BITS_PER_WORD, so it'll not be _that_ hard to
change if someone disagrees.
r~
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===================================================================
ChangeSet@1.958, 2002-12-27 15:12:24-08:00, rt...@ar...
[FB] Use u32 instead of unsigned long for cfbimgblt bit ops.
The code that maps bits to pixels is not prepared to handle
a 64-bit long.
cfbimgblt.c | 94 +++++++++++++++++++++++++++++++-----------------------------
1 files changed, 49 insertions, 45 deletions
diff -Nru a/drivers/video/cfbimgblt.c b/drivers/video/cfbimgblt.c
--- a/drivers/video/cfbimgblt.c Fri Dec 27 15:16:03 2002
+++ b/drivers/video/cfbimgblt.c Fri Dec 27 15:16:03 2002
@@ -21,13 +21,13 @@
*
* FIXME
* The code for 24 bit is horrible. It copies byte by byte size instead of
- * longs like the other sizes. Needs to be optimized.
+ * words like the other sizes. Needs to be optimized.
*
* Tony:
* Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API. This speeds
* up the code significantly.
*
- * Code for depths not multiples of BITS_PER_LONG is still kludgy, which is
+ * Code for depths not multiples of BITS_PER_WORD is still kludgy, which is
* still processed a bit at a time.
*
* Also need to add code to deal with cards endians that are different than
@@ -48,7 +48,11 @@
#define DPRINTK(fmt, args...)
#endif
-static u32 cfb_tab8[] = {
+/* The following code can *not* handle a 64-bit long. */
+#define WORD u32
+#define BITS_PER_WORD 32
+
+static WORD const cfb_tab8[] = {
#if defined(__BIG_ENDIAN)
0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
@@ -64,7 +68,7 @@
#endif
};
-static u32 cfb_tab16[] = {
+static WORD const cfb_tab16[] = {
#if defined(__BIG_ENDIAN)
0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
#elif defined(__LITTLE_ENDIAN)
@@ -74,11 +78,11 @@
#endif
};
-static u32 cfb_tab32[] = {
+static WORD const cfb_tab32[] = {
0x00000000, 0xffffffff
};
-#if BITS_PER_LONG == 32
+#if BITS_PER_WORD == 32
#define FB_WRITEL fb_writel
#define FB_READL fb_readl
#else
@@ -87,7 +91,7 @@
#endif
#if defined (__BIG_ENDIAN)
-#define LEFT_POS(bpp) (BITS_PER_LONG - bpp)
+#define LEFT_POS(bpp) (BITS_PER_WORD - bpp)
#define NEXT_POS(pos, bpp) ((pos) -= (bpp))
#define SHIFT_HIGH(val, bits) ((val) >> (bits))
#define SHIFT_LOW(val, bits) ((val) << (bits))
@@ -99,25 +103,25 @@
#endif
static inline void color_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long start_index, unsigned long pitch_index)
+ WORD start_index, WORD pitch_index)
{
/* Draw the penguin */
int i, n;
- unsigned long bitmask = SHIFT_LOW(~0UL, BITS_PER_LONG - p->var.bits_per_pixel);
- unsigned long *palette = (unsigned long *) p->pseudo_palette;
- unsigned long *dst, *dst2, color = 0, val, shift;
- unsigned long null_bits = BITS_PER_LONG - p->var.bits_per_pixel;
+ WORD bitmask = SHIFT_LOW(~0UL, BITS_PER_WORD - p->var.bits_per_pixel);
+ u32 *palette = (u32 *) p->pseudo_palette;
+ WORD *dst, *dst2, color = 0, val, shift;
+ WORD null_bits = BITS_PER_WORD - p->var.bits_per_pixel;
u8 *src = image->data;
- dst2 = (unsigned long *) dst1;
+ dst2 = (WORD *) dst1;
for (i = image->height; i--; ) {
n = image->width;
- dst = (unsigned long *) dst1;
+ dst = (WORD *) dst1;
shift = 0;
val = 0;
if (start_index) {
- unsigned long start_mask = ~(SHIFT_HIGH(~0UL, start_index));
+ WORD start_mask = ~(SHIFT_HIGH(~0UL, start_index));
val = FB_READL(dst) & start_mask;
shift = start_index;
@@ -134,14 +138,14 @@
if (shift == null_bits)
val = 0;
else
- val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+ val = SHIFT_LOW(color, BITS_PER_WORD - shift);
}
shift += p->var.bits_per_pixel;
- shift &= (BITS_PER_LONG - 1);
+ shift &= (BITS_PER_WORD - 1);
src++;
}
if (shift) {
- unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
+ WORD end_mask = SHIFT_HIGH(~0UL, shift);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -149,35 +153,35 @@
if (pitch_index) {
dst2 += p->fix.line_length;
dst1 = (char *) dst2;
- (unsigned long) dst1 &= ~(sizeof(unsigned long) - 1);
+ (size_t) dst1 &= ~(sizeof(WORD) - 1);
start_index += pitch_index;
- start_index &= BITS_PER_LONG - 1;
+ start_index &= BITS_PER_WORD - 1;
}
}
}
static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long fgcolor, unsigned long bgcolor,
- unsigned long start_index, unsigned long pitch_index)
+ WORD fgcolor, WORD bgcolor,
+ WORD start_index, WORD pitch_index)
{
- unsigned long i, j, l = 8;
- unsigned long shift, color, bpp = p->var.bits_per_pixel;
- unsigned long *dst, *dst2, val, pitch = p->fix.line_length;
- unsigned long null_bits = BITS_PER_LONG - bpp;
+ WORD i, j, l = 8;
+ WORD shift, color, bpp = p->var.bits_per_pixel;
+ WORD *dst, *dst2, val, pitch = p->fix.line_length;
+ WORD null_bits = BITS_PER_WORD - bpp;
u8 *src = image->data;
- dst2 = (unsigned long *) dst1;
+ dst2 = (WORD *) dst1;
for (i = image->height; i--; ) {
shift = 0;
val = 0;
j = image->width;
- dst = (unsigned long *) dst1;
+ dst = (WORD *) dst1;
/* write leading bits */
if (start_index) {
- unsigned long start_mask = ~(SHIFT_HIGH(~0UL, start_index));
+ WORD start_mask = ~(SHIFT_HIGH(~0UL, start_index));
val = FB_READL(dst) & start_mask;
shift = start_index;
@@ -196,15 +200,15 @@
if (shift == null_bits)
val = 0;
else
- val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+ val = SHIFT_LOW(color, BITS_PER_WORD - shift);
}
shift += bpp;
- shift &= (BITS_PER_LONG - 1);
+ shift &= (BITS_PER_WORD - 1);
if (!l) { l = 8; src++; };
}
/* write trailing bits */
if (shift) {
- unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
+ WORD end_mask = SHIFT_HIGH(~0UL, shift);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -213,24 +217,24 @@
if (pitch_index) {
dst2 += pitch;
dst1 = (char *) dst2;
- (unsigned long) dst1 &= ~(sizeof(unsigned long) - 1);
+ (size_t) dst1 &= ~(sizeof(WORD) - 1);
start_index += pitch_index;
- start_index &= BITS_PER_LONG - 1;
+ start_index &= BITS_PER_WORD - 1;
}
}
}
static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long fgcolor, unsigned long bgcolor)
+ WORD fgcolor, WORD bgcolor)
{
int i, j, k, l = 8, n;
- unsigned long bit_mask, end_mask, eorx;
- unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
- unsigned long tmp = (1 << bpp) - 1;
- unsigned long ppw = BITS_PER_LONG/bpp, ppos;
- unsigned long *dst;
+ WORD bit_mask, end_mask, eorx;
+ WORD fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+ WORD tmp = (1 << bpp) - 1;
+ WORD ppw = BITS_PER_WORD/bpp, ppos;
+ WORD *dst;
u32 *tab = NULL;
char *src = image->data;
@@ -263,7 +267,7 @@
k = image->width/ppw;
for (i = image->height; i--; ) {
- dst = (unsigned long *) dst1;
+ dst = (WORD *) dst1;
for (j = k; j--; ) {
l -= ppw;
@@ -291,8 +295,8 @@
void cfb_imageblit(struct fb_info *p, struct fb_image *image)
{
int x2, y2, vxres, vyres;
- unsigned long fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
- unsigned long bpl = sizeof(unsigned long), bpp = p->var.bits_per_pixel;
+ WORD fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
+ WORD bpl = sizeof(WORD), bpp = p->var.bits_per_pixel;
u8 *dst1;
vxres = p->var.xres_virtual;
@@ -315,7 +319,7 @@
image->height = y2 - image->dy;
bitstart = (image->dy * p->fix.line_length * 8) + (image->dx * bpp);
- start_index = bitstart & (BITS_PER_LONG - 1);
+ start_index = bitstart & (BITS_PER_WORD - 1);
pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
bitstart /= 8;
@@ -332,7 +336,7 @@
bgcolor = image->bg_color;
}
- if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index &&
+ if (BITS_PER_WORD % bpp == 0 && !start_index && !pitch_index &&
bpp >= 8 && bpp <= 32 && (image->width & 7) == 0)
fast_imageblit(image, p, dst1, fgcolor, bgcolor);
else
===================================================================
This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##
begin 664 bkpatch3145
M'XL(`#/?##X``[U76W/:.!1^QK_B[&0V`RP72[Y@2.FT*6V3:6:32=KI0[?#
M"%N`&F-[;!'27::_?8\D<(!<2KL7AY&0=*[?^8Y,#N!#P?->)9=3ZP!.TD+V
M*BSG+;D0413S5L(E[E^F*>ZWI^F,MU&R??RN+2>L25N>A:<73(93N.%YT:N0
MEE/NR*\9[U4N7[_]</;RTK+Z?7@U9<F$7W$)_;XET_R&Q5'Q@LEIG"8MF;.D
MF'')6F$Z6Y:B2VK;%/\\TG%LSU\2WW8[RY!$A#"7\,BF;N"[%H;U8B?P'1N$
MT@YU;-<.EH[C=@-K`*35]0*P:9O0-NT`\7J$]JC;M(.>;<,#)N$W`DW;.H9_
M-_A75@B?WAQ_5L6`N4-!)(7D+()T#/.D$).$1X!N)C!.<PC'(S&;C&()(R$A
MS8H6JK^?<@C3B(.<,@DSEA7JM,!`(1.W/"Y`%)"D$K*<9YA5I$XP3$P,M1GX
M;E-94TY:UCMP*.UVK(N[BEG-'WPLRV:V]1R^%&(V2Y/BQ92+@B<CGD\,6C<B
MEW,6:\"B7"C^M&]$Q--VF6`K-`!ZQ*<.M0E94M(-G"4+6<BCP!EWV-AV,>F'
MJO^T3<,&0HF]]%TWH)J?CZHHOOX?B=PYF;';!8_C%F>86RR2Z[URLCVT;5.Z
MI'[@4<UPXNX2G-A/$=SM0M/U_A.*[\7N-:=AF]*H_D.DOD]I4^9S:.8+_4&*
M7CQ>\9_@^X"Z0*Q3/4(=8)'F40&QN%89<$AQR*$0?W),[G?.(YW'"`\R*6:X
M';6L@6,K$WI4)EZI]!4J$<_DU.0ZF\=29#$O%'['I^^OAA>O+X<?SR\'"HU"
MBCB&ZW@>3;XV8#$5>!&+PAIX1!G&T;/:=0WM.(WC="$0=@URR!*HH_WZPP`"
MU-O60<3'(N&@G6$ERXWM,/#@#ZN03(K0B(;(:*GNK:%DH^#39^C#7];`[ZB0
M]/BH,/'7TATMW7E2VJ%KZ4"GJ\<#L0L3=CJ&..AJK/6XSN/L]9OWPXOSJ^HH
MRVI0/M5M_2:H8VN`G:8LF*F"#XIJ`0PPET.11/RV878R@6]$LZ,5?7"58A>G
MBA9`H&>LN,;HKTY.,8BS\X_5;_:'LP;L^LZ:SV]8WE*-,,QX/M2=4#NR*JJU
MZAF+N90<[53UNJ;DLX+/HW2X.CM:N:Q'A6SHD380QQAIU@>[`=CU#2BF8BS7
MDLD\CH>Z\_K[A7,$F"0QZ.BIHKRHH(SG&N":'"DASPAY&D+<?4B(ZDJ9"6'>
MP'B%V;>J0>WD].W)"K:-&M1JRHBC"60F5:P*YKD%MX;@/MX:"6W!-6&XJS#T
M`1SV[].#&''7B+L;4?,D&F[5>3/BTI%GD/-6O*JJ2V,H#1[*X3>]DXXU4+72
MH6>P]+Q5?'<(**5[02H5GP!%%9_B9!BL3\>3%1B&F^O5ILAW.>Z[FN/8WVN.
MBP9\:8`"/5@S2^>\8E]#M14>/LRHATBKF:K=&K6QN&WANY(/8YY,Y'0?^J)+
MA4/'E%9/CW*UXQLA_RFN!L92\(^XVNUJ(WKZ*:Y2<S71]=7T':Y2NV/$.S_*
M54HT*&;:GZOX\\>H=??F*J7&$_7+V_9QKM9`*73Q;7=*'0>G\I;5*37*Y/!;
MFM_B?559&;O%=$N3([TL^9^Q:"^2RID2J1)X]DR_*DP&YBS+%KLT;*,,&L_2
M8I/E*F7?I.P_Q3C:=54/TZZG>G@;DC+RK6Y50:MU8[-EU=V_=C_*%-LVZ_:=
MM`<."?0/%SUM5;-?NH/#1]CG./KB,E.E@N_K';E?C7>,$`X/X9<MLN!Z,PM<
;W_U/&DYY>%W,9WU&(I^&H6_]#;UYC$7P#@``
`
end
|
|
From: Richard H. <rt...@tw...> - 2002-12-27 23:09:46
|
I got link errors due to a missing fb_blank function. The best I can figure is that you were intending to call the fb_blank fbops hook. Certainly that seems to work. I'm not sure how no one else ran into this. r~ You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. =================================================================== ChangeSet@1.957, 2002-12-27 15:04:08-08:00, rt...@ar... [FB] fb_blank is an fbops hook, not a standalone function. drivers/video/console/fbcon.c | 2 +- include/linux/fb.h | 1 - 2 files changed, 1 insertion, 2 deletions diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c --- a/drivers/video/console/fbcon.c Fri Dec 27 15:05:10 2002 +++ b/drivers/video/console/fbcon.c Fri Dec 27 15:05:10 2002 @@ -1993,7 +1993,7 @@ update_screen(vc->vc_num); return 0; } else - return fb_blank(blank, info); + return info->fbops->fb_blank(blank, info); } static void fbcon_free_font(struct display *p) diff -Nru a/include/linux/fb.h b/include/linux/fb.h --- a/include/linux/fb.h Fri Dec 27 15:05:10 2002 +++ b/include/linux/fb.h Fri Dec 27 15:05:10 2002 @@ -449,7 +449,6 @@ extern int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info); extern int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info); -extern int fb_blank(int blank, struct fb_info *info); extern int soft_cursor(struct fb_info *info, struct fb_cursor *cursor); extern void cfb_fillrect(struct fb_info *info, struct fb_fillrect *rect); extern void cfb_copyarea(struct fb_info *info, struct fb_copyarea *area); =================================================================== This BitKeeper patch contains the following changesets: + ## Wrapped with gzip_uu ## begin 664 bkpatch2996 M'XL(`*;<##X``[55VVZ<,!!]7G^%I;RT:H"Q,==JHS3I+4JE1EOEJ:HJ`[.! M+M@1F$TJ\?'UDC;73;9)&T`@;#,^,^><88L>=]BFD]:49(M^U)U))[)%UYQ5 M15&CJ]#8\9G6=MPK=8.>7>GM'7KF1#K<#8B=/9(F+^D2VRZ=,->_'#$_3S&= MS-Y]./[T9D;(=$KW2ZE.\`L:.IT2H]NEK(MN5YJRULHUK51=@T:ZN6Z&RZ4# M!^#V#%CD0Q`.+`01#3DK&)."80%<Q*$@%M;N+>"W8C#.0^X'(42#+R*(R%O* MW"2(*'"/<8]'E`4IB!1B!^(4@*X)25]QZ@#9H_\7_#[)Z=?W>]_H//N>U5(M M:-51J>RK/NUHJ?5BFRIMJ*2=D:J0=D>D\U[EIK)[DT/J^R*)R=%5@8GSR(,0 MD$!V-B16J;SN"_3J2O7GWCQSR^L9)H(-$"8^'T+@2584&681HI!B72WO"V9Y MBK@/?K`*$P';"*IHJY7XO&55H+9Q<KLBOX9+``L''M@*#3P*YTD""<;9/!09 M6XOK9CP;K=,UWHA[#:(?1'$\BOO!SS8+_A^R(#^ZJFGLAKN-/#_#NG91VL1L M71=_G1`DW+J"Q]8;(<2C-X+DIC7\-.`/68-1ASV+-0[44B_PRAS+2EY88Y3^ M2,!GZK1GXV6E?/0P%T_PQEN6)"%EY.#W<S)IT?2MHI6::V=G!+-Z7`!\,=ZW MQ\F7KT=QW-7Z9D4\U6QK>^']9K--<47]```QC,3S1Q(/ST7\#!N]1-JKOL/B MBO\"\UJV\D_SN^@2MQ1P-]^GT"X";MF^_*/E)>:+KF^F++:E$WE`?@&"R\7O $0`<````` ` end |
|
From: Petr V. <van...@vc...> - 2002-12-27 23:01:32
|
On Fri, Dec 27, 2002 at 12:05:38PM +0100, Geert Uytterhoeven wrote: > On Fri, 27 Dec 2002, Petr Vandrovec wrote: > > On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote: > > > Petr is expressing his political view. It has nothing to do with technical > > > arguments. In fact I place a bet. I will port the matrox driver and it > > > will have the same functionality as the previous driver except for text > > > mode support. If I can't do it I will not only revert the changes but I > > > > Yes. Without text mode support. But without textmode support that driver is > > of no use for me because of it is not compatible with VMware then. > > What exactly in the new fbdev API is preventing you from having text mode > support? Problem is that in new framework driver does not get in touch with characters. It gets only prepared bitmap passed to imageblit callback (because of fbcon_putcs unconditionally calls accel_putcs, which does character -> bitmap conversion). Of course it is possible to convert bitmap back to character number, but it is very time consuming, and it looks illogical to me first convert character number to its graphic image, and then convert graphic image back to character number... Not even talking about 9x16 character cell. Next problem is that fbdev driver is no more notified (if I understand code correctly) about font changes, so it even cannot upload correct font into the hardware, and so it must rely on accel_putcs at the time of character print. If nothing else, VMware can be happy with just black screen in text mode, it will paint proper characters directly... Much worse problem is that I do not see any way how to have different resolutions on different virtual terminals, and I do not know how to work around this. Best regards, Petr Vandrovec van...@vc... |
|
From: Antonino D. <ad...@po...> - 2002-12-27 15:12:12
|
On Sun, 2002-12-22 at 16:44, Geert Uytterhoeven wrote:
> On 15 Dec 2002, Antonino Daplas wrote:
> > On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> > > What if I'll decide to paint characters through busmastering? Then
> > > I need font data in buffers allocated by pci_alloc_consistent...
> > > In the past it was not a win to use busmastering, but now, when
> > > upper layers might prepare images much larger than 8x16, it may be
> > > worth of rechecking that...
> >
> > True, using kmalloc() to cache a good-sized pixmap is probably not the
> > best idea in all cases (in my case, it is best when the pixmap is in
> > graphics memory). I submitted a proposal before that allows more
> > flexibility: it will let the drivers decide on how it wants the buffers
> > allocated, the size of the buffer, specific alignment requirements, or
> > if it even actually needs one. Other driver-specific needs can probably
> > be added if necessary.
>
> Add address/size fields in fb_info to let the driver tell it already allocated
> a suitable buffer? If those are NULL, fbcon can fall back to its own buffer
> (e.g. static and fixed 8 kiB buffer).
>
How about the following?
Drivers can choose to fill up the fb_pixmap structure for
device-specific buffer requirements:
#define FB_PIXMAP_SYSMEM 0
#define FB_PIXMAP_IOMEM 1
struct fb_pixmap {
__u32 loc; /* location of buffer */
__u8 *addr; /* address of buffer */
__u32 size; /* size of buffer */
__u32 align; /* byte alignment per scanline */
};
Drivers can allocate the buffer in system memory (FB_PIXMAP_SYSMEM) or
io/graphics memory (FB_PIXMAP_IOMEM) and specify the alignment of each
line of pixels. Otherwise, accel_putcs will default to using the
statically allocated buffer with a 1-byte alignment per scanline.
Attached is a patch against 2.5.52. Other changes:
call fb_sync() if framebuffer memory is to be accessed (cfb_* drawing
functions, fb_read and fb_write).
Tony
diff -Nuar linux-2.4.52/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.4.52/drivers/video/cfbcopyarea.c 2002-12-27 14:39:27.000000000 +0000
+++ linux/drivers/video/cfbcopyarea.c 2002-12-27 14:38:27.000000000 +0000
@@ -375,6 +375,9 @@
dst_idx += area->dy*next_line*8 + area->dx*p->var.bits_per_pixel;
src_idx += area->sy*next_line*8 + area->sx*p->var.bits_per_pixel;
+ if (p->fbops->fb_sync)
+ p->fbops->fb_sync(p);
+
if (rev_copy) {
while (area->height--) {
dst_idx -= next_line*8;
diff -Nuar linux-2.4.52/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.4.52/drivers/video/cfbfillrect.c 2002-12-27 14:39:30.000000000 +0000
+++ linux/drivers/video/cfbfillrect.c 2002-12-27 14:38:32.000000000 +0000
@@ -397,6 +397,10 @@
dst_idx += rect->dy*p->fix.line_length*8+rect->dx*bpp;
/* FIXME For now we support 1-32 bpp only */
left = BITS_PER_LONG % bpp;
+
+ if (p->fbops->fb_sync)
+ p->fbops->fb_sync(p);
+
if (!left) {
u32 pat = pixel_to_pat32(p, fg);
void (*fill_op32)(unsigned long *dst, int dst_idx, u32 pat, u32 n) = NULL;
diff -Nuar linux-2.4.52/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.4.52/drivers/video/cfbimgblt.c 2002-12-27 14:39:23.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2002-12-27 14:38:22.000000000 +0000
@@ -322,6 +322,9 @@
bitstart &= ~(bpl - 1);
dst1 = p->screen_base + bitstart;
+ if (p->fbops->fb_sync)
+ p->fbops->fb_sync(p);
+
if (image->depth == 1) {
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
diff -Nuar linux-2.4.52/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.4.52/drivers/video/console/fbcon.c 2002-12-27 14:39:13.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2002-12-27 14:38:09.000000000 +0000
@@ -378,16 +378,26 @@
info->fbops->fb_fillrect(info, ®ion);
}
+static inline void syswriteb(u8 val, u8 *addr)
+{
+ *addr = val;
+}
+
+static inline void iowriteb(u8 val, u8 *addr)
+{
+ fb_writeb(val, addr);
+}
+
void accel_putcs(struct vc_data *vc, struct display *p,
const unsigned short *s, int count, int yy, int xx)
{
+ static char pixmap[8192];
struct fb_info *info = p->fb_info;
unsigned short charmask = p->charmask;
unsigned int width = ((vc->vc_font.width + 7)/8);
unsigned int cellsize = vc->vc_font.height * width;
struct fb_image image;
u16 c = scr_readw(s);
- static u8 pixmap[8192];
image.fg_color = attr_fgcol(p, c);
image.bg_color = attr_bgcol(p, c);
@@ -396,30 +406,60 @@
image.height = vc->vc_font.height;
image.depth = 1;
-/* pixmap = kmalloc((info->var.bits_per_pixel + 7) >> 3 *
- vc->vc_font.height, GFP_KERNEL);
-*/
-
- if (!(vc->vc_font.width & 7) && pixmap != NULL) {
- unsigned int pitch = width * count, i, j;
+ if (!(vc->vc_font.width & 7)) {
+ unsigned int pitch, i, j;
char *src, *dst, *dst0;
+ void (*write_op)(u8 val, u8 *addr) = syswriteb;
+
+ if (info->pixmap.addr != NULL) {
+ unsigned int align = (info->pixmap.align) ?
+ info->pixmap.align - 1 : 0;
+
+ pitch = (width * count + align) & ~(align);
+ if (pitch * vc->vc_font.height > info->pixmap.size)
+ /*
+ * FIXME: do multiple blit's instead
+ * of exiting
+ */
+ return;
+
+ dst0 = info->pixmap.addr;
+ image.data = info->pixmap.addr;
+ switch (info->pixmap.loc) {
+ case FB_PIXMAP_IOMEM:
+ write_op = iowriteb;
+ break;
+ case FB_PIXMAP_SYSMEM:
+ default:
+ write_op = syswriteb;
+ break;
+ }
+ }
+ else {
+ pitch = width * count;
+ dst0 = pixmap;
+ image.data = pixmap;
+ if (pitch * vc->vc_font.height > 8192)
+ /*
+ * FIXME: do multiple blit's instead
+ * of exiting
+ */
+ return;
+ }
- dst0 = pixmap;
image.width = vc->vc_font.width * count;
- image.data = pixmap;
while (count--) {
src = p->fontdata + (scr_readw(s++) & charmask) * cellsize;
dst = dst0;
for (i = image.height; i--; ) {
for (j = 0; j < width; j++)
- dst[j] = *src++;
+ write_op(*src++, dst + j);
dst += pitch;
}
dst0 += width;
}
info->fbops->fb_imageblit(info, &image);
- if (info->fbops->fb_sync)
- info->fbops->fb_sync(info);
+
} else {
image.width = vc->vc_font.width;
while (count--) {
@@ -429,10 +469,6 @@
image.dx += vc->vc_font.width;
}
}
- /*
- if (pixmap);
- kfree(pixmap);
- */
}
void accel_clear_margins(struct vc_data *vc, struct display *p,
diff -Nuar linux-2.4.52/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.4.52/drivers/video/fbmem.c 2002-12-27 14:39:19.000000000 +0000
+++ linux/drivers/video/fbmem.c 2002-12-27 14:41:30.000000000 +0000
@@ -392,6 +392,9 @@
if (!info || ! info->screen_base)
return -ENODEV;
+ if (info->fbops->fb_sync)
+ info->fbops->fb_sync(info);
+
if (info->fbops->fb_read)
return info->fbops->fb_read(file, buf, count, ppos);
@@ -425,6 +428,9 @@
if (!info || !info->screen_base)
return -ENODEV;
+ if (info->fbops->fb_sync)
+ info->fbops->fb_sync(info);
+
if (info->fbops->fb_write)
return info->fbops->fb_write(file, buf, count, ppos);
diff -Nuar linux-2.4.52/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.4.52/include/linux/fb.h 2002-12-27 14:39:43.000000000 +0000
+++ linux/include/linux/fb.h 2002-12-27 14:41:31.000000000 +0000
@@ -294,6 +294,16 @@
struct fb_cmap cmap; /* color map info */
};
+#define FB_PIXMAP_SYSMEM 0
+#define FB_PIXMAP_IOMEM 1
+
+struct fb_pixmap {
+ __u32 loc; /* location of buffer */
+ __u8 *addr; /* address of buffer */
+ __u32 size; /* size of buffer */
+ __u32 align; /* byte alignment per scanline */
+};
+
/*
* hardware cursor control
*/
@@ -386,6 +396,7 @@
struct fb_monspecs monspecs; /* Current Monitor specs */
struct fb_cursor cursor; /* Current cursor */
struct fb_cmap cmap; /* Current cmap */
+ struct fb_pixmap pixmap; /* Current pixmap */
struct fb_ops *fbops;
char *screen_base; /* Virtual address */
struct vc_data *display_fg; /* Console visible on this display */
|
|
From: Geert U. <ge...@li...> - 2002-12-27 11:34:40
|
On Fri, 27 Dec 2002, Abhilash wrote:
> I need to capture the screen .For that I use mirror driver in Windows for
> capturing screen.
> ie, its basically overloading the driver functions.
>
> So in case of Linux, is there any method like this or which is the best
> method?
> In Xlib there are some functions to capture screen and also heard abt VESA
> which is better?
If you are using a frame buffer device, you can capture the contents of
/dev/fb*. Either read from /dev/fb*, or mmap() it. The data you receive are in
the native format of the graphics chip. For CLUT modes, you have to use an
ioctl() to get the colormap.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2002-12-27 11:07:55
|
On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
> > Petr is expressing his political view. It has nothing to do with technical
> > arguments. In fact I place a bet. I will port the matrox driver and it
> > will have the same functionality as the previous driver except for text
> > mode support. If I can't do it I will not only revert the changes but I
>
> Yes. Without text mode support. But without textmode support that driver is
> of no use for me because of it is not compatible with VMware then.
What exactly in the new fbdev API is preventing you from having text mode
support?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Abhilash <abh...@av...> - 2002-12-27 08:27:50
|
Hello, I need to capture the screen .For that I use mirror driver in Windows = for capturing screen. ie, its basically overloading the driver functions. So in case of Linux, is there any method like this or which is the best method? In Xlib there are some functions to capture screen and also heard abt = VESA which is better? Thank you, Abhilash |
|
From: Petr V. <van...@vc...> - 2002-12-27 02:41:23
|
On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote: > > > It's rather annoying that in a feature-freeze period a change goes in > > that cripples the one framebuffer with the best speed and features - > > the matrox framebuffer. > > Because a driver has over 10,000 lines of code does not mean it is a > quality driver. I do not say that driver is perfect. But at least it worked... on wide variety of architectures. > > The author mentioned it could be weeks or months > > before he would be able to get his matrox framebuffer working with the > > new framework, since its simple API doesn't fit the possibilities of the > > matrox framebuffer. Read more about it on the fbdev-users or > > fbdev-developers mailinglist on sourceforge. > > Petr is expressing his political view. It has nothing to do with technical > arguments. In fact I place a bet. I will port the matrox driver and it > will have the same functionality as the previous driver except for text > mode support. If I can't do it I will not only revert the changes but I Yes. Without text mode support. But without textmode support that driver is of no use for me because of it is not compatible with VMware then. You know that I'm not forcing my view to anybody. I just wrote matroxfb to fullfill my needs, and that's everything. > will give Petr his wetdream. I will start inetergrating vt.c and > vt_ioctl.c into each fbdev driver. Each fbdev driver will be its own > console system. We will not longer need vt.c and vt_ioctl.c as each driver > will have its own version intergated into the driver. Sound fair? I do not need that. I just need API which will allow at least same functionality which old API offered. Nothing more, and of course, nothing less. For now I just added putc/putcs into the fbops, and matroxfb uses its own while other drivers can use default accel_putc(s) directly. Of course uploading font data to the hardware will need more hooks... Another interesting question is how can I have different resolutions on different virtual terminals... An 640x16 bitmap is of no use for me if I just want to put 80 characters on text terminal. Or if I want to tell to the accelerator what character it should retrieve from its onboard font cache... Petr Vandrovec van...@vc... |
754 messages has been excluded from this view by a project administrator.
