linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] PPC 832 LCD Driver questions

[Paul M. <le...@Ch...>]

On Wed, Jan 30, 2002 at 09:57:38PM +0100, Hihn Jason wrote:
> I have the stock driver from the bzip mentioned today. (Which I also
> compared to the 2.2 driver, which is eerily similar.) Where could I find
> this other driver of which you speak?
>=20
> Sorry about the barrage of questions earlier, but I was really wondering =
why
> no one has done those things yet. It seems to be a simple matter that even
> _I_ could do. ;)=20
>=20
There's two drivers for this.. the one in the linuxppc tree (maintained by
Wolfgang Denk, and the one in the MontaVista Linux (formerly HHL) tree which
is maintained by myself. Have been meaning to merge the two.. but lack of t=
ime
is a rather irritating nuisance.

If one of them doesn't have what you're looking for, you might wish to
consult the other one before making any decisions over what to start hacking
on..

As far as things like the ioctl() interface.. there really isn't much need =
for
it, since there isn't a whole lot that's needed in this case. Even powering
the panel on and off isn't worth dealing with through the ioctl() interface.
Is there anything in particular that you really have a need for the ioctl()
for?

Regards,

--=20
Paul Mundt <le...@ch...>

RE: [Linux-fbdev-devel] PPC 832 LCD Driver questions

[Hihn J. <Jas...@DA...>]

Yes. You are correct. I cannot type. 

I have the stock driver from the bzip mentioned today. (Which I also
compared to the 2.2 driver, which is eerily similar.) Where could I find
this other driver of which you speak?

Sorry about the barrage of questions earlier, but I was really wondering why
no one has done those things yet. It seems to be a simple matter that even
_I_ could do. ;) 

-J
Hey, check out this humor from my demented mind:
Linux Philosophy 101: ln -s /bin/less more

-----Original Message-----
From: Paul Mundt [mailto:le...@Ch...]
Sent: Wednesday, January 30, 2002 3:43 PM
To: Hihn Jason
Cc: lin...@li...
Subject: Re: [Linux-fbdev-devel] PPC 832 LCD Driver questions


On Wed, Jan 30, 2002 at 09:33:44PM +0100, Hihn Jason wrote:
> Is there some reason why it's bare bones? And by that I mean: 
> Why does the IOCTL function do nothing?
> Why doesn't ....set_var() do any setting?
> Why doesn't the driver read from the registers?  (Particularly necessary
if
> you could change depth, resolution)
> And what is this "int con" everywhere? console?
> 
I'm presuming this is a typo, since I've never heard of an MPC832...

If you're ferring to the MPC823, which driver in particular are you
referring
to? There are two of these in circulation (which should probably get around
to
being merged.. but thats another matter entirely..). 

Regards,

-- 
Paul Mundt <le...@ch...>

Re: [Linux-fbdev-devel] PPC 832 LCD Driver questions

[Paul M. <le...@Ch...>]

On Wed, Jan 30, 2002 at 09:33:44PM +0100, Hihn Jason wrote:
> Is there some reason why it's bare bones? And by that I mean:=20
> Why does the IOCTL function do nothing?
> Why doesn't ....set_var() do any setting?
> Why doesn't the driver read from the registers?  (Particularly necessary =
if
> you could change depth, resolution)
> And what is this "int con" everywhere? console?
>=20
I'm presuming this is a typo, since I've never heard of an MPC832...

If you're ferring to the MPC823, which driver in particular are you referri=
ng
to? There are two of these in circulation (which should probably get around=
 to
being merged.. but thats another matter entirely..).=20

Regards,

--=20
Paul Mundt <le...@ch...>

[Linux-fbdev-devel] PPC 832 LCD Driver questions

[Hihn J. <Jas...@DA...>]

Is there some reason why it's bare bones? And by that I mean: 
Why does the IOCTL function do nothing?
Why doesn't ....set_var() do any setting?
Why doesn't the driver read from the registers?  (Particularly necessary if
you could change depth, resolution)
And what is this "int con" everywhere? console?

I'm not a kernel hacker, If I must add onto this driver, I will. If I do, I
make no guarantees as to quality, since it only needs to be adapted to my
current project. Of course, I'll release what I do, integrate it of you dare
;) Oh, and I plan to have a software emulated text layer.

Any comments, suggestions or objections before I begin?
-J

