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

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

> Good news is that 2.5.59 seems quite stable as regards framebuffer.
> It no longer locks up after loading fbcon. But rmmod fbcon still
> causes instant death accompanied by increased whirring noises from inside
> box.

rmmod is really broken for fbcon. It shuts down the VT console system. It 
needs work in this area.

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

[Ani J. <aj...@un...>]

Try patching your 2.4.18 with

http://gate.crashing.org/~ajoshi/radeonfb-0.1.6.diff.gz

(I forget which kernel I made this diff against, but it shouldn't complain
much.)


ani



On Fri, 24 Jan 2003, Sven Luther wrote:

> Hello, ...
>
> I am trying to use a Radeon 9000 on my pegasos board, and had the same
> success with it as with the matrox millenium II i used previously. Well,
> it is even worse, since radeonfb doesn't even output a bit in the boot
> log.
>
> After a bit of thinking, i realize that this is quite normal, sine i
> have to use a 2.4.18 kernel, which knows nothing of the Radeon 9000,
> since it did not exist at that time.
>
> So, my questions are :
>
>   1) is it ok to just add the Radeon 9000 pci ids and whatever to the
>   2.4.28 kernel and hope it works. (Maybe not, but then the Radeon 9000
>   and the Radeon 8500 are supposed to be really similar).
>
>   2) Does anyone know how to check the pci ids of such a card from OF ?
>
>   3) Are the 2.5.x kernel working on powerpc, and if yes, is the
>   radeonfb driver ported ?
>
> Friendly,
>
> Sven Luther
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

Re: [Linux-fbdev-devel] [PATCH] 2.5.59 for ATI Mach64(port from Daniel code for 2.5.59)

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

> Am Freitag, 17. Januar 2003 22:27 schrieb Alexander Kern:
> > Hi, tested with ATI RAGE 3D MOBILITY M1 (P/M). 1400x1050 works, i assume
> > all others must work too.
> 
> Arrrrh, full speed back.
> 
> Please don't beat me, it works only with 1400x1050 on exetern CRT, image 
> timing for LCD is incorrect

Do you want me to applied the changes still?

[Linux-fbdev-devel] Re: [PATCH]: i810fb updates

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

Applied.

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

[Sven L. <lu...@dp...>]

On Fri, Jan 24, 2003 at 10:04:23AM +0100, Sven Luther wrote:
> Hello, ...
> 
> I am trying to use a Radeon 9000 on my pegasos board, and had the same
> success with it as with the matrox millenium II i used previously. Well,
> it is even worse, since radeonfb doesn't even output a bit in the boot
> log.
> 
> After a bit of thinking, i realize that this is quite normal, sine i
> have to use a 2.4.18 kernel, which knows nothing of the Radeon 9000,
> since it did not exist at that time.
> 
> So, my questions are :
> 
>   1) is it ok to just add the Radeon 9000 pci ids and whatever to the
>   2.4.28 kernel and hope it works. (Maybe not, but then the Radeon 9000
>   and the Radeon 8500 are supposed to be really similar).

Mmm, i got the info from the 2.5.x radeonfb, and added it to the 2.4.18
radeonfb (just the pll thingies and the chip detection, as i didn't see
anything else specific in the 2.5.X radeonfb.c).

but the kernel dies with :

Oops: kernel access of bad area, sig: 11
NIP: C012DD40 XER: 20000000 LR: C012DD40 SP: C07F7E90 REGS: c07f7de0 TRAP:
0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 40000000
TASK = c07f6000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C012DD40 C07F7E90 C07F6000 00000000 C01E1DF0 C02ADF4C C07DA299 00000003
GPR08: C01E1AC4 00000001 00000006 00000000 82002022 FFFC507C 00000034 00000014
GPR16: FFFFFFFF FDFFFDF7 FFFFDFFF FFFFFFFF 003FF000 C07DA299 00EFFF48 00EFFF4C
GPR24: 00000000 002AF8FC 40010000 C07DA288 C07EC000 C07DA000 C07EC000 C07DA000
Call backtrace:
C012DD40 C012D364 C012CD9C C0122598 C012262C C023EF64 C023E114
C0236294 C02267B0 C02267FC C0003F1C C0006AB4

the call trace corresponds to :

radeon_read_OF
radeon_get_pllinfo
radoenfb_pci_register
...

I suppose there is something wrong with the data passed from OF, but may
be wrong. I will now try to dump the content of the OF that is created
by the kernel in the begining, just to check it is ok. Any hint on how
to best do this ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

[Sven L. <lu...@dp...>]

