You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(12) |
Feb
(10) |
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
(5) |
Aug
(7) |
Sep
(15) |
Oct
(4) |
Nov
(3) |
Dec
(7) |
2003 |
Jan
(5) |
Feb
(30) |
Mar
(5) |
Apr
(13) |
May
(12) |
Jun
(11) |
Jul
(1) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(7) |
2004 |
Jan
(4) |
Feb
(9) |
Mar
(16) |
Apr
(42) |
May
(5) |
Jun
(11) |
Jul
(3) |
Aug
(39) |
Sep
(5) |
Oct
(32) |
Nov
(27) |
Dec
|
2005 |
Jan
(11) |
Feb
(8) |
Mar
(22) |
Apr
(26) |
May
(9) |
Jun
(10) |
Jul
(7) |
Aug
(43) |
Sep
(23) |
Oct
(18) |
Nov
(15) |
Dec
(15) |
2006 |
Jan
(7) |
Feb
(16) |
Mar
(10) |
Apr
(1) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(35) |
Sep
(7) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
2007 |
Jan
(2) |
Feb
(30) |
Mar
(6) |
Apr
(7) |
May
(5) |
Jun
|
Jul
(15) |
Aug
(12) |
Sep
(22) |
Oct
(48) |
Nov
(9) |
Dec
(7) |
2008 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(4) |
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(4) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(2) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: davidm <dav...@da...> - 2007-09-09 15:13:58
|
Hi, I suspect this ought to be an FAQ, but I can't find anything definitive easily... I have a g450. I cannot get my tv to sync to the tvout if I attach the primary crtc to that output (eg, taken from http://www.rockhopper.dk/linux/hardware/graphics_cards.html: #!/bin/bash modprobe i2c-matroxfb modprobe matroxfb_maven matroxset -f /dev/fb1 -m 0 matroxset -f /dev/fb0 -m 0 matroxset -f /dev/fb0 -m 3 matroxset -o 1 1 # Sets the output to pal, ntsc users should use -o 1 2 # Set the resolution to 720x576 fbset -fb /dev/fb0 -left 18 -right 0 -upper 39 -lower 10 -hslen 46 \ -vslen 4 -xres 720 -yres 576 -vxres 720 -vyres 576 -depth 32 \ -laced false -bcast true - I just get rubbish). That page is referring to a G400, not a G450 - is that my problem? (obviously it would be nice to be able to get the goodies from the primary crtc through the tv, rather than effectively having a dumb fb). Cheers, David |
From: Antonino A. D. <ad...@gm...> - 2007-09-02 10:49:12
|
On Sun, 2007-09-02 at 11:46 +0200, Pavel Pisa wrote: > On Sunday 02 September 2007 05:34, Antonino A. Daplas wrote: > > On Sun, 2007-09-02 at 02:58 +0200, Pavel Pisa wrote: > > > On Sunday 02 September 2007 02:36, Antonino A. Daplas wrote: > > > > On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > > > > > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > > > > > > The swapping is necessary for 4-bit gray scale levels or 4-bit > color palette modes for i.MX/MX1 framebuffer driver. > But if the kernel is compiled for MX1 board/application, where these > modes are not used, then it is not necessary to compile swapping > support into kernel. It does not harm hand but it causes some > overhead. The selection of CONFIG_FB_CFB_REV_PIXELS_IN_BYTE > can be left on user or board configuration. It does not need to > be forced by select and I agree, that this line does not belong to > generic part of changes. Understood. Although someone might comment that I'm including a feature without a driver depending on it. I'll just clarify this in the changelog. > > > Well, I still need your changelog and Signed-off-by: line for the > > imxfb-nonstd-info.patch. I can get the other 2 from your repository > > though. > > As for "imxfb-nonstd-info.patch", I add changelog for sure. But > before inclusion it should go through linux-arm-kernel mailinglist and > should be reviewed by Sascha Hauer. I would send it there > with CC to you. Please, inform me, if it should go through ARM patch > system or over your queue then. I don't mind you submitting your changes to the linux-arm mailing list and Sascha first. Sascha can channel it through me or directly to mainline later. I'll just pick up the 2 patches then. Tony |
From: Pavel P. <pi...@cm...> - 2007-09-02 09:46:44
|
On Sunday 02 September 2007 05:34, Antonino A. Daplas wrote: > On Sun, 2007-09-02 at 02:58 +0200, Pavel Pisa wrote: > > On Sunday 02 September 2007 02:36, Antonino A. Daplas wrote: > > > On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > > > > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > > > > > > > @@ -348,6 +357,7 @@ config FB_IMX > > > > select FB_CFB_FILLRECT > > > > select FB_CFB_COPYAREA > > > > select FB_CFB_IMAGEBLIT > > > > + select FB_CFB_REV_PIXELS_IN_BYTE > > > > > > > > config FB_CYBER2000 > > > > tristate "CyberPro 2000/2010/5000 support" > > > > > > BTW, I'll submit this hunk as a separate patch, so it's clearer that > > > imxfb is the one particular driver that needs this change. > > > > Hello Tony, > > > > in the fact, this line is not necessary at all. If "imxfb" > > is used with color display or TFT, then it is not required. > > Omit this change from the patch. It could be moved into > > "imxfb-nonstd-info.patch" patch, but it is not necessary. > > Now you're confusing me. If you don't enable > CONFIG_FB_CFB_REV_PIXELS_IN_BYTE, then the byte-swapping code does not > get compiled, yes? Hello Tony, I have not worded it cleanly, sorry. The swapping is necessary for 4-bit gray scale levels or 4-bit color palette modes for i.MX/MX1 framebuffer driver. But if the kernel is compiled for MX1 board/application, where these modes are not used, then it is not necessary to compile swapping support into kernel. It does not harm hand but it causes some overhead. The selection of CONFIG_FB_CFB_REV_PIXELS_IN_BYTE can be left on user or board configuration. It does not need to be forced by select and I agree, that this line does not belong to generic part of changes. > Well, I still need your changelog and Signed-off-by: line for the > imxfb-nonstd-info.patch. I can get the other 2 from your repository > though. As for "imxfb-nonstd-info.patch", I add changelog for sure. But before inclusion it should go through linux-arm-kernel mailinglist and should be reviewed by Sascha Hauer. I would send it there with CC to you. Please, inform me, if it should go through ARM patch system or over your queue then. Thanks again Pavel |
From: Antonino A. D. <ad...@gm...> - 2007-09-02 03:34:21
|
On Sun, 2007-09-02 at 02:58 +0200, Pavel Pisa wrote: > On Sunday 02 September 2007 02:36, Antonino A. Daplas wrote: > > On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > > > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > > > > > @@ -348,6 +357,7 @@ config FB_IMX > > > select FB_CFB_FILLRECT > > > select FB_CFB_COPYAREA > > > select FB_CFB_IMAGEBLIT > > > + select FB_CFB_REV_PIXELS_IN_BYTE > > > > > > config FB_CYBER2000 > > > tristate "CyberPro 2000/2010/5000 support" > > > > BTW, I'll submit this hunk as a separate patch, so it's clearer that > > imxfb is the one particular driver that needs this change. > > Hello Tony, > > in the fact, this line is not necessary at all. If "imxfb" > is used with color display or TFT, then it is not required. > Omit this change from the patch. It could be moved into > "imxfb-nonstd-info.patch" patch, but it is not necessary. > Now you're confusing me. If you don't enable CONFIG_FB_CFB_REV_PIXELS_IN_BYTE, then the byte-swapping code does not get compiled, yes? > http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/imxfb-nonstd-info.patch > > I suggest to keep the next two as separate > cfb-pixels-in-byte-swapped.patch > cfb-copyarea-swapping.patch > > Would you take latest version from my repository > or should I resend them inline? Well, I still need your changelog and Signed-off-by: line for the imxfb-nonstd-info.patch. I can get the other 2 from your repository though. Tony |
From: Pavel P. <pi...@cm...> - 2007-09-02 00:59:24
|
On Sunday 02 September 2007 02:36, Antonino A. Daplas wrote: > On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > > > @@ -348,6 +357,7 @@ config FB_IMX > > select FB_CFB_FILLRECT > > select FB_CFB_COPYAREA > > select FB_CFB_IMAGEBLIT > > + select FB_CFB_REV_PIXELS_IN_BYTE > > > > config FB_CYBER2000 > > tristate "CyberPro 2000/2010/5000 support" > > BTW, I'll submit this hunk as a separate patch, so it's clearer that > imxfb is the one particular driver that needs this change. Hello Tony, in the fact, this line is not necessary at all. If "imxfb" is used with color display or TFT, then it is not required. Omit this change from the patch. It could be moved into "imxfb-nonstd-info.patch" patch, but it is not necessary. http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/imxfb-nonstd-info.patch I suggest to keep the next two as separate cfb-pixels-in-byte-swapped.patch cfb-copyarea-swapping.patch Would you take latest version from my repository or should I resend them inline? Best wishes Pavel |
From: Antonino A. D. <ad...@gm...> - 2007-09-02 00:36:15
|
On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > @@ -348,6 +357,7 @@ config FB_IMX > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > + select FB_CFB_REV_PIXELS_IN_BYTE > > config FB_CYBER2000 > tristate "CyberPro 2000/2010/5000 support" BTW, I'll submit this hunk as a separate patch, so it's clearer that imxfb is the one particular driver that needs this change. Tony |
From: Antonino A. D. <ad...@gm...> - 2007-09-02 00:34:04
|
On Sat, 2007-09-01 at 15:47 +0200, Pavel Pisa wrote: > On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > > May it be - this would make some not so nice effects > > > for cursor when some strange font width is used. > > > > You basically have 3 choices: > > > > 1. Fix copyarea/fillrect > > 2. Accept that the console may become corrupted if a non-8x16 font is > > loaded. > > 3. Tell the console layer that it can only handle multiple-of-8 wide > > fonts > > Hello Tony and Geert, > > I have updated patch to support all above operations. The feature > is disabled at compile time if CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set. > I have added simplified inline functions variants for this case > to help compiler to optimize code. The compiler should be able to optimize > code to same instructions as before this change. If option is enabled, > then actual swapping is controlled by FB_NONSTD_REV_PIX_IN_B > option in variable informations. > > I have tested code on our target with fbcon=font:ProFont6x11 and 7x14 > and I see no glitches, but more precise review by more people is probably > necessary mainly to check, that there is no regression for regular use. > Is there some userspace tests which invoke copyarea, fillrectangles > and blits with different parameters? There're no userspace tools, but I'll do my own testing. I'll have your patches go to the -mm tree soon, and if there are problems, it should be easily noticed by users. Thanks. Tony |
From: Pavel P. <pi...@cm...> - 2007-09-01 18:30:28
|
Hello all, I have found that I forgot to update prototypes for swapping bypass function. I have corrected one case for copy-area function still not covered by previous code. This is the case, where horizontal difference of source and destination is not multiple of pixels in byte. This is relatively complicated case and I am not sure, if it can appear during normal operation. I have not found solution other, than to swap pixels in long after reads and before writes. These changes should not lead to different operation for non swapped compilation, but because more reorganization of code has been done I would submit this as different patch. Actual version of patches is there http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/cfb-pixels-in-byte-swapped.patch http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/cfb-copyarea-swapping.patch The changes in original patch are correction of bypass functions =============================================================================== +#else /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */ + +static inline unsigned long fb_rev_pixels_in_long(unsigned long val, u32 bswapmask) +{ + return val; +} + +static inline u32 fb_shifted_pixels_mask_u32(u32 index, u32 bswapmask) +{ + return FB_SHIFT_HIGH(~(u32)0, index); +} + +static inline unsigned long fb_shifted_pixels_mask_long(u32 index, u32 bswapmask) +{ + return FB_SHIFT_HIGH(~0UL, index); +} + +static inline u32 fb_compute_bswapmask(struct fb_info *info) +{ + return 0; +} + +#endif /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */ + =============================================================================== and addition of new function for full pixels swapping (aghr) =============================================================================== + +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE + +#if BITS_PER_LONG == 64 +#define REV_PIXELS_MASK1 0x5555555555555555ul +#define REV_PIXELS_MASK2 0x3333333333333333ul +#define REV_PIXELS_MASK4 0x0f0f0f0f0f0f0f0ful +#else +#define REV_PIXELS_MASK1 0x55555555ul +#define REV_PIXELS_MASK2 0x33333333ul +#define REV_PIXELS_MASK4 0x0f0f0f0ful +#endif + +static inline unsigned long fb_rev_pixels_in_long(unsigned long val, u32 bswapmask) +{ + if(bswapmask & 1) + val = comp(val >> 1, val << 1, REV_PIXELS_MASK1); + if(bswapmask & 2) + val = comp(val >> 2, val << 2, REV_PIXELS_MASK2); + if(bswapmask & 3) + val = comp(val >> 4, val << 4, REV_PIXELS_MASK4); +} =============================================================================== The additional changes in copy area are in the following patch Best wishes Pavel =============================================================================== Subject: Framebuffer copyarea function taught to fully support swapped pixel order in bytes From: Pavel Pisa <pi...@cm...> This correct case, when source and destination X coordinates difference is not multiple of pixels in byte. This is probably rare case, but this case should be supported for completeness. Reorganization of FB_READL and FB_WRITEL calls results in code size decrease for normal build without swapping support and size with support enabled is reasonable too. Signed-off-by: Pavel Pisa <pi...@cm...> drivers/video/cfbcopyarea.c | 84 ++++++++++++++++++++++++++++++-------------- 1 file changed, 59 insertions(+), 25 deletions(-) Index: linux-2.6.23-git/drivers/video/cfbcopyarea.c =================================================================== --- linux-2.6.23-git.orig/drivers/video/cfbcopyarea.c +++ linux-2.6.23-git/drivers/video/cfbcopyarea.c @@ -94,29 +94,34 @@ bitcpy(unsigned long __iomem *dst, int d FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst); } } else { + // Different alignment for source and dest unsigned long d0, d1; int m; - // Different alignment for source and dest right = shift & (bits - 1); left = -shift & (bits - 1); + bswapmask &= shift; if (dst_idx+n <= bits) { // Single destination word if (last) first &= last; + d0 = FB_READL(src); + d0 = fb_rev_pixels_in_long(d0, bswapmask); if (shift > 0) { // Single source word - FB_WRITEL( comp( FB_READL(src) >> right, FB_READL(dst), first), dst); + d0 >>= right; } else if (src_idx+n <= bits) { // Single source word - FB_WRITEL( comp(FB_READL(src) << left, FB_READL(dst), first), dst); + d0 <<= left;; } else { // 2 source words - d0 = FB_READL(src++); - d1 = FB_READL(src); - FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), first), dst); + d1 = FB_READL(src + 1); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0<<left | d1>>right; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), first), dst); } else { // Multiple destination words /** We must always remember the last value read, because in case @@ -125,25 +130,31 @@ bitcpy(unsigned long __iomem *dst, int d overlap with the current long from SRC. We store this value in 'd0'. */ d0 = FB_READL(src++); + d0 = fb_rev_pixels_in_long(d0, bswapmask); // Leading bits if (shift > 0) { // Single source word - FB_WRITEL( comp(d0 >> right, FB_READL(dst), first), dst); + d1 = d0; + d0 >>= right; dst++; n -= bits - dst_idx; } else { // 2 source words d1 = FB_READL(src++); - FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), first), dst); - d0 = d1; + d1 = fb_rev_pixels_in_long(d1, bswapmask); + + d0 = d0<<left | d1>>right; dst++; n -= bits - dst_idx; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), first), dst); + d0 = d1; // Main chunk m = n % bits; n /= bits; - while (n >= 4) { + while ((n >= 4) && !bswapmask) { d1 = FB_READL(src++); FB_WRITEL(d0 << left | d1 >> right, dst++); d0 = d1; @@ -160,7 +171,10 @@ bitcpy(unsigned long __iomem *dst, int d } while (n--) { d1 = FB_READL(src++); - FB_WRITEL(d0 << left | d1 >> right, dst++); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0 << left | d1 >> right; + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL(d0, dst++); d0 = d1; } @@ -168,12 +182,15 @@ bitcpy(unsigned long __iomem *dst, int d if (last) { if (m <= right) { // Single source word - FB_WRITEL( comp(d0 << left, FB_READL(dst), last), dst); + d0 <<= left; } else { // 2 source words d1 = FB_READL(src); - FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), last), dst); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0<<left | d1>>right; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), last), dst); } } } @@ -247,24 +264,32 @@ bitcpy_rev(unsigned long __iomem *dst, i } } else { // Different alignment for source and dest + unsigned long d0, d1; + int m; int const left = -shift & (bits-1); int const right = shift & (bits-1); + bswapmask &= shift; if ((unsigned long)dst_idx+1 >= n) { // Single destination word if (last) first &= last; + d0 = FB_READL(src); if (shift < 0) { // Single source word - FB_WRITEL( comp( FB_READL(src)<<left, FB_READL(dst), first), dst); + d0 <<= left; } else if (1+(unsigned long)src_idx >= n) { // Single source word - FB_WRITEL( comp( FB_READL(src)>>right, FB_READL(dst), first), dst); + d0 >>= right; } else { // 2 source words - FB_WRITEL( comp( (FB_READL(src)>>right | FB_READL(src-1)<<left), FB_READL(dst), first), dst); + d1 = FB_READL(src - 1); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0>>right | d1<<left; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), first), dst); } else { // Multiple destination words /** We must always remember the last value read, because in case @@ -272,27 +297,30 @@ bitcpy_rev(unsigned long __iomem *dst, i 1bpp), we always collect one full long for DST and that might overlap with the current long from SRC. We store this value in 'd0'. */ - unsigned long d0, d1; - int m; d0 = FB_READL(src--); + d0 = fb_rev_pixels_in_long(d0, bswapmask); // Leading bits if (shift < 0) { // Single source word - FB_WRITEL( comp( (d0 << left), FB_READL(dst), first), dst); + d1 = d0; + d0 <<= left; } else { // 2 source words d1 = FB_READL(src--); - FB_WRITEL( comp( (d0>>right | d1<<left), FB_READL(dst), first), dst); - d0 = d1; + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0>>right | d1<<left; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), first), dst); + d0 = d1; dst--; n -= dst_idx+1; // Main chunk m = n % bits; n /= bits; - while (n >= 4) { + while ((n >= 4) && !bswapmask) { d1 = FB_READL(src--); FB_WRITEL(d0 >> right | d1 << left, dst--); d0 = d1; @@ -309,7 +337,10 @@ bitcpy_rev(unsigned long __iomem *dst, i } while (n--) { d1 = FB_READL(src--); - FB_WRITEL(d0 >> right | d1 << left, dst--); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0 >> right | d1 << left; + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL(d0, dst--); d0 = d1; } @@ -317,12 +348,15 @@ bitcpy_rev(unsigned long __iomem *dst, i if (last) { if (m <= left) { // Single source word - FB_WRITEL( comp(d0 >> right, FB_READL(dst), last), dst); + d0 >>= right; } else { // 2 source words d1 = FB_READL(src); - FB_WRITEL( comp(d0>>right | d1<<left, FB_READL(dst), last), dst); + d1 = fb_rev_pixels_in_long(d1, bswapmask); + d0 = d0>>right | d1<<left; } + d0 = fb_rev_pixels_in_long(d0, bswapmask); + FB_WRITEL( comp(d0, FB_READL(dst), last), dst); } } } |
From: Pavel P. <pi...@cm...> - 2007-09-01 13:47:50
|
On Friday 31 August 2007 13:03, Antonino A. Daplas wrote: > > May it be - this would make some not so nice effects > > for cursor when some strange font width is used. > > You basically have 3 choices: > > 1. Fix copyarea/fillrect > 2. Accept that the console may become corrupted if a non-8x16 font is > loaded. > 3. Tell the console layer that it can only handle multiple-of-8 wide > fonts Hello Tony and Geert, I have updated patch to support all above operations. The feature is disabled at compile time if CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set. I have added simplified inline functions variants for this case to help compiler to optimize code. The compiler should be able to optimize code to same instructions as before this change. If option is enabled, then actual swapping is controlled by FB_NONSTD_REV_PIX_IN_B option in variable informations. I have tested code on our target with fbcon=font:ProFont6x11 and 7x14 and I see no glitches, but more precise review by more people is probably necessary mainly to check, that there is no regression for regular use. Is there some userspace tests which invoke copyarea, fillrectangles and blits with different parameters? Thanks for help Pavel ============================================================================= The next patch allows generic frame-buffer code to correctly write texts and blit images for 1, 2 and 4 bit per pixel frame-buffer organizations when pixels in bytes are organized to in opposite order than bytes in long type. Overhead should be reasonable. If option is not selected, than compiler should eliminate completely all overhead. Signed-off-by: Pavel Pisa <pi...@cm...> drivers/video/Kconfig | 10 +++++ drivers/video/cfbcopyarea.c | 17 +++++---- drivers/video/cfbfillrect.c | 20 ++++++----- drivers/video/cfbimgblt.c | 17 +++++---- drivers/video/fb_draw.h | 79 ++++++++++++++++++++++++++++++++++++++++++++ include/linux/fb.h | 1 6 files changed, 121 insertions(+), 23 deletions(-) Index: linux-2.6.23-git/drivers/video/cfbimgblt.c =================================================================== --- linux-2.6.23-git.orig/drivers/video/cfbimgblt.c +++ linux-2.6.23-git/drivers/video/cfbimgblt.c @@ -33,6 +33,7 @@ #include <linux/string.h> #include <linux/fb.h> #include <asm/types.h> +#include "fb_draw.h" #define DEBUG @@ -87,6 +88,7 @@ static inline void color_imageblit(const u32 null_bits = 32 - bpp; u32 *palette = (u32 *) p->pseudo_palette; const u8 *src = image->data; + u32 bswapmask = fb_compute_bswapmask(p); dst2 = (u32 __iomem *) dst1; for (i = image->height; i--; ) { @@ -96,7 +98,7 @@ static inline void color_imageblit(const val = 0; if (start_index) { - u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0, start_index)); + u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask); val = FB_READL(dst) & start_mask; shift = start_index; } @@ -107,7 +109,7 @@ static inline void color_imageblit(const else color = *src; color <<= FB_LEFT_POS(bpp); - val |= FB_SHIFT_HIGH(color, shift); + val |= FB_SHIFT_HIGH(color, shift ^ bswapmask); if (shift >= null_bits) { FB_WRITEL(val, dst++); @@ -119,7 +121,7 @@ static inline void color_imageblit(const src++; } if (shift) { - u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift); + u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask); FB_WRITEL((FB_READL(dst) & end_mask) | val, dst); } @@ -147,7 +149,8 @@ static inline void slow_imageblit(const u32 spitch = (image->width+7)/8; const u8 *src = image->data, *s; u32 i, j, l; - + u32 bswapmask = fb_compute_bswapmask(p); + dst2 = (u32 __iomem *) dst1; fgcolor <<= FB_LEFT_POS(bpp); bgcolor <<= FB_LEFT_POS(bpp); @@ -161,7 +164,7 @@ static inline void slow_imageblit(const /* write leading bits */ if (start_index) { - u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,start_index)); + u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask); val = FB_READL(dst) & start_mask; shift = start_index; } @@ -169,7 +172,7 @@ static inline void slow_imageblit(const while (j--) { l--; color = (*s & (1 << l)) ? fgcolor : bgcolor; - val |= FB_SHIFT_HIGH(color, shift); + val |= FB_SHIFT_HIGH(color, shift ^ bswapmask); /* Did the bitshift spill bits to the next long? */ if (shift >= null_bits) { @@ -184,7 +187,7 @@ static inline void slow_imageblit(const /* write trailing bits */ if (shift) { - u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift); + u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask); FB_WRITEL((FB_READL(dst) & end_mask) | val, dst); } Index: linux-2.6.23-git/drivers/video/Kconfig =================================================================== --- linux-2.6.23-git.orig/drivers/video/Kconfig +++ linux-2.6.23-git/drivers/video/Kconfig @@ -103,6 +103,15 @@ config FB_CFB_IMAGEBLIT blitting. This is used by drivers that don't provide their own (accelerated) version. +config FB_CFB_REV_PIXELS_IN_BYTE + bool + depends on FB + default n + ---help--- + Allow generic frame-buffer functions to work on displays with 1, 2 and 4 + bits per pixel depths which has opposite order of pixels in byte order + to bytes in long order. + config FB_SYS_FILLRECT tristate depends on FB @@ -348,6 +357,7 @@ config FB_IMX select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT + select FB_CFB_REV_PIXELS_IN_BYTE config FB_CYBER2000 tristate "CyberPro 2000/2010/5000 support" Index: linux-2.6.23-git/drivers/video/fb_draw.h =================================================================== --- linux-2.6.23-git.orig/drivers/video/fb_draw.h +++ linux-2.6.23-git/drivers/video/fb_draw.h @@ -2,6 +2,7 @@ #define _FB_DRAW_H #include <asm/types.h> +#include <linux/fb.h> /* * Compose two values, using a bitmask as decision value @@ -69,4 +70,82 @@ pixel_to_pat( u32 bpp, u32 pixel) } } #endif + +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE + +static inline u32 fb_shifted_pixels_mask_u32(u32 index, u32 bswapmask) +{ + u32 mask; + + if (!bswapmask) { + mask = FB_SHIFT_HIGH(~(u32)0, index); + } else { + mask = 0xff << FB_LEFT_POS(8); + mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask; + mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask)); +#if defined(__i386__) || defined(__x86_64__) + /* Shift argument is limited to 0 - 31 on x86 based CPU's */ + if(index + bswapmask < 32) +#endif + mask |= FB_SHIFT_HIGH(~(u32)0, + (index + bswapmask) & ~(bswapmask)); + } + return mask; +} + +static inline unsigned long fb_shifted_pixels_mask_long(u32 index, u32 bswapmask) +{ + unsigned long mask; + + if (!bswapmask) { + mask = FB_SHIFT_HIGH(~0UL, index); + } else { + mask = 0xff << FB_LEFT_POS(8); + mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask; + mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask)); +#if defined(__i386__) || defined(__x86_64__) + /* Shift argument is limited to 0 - 31 on x86 based CPU's */ + if(index + bswapmask < BITS_PER_LONG) +#endif + mask |= FB_SHIFT_HIGH(~0UL, + (index + bswapmask) & ~(bswapmask)); + } + return mask; +} + + +static inline u32 fb_compute_bswapmask(struct fb_info *info) +{ + u32 bswapmask = 0; + unsigned bpp = info->var.bits_per_pixel; + + if ((bpp < 8) && (info->var.nonstd & FB_NONSTD_REV_PIX_IN_B)) { + /* + * Reversed order of pixel layout in bytes + * works only for 1, 2 and 4 bpp + */ + bswapmask = 7 - bpp + 1; + } + return bswapmask; +} + +#else /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */ + +static inline u32 fb_shifted_pixels_mask_u32(index, bswapmask) +{ + return FB_SHIFT_HIGH(~(u32)0, _indx); +} + +static inline unsigned long fb_shifted_pixels_mask_long(index, bswapmask) +{ + return FB_SHIFT_HIGH(~0UL, _indx); +} + +static inline u32 fb_compute_bswapmask(struct fb_info *info) +{ + return 0; +} + +#endif /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */ + #endif /* FB_DRAW_H */ Index: linux-2.6.23-git/drivers/video/cfbfillrect.c =================================================================== --- linux-2.6.23-git.orig/drivers/video/cfbfillrect.c +++ linux-2.6.23-git/drivers/video/cfbfillrect.c @@ -36,15 +36,16 @@ */ static void -bitfill_aligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat, unsigned n, int bits) +bitfill_aligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat, + unsigned n, int bits, u32 bswapmask) { unsigned long first, last; if (!n) return; - first = FB_SHIFT_HIGH(~0UL, dst_idx); - last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits)); + first = fb_shifted_pixels_mask_long(dst_idx, bswapmask); + last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask); if (dst_idx+n <= bits) { // Single word @@ -146,7 +147,8 @@ bitfill_unaligned(unsigned long __iomem * Aligned pattern invert using 32/64-bit memory accesses */ static void -bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat, unsigned n, int bits) +bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat, + unsigned n, int bits, u32 bswapmask) { unsigned long val = pat, dat; unsigned long first, last; @@ -154,8 +156,8 @@ bitfill_aligned_rev(unsigned long __iome if (!n) return; - first = FB_SHIFT_HIGH(~0UL, dst_idx); - last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits)); + first = fb_shifted_pixels_mask_long(dst_idx, bswapmask); + last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask); if (dst_idx+n <= bits) { // Single word @@ -303,8 +305,10 @@ void cfb_fillrect(struct fb_info *p, con if (p->fbops->fb_sync) p->fbops->fb_sync(p); if (!left) { + u32 bswapmask = fb_compute_bswapmask(p); void (*fill_op32)(unsigned long __iomem *dst, int dst_idx, - unsigned long pat, unsigned n, int bits) = NULL; + unsigned long pat, unsigned n, int bits, + u32 bswapmask) = NULL; switch (rect->rop) { case ROP_XOR: @@ -321,7 +325,7 @@ void cfb_fillrect(struct fb_info *p, con while (height--) { dst += dst_idx >> (ffs(bits) - 1); dst_idx &= (bits - 1); - fill_op32(dst, dst_idx, pat, width*bpp, bits); + fill_op32(dst, dst_idx, pat, width*bpp, bits, bswapmask); dst_idx += p->fix.line_length*8; } } else { Index: linux-2.6.23-git/drivers/video/cfbcopyarea.c =================================================================== --- linux-2.6.23-git.orig/drivers/video/cfbcopyarea.c +++ linux-2.6.23-git/drivers/video/cfbcopyarea.c @@ -45,14 +45,14 @@ static void bitcpy(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src, - int src_idx, int bits, unsigned n) + int src_idx, int bits, unsigned n, u32 bswapmask) { unsigned long first, last; int const shift = dst_idx-src_idx; int left, right; - first = FB_SHIFT_HIGH(~0UL, dst_idx); - last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits)); + first = fb_shifted_pixels_mask_long(dst_idx, bswapmask); + last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask); if (!shift) { // Same alignment for source and dest @@ -185,7 +185,7 @@ bitcpy(unsigned long __iomem *dst, int d static void bitcpy_rev(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src, - int src_idx, int bits, unsigned n) + int src_idx, int bits, unsigned n, u32 bswapmask) { unsigned long first, last; int shift; @@ -203,8 +203,8 @@ bitcpy_rev(unsigned long __iomem *dst, i shift = dst_idx-src_idx; - first = FB_SHIFT_LOW(~0UL, bits - 1 - dst_idx); - last = ~(FB_SHIFT_LOW(~0UL, bits - 1 - ((dst_idx-n) % bits))); + first = fb_shifted_pixels_mask_long(bits - 1 - dst_idx, bswapmask); + last = ~fb_shifted_pixels_mask_long(bits - 1 - ((dst_idx-n) % bits), bswapmask); if (!shift) { // Same alignment for source and dest @@ -336,6 +336,7 @@ void cfb_copyarea(struct fb_info *p, con unsigned long __iomem *dst = NULL, *src = NULL; int bits = BITS_PER_LONG, bytes = bits >> 3; int dst_idx = 0, src_idx = 0, rev_copy = 0; + u32 bswapmask = fb_compute_bswapmask(p); if (p->state != FBINFO_STATE_RUNNING) return; @@ -368,7 +369,7 @@ void cfb_copyarea(struct fb_info *p, con src += src_idx >> (ffs(bits) - 1); src_idx &= (bytes - 1); bitcpy_rev(dst, dst_idx, src, src_idx, bits, - width*p->var.bits_per_pixel); + width*p->var.bits_per_pixel, bswapmask); } } else { while (height--) { @@ -377,7 +378,7 @@ void cfb_copyarea(struct fb_info *p, con src += src_idx >> (ffs(bits) - 1); src_idx &= (bytes - 1); bitcpy(dst, dst_idx, src, src_idx, bits, - width*p->var.bits_per_pixel); + width*p->var.bits_per_pixel, bswapmask); dst_idx += bits_per_line; src_idx += bits_per_line; } Index: linux-2.6.23-git/include/linux/fb.h =================================================================== --- linux-2.6.23-git.orig/include/linux/fb.h +++ linux-2.6.23-git/include/linux/fb.h @@ -180,6 +180,7 @@ struct fb_bitfield { }; #define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM) */ +#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is reversed */ #define FB_ACTIVATE_NOW 0 /* set values immediately (or vbl)*/ #define FB_ACTIVATE_NXTOPEN 1 /* activate on next open */ |
From: James L. <ja...@ak...> - 2007-09-01 03:16:45
|
The colors that you see in an ncurses application are based on an (any OS) ANSI color terminal. There is a specific set of 16 colors and their associated escape sequences that set any ANSI compliant terminal's foreground and background colors for each character cell. BUT, there is nothing that says that you couldn't write your own layer of abstraction / interpretation that could render its own bitmapped fonts in either high or true color. Take a look at this... http://www.akrobiz.com/ezfb EZFB version 10.0 is done and awaiting release. It's WAY faster than any previous version. James. :o) ----- Original Message ----- From: "gavron" <cg...@op...> To: <lin...@li...> Sent: Friday, August 31, 2007 7:47 PM Subject: [Linux-fbdev-users] How many colors? > I was wondering if there was any way I could get 256 colors - or more .. > when running ncurses applications on a linux console with the frame > buffer enabled. There are a few applications that greatly benefit from > this enhancement such as mutt, vim, ELinks .. and I was wondering if > this is possible when not running in an xterm under xorg. > > Maybe I need to run a terminal emulator that supports more than 16 > colors rather than the standard linux console? > > Rather confused about these aspects, so any pointers to doc or a > discussion of these capabilities would be very welcome. > > Thank you! > > gavron > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Linux-fbdev-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > |
From: Antonino A. D. <ad...@gm...> - 2007-09-01 00:58:03
|
On Fri, 2007-08-31 at 19:47 -0400, gavron wrote: > I was wondering if there was any way I could get 256 colors - or more .. > when running ncurses applications on a linux console with the frame > buffer enabled. There are a few applications that greatly benefit from > this enhancement such as mutt, vim, ELinks .. and I was wondering if > this is possible when not running in an xterm under xorg. No it's not possible under the linux console. The linux console supports 16-colors only and changing this to support 256-colors will entail a massive rewrite of the console code. Even a 32bpp framebuffer is stuck with a 16-color console. > > Maybe I need to run a terminal emulator that supports more than 16 > colors rather than the standard linux console? > Yes, you will basically need a new terminal emulator, one that basically re-implements the kernel console code. Tony |
From: gavron <cg...@op...> - 2007-08-31 23:47:46
|
I was wondering if there was any way I could get 256 colors - or more .. when running ncurses applications on a linux console with the frame buffer enabled. There are a few applications that greatly benefit from this enhancement such as mutt, vim, ELinks .. and I was wondering if this is possible when not running in an xterm under xorg. Maybe I need to run a terminal emulator that supports more than 16 colors rather than the standard linux console? Rather confused about these aspects, so any pointers to doc or a discussion of these capabilities would be very welcome. Thank you! gavron |
From: Antonino A. D. <ad...@gm...> - 2007-08-31 11:03:41
|
On Fri, 2007-08-31 at 03:29 +0200, Pavel Pisa wrote: > Hello Antonino, > > The notice has been about rectangle fill and copy, which are in different > files. I am not sure if they are used for console such way that it would > could mean problems. The screen scroll should not be problem with > swapped pixels in bytes. Any operation on whole lines should not be problem fillrect is used by the vt layer to erase characters and by fbcon to clear the screen margins in case the display width is greater than the font width * screen columns. copyarea, on the other hand, is used by the vt layer to insert or delete a character, or by fbcon to scroll the screen if the scrolling mode is SCROLL_MOVE. > too. Only problem is if they are used for real moves with odd/unaligned > X coordinates. If you use non-8x16 fonts, it's indeed possible to have an X coordinate which is unaligned. Example, erase the 2nd 7x14 character using fillrect. At 4 bpp, the origin of the 2nd character is at the 28th bit. > May it be - this would make some not so nice effects > for cursor when some strange font width is used. > You basically have 3 choices: 1. Fix copyarea/fillrect 2. Accept that the console may become corrupted if a non-8x16 font is loaded. 3. Tell the console layer that it can only handle multiple-of-8 wide fonts Tony |
From: Geert U. <ge...@li...> - 2007-08-31 09:24:09
|
On Fri, 31 Aug 2007, Pavel Pisa wrote: > Even if swapping support is enabled, I would like to allow control > actual swapping through some field in mode information and propagated > to > struct fb_info->var or fix > struct fb_var_screeninfo > struct fb_fix_screeninfo > > have you idea for name and correct place for this SWAP_PIXELS_IN_BYTE > bit/flag. The proper place for a driver to advertise this (for the current mode) is fb_fix_screeninfo.type. We can add a new type, e.g. FB_TYPE_PACKED_PIXELS_SWAP, for non-native ordering of pixels. To control byte swapping when setting the video mode, we could use fb_var_screeninfo.nonstd and a new FB_NONST_* value. 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 A. D. <ad...@gm...> - 2007-08-31 02:41:58
|
On Thu, 2007-08-30 at 19:28 +0200, Pavel Pisa wrote: > Hello Antonino and others, > > the generic BLT functions binds unconditionally byte endian with > pixels in byte order. Unfortunately there are more devices which > can work only in unsupported pixels layout. One of them is > Freescale MX1 found on PiMX1 board when used in 4 bpp monochromatic > mode. Curiously Microwindows and Qt-embedded take this layout > as default one and works without problems. Linux console output > is funny on the other hand. > > I would like to know, if suggested solution is at least remotely > acceptable for mainline in future. It would be probably good > to add some flag to struct fb_info.var which would enable swapping. > This would allow code to be generic even if > CONFIG_FB_CFB_REV_PIXELS_IN_BYTE > is selected. If option is disabled, then there should be > zero overhead, all abundant code should be removed by compiller. > > If this is acceptable, I try to add support for rectangle > and copy in future, but this do not seems to be critical for > console. Normal fonts widths are multiples of 8 so problems > are not seen. > > Best wishes > > Pavel Pisa > > =================================================================== > > The next patch allows generic frame-buffer code to correctly write texts > and blit images for 1, 2 and 4 bit per pixel frame-buffer organizations > when pixels in bytes are organized to in opposite order than bytes > in long type. > > Overhead should be reasonable. If option is not selected, than compiler > should eliminate completely all overhead. > > Signed-off-by: Pavel Pisa <pi...@cm...> > > drivers/video/Kconfig | 10 +++++++++ > drivers/video/cfbimgblt.c | 48 ++++++++++++++++++++++++++++++++++++++++------ > 2 files changed, 52 insertions(+), 6 deletions(-) > > Index: linux-2.6.23-git/drivers/video/cfbimgblt.c > =================================================================== > --- linux-2.6.23-git.orig/drivers/video/cfbimgblt.c > +++ linux-2.6.23-git/drivers/video/cfbimgblt.c > @@ -75,6 +75,20 @@ static const u32 cfb_tab32[] = { > #define FB_WRITEL fb_writel > #define FB_READL fb_readl > > +#define FB_SHIFTED_PIXELS_MASK(index, bswapmask) ({ \ > + u32 _m; \ > + u32 _indx = (index); \ > + if (!bswapmask) { \ > + _m = FB_SHIFT_HIGH(~(u32)0, _indx); \ > + } else { \ > + _m = 0xff << FB_LEFT_POS(8); \ > + _m = FB_SHIFT_LOW(_m, _indx & (bswapmask)) & _m; \ > + _m = FB_SHIFT_HIGH(_m, _indx & ~(bswapmask)); \ > + _m |= FB_SHIFT_HIGH(~(u32)0, (_indx + bswapmask) & ~(bswapmask)); \ > + } \ > + _m; \ > + }) > + If you can convert the above to to an inline function instead of a macro, that would be best. > + > +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE > + if (bpp < 8) { > + /* > + * Reversed order of pixel layout in bytes > + * works only for 1, 2 and 4 bpp > + */ > + bswapmask = 7 - bpp + 1; > + } > +#endif And this too, if you can create a small inline function and move out the #ifdef out of the function, that would be nice also. Tony |
From: Pavel P. <pi...@cm...> - 2007-08-31 01:30:08
|
Hello Antonino, thanks for fast reply. On Friday 31 August 2007 02:43, Antonino A. Daplas wrote: > > > > +#define FB_SHIFTED_PIXELS_MASK(index, bswapmask) ({ \ > > + u32 _m; \ > > + u32 _indx = (index); \ > > + if (!bswapmask) { \ > > + _m = FB_SHIFT_HIGH(~(u32)0, _indx); \ > > + } else { \ > > + _m = 0xff << FB_LEFT_POS(8); \ > > + _m = FB_SHIFT_LOW(_m, _indx & (bswapmask)) & _m; \ > > + _m = FB_SHIFT_HIGH(_m, _indx & ~(bswapmask)); \ > > + _m |= FB_SHIFT_HIGH(~(u32)0, (_indx + bswapmask) & ~(bswapmask)); \ > > + } \ > > + _m; \ > > + }) > > + > > If you can convert the above to to an inline function instead of a > macro, that would be best. I would prefer that as inline too. I have not been sure only, if all GCC versions would optimize that equally well in such case. When bswapmask is constantly zero, the else part should be eliminated. > > + > > +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE > > + if (bpp < 8) { > > + /* > > + * Reversed order of pixel layout in bytes > > + * works only for 1, 2 and 4 bpp > > + */ > > + bswapmask = 7 - bpp + 1; > > + } > > +#endif > > And this too, if you can create a small inline function and move out the > #ifdef out of the function, that would be nice also. I am not sure there if this is not better documenting what is going about there. But if you prefer to solve that as inline I change it. Even if swapping support is enabled, I would like to allow control actual swapping through some field in mode information and propagated to struct fb_info->var or fix struct fb_var_screeninfo struct fb_fix_screeninfo have you idea for name and correct place for this SWAP_PIXELS_IN_BYTE bit/flag. > > If this is acceptable, I try to add support for rectangle > > and copy in future, but this do not seems to be critical for > > console. Normal fonts widths are multiples of 8 so problems > > are not seen. > > BTW, if this driver will support only multiples of 8 font widths at less > than 8bpp, you might want to advertise this limitation to the console, > so it won't accidentally load an incompatible font. The pertinent > fields and function would be info->pixmap.blit_x and fb_get_caps(). > > An example would be s3fb. In tileblitting/text mode, it can only handle > certain fonts (specifically 8x16 fonts) > > See s3fb.c and svgalib.c in drivers/video. The extended cfbimgblt functions should fully handle all previous modes + 1, 2, 4 bit bpp modes with swapped pixels in byte. There should not be any problem for arbitrarily images/fonts sizes. It cannot support 12 or 6 bit bpp with swapped pixels in bytes. I think, that LE to BE conversions are only solutions for that. The notice has been about rectangle fill and copy, which are in different files. I am not sure if they are used for console such way that it would could mean problems. The screen scroll should not be problem with swapped pixels in bytes. Any operation on whole lines should not be problem too. Only problem is if they are used for real moves with odd/unaligned X coordinates. May it be - this would make some not so nice effects for cursor when some strange font width is used. Best wishes Pavel |
From: Antonino A. D. <ad...@gm...> - 2007-08-31 01:04:52
|
On Thu, 2007-08-30 at 19:28 +0200, Pavel Pisa wrote: > Hello Antonino and others, > > If this is acceptable, I try to add support for rectangle > and copy in future, but this do not seems to be critical for > console. Normal fonts widths are multiples of 8 so problems > are not seen. > BTW, if this driver will support only multiples of 8 font widths at less than 8bpp, you might want to advertise this limitation to the console, so it won't accidentally load an incompatible font. The pertinent fields and function would be info->pixmap.blit_x and fb_get_caps(). An example would be s3fb. In tileblitting/text mode, it can only handle certain fonts (specifically 8x16 fonts) See s3fb.c and svgalib.c in drivers/video. Tony |
From: Pavel P. <pi...@cm...> - 2007-08-30 17:28:29
|
Hello Antonino and others, the generic BLT functions binds unconditionally byte endian with pixels in byte order. Unfortunately there are more devices which can work only in unsupported pixels layout. One of them is Freescale MX1 found on PiMX1 board when used in 4 bpp monochromatic mode. Curiously Microwindows and Qt-embedded take this layout as default one and works without problems. Linux console output is funny on the other hand. I would like to know, if suggested solution is at least remotely acceptable for mainline in future. It would be probably good to add some flag to struct fb_info.var which would enable swapping. This would allow code to be generic even if CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is selected. If option is disabled, then there should be zero overhead, all abundant code should be removed by compiller. If this is acceptable, I try to add support for rectangle and copy in future, but this do not seems to be critical for console. Normal fonts widths are multiples of 8 so problems are not seen. Best wishes Pavel Pisa =================================================================== The next patch allows generic frame-buffer code to correctly write texts and blit images for 1, 2 and 4 bit per pixel frame-buffer organizations when pixels in bytes are organized to in opposite order than bytes in long type. Overhead should be reasonable. If option is not selected, than compiler should eliminate completely all overhead. Signed-off-by: Pavel Pisa <pi...@cm...> drivers/video/Kconfig | 10 +++++++++ drivers/video/cfbimgblt.c | 48 ++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 52 insertions(+), 6 deletions(-) Index: linux-2.6.23-git/drivers/video/cfbimgblt.c =================================================================== --- linux-2.6.23-git.orig/drivers/video/cfbimgblt.c +++ linux-2.6.23-git/drivers/video/cfbimgblt.c @@ -75,6 +75,20 @@ static const u32 cfb_tab32[] = { #define FB_WRITEL fb_writel #define FB_READL fb_readl +#define FB_SHIFTED_PIXELS_MASK(index, bswapmask) ({ \ + u32 _m; \ + u32 _indx = (index); \ + if (!bswapmask) { \ + _m = FB_SHIFT_HIGH(~(u32)0, _indx); \ + } else { \ + _m = 0xff << FB_LEFT_POS(8); \ + _m = FB_SHIFT_LOW(_m, _indx & (bswapmask)) & _m; \ + _m = FB_SHIFT_HIGH(_m, _indx & ~(bswapmask)); \ + _m |= FB_SHIFT_HIGH(~(u32)0, (_indx + bswapmask) & ~(bswapmask)); \ + } \ + _m; \ + }) + static inline void color_imageblit(const struct fb_image *image, struct fb_info *p, u8 __iomem *dst1, u32 start_index, @@ -87,6 +101,17 @@ static inline void color_imageblit(const u32 null_bits = 32 - bpp; u32 *palette = (u32 *) p->pseudo_palette; const u8 *src = image->data; + u32 bswapmask = 0; + +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE + if (bpp < 8) { + /* + * Reversed order of pixel layout in bytes + * works only for 1, 2 and 4 bpp + */ + bswapmask = 7 - bpp + 1; + } +#endif dst2 = (u32 __iomem *) dst1; for (i = image->height; i--; ) { @@ -96,7 +121,7 @@ static inline void color_imageblit(const val = 0; if (start_index) { - u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0, start_index)); + u32 start_mask = ~FB_SHIFTED_PIXELS_MASK(start_index, bswapmask); val = FB_READL(dst) & start_mask; shift = start_index; } @@ -107,7 +132,7 @@ static inline void color_imageblit(const else color = *src; color <<= FB_LEFT_POS(bpp); - val |= FB_SHIFT_HIGH(color, shift); + val |= FB_SHIFT_HIGH(color, shift ^ bswapmask); if (shift >= null_bits) { FB_WRITEL(val, dst++); @@ -119,7 +144,7 @@ static inline void color_imageblit(const src++; } if (shift) { - u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift); + u32 end_mask = FB_SHIFTED_PIXELS_MASK(shift, bswapmask); FB_WRITEL((FB_READL(dst) & end_mask) | val, dst); } @@ -147,6 +172,17 @@ static inline void slow_imageblit(const u32 spitch = (image->width+7)/8; const u8 *src = image->data, *s; u32 i, j, l; + u32 bswapmask = 0; + +#ifdef CONFIG_FB_CFB_REV_PIXELS_IN_BYTE + if (bpp < 8) { + /* + * Reversed order of pixel layout in bytes + * works only for 1, 2 and 4 bpp + */ + bswapmask = 7 - bpp + 1; + } +#endif dst2 = (u32 __iomem *) dst1; fgcolor <<= FB_LEFT_POS(bpp); @@ -161,7 +197,7 @@ static inline void slow_imageblit(const /* write leading bits */ if (start_index) { - u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,start_index)); + u32 start_mask = ~FB_SHIFTED_PIXELS_MASK(start_index, bswapmask); val = FB_READL(dst) & start_mask; shift = start_index; } @@ -169,7 +205,7 @@ static inline void slow_imageblit(const while (j--) { l--; color = (*s & (1 << l)) ? fgcolor : bgcolor; - val |= FB_SHIFT_HIGH(color, shift); + val |= FB_SHIFT_HIGH(color, shift ^ bswapmask); /* Did the bitshift spill bits to the next long? */ if (shift >= null_bits) { @@ -184,7 +220,7 @@ static inline void slow_imageblit(const /* write trailing bits */ if (shift) { - u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift); + u32 end_mask = FB_SHIFTED_PIXELS_MASK(shift, bswapmask); FB_WRITEL((FB_READL(dst) & end_mask) | val, dst); } Index: linux-2.6.23-git/drivers/video/Kconfig =================================================================== --- linux-2.6.23-git.orig/drivers/video/Kconfig +++ linux-2.6.23-git/drivers/video/Kconfig @@ -103,6 +103,15 @@ config FB_CFB_IMAGEBLIT blitting. This is used by drivers that don't provide their own (accelerated) version. +config FB_CFB_REV_PIXELS_IN_BYTE + bool + depends on FB + default n + ---help--- + Allow generic frame-buffer functions to work on displays with 1, 2 and 4 + bits per pixel depths which has opposite order of pixels in byte order + to bytes in long order. + config FB_SYS_FILLRECT tristate depends on FB @@ -348,6 +357,7 @@ config FB_IMX select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT + select FB_CFB_REV_PIXELS_IN_BYTE config FB_CYBER2000 tristate "CyberPro 2000/2010/5000 support" |
From: William P. <wil...@gm...> - 2007-08-20 00:46:23
|
Ok, hey all again, This time I'm running vesafb (not vesafb-tng). Again, I can suspend properly, and it sort of resumes. However, I now have weird X usage on restarting. X decides to chew up one whole core, but this only occurs after a suspend. I tried attaching strace to the running X session, but that crashed out my whole X server. Well, froze it at least. I could still power the machine off via the power button. As in, it cleanly shut down, so the kernel didn't hang or anything. Anyway, I'm not really sure what causes this. It only happens after suspending, which is why I thought I'd try this list again, incase anyone has seen anything like this before. If no one has any ideas on what I could look at, I might try to see if I can find some xorg people to give me pointers. Thanks again William |
From: Antonino A. D. <ad...@gm...> - 2007-08-19 18:56:19
|
On Sun, 2007-08-19 at 20:28 +1000, William Pettersson wrote: > Hey list, > I've got a new Dell laptop, with an Nvidia 8400GS video card. I can > suspend to RAM fine, and waking up "works". However, when waking up, > the [vesafb] process starts hogging 100% of one of the cores (core2duo). > > I've tried attaching strace to the vesafb process, but since it's a > kernel thing (I assume), it doesn't print anything. I've tried > Alt+SysRq+T, but that doesn't show any stack trace for vesafb for some > reason. The only "interesting" thing that I've found is the following, > in dmesg: > Just after/during a suspend: > vesafb: BUG, returned from vm86 with 0 (EIP: 0xc7e9b) > vesafb: mode switch failed (eax: 0x0) > > While trying to shut down after a suspend (doesn't print if I don't > suspend, just shutdown): > vesafb: BUG, returned from vm86 with 0 (EIP: 0xc18b2) > vesafb: mode switch failed (eax: 0x4f02) > > Can anyone clue me in on how to best debug this? It's essentially > leaving me one core down after a suspend, which is very annoying to say > the least. > You're probably using vesafb-tng, not the vanilla vesafb. vesafb-tng is maintained outside the kernel tree, so you have to ask for help somewhere. Tony |
From: William P. <wil...@gm...> - 2007-08-19 10:28:13
|
Hey list, I've got a new Dell laptop, with an Nvidia 8400GS video card. I can suspend to RAM fine, and waking up "works". However, when waking up, the [vesafb] process starts hogging 100% of one of the cores (core2duo). I've tried attaching strace to the vesafb process, but since it's a kernel thing (I assume), it doesn't print anything. I've tried Alt+SysRq+T, but that doesn't show any stack trace for vesafb for some reason. The only "interesting" thing that I've found is the following, in dmesg: Just after/during a suspend: vesafb: BUG, returned from vm86 with 0 (EIP: 0xc7e9b) vesafb: mode switch failed (eax: 0x0) While trying to shut down after a suspend (doesn't print if I don't suspend, just shutdown): vesafb: BUG, returned from vm86 with 0 (EIP: 0xc18b2) vesafb: mode switch failed (eax: 0x4f02) Can anyone clue me in on how to best debug this? It's essentially leaving me one core down after a suspend, which is very annoying to say the least. William |
From: William P. <wil...@gm...> - 2007-08-18 12:59:30
|
Hey list, I've got a new Dell laptop, with an Nvidia 8400GS video card. I can suspend to RAM fine, and waking up "works". However, when waking up, the [vesafb] process starts hogging 100% of one of the cores (core2duo). I've tried attaching strace to the vesafb process, but since it's a kernel thing (I assume), it doesn't print anything. I've tried Alt+SysRq+T, but that doesn't show any stack trace for vesafb for some reason. Can anyone clue me in on how to best debug this? It's essentially leaving me one core down after a suspend, which is very annoying. William |
From: p <p...@jc...> - 2007-08-01 19:24:32
|
Are there any known problems with an Ati Xpress 200M, since I can load the module and fbcon or anything else but the screen constantly keeps being black. Cheers Philipp Goins Paul schrieb: >> Ah, okay, this particular chipset was just added to radeonfb a week ago. >> Apply this commit: >> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c >> > >> >> Tony >> > > Thanks for the info, Tony. Unfortunately this does not yet solve the > issue. The good news is that the module now gives me an error on > modprobe. This is what I get: > > ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 17 (level, low) -> IRQ 22 > radeonfb (0000:01:05.0): cannot map FB > radeonfb: probe of 0000:01:05.0 failed with error -5 > > If I rmmod and try again, the error repeats, excluding the first line > above. > > I've tried this both on my 2.6.21 kernel I was using before as well as > a newly compiled 2.6.22-2 kernel, both after applying the patch > specified. Same error. So... any ideas? > > Attached are update-to-date config files, dmesg, ls /sys/bus/pci/..., > etc., in case they're needed. Thanks again. > > - Paul > > _________________________________________________________________ > 熱いライブ映像が無料!BON JOVI、RED HOT CHILI PEPPERS、LINKIN PARK他 > http://liveearth.jp.msn.com/ > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Linux-fbdev-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users > |
From: Goins P. <ast...@ho...> - 2007-07-30 05:15:25
|
>Ah, okay, this particular chipset was just added to radeonfb a week ago. >Apply this commit: > >http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c > >Tony > Thanks for the info, Tony. Unfortunately this does not yet solve the issue. The good news is that the module now gives me an error on modprobe. This is what I get: ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 17 (level, low) -> IRQ 22 radeonfb (0000:01:05.0): cannot map FB radeonfb: probe of 0000:01:05.0 failed with error -5 If I rmmod and try again, the error repeats, excluding the first line above. I've tried this both on my 2.6.21 kernel I was using before as well as a newly compiled 2.6.22-2 kernel, both after applying the patch specified. Same error. So... any ideas? Attached are update-to-date config files, dmesg, ls /sys/bus/pci/..., etc., in case they're needed. Thanks again. - Paul _________________________________________________________________ 熱いライブ映像が無料!BON JOVI、RED HOT CHILI PEPPERS、LINKIN PARK他 http://liveearth.jp.msn.com/ |
From: Antonino A. D. <ad...@gm...> - 2007-07-28 15:12:29
|
On Tue, 2007-07-24 at 04:46 +0900, Goins Paul wrote: > >Okay, I'm pretty sure there was a patch a year ago that added the Radeon > >Xpress 1100 device id to the table. But to be sure, what is the output > >of lspci -n? > > 01:05.0 0300: 1002:5975 Ah, okay, this particular chipset was just added to radeonfb a week ago. Apply this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c Tony |