Re: Re: fbdev updates.

Re: Re: fbdev updates.

[James Simmons]

> On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote:
> > Since no one has complianed for some time I like to push the next set of
> > changes to Linus. Anyone with objections please give a yell.
>
> A small suggestion - could you post diffstat -p1 output with your patch
> announcements please?

Patch at http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

diffstat results:

 drivers/video/Config.in     |   40
 drivers/video/Makefile      |   28
 drivers/video/anakinfb.c    |    4
 drivers/video/aty128fb.c    |    5
 drivers/video/cfbcopyarea.c |    4
 drivers/video/cfbimgblt.c   |   10
 drivers/video/clps711xfb.c  |    3
 drivers/video/cyber2000fb.c |    5
 drivers/video/dn_accel.h    |    9
 drivers/video/dn_cfb4.c     |  492 -----
 drivers/video/dn_cfb8.c     |  540 ------
 drivers/video/dnfb.c        |  535 +-----
 drivers/video/fbcmap.c      |    2
 drivers/video/fbmem.c       |    3
 drivers/video/maxinefb.c    |  290 ---
 drivers/video/neofb.c       | 3639 ++++++++++++++++++++------------------------
 drivers/video/neofb.h       |  291 ---
 drivers/video/pm2fb.c       |  745 ++++++---
 drivers/video/pmag-ba-fb.c  |  343 ----
 drivers/video/pmagb-b-fb.c  |  344 ----
 drivers/video/skeletonfb.c  |    2
 drivers/video/tdfxfb.c      | 2434 ++++++++---------------------
 drivers/video/tx3912fb.c    |  566 ++----
 drivers/video/tx3912fb.h    |  128 -
 drivers/video/vfb.c         |    4
 include/video/neomagic.h    |  264 +++
 include/video/pm2fb.h       |  222 ++
 include/video/tx3912.h      |   62
 28 files changed, 4034 insertions(+), 6980 deletions(-)



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: FBdev updates.

[Antonino Daplas]

On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> 
> I was for five weeks in U.S., so I did not do anything with
> matroxfb during that time. I plan to use fillrect and copyrect
> from generic code (although it means unnecessary multiply on
> generic side, and division in matroxfb, but well, if we gave
> up on reasonable speed for fbdev long ago...). But I simply
> want loadfont and putcs hooks for character painting. And if 
> fbdev maintainer does not want to give me them, well, then 
> matroxfb and fbdev are not compatible.

Petr,

I submitted the Tile Blitting patch to James some time ago, it has
tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
"multiply in fbcon, divide in driver" bottleneck.

It should result in the same behavior as you would expect in the the 2.4
API, so you can use text mode with your matroxfb driver.  These same
hooks will also help optimize drawing if we need to use fonts like
12x22.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: Re: FBdev updates.

[Antonino Daplas]

On Fri, 2003-02-21 at 17:09, Geert Uytterhoeven wrote:
> On 21 Feb 2003, Antonino Daplas wrote:
> > Note: I cannot test with 12x22 fonts in 2.4 because some/most drivers do
> > not support it.
> 
> Which specific drivers are you talking about? All drivers for popular cards
> support fontwidth 12 (Matrox, ATI, nVidia, 3Dfx, Permedia, VESA, ...).
> 
>
You're absolutely correct, I'm wondering why I thought that :-)  Here's
a benchmark for 12x22, and it's 2x slower than 8x16, 2.4.x or 2.5.x. 
Still, the 2.5.x version is slower than 2.4.x.

Tony

no accel
scrollmode: yredraw
font: 12x22
visual: packed pixels

time cat /usr/src/linux/MAINTAINERS

linux 2.4.20

bpp8
----
real    0m4.984s
user    0m0.000s
sys     0m4.940s

bpp16
-----
real    0m9.188s
user    0m0.000s
sys     0m9.090s

bpp24
-----
real    0m14.574s
user    0m0.000s
sys     0m14.380s

bpp32
-----
real    0m18.578s
user    0m0.000s
sys     0m18.390s

linux-2.5.62

bpp8
----
real    0m5.247s
user    0m0.001s
sys     0m5.245s

bpp16
-----
real    0m9.640s
user    0m0.001s
sys     0m9.591s

bpp24
-----
real    0m15.943s
user    0m0.001s
sys     0m15.944s

bpp32
-----
real    0m19.653s
user    0m0.002s
sys     0m19.651s




-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: Re: FBdev updates.

[Jurriaan]

From: Petr Vandrovec <vandrove@vc.cvut.cz>
Date: Mon, Mar 03, 2003 at 09:35:00PM +0100
> On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> > On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > > 
> > > I was for five weeks in U.S., so I did not do anything with
> > > matroxfb during that time. I plan to use fillrect and copyrect
> > > from generic code (although it means unnecessary multiply on
> > > generic side, and division in matroxfb, but well, if we gave
> > > up on reasonable speed for fbdev long ago...). But I simply
> > > want loadfont and putcs hooks for character painting. And if 
> > > fbdev maintainer does not want to give me them, well, then 
> > > matroxfb and fbdev are not compatible.
> > 
> > Petr,
> > 
> > I submitted the Tile Blitting patch to James some time ago, it has
> > tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
> > "multiply in fbcon, divide in driver" bottleneck.
> >
> > It should result in the same behavior as you would expect in the the 2.4
> > API, so you can use text mode with your matroxfb driver.  These same
> > hooks will also help optimize drawing if we need to use fonts like
> > 12x22.
> 
> Hi,
>   while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode.

There is a regression here: I boot my kernel like this:

kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1

and have the following .config:

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y
CONFIG_RAW_DRIVER=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONTS=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_ACCEL=y

matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1600x1200x16bpp (virtual: 1600x5241)
matroxfb: framebuffer at 0xD4000000, mapped to 0xe0805000, size 33554432
Console: switching to colour frame buffer device 133x54
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 266T chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xd0000000
[drm] Initialized mga 3.1.0 20021029 on minor 0