On Fri, Jan 24, 2003 at 10:34:10AM +0100, Geert Uytterhoeven wrote:
> On Fri, 24 Jan 2003, Sven Luther wrote:
> > On Fri, Jan 24, 2003 at 10:23:19AM +0100, Geert Uytterhoeven wrote:
> > > On Fri, 24 Jan 2003, Sven Luther wrote:
> > > >   2) Does anyone know how to check the pci ids of such a card from OF ?
> > > 
> > > dev /<path_to_device> (use `dev' and `ls' to find out)
> > > .properties
> > 
> > Ok, thanks, will try, it is much easier (i guess) than blindly typing
> > stuff in the the display less linux, and moving the disk (and the pci
> > scsi card) between boxes. I already broke a pin of the vga connector
> > attached to my monitor by doing this and had to buy a new monitor.
> 
> Serial console is still not working?

Yes, for boot log output, but it hangs after i get the first debian
screen. I guess it is a problem with the the debian boot floppies i use,
i think i should create a root partition with a serial console enabling
inittab, or something such, i didn't had time to work much at this right
now though.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

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

On Fri, 24 Jan 2003, Sven Luther wrote:
> On Fri, Jan 24, 2003 at 10:23:19AM +0100, Geert Uytterhoeven wrote:
> > On Fri, 24 Jan 2003, Sven Luther wrote:
> > >   2) Does anyone know how to check the pci ids of such a card from OF ?
> > 
> > dev /<path_to_device> (use `dev' and `ls' to find out)
> > .properties
> 
> Ok, thanks, will try, it is much easier (i guess) than blindly typing
> stuff in the the display less linux, and moving the disk (and the pci
> scsi card) between boxes. I already broke a pin of the vga connector
> attached to my monitor by doing this and had to buy a new monitor.

Serial console is still not working?

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

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

[Sven L. <lu...@dp...>]

On Fri, Jan 24, 2003 at 10:23:19AM +0100, Geert Uytterhoeven wrote:
> On Fri, 24 Jan 2003, Sven Luther wrote:
> >   2) Does anyone know how to check the pci ids of such a card from OF ?
> 
> dev /<path_to_device> (use `dev' and `ls' to find out)
> .properties

Ok, thanks, will try, it is much easier (i guess) than blindly typing
stuff in the the display less linux, and moving the disk (and the pci
scsi card) between boxes. I already broke a pin of the vga connector
attached to my monitor by doing this and had to buy a new monitor.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

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

On Fri, 24 Jan 2003, Sven Luther wrote:
>   2) Does anyone know how to check the pci ids of such a card from OF ?

dev /<path_to_device> (use `dev' and `ls' to find out)
.properties

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] Radeon 9000 on a linux 2.4.18 kernel.

[Sven L. <lu...@dp...>]

Hello, ...

I am trying to use a Radeon 9000 on my pegasos board, and had the same
success with it as with the matrox millenium II i used previously. Well,
it is even worse, since radeonfb doesn't even output a bit in the boot
log.

After a bit of thinking, i realize that this is quite normal, sine i
have to use a 2.4.18 kernel, which knows nothing of the Radeon 9000,
since it did not exist at that time.

So, my questions are :

  1) is it ok to just add the Radeon 9000 pci ids and whatever to the
  2.4.28 kernel and hope it works. (Maybe not, but then the Radeon 9000
  and the Radeon 8500 are supposed to be really similar).

  2) Does anyone know how to check the pci ids of such a card from OF ?

  3) Are the 2.5.x kernel working on powerpc, and if yes, is the
  radeonfb driver ported ?

Friendly,

Sven Luther

[Linux-fbdev-devel] Some small problems...

[Stian H. <sti...@ki...>]

Hi, all !

I'm having a slight trouble with getting my hardware to work together
with the new 2.5.59 development kernel. The problems is as follows :

1. When compiling, the following framebuffer devices does not compile :
	- Cirrus Logic
	- Matrox
	- Riva (had some warnings)
	- Ati (Had to do some small hack in aty_base.c to get this compiling)

2. When I'm doing make modules_install everything stops. This I got
around by installing module-init-tools-0.9.8 - This is not a good
solutions (Or at least there should be some notes that you have to
install some external software packages to get the kernel compiled.)

3. When the compiling sequence is finished, and it is time for reboot,
there is no output on the screen after the grub startup manager.
(Sometimes I get the following : Uncompressing Linux... Ok, booting the
kernel.)The disk is working, and services are starting - But no output
on the monitor. I've tried different parameter to the vga= command, but
all have the same result.

4. Are there a list of framebuffer drivers that are verified on the
2.5.59 kernel ?


WBR Stian Hartviksen