RE: [Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[James S. <jsi...@tr...>]

> James,
>   If the upper layers don't know what the data is (Because it is
> device specific) then why can they even see it? Device specific
> data should remain in device specific data structures. Just because
> almost all cards are going to need a similar place to store the
> console colors doesn't mean it goes in a device independent data
> structure. (I realize it's always been there, and it isn't the only
> device dependent thing in there, but that doesn't make it correct)

I know. I have been doing even more deep thinking about this. First lets
look at what the original intent was. Originally nearly all fbdev drivers
have something like:

  union {
#ifdef FBCON_HAS_CFB16
    u16 cfb16[16];
#endif
#ifdef FBCON_HAS_CFB24
    u32 cfb24[16];
#endif
#ifdef FBCON_HAS_CFB32
    u32 cfb32[16];
#endif
  } fbcon_cmap;

Which is just plain disgusting. So my original motivation was to remove
this. Replace it with a cleaner pseudo_palette that everyone could us. I
original thought about having it a u32 field. Then I wanted to trim the
amount of memory used and I also wanted to expand the idea behind
pseudo_palette. For example we have 17 instead of 16 indexs where the 17
index is used to store the cursor XOR mask. Also since my major goal was
to remove struct display complete I wanted to replace void *dispsw_data in
struct display with something like it in struct fb_info. So pseudo_palette
was the replacement. 
    The original idea behind dispsw_data was to provide a quick fake color
palette for fbcon. struct fb_cmap represents the color map and the
console system emulates a device with a color palette. Well for non-palette 
modes we had to fake a color palette. Their is no real need for fb_cmap
here. So the values in dispsw_data was the values we wrote to the pixels
in the framebuffer memory. So it was

console palette           fbcon  
   PSEUDOCOLOR            TRUECOLOR 
   color -> [index] ---> [index]->dispsw_data -> pixel value ->
				                 place value into memory

   PSEUDOCOLOR            PSEUDOCOLOR
   color -> [index] ---> [index] -> place value of index itself into
                                    memory  

Where fb_set_cmap would have set the hardware color palette to match the 
software one.

     I wanted to see pseudo_palette to be evern more than this. It could
also be a array of device specific structs to represent who knows what for
a device. Values that you need to write to hardware reisters for example.  
     
------------------------------------------------------------------------------

So that is what the original ideas where. Now to what I'm thinking know.

>   What you need is a color format in your region (which I think you
> have when doing image blit). 

Actually struct fb_fillrect already has a color field :-) 

> Then you just send the palette entry
> for the color. Fillrect does a switch for the types of things it can
> do in hardware or via a quick lookup or it returns an error.
> Basically fill rect acts just like an image blit.
> 
> Something like this:

>     region.color = attr_bgcol_ec(p,vc);
>     region.visual = FB_VISUAL_PSEUDOCOLOR;

>     info->fbops->fb_fillrect(info, &region);
> }

We don't have to worry about the visual field since this is in 
info->fix.visual. That can be handled internall by xxxfb_fillrect. I have
been think about just sending the colormap index. Since you can create a
color at anytime via fb_set_cmap and we have a color map in struct fb_info. 
We can use the index placed into region.color and after passing to the
below use the color map in struct fb_info to extract the data we need to
pass to the hardware. As Petr pointed out we can extract values that can
speed up the accelerators. It hides more data away from the upper layers.
The only thing is I hope people don't do the above fbcon_cmap mess again.
Of course that is what code review is for. 

> Perhaps we can take a step back and look at all the data structures
> and justify why things are the way they are. If you are changing the
> data structures we might as well make sure they make sense.

Expect alot of useless stuff to be removed in the near future.

[Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[James S. <jsi...@tr...>]

> On Tue, Jan 29, 2002 at 03:59:26PM -0800, James Simmons wrote:
> >     if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
> >         region.color = attr_bgcol_ec(p,vc);
> >     else 
> >         region.color = info->pseudo_palette)[attr_bgcol_ec(p,vc)];
>                         ^                    ^
> 
> I hope this is a typing mistake that's not present in the real source. 8)

The above is my pseudo code I wrote in the email. 

Re: [Linux-fbdev-devel] cyber2000fb

[Emmanuel M. <emm...@re...>]

Frederick Lefebvre <fle...@ir...> writes:

> Did anybody had success using the cyber2000fb driver on a i386 system.  
> The framebuffer seems to load properly but I end up with the card in 
> graphic mode with a very distorded display ( it seems my whole screens 
> display on 1/4 of it).

I could; in console mode when you scroll at some point
the screen becomes unreadable I don't know who is to blame for this

I report no troubles running X fbdev on top of cyber2000fb

Sincerely yours

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0685316107 GPGkeyID: D2997E42  

[Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[Russell K. <rm...@ar...>]

On Tue, Jan 29, 2002 at 03:59:26PM -0800, James Simmons wrote:
>     if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
>         region.color = attr_bgcol_ec(p,vc);
>     else 
>         region.color = info->pseudo_palette)[attr_bgcol_ec(p,vc)];
                        ^                    ^

I hope this is a typing mistake that's not present in the real source. 8)

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] atyfb has always failed here

[Felipe C. <al5...@ma...>]

It seems the message was lost, so I'm resending:

On Thu, Jan 24, 2002 at 11:06:58AM -0800, James Simmons wrote:
> 
> > Since I have tryied to use atyfb (2.4.x) I've never been able to make it
> > work. Even on the new 2.5 and the dj4 one it fails.
> > 
> > This is my card:
> > ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 100)
> 
> Can you use vga text and run lspci then post the results. You might be
> using the framebuffer driver.

I'm not, I have it as a moudule, that string was obtained from cat
/proc/pci, as I don't have lspci.