I see a continuous strip of alternating blocks, of sub-character size,
at the extreme right end of my screen. The colors seem linked to the
color of the line with the cursor in some way.

After leaving XFRee, a piece of chbg's background picture is shown for a
short while, then the blocks return.

Kind regards,
Jurriaan


-- 
But the threat of disapproval had terrified me
No more my soul will I reveal
	Wargasm - Chameleon
GNU/Linux 2.5.63 SMP/ReiserFS 1x2793 bogomips load av: 1.18 0.46 0.17


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

On Tue, Mar 04, 2003 at 10:29:06PM +0100, Jurriaan wrote:
> > text mode.
> 
> There is a regression here: I boot my kernel like this:
> 
> kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1
> 
> I see a continuous strip of alternating blocks, of sub-character size,
> at the extreme right end of my screen. The colors seem linked to the
> color of the line with the cursor in some way.
> 
> After leaving XFRee, a piece of chbg's background picture is shown for a
> short while, then the blocks return.

Reproduced. Try this (untested) (it is against clean tree, so you'll 
get some line offsets if you had applied my matroxfb patch). Or set 
xres to odd value, even values do not work...
							Petr Vandrovec


--- linux/drivers/video/console/fbcon.c	2003-03-03 18:42:37.000000000 +0100
+++ linux/drivers/video/console/fbcon.c	2003-03-04 22:44:05.000000000 +0100
@@ -456,7 +456,7 @@
 	region.color = attr_bgcol_ec(p, vc);
 	region.rop = ROP_COPY;
 
-	if (rw & !bottom_only) {
+	if (rw && !bottom_only) {
 		region.dx = info->var.xoffset + rs;
 		region.dy = 0;
 		region.width = rw;


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[James Simmons]

> Hi,
>   while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode. I have still dozen of changes in fbcon.c which I have
> to eliminate (mainly logo painting and cursor handling - for now
> I still use revc method, mainly because of I did not make into it yet).

I grabbed your latest patch and started to merge it with my latest work on 
the matrox driver. As soon as I'm done merging my matrox changes I will 
send you a patch right away.

>   My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp 
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).

Try the latest patch I released.
 
>   And one (or two...) generic questions: why is not pseudo_palette
> u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?

pseudo_palette was originally designed to be a pointer to some kind of 
data for color register programming. For example many PPC graphics cards 
have a color register region. Now you could have that point to 
pseudo_palette.  Note pseudo_palette is only visiable in fbmem.c for the 
logo drawing code. Personally I liek to see that hidden.

> And why we do not fill this pseudo_palette with
> i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> pseudocolor? This allowed me to remove couple of switches and tests
> from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> but I did not changed these two in my benchmarks below).

??? Does your accel engine require these kinds of values?




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[James Simmons]

> >   And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> 
> Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
> not change pseudo-palette from void* to u32*?

See other email.

> > And why we do not fill this pseudo_palette with
> > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > pseudocolor? This allowed me to remove couple of switches and tests
> > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > but I did not changed these two in my benchmarks below).
> 
> I also agree for a different reason.  Cards with unconventional formats
> (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
> work with the current code.

Isn't that the job of setcolreg?



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

On  5 Mar 03 at 20:22, James Simmons wrote:
>  
> >   And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> 
> pseudo_palette was originally designed to be a pointer to some kind of 
> data for color register programming. For example many PPC graphics cards 
> have a color register region. Now you could have that point to 
> pseudo_palette.  Note pseudo_palette is only visiable in fbmem.c for the 
> logo drawing code. Personally I liek to see that hidden.

cfbfillrect? cfbimageblit? Both use pseudo_palette, and both convert
it to u32*.
 
> > And why we do not fill this pseudo_palette with
> > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > pseudocolor? This allowed me to remove couple of switches and tests
> > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > but I did not changed these two in my benchmarks below).
> 
> ??? Does your accel engine require these kinds of values?

Yes. It is 32bit engine, and so it wants 32bit value. And even if 
not, code doing

if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
    p->fix.visual == FB_VISUAL_DIRECTCOLOR)
      fg = p->pseudo_palette[rect->color];
else
      fg = rect->color;

is horrible. Two conditional jumps on each rectangle. If you'll do
always lookup through pseudo_palette, not only that you get rid of
these jumps, you can also remove calls to pixel_to_pat32 (and accompanying
tables & lookups), as you do this expansion at set_var time,
instead of at blit/clear time.
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Antonino Daplas]

On Thu, 2003-03-06 at 04:23, James Simmons wrote:
> 
> > >   And one (or two...) generic questions: why is not pseudo_palette
> > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> > 
> > Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
> > not change pseudo-palette from void* to u32*?
> 
> See other email.
> 
> > > And why we do not fill this pseudo_palette with
> > > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > > pseudocolor? This allowed me to remove couple of switches and tests
> > > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > > but I did not changed these two in my benchmarks below).
> > 
> > I also agree for a different reason.  Cards with unconventional formats
> > (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
> > work with the current code.
> 
> Isn't that the job of setcolreg?
> 
setcolreg does that for directcolor and truecolor modes, because they're
the only ones that uses the pseudo_palette.  See all driver codes, the
pseudo_palette is never initialized if in pseudo_color.

The purpose of the pseudo_palette is to enable to write pixels to the
framebuffer without knowing the color format at all.  So, if you have
monochrome, then black is 0 and white is 1.  But for monochrome 8bpp,
black is 0 and white is 0xff. 

fbcon will send 0's and 1's, thus 0 and 1 will be written to the
framebuffer.  If the drawing functions referred to the pseudo_palette,
whatever the visual format, then 0 and 0xff will be written, as it
should be.

Tony
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Sven Luther]