My test equipment is as follows :

Machine #1:
- Pentium II, 266MHz, 128Mb
- ATI Rage Pro 3D (AGP)
- Nvidia Geforce 2 (PCI)
- Nvidia TNT 2 (PCI)
- Matrox Millenium II (PCI)
- Herkules S3virge (PCI)
- Cirrus Logic GD5434-8 (PCI)


Machine #2:
- Pentium 4, 2,4GHz, 512Mb
- Nvidia Geforce 4 MX420 (AGP)
- Nvidia Geforce 2 (PCI)
- Nvidia TNT 2 (PCI)
- Matrox Millenium II (PCI)
- Herkules S3virge (PCI)
- Cirrus Logic GD5434-8 (PCI)


Machine #3:
- Pentium 4, 2,4GHz, 256Mb
- ATI Radeon Mobility M6

Re: [Linux-fbdev-devel] Fwd: [PATCH 2.5.59] fix for fbcon.c

[Alexander K. <ale...@gm...>]

Hello,=20

thanks, it look good for me.

Regards

Alex Kern
Am Montag, 20. Januar 2003 09:45 schrieb Antonino Daplas:
> On Mon, 2003-01-20 at 02:56, Alexander Kern wrote:
> [...]
>
> > --- linux-2.5.orig/drivers/video/console/fbcon.c=092003-01-17
> > 16:13:53.000000000 +0100 +++
> > linux/drivers/video/console/fbcon.c=092003-01-19 19:17:23.000000000 +=
0100
> > @@ -1876,17 +1876,23 @@
> >  =09struct display *p =3D &fb_display[vc->vc_num];
> >  =09struct fb_info *info =3D p->fb_info;
> >  =09struct fb_var_screeninfo var =3D info->var;
> > -=09int err;
> > +=09int err; int x_diff, y_diff;
> >
> >  =09var.xres =3D width * vc->vc_font.width;
> >  =09var.yres =3D height * vc->vc_font.height;
> >  =09var.activate =3D FB_ACTIVATE_NOW;
> > -
> > +=09x_diff =3D info->var.xres - var.xres;
> > +=09y_diff =3D info->var.yres - var.yres;
> > +=09if(x_diff < 0 || x_diff > vc->vc_font.width ||
> > +=09  (y_diff < 0 || y_diff > vc->vc_font.height)) {
> > +=09=09DPRINTK("resize now %ix%i\n", var.xres, var.yres);
> >  =09err =3D fb_set_var(&var, info);
> >  =09return  (err || var.xres !=3D info->var.xres ||
> > -=09=09 var.yres !=3D info->var.yres) ?
> > -=09=09-EINVAL : 0;
> > -
> > +=09=09=09var.yres !=3D info->var.yres) ? -EINVAL : 0;
> > +=09} else {
> > +=09=09DPRINTK("prevent resize\n");
> > +=09=09return 0;
> > +=09}
> >  }
> >
> >  static int fbcon_switch(struct vc_data *vc)
>
> Yes, that will work, only if all your console have the same window
> size.  If the size of one of your console is different, then these test=
s
> (x_diff > vc->vc_font.width || y_diff > vc->vc_font.height) will become
> true each time you switch consoles, so you'll be back with a yres of
> 1040 instead of 1050.  The best solution is for the driver to round up
> to 1050 if 1040 is not acceptable.
>
> Still, its much better than the old one :-).  If you don't mind, I'll
> add a few things to your patch:
>
> a.  We do not need to activate the hardware immediately if there is a
> chance of failure.
>
> b.  The xres/yres returned from fb_set_var() will be acceptable as long
> as the value is within a fontwidth/fontheight. This should fix hardware
> that only has a limited set of video modes.
>
> BTW, I'm also attaching a diff to fix vc_resize() in vt.c. In
> vc_resize(), if con_resize() exits with an error, the new console
> dimensions are not reset to the original, and memory from kmalloc() is
> not freed.
>
> Tony
>
> PATCH 1: fbcon_resize
> << begin >>
>
> diff -Naur linux-2.5.59/drivers/video/console/fbcon.c
> linux/drivers/video/console/fbcon.c ---
> linux-2.5.59/drivers/video/console/fbcon.c=092003-01-20 08:19:50.000000=
000
> +0000 +++ linux/drivers/video/console/fbcon.c=092003-01-20 08:37:06.000=
000000
> +0000 @@ -1870,23 +1870,35 @@
>  }
>
>
> -static int fbcon_resize(struct vc_data *vc, unsigned int width,
> -=09=09=09unsigned int height)
> + static int fbcon_resize(struct vc_data *vc, unsigned int width,
> +=09=09=09 unsigned int height)
>  {
>  =09struct display *p =3D &fb_display[vc->vc_num];
>  =09struct fb_info *info =3D p->fb_info;
>  =09struct fb_var_screeninfo var =3D info->var;
> -=09int err;
> -
> -=09var.xres =3D width * vc->vc_font.width;
> -=09var.yres =3D height * vc->vc_font.height;
> -=09var.activate =3D FB_ACTIVATE_NOW;
> -
> -=09err =3D fb_set_var(&var, info);
> -=09return  (err || var.xres !=3D info->var.xres ||
> -=09=09 var.yres !=3D info->var.yres) ?
> -=09=09-EINVAL : 0;
> -
> +=09int err; int x_diff, y_diff;
> +=09int fw =3D vc->vc_font.width;
> +=09int fh =3D vc->vc_font.height;
> +
> +=09var.xres =3D width * fw;
> +=09var.yres =3D height * fh;
> +=09x_diff =3D info->var.xres - var.xres;
> +=09y_diff =3D info->var.yres - var.yres;
> +=09if (x_diff < 0 || x_diff > fw ||
> +=09    (y_diff < 0 || y_diff > fh)) {
> +=09=09var.activate =3D FB_ACTIVATE_TEST;
> +=09=09err =3D fb_set_var(&var, info);
> +=09=09if (err || width !=3D var.xres/fw ||
> +=09=09    height !=3D var.yres/fh)
> +=09=09=09return -EINVAL;
> +=09=09DPRINTK("resize now %ix%i\n", var.xres, var.yres);
> +=09=09var.activate =3D FB_ACTIVATE_NOW;
> +=09=09fb_set_var(&var, info);
> +=09=09p->vrows =3D info->var.yres_virtual/fh;
> +=09} else {
> +=09=09DPRINTK("prevent resize\n");
> +=09}
> +=09return 0;
>  }
>
>  static int fbcon_switch(struct vc_data *vc)
> << end >>
>
> PATCH 2: vc_resize
>
> << begin >>
>
> diff -Naur linux-2.5.59/drivers/char/vt.c linux/drivers/char/vt.c
> --- linux-2.5.59/drivers/char/vt.c=092003-01-20 08:18:11.000000000 +000=
0
> +++ linux/drivers/char/vt.c=092003-01-20 08:17:37.000000000 +0000
> @@ -732,6 +732,10 @@
>  =09if (new_cols =3D=3D video_num_columns && new_rows =3D=3D video_num_=
lines)
>  =09=09return 0;
>
> +=09err =3D resize_screen(currcons, new_cols, new_rows);
> +=09if (err)
> +=09=09return err;
> +
>  =09newscreen =3D (unsigned short *) kmalloc(new_screen_size, GFP_USER)=
;
>  =09if (!newscreen)
>  =09=09return -ENOMEM;
> @@ -746,9 +750,6 @@
>  =09video_size_row =3D new_row_size;
>  =09screenbuf_size =3D new_screen_size;
>
> -=09err =3D resize_screen(currcons, new_cols, new_rows);
> -=09if (err)
> -=09=09return err;
>
>  =09rlth =3D min(old_row_size, new_row_size);
>  =09rrem =3D new_row_size - rlth;
> << end >>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] fonts

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