Bus  1, device   0, function  0:
        VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 100).
        IRQ 10.
        Master Capable.  Latency=66.  Min Gnt=8.
        Non-prefetchable 32 bit memory at 0xf5000000
        [0xf5ffffff].
        I/O at 0x2000 [0x20ff].
        Non-prefetchable 32 bit memory at
        0xf4100000 [0xf4100fff].

You still want me compile without atyfb.o and download lspci?

-- 
Felipe Contreras

[Linux-fbdev-devel] cyber2000fb

[Frederick L. <fle...@ir...>]

Did anybody had success using the cyber2000fb driver on a i386 system.  
The framebuffer seems to load properly but I end up with the card in 
graphic mode with a very distorded display ( it seems my whole screens 
display on 1/4 of it).

any ideas?

-- 
Frederick Lefebvre
fle...@ir...
Software Developer,
Infomedia Research Group (IRG)
Quebec, Canada

RE: [Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[Sottek, M. J <mat...@in...>]

James,
  If the upper layers don't know what the data is (Because it is
device specific) then why can they even see it? Device specific
data should remain in device specific data structures. Just because
almost all cards are going to need a similar place to store the
console colors doesn't mean it goes in a device independent data
structure. (I realize it's always been there, and it isn't the only
device dependent thing in there, but that doesn't make it correct)
  What you need is a color format in your region (which I think you
have when doing image blit). Then you just send the palette entry
for the color. Fillrect does a switch for the types of things it can
do in hardware or via a quick lookup or it returns an error.
Basically fill rect acts just like an image blit.

Something like this:
void fbcon_accel_clear(struct vc_data *vc, struct display *p, int sy, 
                       int sx, int height, int width)
{
    struct fb_info *info = p->fb_info;
    struct fb_fillrect region;

    region.color = attr_bgcol_ec(p,vc);
    region.visual = FB_VISUAL_PSEUDOCOLOR;
    height++;
    region.dx = sx * fontwidth(p);
    region.dy = sy * fontheight(p);
    region.width = width * fontwidth(p);
    region.height = height * fontheight(p);
    region.rop = ROP_COPY;

    info->fbops->fb_fillrect(info, &region);
}


Perhaps we can take a step back and look at all the data structures
and justify why things are the way they are. If you are changing the
data structures we might as well make sure they make sense.

 -Matt

Re: [Linux-fbdev-devel] Re: [PATCH?] Crash in 2.4.17/ptrace

[James S. <jsi...@tr...>]

> Ah, thanks.  Also I missed sbusfb.c (not that it was fatal - the driver
> got it right anyway).

Great.
 
> Here's the current patch.  After some discussion with Ben
> Herrenschmidt, it now sets VM_IO against the vma *before*
> calling the subdriver's mmap method, just in case the
> driver really does want to clear that flag (presumably, a shadow
> buffer in main memory).

I also thought about it as well. Never thought about the issue with shadow
buffers. Is it safe to move it before if (fb->fb_mmap)? 

> --- linux-2.4.18-pre7/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
> +++ linux-akpm/drivers/video/fbmem.c	Tue Jan 29 14:57:00 2002
> @@ -541,6 +541,16 @@ fb_mmap(struct file *file, struct vm_are
>  	if (fb->fb_mmap) {
>  		int res;
>  		lock_kernel();
> +		/*
> +		 * This is an IO map - tell maydump to skip this VMA.
> +		 * If, for some reason, the sub-driver wishes to allow the
> +		 * mapping to be dumpable and accessible via ptrace then
> +		 * it may clear VM_IO later.
> +		 * (This only makes sense if the buffer is actually
> +		 * in main memory, and is described by a page struct in
> +		 * mem_map[])
> +		 */
> +		vma->vm_flags |= VM_IO;
>  		res = fb->fb_mmap(info, file, vma);
>  		unlock_kernel();
>  		return res;

[Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[James S. <jsi...@tr...>]

> > +void fbcon_accel_clear(struct vc_data *vc, struct display *p, int sy, int sx,
> > +		       int height, int width)
> > +{
> > +	struct fb_info *info = p->fb_info;
> > +	struct fb_fillrect region;
> > +
> > +	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
> > +		region.color = attr_bgcol_ec(p,vc);
> > +	else {
> > +		if (info->var.bits_per_pixel > 16)
> > +			region.color = ((u32*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
> > +		else
> > +			region.color = ((u16*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
> > +	}
> 
> What about non-pseudocolor modes with bpp <= 8? We still use the 16-bit wide
> pseudo-palette in that case?
> 
> Alternatively we can always use the 32-bit wide pseudo-palette, so the test
> for info->var.bits_per_pixel can go away (assumed there are no pixel sizes
> where more than 32 bits are needed for the color information). Then a pixel
> value is just an opaque 32-bit value (cfr. fbtest).

   I have been giving it some thought plus with the conversation with
Petr. The whole point of pseudo_palette was to be a generic data storage
area to pass around in the upper layers without the upper layers touching
it. Even having those simple test in fbcon-accel.c defeats this purpose.
  
  I now feel it is best if we set psuedo_palette to u32 size. The way to
look at pseudo_palette[regno] is not as a place where a pixel value is
stored but a place where device specific data is held. That device
specific data could be anything. We just know that data is related to
a specific color from the palette for the console system. The value in 
pseudo_palette[x] might not match the framebuffer lay out. The value could
be something that optimizes the graphics accelerator when dealing with
colors. For example as Petr pointed out we can fill psuedo_palette[indx] 
with "(value << 16) | value" in 16bpp case. This will make several accelerators 
(such as MGA...) much happier. If we use (value * 0x01010101) for 8bpp the
MGA bitblt/clear functions can be exactly identical for all color depths.
   This is one of the goals. To provide one function for all color depths.
We now have the above as  

void fbcon_accel_clear(struct vc_data *vc, struct display *p, int sy, 
                       int sx, int height, int width)
{
    struct fb_info *info = p->fb_info;
    struct fb_fillrect region;

    if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
        region.color = attr_bgcol_ec(p,vc);
    else 
        region.color = info->pseudo_palette)[attr_bgcol_ec(p,vc)];
      
    height++;
    region.dx = sx * fontwidth(p);
    region.dy = sy * fontheight(p);
    region.width = width * fontwidth(p);
    region.height = height * fontheight(p);
    region.rop = ROP_COPY;

    info->fbops->fb_fillrect(info, &region);
}
  
As you can see the upper layer function doesn't care what data is in
pseudo_palette[x]. It just grabs that data and pushes it to xxxfb_fillrect
which does care about the format. How will the driver put the proper data
into pseudo_palette. With xxxfb_setcolreg which handles the hardware
specific stuff. Again this is hidden from the upper layers. Both
xxxfb_setcolreg and xxxfb_fillrect can then work at any color depth.
What do you think?

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [Linux-fbdev-devel] Re: [PATCH?] Crash in 2.4.17/ptrace

[Andrew M. <ak...@zi...>]

James Simmons wrote:
> 
> > It marks all framebuffer mappings as VM_IO.  This prevents
> > kernel deadlocks which can occur when a program which
> > has a framebuffer mapping attempts to dump core.
> 
> Good this is needed.
> 
> > I've Cc'ed linux-fbdev-devel.  Could someone please
> > review?
> 
> > --- linux-2.4.18-pre7/drivers/video/acornfb.c Thu Nov 22 23:02:58 2001
> 
> You missed the atyfb driver. Other then that it looks fine. Geert what do
> you think?

Ah, thanks.  Also I missed sbusfb.c (not that it was fatal - the driver
got it right anyway).

Here's the current patch.  After some discussion with Ben
Herrenschmidt, it now sets VM_IO against the vma *before*
calling the subdriver's mmap method, just in case the
driver really does want to clear that flag (presumably, a shadow
buffer in main memory).



--- linux-2.4.18-pre7/drivers/video/acornfb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/acornfb.c	Tue Jan 29 14:57:00 2002
@@ -1139,9 +1139,6 @@ acornfb_mmap(struct fb_info *info, struc
 	off += start;
 	vma->vm_pgoff = off >> PAGE_SHIFT;
 
-	/* This is an IO map - tell maydump to skip this VMA */
-	vma->vm_flags |= VM_IO;
-
 #ifdef CONFIG_CPU_32
 	pgprot_val(vma->vm_page_prot) &= ~L_PTE_CACHEABLE;
 #endif
--- linux-2.4.18-pre7/drivers/video/igafb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/igafb.c	Tue Jan 29 14:57:00 2002
@@ -293,8 +293,6 @@ static int igafb_mmap(struct fb_info *in
 	if (!map_size)
 		return -EINVAL;
 
-	vma->vm_flags |= VM_IO;
-
 	if (!fb->mmaped) {
 		int lastconsole = 0;
 
--- linux-2.4.18-pre7/drivers/video/sgivwfb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/sgivwfb.c	Tue Jan 29 14:57:00 2002
@@ -846,7 +846,6 @@ static int sgivwfb_mmap(struct fb_info *
     return -EINVAL;
   offset += sgivwfb_mem_phys;
   pgprot_val(vma->vm_page_prot) = pgprot_val(vma->vm_page_prot) | _PAGE_PCD;
-  vma->vm_flags |= VM_IO;
   if (remap_page_range(vma->vm_start, offset, size, vma->vm_page_prot))
     return -EAGAIN;
   vma->vm_file = file;
--- linux-2.4.18-pre7/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Tue Jan 29 14:57:00 2002
@@ -541,6 +541,16 @@ fb_mmap(struct file *file, struct vm_are
 	if (fb->fb_mmap) {
 		int res;
 		lock_kernel();
+		/*
+		 * This is an IO map - tell maydump to skip this VMA.
+		 * If, for some reason, the sub-driver wishes to allow the
+		 * mapping to be dumpable and accessible via ptrace then
+		 * it may clear VM_IO later.
+		 * (This only makes sense if the buffer is actually
+		 * in main memory, and is described by a page struct in
+		 * mem_map[])
+		 */
+		vma->vm_flags |= VM_IO;
 		res = fb->fb_mmap(info, file, vma);
 		unlock_kernel();
 		return res;
@@ -576,12 +586,13 @@ fb_mmap(struct file *file, struct vm_are
 		return -EINVAL;
 	off += start;
 	vma->vm_pgoff = off >> PAGE_SHIFT;
+	/* This is an IO map - tell maydump to skip this VMA */
+	vma->vm_flags |= VM_IO;
 #if defined(__sparc_v9__)
 	vma->vm_flags |= (VM_SHM | VM_LOCKED);
 	if (io_remap_page_range(vma->vm_start, off,
 				vma->vm_end - vma->vm_start, vma->vm_page_prot, 0))
 		return -EAGAIN;
-	vma->vm_flags |= VM_IO;
 #else
 #if defined(__mc68000__)
 #if defined(CONFIG_SUN3)
@@ -607,8 +618,6 @@ fb_mmap(struct file *file, struct vm_are
 	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;
 #elif defined(__arm__)
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-	/* This is an IO map - tell maydump to skip this VMA */
-	vma->vm_flags |= VM_IO;
 #elif defined(__sh__)
 	pgprot_val(vma->vm_page_prot) &= ~_PAGE_CACHABLE;
 #else
--- linux-2.4.18-pre7/drivers/video/sbusfb.c	Thu Sep 13 16:04:43 2001
+++ linux-akpm/drivers/video/sbusfb.c	Tue Jan 29 14:58:59 2002
@@ -220,7 +220,6 @@ static int sbusfb_mmap(struct fb_info *i
 		page += map_size;
 	}
 	
-	vma->vm_flags |= VM_IO;
 	if (!fb->mmaped) {
 		int lastconsole = 0;
 		
--- linux-2.4.18-pre7/drivers/video/aty/atyfb_base.c	Wed Jan 23 15:11:34 2002
+++ linux-akpm/drivers/video/aty/atyfb_base.c	Tue Jan 29 14:56:46 2002
@@ -1426,8 +1426,6 @@ static int atyfb_mmap(struct fb_info *in
 	if (!map_size)
 		return -EINVAL;
 
-	vma->vm_flags |= VM_IO;
-
 	if (!fb->mmaped) {
 		int lastconsole = 0;

Re: [Linux-fbdev-devel] Re: [PATCH?] Crash in 2.4.17/ptrace

[James S. <jsi...@tr...>]

> It marks all framebuffer mappings as VM_IO.  This prevents
> kernel deadlocks which can occur when a program which
> has a framebuffer mapping attempts to dump core.

Good this is needed.

> I've Cc'ed linux-fbdev-devel.  Could someone please
> review?

> --- linux-2.4.18-pre7/drivers/video/acornfb.c	Thu Nov 22 23:02:58 2001

You missed the atyfb driver. Other then that it looks fine. Geert what do
you think? 

Re: [Linux-fbdev-devel] Hello...

[M. R. B. <mr...@0x...>]

* Jo Dillon <jo...@tr...> on Tue, Jan 29, 2002:

> I've just subscribed to the list and I'm interested in working on the Lin=
ux=20
> framebuffer code (I wrote the Qt/Embedded accelerated drivers so I have s=
ome=20
> experience of working on that sort of thing) but I was wondering what the=
=20
> status of the framebuffer architecture is at the moment; I seem to recall=
=20
> reading there would be a big change to the framebuffer code to allow thin=
gs=20
> like multihead in 2.5. Is there a separate tree for that kind of thing? A=
lso,=20
> what drivers are most needed at the moment?
>=20

linuxconsole.sourceforge.net.  You'll also want to subscribe to the
relevant mailing lists.  ruby is the tree you'll want to check out of CVS.

M. R.

[Linux-fbdev-devel] Hello...

[Jo D. <jo...@tr...>]

I've just subscribed to the list and I'm interested in working on the Linux 
framebuffer code (I wrote the Qt/Embedded accelerated drivers so I have some 
experience of working on that sort of thing) but I was wondering what the 
status of the framebuffer architecture is at the moment; I seem to recall 
reading there would be a big change to the framebuffer code to allow things 
like multihead in 2.5. Is there a separate tree for that kind of thing? Also, 
what drivers are most needed at the moment?

-- 

	Jo

[Linux-fbdev-devel] fb_find_mode

[Frederick L. <fle...@ir...>]

How does fb_find_mode determines if there is a valid mode while 
initializing a frame buffer device?  I keep getting error while tring to 
use modedb.

err = fb_find_mode(&cfb_info->info.var, &cfb_info->info, 
		"640x480", NULL, 0, &cyber50xxfb_default_mode, 0);


-- 
Frederick Lefebvre
fle...@ir...
Software Developer,
Infomedia Research Group (IRG)
Quebec, Canada

Re: [Linux-fbdev-devel] mmap method usage

[Emmanuel M. <emm...@re...>]

Geert Uytterhoeven <ge...@li...> writes:

> On 29 Jan 2002, Emmanuel Michon wrote:
> > I derived a fb implementation from vfb and I noticed
> > the latter does not implement the mmap() function.
> > So I guess X with fbdev does not run on top of vfb...

When I say it does not run I don't know where the pixel go if mmap()
fails but it seems it's up ;-) It just does not really draw anything
even in the vmalloc'd area

> Indeed not. Until someone ports the mmap() trick from vga256fb
> (http://www.kyuzz.org/antirez/vga256fb.html) to vfb.

I think this trick won't work with normal vmalloc'd RAM: somebody has
to render the virtual-physical mapping permanent walking the pages
to set them reserved (something like rvmalloc found in bttv).

Then mmap() implementation requires a call to remap_page_range for
each physically contiguous region (one per 4K I'm afraid)

Sincerely yours,

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0685316107 GPGkeyID: D2997E42  

[Linux-fbdev-devel] multiple fb registered: how can I allocate properly per-fb data?

[Emmanuel M. <emm...@re...>]

Hi,

looking at the various implementation of framebuffer
devices in the kernel source tree, it seems most of
them store allocate appropriate structs in static variables
at the beginning of C file.
Having at most one framebuffer registered per module
allows to do this, there is no problem to refer to these
structs or to hardware specific data.

The point is I want to enable one framebuffer device per
PCI chip in a driver that registers all of them in a row
(up to eight).

So, I need to allocate these data on a per-framebuffer basis,
and also find a way to derive a pointer to hardware specific
data from the structs appearing in the methods.

Shouldn't I use the field void* par (probably Private ARea)
of struct fb_info for this purpose?
[It also seem _gen variants are never used.]

For instance: looking at this prototype:

static void vfb_encode_fix(struct fb_fix_screeninfo *fix,
			   struct fb_var_screeninfo *var);

there's no way I can rewind to fb_info.par: how should I find
the right instance-dependent value of fix->smem_start?

  instance = help->me->to->get->there;       
  fix->smem_start = (unsigned long)boards[instance].videomemory;

I tried to use the reserved fields but I guess this is not a very
good idea...
  
cyber2000fb.c defines a struct cfb_info which first member is
fb_info and recasts everything in all implementations. No other
way to do this?

Sincerely yours,

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0685316107 GPGkeyID: D2997E42  

Re: [Linux-fbdev-devel] mmap method usage

[Geert U. <ge...@li...>]

On 29 Jan 2002, Emmanuel Michon wrote:
> I derived a fb implementation from vfb and I noticed
> the latter does not implement the mmap() function.
> So I guess X with fbdev does not run on top of vfb...

Indeed not. Until someone ports the mmap() trick from vga256fb
(http://www.kyuzz.org/antirez/vga256fb.html) to vfb.

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

[Linux-fbdev-devel] mmap method usage

[Emmanuel M. <emm...@re...>]

Hi,

I derived a fb implementation from vfb and I noticed
the latter does not implement the mmap() function.
So I guess X with fbdev does not run on top of vfb...

After implementing it I could run X with success; can
you precise in which cases it is necessary to implement
the mmap() function?

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0685316107 GPGkeyID: D2997E42  

[Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[Geert U. <ge...@li...>]

On Mon, 28 Jan 2002, James Simmons wrote:
> Oops. Forgot the patch. Here you go.
> 
> diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-dj6/drivers/video/fbcon-accel.c linux/drivers/video/fbcon-accel.c
> --- linux-2.5.2-dj6/drivers/video/fbcon-accel.c	Wed Dec 31 16:00:00 1969
> +++ linux/drivers/video/fbcon-accel.c	Mon Jan 28 11:15:10 2002

  [...]

> +void fbcon_accel_clear(struct vc_data *vc, struct display *p, int sy, int sx,
> +		       int height, int width)
> +{
> +	struct fb_info *info = p->fb_info;
> +	struct fb_fillrect region;
> +
> +	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
> +		region.color = attr_bgcol_ec(p,vc);
> +	else {
> +		if (info->var.bits_per_pixel > 16)
> +			region.color = ((u32*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
> +		else
> +			region.color = ((u16*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
> +	}

What about non-pseudocolor modes with bpp <= 8? We still use the 16-bit wide
pseudo-palette in that case?

Alternatively we can always use the 32-bit wide pseudo-palette, so the test
for info->var.bits_per_pixel can go away (assumed there are no pixel sizes
where more than 32 bits are needed for the color information). Then a pixel
value is just an opaque 32-bit value (cfr. fbtest).

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

[Linux-fbdev-devel] Re: [PATCH] fbdev accel wrapper. II

[James S. <jsi...@tr...>]

Oops. Forgot the patch. Here you go.

diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-dj6/drivers/video/Makefile linux/drivers/video/Makefile
--- linux-2.5.2-dj6/drivers/video/Makefile	Mon Jan 28 10:04:47 2002
+++ linux/drivers/video/Makefile	Mon Jan 28 10:52:59 2002
@@ -14,7 +14,7 @@
 		  fbcon-vga.o fbcon-iplan2p2.o fbcon-iplan2p4.o \
 		  fbcon-iplan2p8.o fbcon-vga-planes.o fbcon-cfb16.o \
 		  fbcon-cfb2.o fbcon-cfb24.o fbcon-cfb32.o fbcon-cfb4.o \
-		  fbcon-cfb8.o fbcon-mac.o fbcon-mfb.o \
+		  fbcon-cfb8.o fbcon-mac.o fbcon-mfb.o fbcon-accel.o \
 		  cyber2000fb.o sa1100fb.o fbcon-hga.o
 
 # Each configuration option enables a list of files.
@@ -136,6 +136,7 @@
 obj-$(CONFIG_FBCON_VGA)           += fbcon-vga.o
 obj-$(CONFIG_FBCON_HGA)           += fbcon-hga.o
 obj-$(CONFIG_FBCON_STI)           += fbcon-sti.o
+obj-$(CONFIG_FBCON_ACCEL)	  += fbcon-accel.o
 
 include $(TOPDIR)/Rules.make
 
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-dj6/drivers/video/fbcon-accel.c linux/drivers/video/fbcon-accel.c
--- linux-2.5.2-dj6/drivers/video/fbcon-accel.c	Wed Dec 31 16:00:00 1969
+++ linux/drivers/video/fbcon-accel.c	Mon Jan 28 11:15:10 2002
@@ -0,0 +1,229 @@
+/*
+ *  linux/drivers/video/fbcon-accel.c -- Framebuffer accel console wrapper
+ *
+ *      Created 20 Feb 2001 by James Simmons <jsi...@us...>
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License.  See the file COPYING in the main directory of this archive for
+ *  more details.
+ */
+
+#include <linux/module.h>
+#include <linux/tty.h>
+#include <linux/console.h>
+#include <linux/string.h>
+#include <linux/fb.h>
+
+#include <video/fbcon.h>
+
+void fbcon_accel_setup(struct display *p)
+{
+	p->next_line = p->line_length ? p->line_length : p->var.xres_virtual*(p->var.bits_per_pixel<<3);
+	p->next_plane = 0;
+}
+
+void fbcon_accel_bmove(struct display *p, int sy, int sx, int dy, int dx,
+		       int height, int width)
+{
+	struct fb_info *info = p->fb_info;
+	struct fb_copyarea area;
+
+	area.sx = sx * fontwidth(p);
+	area.sy = sy * fontheight(p);
+	area.dx = dx * fontwidth(p);
+	area.dy = dy * fontheight(p);
+	area.height = height * fontheight(p);
+	area.width  = width * fontwidth(p);
+
+	info->fbops->fb_copyarea(info, &area);
+}
+
+void fbcon_accel_clear(struct vc_data *vc, struct display *p, int sy, int sx,
+		       int height, int width)
+{
+	struct fb_info *info = p->fb_info;
+	struct fb_fillrect region;
+
+	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
+		region.color = attr_bgcol_ec(p,vc);
+	else {
+		if (info->var.bits_per_pixel > 16)
+			region.color = ((u32*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
+		else
+			region.color = ((u16*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
+	}
+	height++;
+	region.dx = sx * fontwidth(p);
+	region.dy = sy * fontheight(p);
+	region.width = width * fontwidth(p);
+	region.height = height * fontheight(p);
+	region.rop = ROP_COPY;
+
+	info->fbops->fb_fillrect(info, &region);
+}
+
+void fbcon_accel_putc(struct vc_data *vc, struct display *p, int c, int yy,
+		      int xx)
+{
+	struct fb_info *info = p->fb_info;
+	unsigned short charmask = p->charmask;
+	unsigned int width = ((fontwidth(p)+7)>>3);
+	struct fb_image image;
+
+	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR) {
+		image.fg_color = attr_fgcol(p, c);
+		image.bg_color = attr_bgcol(p, c);
+	} else {
+		if (info->var.bits_per_pixel > 16) {
+			image.fg_color = ((u32*)info->pseudo_palette)[attr_fgcol(p,c)];
+			image.bg_color = ((u32*)info->pseudo_palette)[attr_bgcol(p,c)];
+		} else {
+			image.fg_color = ((u16*)info->pseudo_palette)[attr_fgcol(p,c)];
+			image.bg_color = ((u16*)info->pseudo_palette)[attr_bgcol(p,c)];
+		}
+	}
+	image.dx = xx * fontwidth(p);
+	image.dy = yy * fontheight(p);
+	image.width = fontwidth(p);
+	image.height = fontheight(p);
+	image.depth = 1;
+	image.data = p->fontdata + (c & charmask)*fontheight(p)*width;
+	info->fbops->fb_imageblit(info, &image);
+}
+
+void fbcon_accel_putcs(struct vc_data *vc, struct display *p,
+		       const unsigned short *s, int count, int yy, int xx)
+{
+	struct fb_info *info = p->fb_info;
+	unsigned short charmask = p->charmask;
+	unsigned int width = ((fontwidth(p)+7)>>3);
+	struct fb_image image;
+
+	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR) {
+		image.fg_color = attr_fgcol(p, *s);
+		image.bg_color = attr_bgcol(p, *s);
+	} else {
+		if (info->var.bits_per_pixel > 16) {
+			image.fg_color = ((u32*)info->pseudo_palette)[attr_fgcol(p,*s)];
+			image.bg_color = ((u32*)info->pseudo_palette)[attr_bgcol(p,*s)];
+		} else {
+			image.fg_color = ((u16*)info->pseudo_palette)[attr_fgcol(p,*s)];
+			image.bg_color = ((u16*)info->pseudo_palette)[attr_bgcol(p,*s)];
+	}
+}
+
+	image.dx = xx * fontwidth(p);
+	image.dy = yy * fontheight(p);
+	image.width = fontwidth(p);
+	image.height = fontheight(p);
+	image.depth = 1;
+
+	while (count--) {
+		image.data = p->fontdata +
+			(scr_readw(s++) & charmask) * fontheight(p) * width;
+		info->fbops->fb_imageblit(info, &image);
+		image.dx += fontwidth(p);
+	}
+}
+
+void fbcon_accel_revc(struct display *p, int xx, int yy)
+{
+	struct fb_info *info = p->fb_info;
+	struct fb_fillrect region;
+
+	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
+		region.color = attr_bgcol_ec(p, p->conp);
+	else {
+		if (info->var.bits_per_pixel > 16)
+			region.color = ((u32*)info->pseudo_palette)[attr_bgcol_ec(p,p->conp)];
+		else
+			region.color = ((u16*)info->pseudo_palette)[attr_bgcol_ec(p,p->conp)];
+	}
+	region.dx = xx * fontwidth(p);
+	region.dy = yy * fontheight(p);
+	region.width  = fontwidth(p);
+	region.height = fontheight(p); 
+	region.rop = ROP_XOR;
+	info->fbops->fb_fillrect(info, &region);
+}
+
+void fbcon_accel_clear_margins(struct vc_data *vc, struct display *p,
+			       int bottom_only)
+{
+	struct fb_info *info = p->fb_info;
+	unsigned int cw = fontwidth(p);
+	unsigned int ch = fontheight(p);
+	unsigned int rw = info->var.xres % cw;
+	unsigned int bh = info->var.yres % ch;
+	unsigned int rs = info->var.xres - rw;
+	unsigned int bs = info->var.yres - bh;
+	struct fb_fillrect region;
+
+	if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR)
+		region.color = attr_bgcol_ec(p,vc);
+	else {
+		if (info->var.bits_per_pixel > 16)
+			region.color = ((u32*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
+		else
+			region.color = ((u16*)info->pseudo_palette)[attr_bgcol_ec(p,vc)];
+	}
+
+	if (rw && !bottom_only) {
+		region.dx = info->var.xoffset + rs;
+		region.dy = 0;
+		region.width  = rw;
+		region.height = info->var.yres_virtual;
+		region.rop = ROP_COPY;
+		info->fbops->fb_fillrect(info, &region); 
+	}
+
+	if (bh) {
+		region.dx = info->var.xoffset;
+                region.dy = info->var.yoffset + bs;
+                region.width  = rs;
+                region.height = bh;
+                region.rop = ROP_COPY;
+		info->fbops->fb_fillrect(info, &region);
+	}
+}
+
+    /*
+     *  `switch' for the low level operations
+     */
+
+struct display_switch fbcon_accel = {
+	setup:		fbcon_accel_setup,
+	bmove:		fbcon_accel_bmove,
+	clear:		fbcon_accel_clear,
+	putc:		fbcon_accel_putc,
+	putcs:		fbcon_accel_putcs,
+	revc:		fbcon_accel_revc,
+	clear_margins:	fbcon_accel_clear_margins,
+	fontwidthmask:	FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16)
+};
+
+#ifdef MODULE
+MODULE_LICENSE("GPL");
+
+int init_module(void)
+{
+    return 0;
+}
+
+void cleanup_module(void)
+{}
+#endif /* MODULE */
+
+
+    /*
+     *  Visible symbols for modules
+     */
+
+EXPORT_SYMBOL(fbcon_accel);
+EXPORT_SYMBOL(fbcon_accel_setup);
+EXPORT_SYMBOL(fbcon_accel_bmove);
+EXPORT_SYMBOL(fbcon_accel_clear);
+EXPORT_SYMBOL(fbcon_accel_putc);
+EXPORT_SYMBOL(fbcon_accel_putcs);
+EXPORT_SYMBOL(fbcon_accel_revc);
+EXPORT_SYMBOL(fbcon_accel_clear_margins);

[Linux-fbdev-devel] [PATCH] fbdev accel wrapper.

[James S. <jsi...@tr...>]

Hi!
 
  This patch provides a wrapper to use a graphics card's accel engine.
This is a needed step to remove the mess with fbcon-cfb* etc. No driver
has been changed. Just the wrapper has been provided. Geert with your
blessing I like to see it applied to the DJ tree.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/