On Wed, Mar 05, 2003 at 08:22:26PM +0000, James Simmons wrote:
> 
> > Hi,
> >   while waiting on these updates I updated matroxfb a bit
> > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> > so that it now uses fb_* for cfb modes, and putcs/... hooks for
> > text mode. I have still dozen of changes in fbcon.c which I have
> > to eliminate (mainly logo painting and cursor handling - for now
> > I still use revc method, mainly because of I did not make into it yet).
> 
> I grabbed your latest patch and started to merge it with my latest work on 
> the matrox driver. As soon as I'm done merging my matrox changes I will 
> send you a patch right away.
> 
> >   My main concern now is 12x22 font... Accelerator setup
> > is so costly for each separate painted character that for 8bpp 
> > accelerated version is even slower than unaccelerated one :-(
> > (and almost twice as slow when compared with 2.4.x).
> 
> Try the latest patch I released.
>  
> >   And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> 
> pseudo_palette was originally designed to be a pointer to some kind of 
> data for color register programming. For example many PPC graphics cards 
> have a color register region. Now you could have that point to 

Does this correspond to the LUT i have in my boards ?

BTW, what is the point in having a pseudo_palette if you can store
the colors in the onchip LUT table.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

Hi James,
  I tried to use fb_cursor and I have quite a lot problems with
it:
(1) it uses global variables for storing last cursor value -
    - but there is no global hardware, so after switching from
    one fbdev to another you can have cursor with wrong shape,
    wrong color and so on...
(2) callback from timer for cursor blinking may set almost any
    FB_CUR_* bits. But in this case fb_cursor callback may be
    called from interrupt context, while accelerator is busy
    and so on... Did I miss some synchronization? Best for me
    would be disabling blinking code in fbcon completely:
    in VGA mode cursor blinks automatically, and in graphics mode
    more lightweight only 'flash' callback is more appropriate
    for me. But then there is problem with
(3) cursor_undrawn... I have no idea how is this supposed to work
    if fbdev provides hardware cursor... And HZ/50 delay after
    putcs makes orientation on screen very complicated, as there
    is no cursor while new characters are appearing on screen.
    
					Thanks,
						Petr Vandrovec
						vandrove@vc.cvut.cz


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Antonino Daplas]

On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> Hi James,
>   I tried to use fb_cursor and I have quite a lot problems with
> it:
> (1) it uses global variables for storing last cursor value -
>     - but there is no global hardware, so after switching from
>     one fbdev to another you can have cursor with wrong shape,
>     wrong color and so on...
> (2) callback from timer for cursor blinking may set almost any
>     FB_CUR_* bits. But in this case fb_cursor callback may be
>     called from interrupt context, while accelerator is busy
>     and so on... Did I miss some synchronization? Best for me
>     would be disabling blinking code in fbcon completely:
>     in VGA mode cursor blinks automatically, and in graphics mode
>     more lightweight only 'flash' callback is more appropriate
>     for me. But then there is problem with

I've also noticed problems with 1 and 2, and I submitted a patch to
James that allocates resources on a per device basis instead of being
global and statically allocated.  This includes the cursor data
structures, cursor timer/vbl interrupt service, putcs buffer, and
optionally the softback buffer.  The last is probably not very important
for the present setup but may become useful later on (ie, multiple
active consoles).

As for synchronization, I was meaning to ask some pointers on that.  The
setup currently works like this:

                        (blink)
fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
     |                     |
     -----------------------
               |
           accel_cursor
               |
     -----------------------
     |                      |
  hardware              soft_cursor    accel_putcs    accel_putc
                            |              |               |
                            -------------- -----------------
                                           | 
                                   fb_get_buffer_offset
                                           |
                                     xxxfb_imageblit
                                           |
                                  -------------------
                                  |                  |
                              hardware           software


I was thinking of placing locks in accel_cursor and
fb_get_buffer_offset, but I'm not sure.
  
> (3) cursor_undrawn... I have no idea how is this supposed to work

In the present cursor api, the driver just needs to draw/undraw the
cursor whether by software or hardware.  So the problem here is with
cursors that does it's own blinking, such as text modes.

>     if fbdev provides hardware cursor... And HZ/50 delay after
>     putcs makes orientation on screen very complicated, as there
>     is no cursor while new characters are appearing on screen.

The delay is only for the blinking.  After drawing a character/stream of
characters, an explicit "draw cursor" command immediately follows (I
think) via fbcon_cursor.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> 
> As for synchronization, I was meaning to ask some pointers on that.  The
> setup currently works like this:
> 
>                         (blink)
> fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
>      |                     |
>      -----------------------
>                |
>            accel_cursor
>                |
>      -----------------------
>      |                      |
>   hardware              soft_cursor    accel_putcs    accel_putc
>                             |              |               |
>                             -------------- -----------------
>                                            | 
>                                    fb_get_buffer_offset
>                                            |
>                                      xxxfb_imageblit
>                                            |
>                                   -------------------
>                                   |                  |
>                               hardware           software
> 
> 
> I was thinking of placing locks in accel_cursor and
> fb_get_buffer_offset, but I'm not sure.

Maybe just auditing code is enough: cursor_on should be zero while
we are inside accel_putc/putcs (or inside any other fb function), and
if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
sure that fbcon_vbl_handler is not running on other CPU while we set
cursor_on = 0 should be enough.

> >     if fbdev provides hardware cursor... And HZ/50 delay after
> >     putcs makes orientation on screen very complicated, as there
> >     is no cursor while new characters are appearing on screen.
> 
> The delay is only for the blinking.  After drawing a character/stream of
> characters, an explicit "draw cursor" command immediately follows (I
> think) via fbcon_cursor.