On 22 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-22 at 00:14, Geert Uytterhoeven wrote:
> > On Wed, 15 Jan 2003, James Simmons wrote:
> > > > > The cfb_imageblit() function exhibited the same behavior.  I think we
> > > > > both made the wrong assumption that all monochrome bitmaps are packed. I
> > > > > think the rule is:
> > > > > 
> > > > >     The first pixel on the next scanline is always at the next byte from
> > > > >     the last pixel of the current scanline.  
> > > > > 
> > > > > So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> > > > > last 4 are used as padding.  It's worse with a 4x6 fonts where the
> > > > > 4-bits are just duplicated in the other nibble.
> > > > 
> > > > Yes.
> > > 
> > > All the font data should be packed and byte padded at the end of each 
> > > scanline worth of data. Also most accel engines expect the data to byte 
> > > packed.
> > 
> > What do you mean with `each scanline worth of data'? Data for one character, or
> > data for the whole font (i.e. all characters)?
> 
> I meant for each row of bits representing a pixel in a bitmap, the start
> index and the size of each row will be byte-aligned.  So, the padded
> version.

  [...]

> The latter is very difficult to support by most common hardware as they
> require the padding.  Actually, some, maybe most, cards require more
> than a byte padding. 

  [...]

> If we do need to support both versions, then we need extra fields to
> fb_image, such as clipx1 and clipx2, where: 
> 
> 	image.clipx1 = starting index;
> 	image.clipx2 = clipx1 + width;
> 
> (Do we also need something similar for the y coordinate?)

Or add sx and sy, cfr fb_copyarea. Makes clipping behave the same for both.

> I think I'll let you and James decide on this :-) 

I'm happy with the current scheme. I just wanted to be 100% what James meant
with `All the font data should be packed and byte padded at the end of each 
scanline worth of data.'.

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: Here is that sample