Why we schedule cursor painting at all then? While we are inside putcs,
we cannot paint cursor anyway (as we are busy with painting characters
at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval
anyway (so you see cursor while you type characters, and not like Solaris
where cursor appears after you stop typing characters) (unfortunately when 
I tried to verify how it behaves on secondary head of matrox (which does not
have hardware cursor), I made a typo and ...

Unable to handle kernel NULL pointer dereference at virtual address 00000196
 printing eip:
c02f9258
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<c02f9258>]    Tainted: PFS
EFLAGS: 00010202
EIP is at fb_open+0x28/0xf0
eax: c6ed2c30   ebx: 00000020   ecx: 00000001   edx: c04848e0
esi: 00000002   edi: 00000000   ebp: c6ed2c30   esp: c4bb3f18
ds: 007b   es: 007b   ss: 0068
Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940)
Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4
       dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30
       c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830
Call Trace:
 [<c01669ea>] chrdev_open+0xaa/0x110
 [<c01435e3>] file_ra_state_init+0x23/0x40
 [<c015af91>] dentry_open+0x1d1/0x1f0
 [<c015adb7>] filp_open+0x67/0x70
 [<c015b26b>] sys_open+0x5b/0x90
 [<c0109983>] syscall_call+0x7/0xb

Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0

so I'll have to check it tomorrow on real dualhead system...)

						Petr Vandrovec
						vandrove@vc.cvut.cz





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Antonino Daplas]

On Mon, 2003-03-10 at 06:54, Petr Vandrovec wrote:
> On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> > On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> > 
> > As for synchronization, I was meaning to ask some pointers on that.  The
> > setup currently works like this:
> > 
> >                         (blink)
> > fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
> >      |                     |
> >      -----------------------
> >                |
> >            accel_cursor
> >                |
> >      -----------------------
> >      |                      |
> >   hardware              soft_cursor    accel_putcs    accel_putc
> >                             |              |               |
> >                             -------------- -----------------
> >                                            | 
> >                                    fb_get_buffer_offset
> >                                            |
> >                                      xxxfb_imageblit
> >                                            |
> >                                   -------------------
> >                                   |                  |
> >                               hardware           software
> > 
> > 
> > I was thinking of placing locks in accel_cursor and
> > fb_get_buffer_offset, but I'm not sure.
> 
> Maybe just auditing code is enough: cursor_on should be zero while
> we are inside accel_putc/putcs (or inside any other fb function), and
> if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
> sure that fbcon_vbl_handler is not running on other CPU while we set
> cursor_on = 0 should be enough.

I think that's what happens.  cursor_on is set to 0 at the beginning of
fbcon_cursor(), and it remains 0 until the next fbcon_cursor() is
CM_DRAW or CM_MOVE.  And while cursor_on is 0, fbcon_vbl_handler just
exits immediately.  Yes, it's basically the code in 2.4, but instead of
using revc, it uses imageblit, and instead of allowing the drivers to do
the blinking, fbcon does it entirely, whether a hardware or software
cursor method is installed.  

> 
> > >     if fbdev provides hardware cursor... And HZ/50 delay after
> > >     putcs makes orientation on screen very complicated, as there
> > >     is no cursor while new characters are appearing on screen.
> > 
> > The delay is only for the blinking.  After drawing a character/stream of
> > characters, an explicit "draw cursor" command immediately follows (I
> > think) via fbcon_cursor.
> 
> Why we schedule cursor painting at all then? While we are inside putcs,
> we cannot paint cursor anyway (as we are busy with painting characters

I don't think any cursor painting is done while doing putcs, if the
CM_ERASE, putc/putcs, CM_DRAW/CM_MOVE sequence is followed.  Note that I
haven't verified if that particular sequence is followed, I just assume
the console layer does.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Nicholas Wourms]

James Simmons wrote:
>>Hi James,
>>  I tried to use fb_cursor and I have quite a lot problems with
>>it:
> 
> 
> I'm working on the code today. I just finished the final touchs on the 
> pixmap buffer code. The next step is to make the pixmaps have flag for 
> static data versus dynamic data. You can then use fastfonst with static 
> buffer. This comes with the tile code. But first the cursor code today.
> 
> P.S
>   You can grab my latest work on the matroxfb driver at 
> 
> http://phoenix.infradead.org/~jsimmons/matroxfb.diff.gz
> 

James (or anyone),

Do you have something which might apply at least 
semi-cleanly to fbdev-2.5 current?  The reason I ask is 
because I have to use 2.5.64-ac4 or else my system won't 
boot.  The problem is that Alan has already applied your 
latest BK patch which kills your matroxfb diff against 
fbcon.c.  Alan has also modified your changes, thus making 
backing it out quite difficult and prone to error...  Thanks 
in advance :-).

Cheers,
Nicholas



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

FBDEV updates.

[James Simmons]

Hi folks!!

  Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out 
and tell me your results. I like to do a code drop soon. 

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

bk pull http://fbdev.bkbits.net/fbdev-2.6