[<bi...@bo...>]

Attached file:

Re: [Linux-fbdev-devel] fonts

[Antonino D. <ad...@po...>]

On Wed, 2003-01-22 at 00:14, Geert Uytterhoeven wrote:
> On Wed, 15 Jan 2003, James Simmons wrote:
> > > > The cfb_imageblit() function exhibited the same behavior.  I think we
> > > > both made the wrong assumption that all monochrome bitmaps are packed. I
> > > > think the rule is:
> > > > 
> > > >     The first pixel on the next scanline is always at the next byte from
> > > >     the last pixel of the current scanline.  
> > > > 
> > > > So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> > > > last 4 are used as padding.  It's worse with a 4x6 fonts where the
> > > > 4-bits are just duplicated in the other nibble.
> > > 
> > > Yes.
> > 
> > All the font data should be packed and byte padded at the end of each 
> > scanline worth of data. Also most accel engines expect the data to byte 
> > packed.
> 
> What do you mean with `each scanline worth of data'? Data for one character, or
> data for the whole font (i.e. all characters)?

I meant for each row of bits representing a pixel in a bitmap, the start
index and the size of each row will be byte-aligned.  So, the padded
version.
> 
> Currently we use the former, while e.g. AmigaOS used the latter and stored
> fonts like this:
> 
>   - First line: concatenated bit string of the first lines of each character
>   - Second line: concatenated bit string of the second lines of each character
>   - and so on
> 
> I.e. each line looked like
> 
>     aaaaaaaaaaaabbbbbbbbbbbbccccccccccccdddddddddddd...
> 

> with a table to map between characters and starting bit index.
> 
> 
> The former has the following advantages:
>   - Character data always starts at a byte boundary
>   - It's easy to store fonts in a common format (i.e. the same for both little
>     and big endian, currently fonts are stored big endian)
> 
> The latter has the following advantages: 
>   - Less memory waste if fontwidth % 8 != 0
>   - Easy to support proportional (variable width) fonts
> 

The latter is very difficult to support by most common hardware as they
require the padding.  Actually, some, maybe most, cards require more
than a byte padding. 

If we do need to support both versions, then we need extra fields to
fb_image, such as clipx1 and clipx2, where: 

	image.clipx1 = starting index;
	image.clipx2 = clipx1 + width;

(Do we also need something similar for the y coordinate?)

Using a 12x22 font as an example:

In the first (padded) version, 

	image.width = 16;
	image.clipx1 = 0;
	image.clipx2 = 12;

whereas in the second (packed) version:

	image.width = 12;
	image.clipx1 = depends on the character;
	image.clipx2 =  image.clipx1 + image.width;

I can't really think of any other way if we need to support both types
of bitmap in a device and OS independent manner.

I think I'll let you and James decide on this :-) 

Tony

Re: [Linux-fbdev-devel] fonts

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

On Wed, 15 Jan 2003, James Simmons wrote:
> > > The cfb_imageblit() function exhibited the same behavior.  I think we
> > > both made the wrong assumption that all monochrome bitmaps are packed. I
> > > think the rule is:
> > > 
> > >     The first pixel on the next scanline is always at the next byte from
> > >     the last pixel of the current scanline.  
> > > 
> > > So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> > > last 4 are used as padding.  It's worse with a 4x6 fonts where the
> > > 4-bits are just duplicated in the other nibble.
> > 
> > Yes.
> 
> All the font data should be packed and byte padded at the end of each 
> scanline worth of data. Also most accel engines expect the data to byte 
> packed.

What do you mean with `each scanline worth of data'? Data for one character, or
data for the whole font (i.e. all characters)?

Currently we use the former, while e.g. AmigaOS used the latter and stored
fonts like this:

  - First line: concatenated bit string of the first lines of each character
  - Second line: concatenated bit string of the second lines of each character
  - and so on

I.e. each line looked like

    aaaaaaaaaaaabbbbbbbbbbbbccccccccccccdddddddddddd...

with a table to map between characters and starting bit index.


The former has the following advantages:
  - Character data always starts at a byte boundary
  - It's easy to store fonts in a common format (i.e. the same for both little
    and big endian, currently fonts are stored big endian)