This will update the following files:

 Documentation/fb/neofb.txt     |   27 
 MAINTAINERS                    |    5 
 drivers/char/vt_ioctl.c        |   12 
 drivers/video/Kconfig          |  100 
 drivers/video/Makefile         |    9 
 drivers/video/asiliantfb.c     |  619 +++
 drivers/video/aty/Makefile     |    1 
 drivers/video/cfbimgblt.c      |    2 
 drivers/video/chipsfb.c        |    4 
 drivers/video/console/Makefile |   29 
 drivers/video/console/fbcon.c  |  369 -
 drivers/video/console/fbcon.h  |    2 
 drivers/video/controlfb.c      |   10 
 drivers/video/epson1355fb.c    |  967 ++--
 drivers/video/fbmem.c          |  116 
 drivers/video/g364fb.c         |   78 
 drivers/video/i810/Makefile    |    7 
 drivers/video/imsttfb.c        |    2 
 drivers/video/logo/Makefile    |   15 
 drivers/video/logo/logo.c      |    5 
 drivers/video/macfb.c          |   34 
 drivers/video/neofb.c          |  338 +
 drivers/video/platinumfb.c     |   10 
 drivers/video/pvr2fb.c         |  846 +---
 drivers/video/riva/fbdev.c     |   75 
 drivers/video/riva/nv_type.h   |   12 
 drivers/video/sis/300vtbl.h    | 2437 ++----------
 drivers/video/sis/310vtbl.h    | 2574 ++----------
 drivers/video/sis/init.c       | 1882 +++++----
 drivers/video/sis/init.h       | 2435 +++++++++++-
 drivers/video/sis/init301.c    | 8208 +++++++++++++++++++++--------------------
 drivers/video/sis/init301.h    |  222 -
 drivers/video/sis/initdef.h    |  185 
 drivers/video/sis/oem300.h     |  502 --
 drivers/video/sis/oem310.h     |   88 
 drivers/video/sis/osdef.h      |  122 
 drivers/video/sis/sis_accel.c  |   68 
 drivers/video/sis/sis_accel.h  |   27 
 drivers/video/sis/sis_main.c   | 3752 ++++++++++--------
 drivers/video/sis/sis_main.h   |  575 +-
 drivers/video/sis/vgatypes.h   |   81 
 drivers/video/sis/vstruct.h    |  138 
 drivers/video/skeletonfb.c     |   74 
 drivers/video/softcursor.c     |   72 
 drivers/video/tdfxfb.c         |   47 
 drivers/video/valkyriefb.c     |  548 --
 drivers/video/vesafb.c         |   17 
 drivers/video/vgastate.c       |    1 
 include/linux/fb.h             |   88 
 include/linux/linux_logo.h     |    4 
 include/linux/pci_ids.h        |   11 
 include/video/epson1355.h      |   64 
 include/video/neomagic.h       |  261 -
 include/video/sisfb.h          |   91 
 54 files changed, 14922 insertions(+), 13346 deletions(-)

through these ChangeSets:

<jsimmons@bohr.(none)> (03/08/11 1.1151)
   [NEOMAGIC FBDEV] Add going between graphics and VGA text mode. 

<jsimmons@host-193.int.pioneer-pra.com> (03/07/21 1.1046.1.225)
   [TDFX FBDEV] Fixes to make the image blitter work. Also the color handling code was fixed. 

<jsimmons@host-193.int.pioneer-pra.com> (03/07/15 1.1046.1.221)
   [FBCON] Always turn off the cursor in fbcon_cursor. The reason is that cursor might try to blink while we are reprogramming the hardware.

<jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.218)
   [IMSTT FBDEV] Free up resources when it fails.

<jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.217)
   [FBDEV] Makefiel cleanups.

<jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.216)
   [ASILIANT FBDEV] Added support for the asiliant graphics chipset.

<jsimmons@host-193.int.pioneer-pra.com> (03/07/09 1.1046.1.211)
   [RIVA FBDEV] Support for more versions of GEFORCE 4. Also some cursor cleanup to allow it to compile.

<jsimmons@host-193.int.pioneer-pra.com> (03/07/08 1.1046.1.208)
   [SIS FBDEV] Updates to the SiS framebuffer driver. Add support for 760 chipset, LCD scaling.

<jsimmons@kozmo.(none)> (03/07/03 1.1046.1.205)
   [NEOMAGIC FBDEV] Fixed a nasty bug in the copyarea function. It wasn't testing for the condition when both regions have the same y coordinates but are over lapping. This casued a corrpution of data. Also started ot used the macros in vga.h.

<jsimmons@kozmo.(none)> (03/06/30 1.1046.1.200)
   [LOGO] Display the correct logo for MIPS DEC workstations.

<jsimmons@kozmo.(none)> (03/06/25 1.1046.1.194)
   [FBCON] Removed the crappy ROP_COPY/ROP_XOR test for flashing the cursor. Now we disable and enable the cursor timer instead.

<jsimmons@kozmo.(none)> (03/06/24 1.1046.1.192)
   [FBDEV] Now we can use a specific hardware mapper for different hardware functionality.

<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.188)
   [VGA CORE] Added needed vmalloc header.

<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.185)
   [FBCON] When using 512 characters, the mouse pointer starts using the wrong complement_mask after a console reset.

<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.184)
   [FBDEV] Made chipsfb/controlfb/platinumfb use the xxfb kernel command line string.

<jsimmons@maxwell.earthlink.net> (03/06/18 1.1046.1.180)
   [MAC FBDEV] Bug fixes.

<jsimmons@maxwell.earthlink.net> (03/06/15 1.1046.1.176)
   [SIS FBDEV] More updates for the SIS driver. 

<jsimmons@maxwell.earthlink.net> (03/06/14 1.1046.1.174)
   [CONTROL/PLATINUM FBDEV] Fix to match change in fb_set_var.

<jsimmons@maxwell.earthlink.net> (03/06/10 1.1046.1.170)
   [FBDEV] Fixed a issue with soft_cursor. It only worked with drivers with a pixmap.scan_align of 1. Now it will work with any.

<jsimmons@kozmo.(none)> (03/06/07 1.1046.1.164)
   [SIS FBDEV] Fixed sysnc issue.

<jsimmons@kozmo.(none)> (03/06/05 1.1046.1.160)
   [FBCON] Cleared out the struct fb_cursor we passed in. Other wise we get random data being used.

<jsimmons@kozmo.(none)> (03/05/30 1.1046.1.155)
   [FBDEV GENERIC ACCEL] Fixed why logo was not displayed for some.

<jsimmons@maxwell.earthlink.net> (03/05/24 1.1046.155.3)
   [VALKYRUE FBDEV] Ported to new api.

<jsimmons@maxwell.earthlink.net> (03/05/23 1.1046.155.1)
   [FBDEV] Updates to explain the new cursor api.

<jsimmons@maxwell.earthlink.net> (03/05/23 1.1046.1.142)
   [EPSON FRAMEBUFFER] Ported to the new api. Added support for the arm platform.