The latter has the following advantages: 
  - Less memory waste if fontwidth % 8 != 0
  - Easy to support proportional (variable width) fonts

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

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Antonino D. <ad...@po...>]

On Tue, 2003-01-21 at 18:29, Geert Uytterhoeven wrote:
> On 21 Jan 2003, Antonino Daplas wrote:
> > The only problem right now is how do you pass the monitor info to the
> > driver?  The best way is to parse the EDID block and use I2C/DDC. 
> > Personally, I think passing the monitor info as a boot/module option is
> > the simplest and safest method.
> 
> Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?
> 
> Since ioctls are considered evil these days, changing the resolution etc. could
> work in a similar way as well.
> 

True, but I prefer having the monitor limits at driver load time so I
can immediately go into a high resolution.

Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

On 21 Jan 2003, Antonino Daplas wrote:
> The only problem right now is how do you pass the monitor info to the
> driver?  The best way is to parse the EDID block and use I2C/DDC. 
> Personally, I think passing the monitor info as a boot/module option is
> the simplest and safest method.

Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?

Since ioctls are considered evil these days, changing the resolution etc. could
work in a similar way as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Writing a driver for a 128*64 dots LCD (black/white only)

[Voser P. <pet...@si...>]

Hello, 
I have the pleasure to write a driver for a 128*64 dots LCD. 
It's just a black and white display (without grey scale). 
The display is connected to a KS0713 controler circuit. 

Questions: 
- What window messenger do I have to use in order to write 
  texts and draw bitmaps?
- Can anyone recommend a driver I can use as an example?
- How can I edit bitmaps?

Regards, 
Peter

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Antonino D. <ad...@po...>]

On Tue, 2003-01-21 at 03:09, Jak wrote:
> 
> >  int __init rivafb_init(void)
> >  {
> > -	int err;
> > -	err = pci_module_init(&rivafb_driver);
> > -	if (err)
> > -		return err;
> > -	pci_register_driver(&rivafb_driver);
> > -	return 0;
> > +	return pci_module_init(&rivafb_driver);
> >  }
> >

Hmm, come to think of it, pci_module_init() is old-style.  Using

return (pci_register_driver(&rivafb_driver) > 0) ? 0 : -ENODEV;

instead is better and will allow the rivafb driver to appear in sysfs.
Anyway, pci_module_init() should not be called since
pci_register_driver() already does that for you.  That's what causing
the "Badness" in kobject.

Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Antonino D. <ad...@po...>]

On Tue, 2003-01-21 at 03:09, Jak wrote:
> Tony,
> 	thanks for your patches, they have fixed most of the problems I had.
> >
> > Try running stty to fix your display.
> >
> I can't convince stty to do anything useful for me :
> 	do I need a specific/patched version ?

No.
> 	do I need to specify anything except rows cols values ?

No.
> 	how would I change the colour depth ?

You can still use fbset :-), except that as it currently stands, it
might corrupt the display if panning is enabled.  rivafb does not
support panning at bootup so fbset is safe to use.

> 	I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp,
> how can I tell stty that I want to use the equivalent of the timing values of
> any particular one of these 7 modes ( assuming timings are still relevant ) ?

Bullseye :-) This is one of the reasons I submitted the GTF
implementation patch (It's already in fbmon.c).  The patch will compute
the modelines for you given xres, yres and your monitor's operational
limits.  It has the advantage of computing the maximum refresh rate your
monitor is capable of, and it can theoretically calculate any mode
without the use of additional entries in /etc/fb.modes.  This is ideal
for VESA GTF compliant monitors but I have tested this with old monitors
as well.

Once you have changed to an appropriate window size, you can then use
fbset to fine-tune your display timings.

The only problem right now is how do you pass the monitor info to the
driver?  The best way is to parse the EDID block and use I2C/DDC. 
Personally, I think passing the monitor info as a boot/module option is
the simplest and safest method.

Once the above is done, adding support for GTF to a driver is just a
10-liner code.  I already did this for some of the drivers including
rivafb.

Of course, proprietary displays will need their own modeline formula
which, if this is the case, the driver has to add its own algorithm or
use fbset tricks.  You can do something like this:

fbset 1600x1200-85 && stty cols 200 rows 75
 
> 	what was wrong with fbset which I have to keep for the forseeable
> future anyway until 2.6 approaches 2.4 reliability ?

Nothing's wrong with fbset, because if fbset becomes unusable, then so
will most fbdev-based applications.  We don't want that to happen.

The main difference is instead of fbdev telling the console to change
the window size, it's now the console telling fbdev to change the window
size.  As the console is blind to color depth, pixelformat, accel, etc,
you can still use fbset to change most of the above.

> >
> > So can you and Jak try the attached patch?  It should prevent VGA
> > console corruption on insmod and it should eliminate the kobject trace
> > messages.
> >
> Using your 3 recent patches together clears up the green screen problem
> and text corruption as well as kobject "badness".
> 
> >  int __init rivafb_init(void)
> >  {
> > -	int err;
> > -	err = pci_module_init(&rivafb_driver);
> > -	if (err)
> > -		return err;
> > -	pci_register_driver(&rivafb_driver);
> > -	return 0;
> > +	return pci_module_init(&rivafb_driver);
> >  }
> >
> This will normally return 1, not 0 as before. Is this intended ?

The above should return 0 if successful.


Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Jak <rf...@ei...>]