<jsimmons@maxwell.earthlink.net> (03/05/15 1.1046.84.18)
   [SIS FBDEV] SIS Framebuffer updates.
                 - Added preliminary and untested support for SiS660
                 - Added DDC support
                 - Enhanced proprietary programming API for compatibility with X driver
                   and upcoming SDL updates and upcoming vidix driver for mplayer
                 - Fixes for video bridge output on various HW combinations
                 - Fixes in TV detection
                 - Reduced source size by removing duplicated data
                 - Updated Kconfig descriptions

<jsimmons@maxwell.earthlink.net> (03/05/14 1.1046.73.2)
   [PVR2 FBDEV] Port of the Dreamcast Frambuffer to the new api.

<jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.19)
   [FBCON] set_con2fb_map wasn't testing to see the VC we where mapping to actually exist. Now it does. 
   
           I add code to fbcon_cursor to reset the hotspot if it was changed by userland. 

<jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.17)
   [RIVA FBDEV] Removal of exccess variable. Kills off a few warnings.

<jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.16)
   [VESA FBDEV] Removed the EDID code. The results where mixed. It worked for some but not for others.

<jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.15)
   [CONSOLE] This patch fixes the problem of not being able to set the fonts on VCs other than the first one. This also was the bug that was casuing dual head (vga and mda) to lock up.

<jsimmons@kozmo.(none)> (03/05/02 1.1042.122.2)
   [FBDEV] Synced to kdev_t change.

<jsimmons@kozmo.(none)> (03/04/22 1.1042.37.2)
   [FBDEV] Moved pixmap to the kernel side of the header. Will not be needed for ioctl calls at the present time.
   
   [FBCON] Lots more optimizations.

<jsimmons@kozmo.(none)> (03/04/21 1.1042.37.1)
   [LOGO] Removed fb_ prefix. Wil be used by other drivers such as the newport driver.
   
   [G354 FBDEV] Now use the final cursor api.

Re: FBDEV updates.

[Otto Solares]

On Thu, Aug 14, 2003 at 08:54:21PM +0100, James Simmons wrote:
> 
> Hi folks!!
> 
>   Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out 
> and tell me your results. I like to do a code drop soon. 

James:

what is the current state of PM in fb drivers?

does modedb is being used on 2.6 drivers?

Is there an API (or lib) to use framebuffers devices without
worring about differents visuals?, to quering, setting or
disabling EDID support? will these drivers export sysfs
entries instead of control via ioctl's?

thanks for your work on fb.

-solca

Re: FBDEV updates.

[James Simmons]

> what is the current state of PM in fb drivers?

Experinmental patch from Ben is in the works.

> does modedb is being used on 2.6 drivers?

Yes. 

> Is there an API (or lib) to use framebuffers devices without
> worring about differents visuals?, 

??? 

> to quering, setting or
> disabling EDID support? 

Yes. That is the fbmon.c stuff. Still needs work. 

> will these drivers export sysfs
> entries instead of control via ioctl's?

Needs to be done. I'm not familiar with sysfs so it hasn't been done.


> thanks for your work on fb.

Your welcome. 

Re: Re: FBDEV updates.

[Jon Smirl]

When I was working on Rage128/Radeon drivers and
fixing them up for the 2.6 modules parameters, I
noticed that they allow an fb mode as a parameter. How
is this supose to work? I tried setting a mode and it
gets copied into the internal structures but the
display doesn't change. If I modify the driver to
change the display mode fbconsole gets all confused.

I just left the drviers the way I found them. Mode
fills in the internal vars but doesn't actually set it.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: FBDEV updates.

[Greg KH]

On Thu, Aug 14, 2003 at 02:36:58PM -0600, Otto Solares wrote:
> 
> Is there an API (or lib) to use framebuffers devices without
> worring about differents visuals?, to quering, setting or
> disabling EDID support? will these drivers export sysfs
> entries instead of control via ioctl's?

I have some initial sysfs patches for the fb code that I've been sitting
on in my trees.  I was waiting for these patches to hit the mainline
before bothering James and the rest of the world with them.

But they don't export any of the ioctl stuff through the sysfs
interface, but that would not be very hard to do at all if you want to.
They just basically show the major/minor of the fb device, and point
back to the proper place in the device tree where the fb device lives,
which is all udev really needs right now.

thanks,

greg k-h

Re: FBDEV updates.

[Benjamin Herrenschmidt]

On Thu, 2003-08-14 at 22:52, James Simmons wrote:
> > what is the current state of PM in fb drivers?
> 
> Experinmental patch from Ben is in the works.

That patch actually works here and I'm more/less waiting for it
to be merged so I can send you the driver updates based on it.
(It's becoming rather urgent. My pending PowerMac updates that
port things to the new model are causing PM to break on PowerBook
laptops now because fbdev has incorrect PM and the "old style" thing
isn't properly ordered).

The only thing you may probably want to fix (because you know
that code better than I do) are:

 - the "resume" callback in fbcon where I currently just refresh
the foreground console, while you may actually want to refresh the
one on this fb since I suppose that with mutiple heads, we may have
consoles on more than one head ?

 - the suspend callback where you probably want to disable the
cursor timer

Ben. 

Re: FBDEV updates.

[James Simmons]

> That patch actually works here and I'm more/less waiting for it
> to be merged so I can send you the driver updates based on it.
> (It's becoming rather urgent. My pending PowerMac updates that
> port things to the new model are causing PM to break on PowerBook
> laptops now because fbdev has incorrect PM and the "old style" thing
> isn't properly ordered).
> 
> The only thing you may probably want to fix (because you know
> that code better than I do) are:
> 
>  - the "resume" callback in fbcon where I currently just refresh
> the foreground console, while you may actually want to refresh the
> one on this fb since I suppose that with mutiple heads, we may have
> consoles on more than one head ?
> 
>  - the suspend callback where you probably want to disable the
> cursor timer

Will do. I like to also handle Video mode change. Even userland will like 
to know when a mode change happened. For userland a signal can be sent. 
This would be useful for someone in X that runs fbset in a Xterm. This 
hoses the X server. It would be nice if the X server would see the signal 
change and adapt to it. Fbset could in theory be used again to change a VC 
size. Yuck!!!! But it is what people want.

Re: FBDEV updates.

[James Simmons]

> > Is there an API (or lib) to use framebuffers devices without
> > worring about differents visuals?, to quering, setting or
> > disabling EDID support? will these drivers export sysfs
> > entries instead of control via ioctl's?
> 
> I have some initial sysfs patches for the fb code that I've been sitting
> on in my trees.  I was waiting for these patches to hit the mainline
> before bothering James and the rest of the world with them.
> 
> But they don't export any of the ioctl stuff through the sysfs
> interface, but that would not be very hard to do at all if you want to.
> They just basically show the major/minor of the fb device, and point
> back to the proper place in the device tree where the fb device lives,
> which is all udev really needs right now.

Could you send me those patches :-)

Re: FBDEV updates.

[Benjamin Herrenschmidt]

> 
> Will do. I like to also handle Video mode change. Even userland will like 
> to know when a mode change happened. For userland a signal can be sent. 
> This would be useful for someone in X that runs fbset in a Xterm. This 
> hoses the X server. It would be nice if the X server would see the signal 
> change and adapt to it. Fbset could in theory be used again to change a VC 
> size. Yuck!!!! But it is what people want.

And for good reasons as we still have to deal with cases
where neither the driver nor modedb knows what the monitor supports...

Ben.

Re: FBDEV updates.

[Greg KH]

On Fri, Aug 15, 2003 at 11:37:21PM +0100, James Simmons wrote:
> 
> > > Is there an API (or lib) to use framebuffers devices without
> > > worring about differents visuals?, to quering, setting or
> > > disabling EDID support? will these drivers export sysfs
> > > entries instead of control via ioctl's?
> > 
> > I have some initial sysfs patches for the fb code that I've been sitting
> > on in my trees.  I was waiting for these patches to hit the mainline
> > before bothering James and the rest of the world with them.
> > 
> > But they don't export any of the ioctl stuff through the sysfs
> > interface, but that would not be very hard to do at all if you want to.
> > They just basically show the major/minor of the fb device, and point
> > back to the proper place in the device tree where the fb device lives,
> > which is all udev really needs right now.
> 
> Could you send me those patches :-)

I'll clean them up, and port all fb drivers to them (I only did the ones
that I had hardware too), and send them to you next week.  Do not let
them hold anything up that you can send to Linus though, they are not
that important at all right now.

thanks,

greg k-h

Re: FBDEV updates.

[Otto Solares]

On Sat, Aug 16, 2003 at 01:42:32AM +0200, Benjamin Herrenschmidt wrote:
> 
> > 
> > Will do. I like to also handle Video mode change. Even userland will like 
> > to know when a mode change happened. For userland a signal can be sent. 
> > This would be useful for someone in X that runs fbset in a Xterm. This 
> > hoses the X server. It would be nice if the X server would see the signal 
> > change and adapt to it. Fbset could in theory be used again to change a VC 
> > size. Yuck!!!! But it is what people want.
> 
> And for good reasons as we still have to deal with cases
> where neither the driver nor modedb knows what the monitor supports...

It could be really cool if in sysfs be a file with
video modes, something like this:

1024x768x24@80
1024x768x24@60
800x600x24@60
600x400x16@75

and other file named current_mode (or something) with the
current setting, you just echo a value there and bingo,
a video mode change with the desired refresh rate, is that
hard? EDID and modedb can help us here.

Don't you think?

-solca

Re: FBDEV updates.

[Sven Schnelle]

[-- Attachment #1: Type: text/plain, Size: 7421 bytes --]

Hello,

James Simmons <jsimmons@infradead.org> wrote:
 
>   Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out 
> and tell me your results. I like to do a code drop soon. 

Thanks for this patch, it runs now quite nice on a RIVA TNT2. Is there
any special reason why you use soft_cursor in rivafb? I changed the
rivafb_cursor to the new code, maybe you have a look ;-)

-------------------------------------8<----------------------------------------------------------------
diff -Naur linux-2.6.0-test3/drivers/video/riva/fbdev.c linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c
--- linux-2.6.0-test3/drivers/video/riva/fbdev.c	2003-08-16 07:47:20.000000000 +0200
+++ linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c	2003-08-16 07:39:39.000000000 +0200
@@ -460,48 +460,11 @@
 	return (VGA_RD08(par->riva.PVIO, 0x3cc));
 }
 