Tony,
=09thanks for your patches, they have fixed most of the problems I had.
>
> Try running stty to fix your display.
>
I can't convince stty to do anything useful for me :
=09do I need a specific/patched version ?
=09do I need to specify anything except rows cols values ?
=09how would I change the colour depth ?
=09I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp,
how can I tell stty that I want to use the equivalent of the timing value=
s of
any particular one of these 7 modes ( assuming timings are still relevant=
 ) ?
=09what was wrong with fbset which I have to keep for the forseeable
future anyway until 2.6 approaches 2.4 reliability ?
>
> So can you and Jak try the attached patch?  It should prevent VGA
> console corruption on insmod and it should eliminate the kobject trace
> messages.
>
Using your 3 recent patches together clears up the green screen problem
and text corruption as well as kobject "badness".

>  int __init rivafb_init(void)
>  {
> -=09int err;
> -=09err =3D pci_module_init(&rivafb_driver);
> -=09if (err)
> -=09=09return err;
> -=09pci_register_driver(&rivafb_driver);
> -=09return 0;
> +=09return pci_module_init(&rivafb_driver);
>  }
>
This will normally return 1, not 0 as before. Is this intended ?

[Linux-fbdev-devel] Re: Patches for fbtest

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

On Sun, 1 Dec 2002, Jon Smirl wrote:
> This patch fixes the syntax in fbtest so that gcc 3.2

Thanks! I applied most of them.

> is happy. I also adjusted the libs for the current
> version of libnetpbm.
> 
> I went searching for libnetpnm which doesn't seem to
> exist standalone any more. It is part of libnetpbm
> now.

Hmm, this one is more problematic. It seems to depend on your distribution (I
use Debian).

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] [PATCH] fbset.c - fixes mode info (fwd)

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

---------- Forwarded message ----------
Date: 18 Jan 2003 16:10:12 +0100
From: Fredrik Noring <no...@no...>
To: Geert Uytterhoeven <ge...@li...>
Cc: Petr Vandrovec <van...@vc...>
Subject: [PATCH] fbset.c - fixes mode info

Hi,

Please apply this fix to report proper negative sync polarity.

Thanks,

	Fredrik

--- fbset-2.1.old/fbset.c	1999-06-23 16:11:46.000000000 +0200
+++ fbset-2.1.new/fbset.c	2003-01-18 15:55:02.000000000 +0100
@@ -629,8 +629,12 @@
 	       vmode->hslen, vmode->vslen);
 	if (vmode->hsync)
 	    puts("    hsync high");
+	else
+	    puts("    hsync low");
 	if (vmode->vsync)
 	    puts("    vsync high");
+	else
+	    puts("    vsync low");
 	if (vmode->csync)
 	    puts("    csync high");
 	if (vmode->gsync)

Re: [Linux-fbdev-devel] Fwd: [PATCH 2.5.59] fix for fbcon.c

[Antonino D. <ad...@po...>]

On Mon, 2003-01-20 at 02:56, Alexander Kern wrote: 
[...] 
> --- linux-2.5.orig/drivers/video/console/fbcon.c	2003-01-17 16:13:53.000000000 +0100
> +++ linux/drivers/video/console/fbcon.c	2003-01-19 19:17:23.000000000 +0100
> @@ -1876,17 +1876,23 @@
>  	struct display *p = &fb_display[vc->vc_num];
>  	struct fb_info *info = p->fb_info;
>  	struct fb_var_screeninfo var = info->var;
> -	int err;
> +	int err; int x_diff, y_diff;
>  
>  	var.xres = width * vc->vc_font.width;
>  	var.yres = height * vc->vc_font.height;
>  	var.activate = FB_ACTIVATE_NOW;
> -
> +	x_diff = info->var.xres - var.xres;
> +	y_diff = info->var.yres - var.yres;
> +	if(x_diff < 0 || x_diff > vc->vc_font.width ||
> +	  (y_diff < 0 || y_diff > vc->vc_font.height)) {
> +		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
>  	err = fb_set_var(&var, info);
>  	return  (err || var.xres != info->var.xres ||
> -		 var.yres != info->var.yres) ?
> -		-EINVAL : 0;
> -	  
> +			var.yres != info->var.yres) ? -EINVAL : 0;
> +	} else {
> +		DPRINTK("prevent resize\n");
> +		return 0;
> +	}
>  }
>  
>  static int fbcon_switch(struct vc_data *vc)