-static u8 byte_rev[256] = {
-	0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
-	0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
-	0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
-	0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
-	0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
-	0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
-	0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
-	0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
-	0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
-	0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
-	0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
-	0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
-	0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
-	0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
-	0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
-	0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
-	0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
-	0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
-	0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
-	0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
-	0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
-	0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
-	0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
-	0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
-	0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
-	0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
-	0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
-	0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
-	0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
-	0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
-	0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
-	0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
-static inline void reverse_order(u32 *l)
+static inline u32 reverse_order(u32 val)
 {
-	u8 *a = (u8 *)l;
-	*a = byte_rev[*a], a++;
-	*a = byte_rev[*a], a++;
-	*a = byte_rev[*a], a++;
-	*a = byte_rev[*a];
+return((val & 0x80808080) >> 7 | (val & 0x40404040) >> 5 | (val & 0x20202020) >> 3 | \
+       (val & 0x10101010) >> 1 | (val & 0x08080808) << 1 | (val & 0x04040404) << 3 | \
+       (val & 0x02020202) << 5 | (val & 0x01010101) << 7);
 }
 
 /* ------------------------------------------------------------------------- *
@@ -534,13 +497,14 @@
 	int i, j, k = 0;
 	u32 b, m, tmp;
 
+		
 	for (i = 0; i < h; i++) {
-		b = *((u32 *)data)++;
+
+		b = reverse_order(*((u32 *)data)++);
 		m = *((u32 *)mask)++;
-		reverse_order(&b);
-		
+
 		for (j = 0; j < w/2; j++) {
-			tmp = 0;
+		tmp = 0;
 #if defined (__BIG_ENDIAN)
 			if (m & (1 << 31)) {
 				fg |= 1 << 15;
@@ -565,7 +529,7 @@
 			tmp = (b & 1) ? fg : bg;
 			b >>= 1;
 			m >>= 1;
-			
+
 			if (m & 1) {
 				fg |= 1 << 15;
 				bg |= 1 << 15;
@@ -573,10 +537,11 @@
 			tmp |= (b & 1) ? fg << 16 : bg << 16;
 			b >>= 1;
 			m >>= 1;
+			
 #endif
-			writel(tmp, par->riva.CURSOR + k++);
-		}
-		k += (MAX_CURS - w)/2;
+				writel(tmp, par->riva.CURSOR + k++);
+			}
+		    k += (MAX_CURS - w)/2;
 	}
 }
 
@@ -1428,7 +1393,7 @@
 			     const struct fb_image *image)
 {
 	struct riva_par *par = (struct riva_par *) info->par;
-	u32 fgx = 0, bgx = 0, width, tmp;
+	u32 fgx = 0, bgx = 0, width;
 	u8 *cdat = (u8 *) image->data;
 	volatile u32 *d;
 	int i, size;
@@ -1474,23 +1439,20 @@
 
 	width = (image->width + 31)/32;
 	size = width * image->height;
+
 	while (size >= 16) {
 		RIVA_FIFO_FREE(par->riva, Bitmap, 16);
-		for (i = 0; i < 16; i++) {
-			tmp = *((u32 *)cdat)++;
-			reverse_order(&tmp);
-			d[i] = tmp;
-		}
+		for (i = 0; i < 16; i++) 
+			d[i] = reverse_order(*((u32 *)cdat)++);
 		size -= 16;
-	}
+		}
+
 	if (size) {
 		RIVA_FIFO_FREE(par->riva, Bitmap, size);
-		for (i = 0; i < size; i++) {
-			tmp = *((u32 *) cdat)++;
-			reverse_order(&tmp);
-			d[i] = tmp;
+		for (i = 0; i < size; i++)
+			d[i] = reverse_order(*((u32 *) cdat)++);
+
 		}
-	}
 }
 
 /**
@@ -1509,9 +1471,17 @@
 static int rivafb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 {
 	struct riva_par *par = (struct riva_par *) info->par;
+	unsigned int scan_align = info->pixmap.scan_align - 1;
+	unsigned int buf_align = info->pixmap.buf_align - 1;
+		u8 *dst = (u8 *) info->cursor.image.data;
+	unsigned int i, size, pitch;
 	u16 fg, bg;
-	int i;
 
+	pitch = ((info->cursor.image.width + 7) >> 3) + scan_align;
+	pitch &= ~scan_align;
+	size = pitch * info->cursor.image.height + buf_align;
+	size &= ~buf_align;
+	
 	par->riva.ShowHideCursor(&par->riva, 0);
 
 	if (cursor->set & FB_CUR_SETPOS) {
@@ -1540,36 +1510,37 @@
 	if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP)) {
 		u32 bg_idx = info->cursor.image.bg_color;
 		u32 fg_idx = info->cursor.image.fg_color;
-		u8 *dat = (u8 *) info->cursor.image.data;
-		u8 *msk = (u8 *) info->cursor.mask;
-		u8 src[64];	
-		
 		switch (info->cursor.rop) {
 		case ROP_XOR:
-			for (i = 0; i < info->sprite.size; i++)
-					src[i] = dat[i] ^ msk[i];
+			for (i = 0; i < size; i++)
+					dst[i] ^= info->cursor.mask[i];
 			break;
 		case ROP_COPY:
 		default:
-			for (i = 0; i < info->sprite.size; i++)
-					src[i] = dat[i] & msk[i];
+			for (i = 0; i < size; i++)
+					dst[i] &= info->cursor.mask[i];
 			break;
 		}
 		
 		bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
 		     ((info->cmap.green[bg_idx] & 0xf8) << 2) |
-		     ((info->cmap.blue[bg_idx] & 0xf8) >> 3);
+		     ((info->cmap.blue[bg_idx] & 0xf8) >> 3) | 0x8000;
 
 		fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
 		     ((info->cmap.green[fg_idx] & 0xf8) << 2) |
-		     ((info->cmap.blue[fg_idx] & 0xf8) >> 3);
+		     ((info->cmap.blue[fg_idx] & 0xf8) >> 3) | 0x8000;
 
 		par->riva.LockUnlock(&par->riva, 0);
 
-		rivafb_load_cursor_image(par, dat, msk, bg, fg,
-					 info->cursor.image.width, 
+		
+		memset_io(par->riva.CURSOR, 0, MAX_CURS * MAX_CURS*2);
+
+		if(info->cursor.image.data) 
+		    rivafb_load_cursor_image(par, dst, info->cursor.mask, bg, fg, \
+					 info->cursor.image.width, \
 					 info->cursor.image.height);
-	}
+		}
+	
 	if (info->cursor.enable)
 		par->riva.ShowHideCursor(&par->riva, 1);
 	return 0;
@@ -1602,7 +1573,7 @@
 	.fb_fillrect 	= rivafb_fillrect,
 	.fb_copyarea 	= rivafb_copyarea,
 	.fb_imageblit 	= rivafb_imageblit,
-	.fb_cursor	= soft_cursor,	
+	.fb_cursor	= rivafb_cursor,	
 	.fb_sync 	= rivafb_sync,
 };
-----------------------------------------8<----------------------------------------- 


-- 
Sven Schnelle, <schnelle@kabelleipzig.de>
-----------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]