Yes, that will work, only if all your console have the same window
size.  If the size of one of your console is different, then these tests
(x_diff > vc->vc_font.width || y_diff > vc->vc_font.height) will become
true each time you switch consoles, so you'll be back with a yres of
1040 instead of 1050.  The best solution is for the driver to round up
to 1050 if 1040 is not acceptable. 

Still, its much better than the old one :-).  If you don't mind, I'll
add a few things to your patch: 

a.  We do not need to activate the hardware immediately if there is a
chance of failure. 

b.  The xres/yres returned from fb_set_var() will be acceptable as long
as the value is within a fontwidth/fontheight. This should fix hardware
that only has a limited set of video modes. 

BTW, I'm also attaching a diff to fix vc_resize() in vt.c. In
vc_resize(), if con_resize() exits with an error, the new console
dimensions are not reset to the original, and memory from kmalloc() is
not freed.  

Tony 

PATCH 1: fbcon_resize 
<< begin >> 

diff -Naur linux-2.5.59/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.59/drivers/video/console/fbcon.c	2003-01-20 08:19:50.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-20 08:37:06.000000000 +0000
@@ -1870,23 +1870,35 @@
 }
 

-static int fbcon_resize(struct vc_data *vc, unsigned int width, 
-			unsigned int height)
+ static int fbcon_resize(struct vc_data *vc, unsigned int width, 
+			 unsigned int height)
 {
 	struct display *p = &fb_display[vc->vc_num];
 	struct fb_info *info = p->fb_info;
 	struct fb_var_screeninfo var = info->var;
-	int err;
-
-	var.xres = width * vc->vc_font.width;
-	var.yres = height * vc->vc_font.height;
-	var.activate = FB_ACTIVATE_NOW;
-
-	err = fb_set_var(&var, info);
-	return  (err || var.xres != info->var.xres ||
-		 var.yres != info->var.yres) ?
-		-EINVAL : 0;
-	  
+	int err; int x_diff, y_diff;
+	int fw = vc->vc_font.width;
+	int fh = vc->vc_font.height;
+
+	var.xres = width * fw;
+	var.yres = height * fh;
+	x_diff = info->var.xres - var.xres;
+	y_diff = info->var.yres - var.yres;
+	if (x_diff < 0 || x_diff > fw ||
+	    (y_diff < 0 || y_diff > fh)) {
+		var.activate = FB_ACTIVATE_TEST;
+		err = fb_set_var(&var, info);
+		if (err || width != var.xres/fw ||
+		    height != var.yres/fh)
+			return -EINVAL;
+		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
+		var.activate = FB_ACTIVATE_NOW;
+		fb_set_var(&var, info);
+		p->vrows = info->var.yres_virtual/fh;
+	} else {
+		DPRINTK("prevent resize\n");
+	}
+	return 0;
 }
 
 static int fbcon_switch(struct vc_data *vc)
<< end >> 

PATCH 2: vc_resize 

<< begin >> 

diff -Naur linux-2.5.59/drivers/char/vt.c linux/drivers/char/vt.c
--- linux-2.5.59/drivers/char/vt.c	2003-01-20 08:18:11.000000000 +0000
+++ linux/drivers/char/vt.c	2003-01-20 08:17:37.000000000 +0000
@@ -732,6 +732,10 @@
 	if (new_cols == video_num_columns && new_rows == video_num_lines)
 		return 0;
 
+	err = resize_screen(currcons, new_cols, new_rows);
+	if (err)
+		return err;
+
 	newscreen = (unsigned short *) kmalloc(new_screen_size, GFP_USER);
 	if (!newscreen)
 		return -ENOMEM;
@@ -746,9 +750,6 @@
 	video_size_row = new_row_size;
 	screenbuf_size = new_screen_size;
 
-	err = resize_screen(currcons, new_cols, new_rows);
-	if (err)
-		return err;
 
 	rlth = min(old_row_size, new_row_size);
 	rrem = new_row_size - rlth;
<< end >>