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

Re: [Linux-fbdev-devel] module_init == ?

[Ghozlane T. <gt...@pr...>]

You (Geert Uytterhoeven) wrote :
> In the beginning, all builtin drivers of the same class were initialized
in one
> place:
> | #ifdef CONFIG_DRIVER1
> |     driver1_init();
> | #endif
> Nowadays, the trend is to make drivers more self-contained by using
> module_{init,exit}(), so the above construct is no longer necessary.

so if i understand correctly, for fbdev drivers, as we still use the
"old" fashionned way , I should #ifdef MODULE the module_init call, right ?

ghoz

Re: [Linux-fbdev-devel] module_init == ?

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

On Mon, 18 Jun 2001, Ghozlane Toumi wrote:
> I have a small but essential question related to module_init /module_exit
> hum.
> basicaly "what those functions are doing ?" , nothing less ...
> 
> I guess the module initialisation calls the funciton specified by
> module_init,
> and same thing at module unload with module_exit, and my question is much
> more:
> 
> what happens if those macros are used within a *non* module context ?

Then (logical) driver module is still initialized.

In the beginning, all builtin drivers of the same class were initialized in one
place:

| #ifdef CONFIG_DRIVER1
|     driver1_init();
| #endif
| #ifdef CONFIG_DRIVER2
|     driver2_init();
| #endif
| #ifdef CONFIG_DRIVER3
|     driver3_init();
| #endif

Nowadays, the trend is to make drivers more self-contained by using
module_{init,exit}(), so the above construct is no longer necessary.

Caveat: watch out for the initialization order for modules initialized using
module_init(). It depends on the link order now.

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] module_init == ?

[Ghozlane T. <gt...@pr...>]

hello ,

I have a small but essential question related to module_init /module_exit
hum.
basicaly "what those functions are doing ?" , nothing less ...

I guess the module initialisation calls the funciton specified by
module_init,
and same thing at module unload with module_exit, and my question is much
more:

what happens if those macros are used within a *non* module context ?

thanks...

ghoz

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

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

> > > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630
> > > > based laptop - linux-2.4.5-ac13).
> > > 
> > > You can do one of two things. Post both System.map and the complete oops
> > > or you can run ksymoops on the oops. I can find the problem then. Thanks.
> > 
> > ksymoops' output is attached.
> 
> Is there any result with this trace??

Yes. It oops in fbcon_cfb8_putc. I haven't figured out yet what exactly
caused it. I don't have this card to play with :-( Did you run the other
test I suggested. Try booting at 640x480 with a color depth of 32. Then
try booting at a different resolution (1024x768) at the default color
depth. I want to see if its a error with the resolution setting or if it
is a error with setting up the data relating to the color depth handling. 
The results should give me some clue.

Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

> >
> > Are unalligned loads a bad thing in kernel drivers? I could modify the
> > driver, so that it only loads u32s from alligned adresses, but this would
> > either make character sizes where the number of bytes in a character
> > is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require
> > writing a extra u32 to the accel engine in half of the possible allignments,
> > or this this extra write could be avoided by shifting the data before writing
> > it to the accel engine.
>
> The main problem is that not all architectures support unaligned accesses. If
> you want to use them, you must use the get_unaligned() functions. Currently
> tdxfb doesn't do that.

That is a nice way of abstracting away the difference. There is however a small
problem with this approach and uncached memory. When reading n consecutive
words, it would read 2n words instead of the n+1 words required when one
manually alligns the data. This means that this is not the best way of reading
consecutive words from the framebuffer.

> Speedwise is not that bad these days anymore (supposed your CPU supports it),
> since font data is in cached memory and the memory controller will load the
> whole cacheline anyway, and the CPU runs at a much higher speed than the memory
> bus. Even doing successive individual byte loads won't slow it down much if
> your CPU is sufficiently faster than your memory bus.

I guess that I am just old-fashioned, and would prefer my inner loops as simple
as possible, even if this might be up to 5% slower sometimes, so I won't use
those allignment functions in this case.

To increase the speed, I probably shouldn't be using PIO, but instead set up a
command FIFO, so that the commands can be sent asyncroneously to the
accel engine. This way it is possible to write many commands into a buffer,
without having to wait for the accel engine.

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[René R. <ren...@gm...>]

Hi all!

On Wed, 13 Jun 2001 23:25:02 +0200
René Rebe <ren...@gm...> wrote:

> Thanks for the quick reply!
> 
> On Wed, 13 Jun 2001 09:54:21 -0700 (PDT)
> James Simmons <jsi...@tr...> wrote:
> 
> > 
> > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630
> > > based laptop - linux-2.4.5-ac13).
> > 
> > You can do one of two things. Post both System.map and the complete oops
> > or you can run ksymoops on the oops. I can find the problem then. Thanks.
> 
> ksymoops' output is attached.

Is there any result with this trace??

[...]

k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

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

On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> ----- Original Message -----
> From: "Geert Uytterhoeven" <ge...@li...>
> > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > From: "Geert Uytterhoeven" <ge...@li...>
> > > > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > > > I have a couple of further API questions.
> > > > >
> > > > > How about reading 3 bytes past the end of the bitmap.
> > > > > I have noticed that 3dfx driver carefully avoids this,
> > > > > but if this were allowed, it would avoid having a special case for
> > > > > the last 3 bytes.
> > > >
> > > > Which bitmap?
> > >
> > > The bitmap used for drawing characters with putc and putcs.
> >
> > You mean the font data?
> 
> Yes
> 
> > > I was wondering if reading 3 extra bytes past the end could
> > > cause a segmantation fault.
> >
> > In theory yes. But why would you want to read more fontdata than is present?
> 
> The 3dfx driver uses unalligned 32 bit loads to read the font data, and

Ugh, unaligned 32 bit loads...

> has a special case for the last bytes to avoid reading past the character data.
> If reading a few extra bytes were allowed, then this could be avoided by
> just reading the extra data, because the accel engine doesn't use the extra
> bytes in the last u32.
> 
> Are unalligned loads a bad thing in kernel drivers? I could modify the
> driver, so that it only loads u32s from alligned adresses, but this would
> either make character sizes where the number of bytes in a character
> is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require
> writing a extra u32 to the accel engine in half of the possible allignments,
> or this this extra write could be avoided by shifting the data before writing
> it to the accel engine.

The main problem is that not all architectures support unaligned accesses. If
you want to use them, you must use the get_unaligned() functions. Currently
tdxfb doesn't do that.

Speedwise is not that bad these days anymore (supposed your CPU supports it),
since font data is in cached memory and the memory controller will load the
whole cacheline anyway, and the CPU runs at a much higher speed than the memory
bus. Even doing successive individual byte loads won't slow it down much if
your CPU is sufficiently faster than your memory bus.

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] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

----- Original Message -----
From: "Geert Uytterhoeven" <ge...@li...>
To: "Martin Erhardsen" <Mar...@ma...>
Cc: "James Simmons" <jsi...@tr...>; <lin...@li...>
Sent: Saturday, June 16, 2001 4:18 PM
Subject: Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs


> On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > From: "Geert Uytterhoeven" <ge...@li...>
> > > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > > I have a couple of further API questions.
> > > >
> > > > How about reading 3 bytes past the end of the bitmap.
> > > > I have noticed that 3dfx driver carefully avoids this,
> > > > but if this were allowed, it would avoid having a special case for
> > > > the last 3 bytes.
> > >
> > > Which bitmap?
> >
> > The bitmap used for drawing characters with putc and putcs.
>
> You mean the font data?

Yes

> > I was wondering if reading 3 extra bytes past the end could
> > cause a segmantation fault.
>
> In theory yes. But why would you want to read more fontdata than is present?

The 3dfx driver uses unalligned 32 bit loads to read the font data, and
has a special case for the last bytes to avoid reading past the character data.
If reading a few extra bytes were allowed, then this could be avoided by
just reading the extra data, because the accel engine doesn't use the extra
bytes in the last u32.

Are unalligned loads a bad thing in kernel drivers? I could modify the
driver, so that it only loads u32s from alligned adresses, but this would
either make character sizes where the number of bytes in a character
is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require
writing a extra u32 to the accel engine in half of the possible allignments,
or this this extra write could be avoided by shifting the data before writing
it to the accel engine.

[Linux-fbdev-devel] RE: Questions about new Virtual framebuffer device

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

	Hi Caleb,

> Do I need to put something in /etc/modules.conf to get the vfb device
> working?  If so, what?

Ah, now I see what's the problem: vfb_enable is always 0 and you cannot enable
it when vfb is built modular.

Please try this patch:

--- linux-2.4.6-pre3/drivers/video/vfb.c.orig	Mon Feb 19 10:37:01 2001
+++ linux-2.4.6-pre3/drivers/video/vfb.c	Sat Jun 16 16:25:48 2001
@@ -68,8 +68,6 @@
     0, FB_VMODE_NONINTERLACED
 };
 
-static int vfb_enable = 0;	/* disabled by default */
-
 
     /*
      *  Interface used by the world
@@ -371,6 +369,9 @@
 }
 
 
+#ifndef MODULE
+static int vfb_enable = 0;	/* disabled by default */
+
 int __init vfb_setup(char *options)
 {
     char *this_opt;
@@ -389,6 +390,7 @@
     }
     return 0;
 }
+#endif
 
 
     /*
@@ -397,8 +399,10 @@
 
 int __init vfb_init(void)
 {
+#ifndef MODULE
     if (!vfb_enable)
 	return -ENXIO;
+#endif
 
     if (!(videomemory = (u_long)vmalloc(videomemorysize)))
 	return -ENOMEM;

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] Two bugs in fbcon_putcs

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

On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> From: "Geert Uytterhoeven" <ge...@li...>
> > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > I have a couple of further API questions.
> > >
> > > How about reading 3 bytes past the end of the bitmap.
> > > I have noticed that 3dfx driver carefully avoids this,
> > > but if this were allowed, it would avoid having a special case for
> > > the last 3 bytes.
> >
> > Which bitmap?
> 
> The bitmap used for drawing characters with putc and putcs.

You mean the font data?

> I was wondering if reading 3 extra bytes past the end could
> cause a segmantation fault.

In theory yes. But why would you want to read more fontdata than is present?

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] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

----- Original Message -----
From: "Geert Uytterhoeven" <ge...@li...>
To: "Martin Erhardsen" <Mar...@ma...>
Cc: "James Simmons" <jsi...@tr...>; <lin...@li...>
Sent: Saturday, June 16, 2001 10:48 AM
Subject: Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs


> On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > I have a couple of further API questions.
> >
> > How about reading 3 bytes past the end of the bitmap.
> > I have noticed that 3dfx driver carefully avoids this,
> > but if this were allowed, it would avoid having a special case for
> > the last 3 bytes.
>
> Which bitmap?

The bitmap used for drawing characters with putc and putcs.
I was wondering if reading 3 extra bytes past the end could
cause a segmantation fault.

Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

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

On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> I have a couple of further API questions.
> 
> How about reading 3 bytes past the end of the bitmap.
> I have noticed that 3dfx driver carefully avoids this,
> but if this were allowed, it would avoid having a special case for
> the last 3 bytes.

Which bitmap?

> Why not make the fbcon colormap 32 bits in 16 bpp modes too.
> This would use some extra bytes, but would avoid deciding
> between reading 16 or 32 bits from the colormap in putc and putcs.

Because it's not a real colormap but a map from console colors to pixel values?
(In theory we we would need it for bpp 8 etc. too). What with a card that has
pixels larger than 32 bit?

In 2.5.x you'll be able to do what you want, since the contents can be device
private, through your card's accel implementation.

Well, in fact you can use 32 bpp in your driver in 2.4.x as well, as long as
you no longer use _any_ fbcon-cfb* routines.

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] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

 > Yep. putcs write only one line and does not wrap. This is a good thing
> as it makes life easier. putcs is used when you do a cat /dev/tty3 for
> example. It prints the current contents of the screen but note no
> colors/attributes. You use vcsa to do this instead.

Okay that case does not occur. I have a couple of further API questions.

How about reading 3 bytes past the end of the bitmap.
I have noticed that 3dfx driver carefully avoids this,
but if this were allowed, it would avoid having a special case for
the last 3 bytes.

Why not make the fbcon colormap 32 bits in 16 bpp modes too.
This would use some extra bytes, but would avoid deciding
between reading 16 or 32 bits from the colormap in putc and putcs.

Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

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

> Because of this is correct behavior. Upper layer passes data to
> putcs() so that end of line is not crossed and all characters have
> same color.
> 
> If some console code passes buffer with different attributes or buffer
> which crosses end of line, then that console code is buggy.
>                                             Best regards,
>                                                     Petr Vandrovec
>                                                     van...@vc...
> 
> P.S.: James, if this is not in fbdev API doc, it definitely should.

Yep. putcs write only one line and does not wrap. This is a good thing
as it makes life easier. putcs is used when you do a cat /dev/tty3 for
example. It prints the current contents of the screen but note no
colors/attributes. You use vcsa to do this instead.

Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

[Petr V. <VAN...@vc...>]

On 15 Jun 01 at 23:05, Martin Erhardsen wrote:
> I have noticed two bugs in most fbcon implementations of putcs.
> 
> They only use the colours of the first colour/character pair.
> 
> They don't wrap correctly (like vga) at the end of the line.
> 
> I am wondering why no one has noticed this before.

Because of this is correct behavior. Upper layer passes data to
putcs() so that end of line is not crossed and all characters have
same color.

If some console code passes buffer with different attributes or buffer
which crosses end of line, then that console code is buggy.
                                            Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...

P.S.: James, if this is not in fbdev API doc, it definitely should.
                                                    

[Linux-fbdev-devel] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

I have noticed two bugs in most fbcon implementations of putcs.

They only use the colours of the first colour/character pair.

They don't wrap correctly (like vga) at the end of the line.

I am wondering why no one has noticed this before.

Re: [Linux-fbdev-devel] Why do I get this error in aty128fb.c

[Brad D. <br...@ne...>]

On 15 Jun 2001 22:25:44 +0200, Otto Wyss wrote:
> > Is this in the 2.2.x kernel?  Hmm, that should have been changed to match
> > modern gcc awhile ago.  I guess the patch was never accepted.
> > 
> No it's in kernel 2.4.3 and probably in 2.4.5 as well.
> 
> > Change that line to:
> > 
> > DBG("engine reset %s", "");
> > 
> This should not be necessary, if I interpret the gcc manual correct (see
> "http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC76"). 

You'd think so.  And in fact, at one point, it DID work as documented.

It's just a minor inconvenience at worst, but if you'd like to make note
of that to the gcc people, I'd appreciate it.

Brad Douglas
br...@ne...

Re: [Linux-fbdev-devel] Why do I get this error in aty128fb.c

[Otto W. <ott...@bl...>]

> Is this in the 2.2.x kernel?  Hmm, that should have been changed to match
> modern gcc awhile ago.  I guess the patch was never accepted.
> 
No it's in kernel 2.4.3 and probably in 2.4.5 as well.

> Change that line to:
> 
> DBG("engine reset %s", "");
> 
This should not be necessary, if I interpret the gcc manual correct (see
"http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC76"). 

O. Wyss

Re: [Linux-fbdev-devel] Why do I get this error in aty128fb.c

[Brad D. <br...@ne...>]

On 15 Jun 2001 21:28:27 +0200, Otto Wyss wrote:
> I tried to set the debug option in the driver "aty128fb.c" but get this
> error:
> 
> aty128fb.c: In function `aty128_reset_engine':
> aty128fb.c:655: parse error before `)'
> Source:-------------------------------------------
> ...
> #define DEBUG
> #ifdef DEBUG
> #define DBG(fmt, args...)	printk(KERN_DEBUG "aty128fb: %s " fmt,
> __FUNCTION__, ## args);
> #else
> #define DBG(fmt, args...)
> #endif
> ...
>     DBG("engine reset");
>     ^^^^^^^^^^^^^^^^^^^
>     here comes the error

Is this in the 2.2.x kernel?  Hmm, that should have been changed to match
modern gcc awhile ago.  I guess the patch was never accepted.

Change that line to:

DBG("engine reset %s", "");

Brad Douglas
br...@ne...

[Linux-fbdev-devel] Why do I get this error in aty128fb.c

[Otto W. <ott...@bl...>]

I tried to set the debug option in the driver "aty128fb.c" but get this
error:

aty128fb.c: In function `aty128_reset_engine':
aty128fb.c:655: parse error before `)'
Source:-------------------------------------------
...
#define DEBUG
#ifdef DEBUG
#define DBG(fmt, args...)	printk(KERN_DEBUG "aty128fb: %s " fmt,
__FUNCTION__, ## args);
#else
#define DBG(fmt, args...)
#endif
...
    DBG("engine reset");
    ^^^^^^^^^^^^^^^^^^^
    here comes the error
--------------------------------------------------

From the gcc manual this should be okay.

I'm using kernel 2.4.3 and a Debian woody system.

Re: [Linux-fbdev-devel] mode change policy

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

> No, but it was suggested that just changing the color bitfields to acceptable
> values (this can involve rounding up or down) could be acceptable.

Okay. 

Re: [Linux-fbdev-devel] mode change policy

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

> > Youo have to make sure
> > your check_var function would do the right thing.
> 
> I don't have a 'check_var'. It's vanilla 2.2/2.4
> fbcon (using fbgen, no less ;-)

No problem. I will have a patch for a wrapper soon.

> I'll port to Ruby as soon as BenH update his PPC
> tree to 2.4.5+ (2.4.5pre3-* hasn't all the required
> symbol for current Ruby, and 2.4.5-linus doesn't
> compile on my box...)

Never been tested on a PPC. This will be interesting:-)

Re: [Linux-fbdev-devel] Re: mode change policy

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

> > Guess what. I already have something like this in the console CVS. sfb.c
> > (Simple frame buffer device). It needs some work tho. Also I pretty much
> > have made every function in fb_ops a option.
> 
> OK, so vesafb and offb just don't fill in a set_var function, right?

Pretty much. Or in the case of teh new api fb_check_var nor fb_set_par are
needed.

[Linux-fbdev-devel] Re: [Linux-fbdev-users] rivafb and lilo.conf params

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

> Thanks James, here it is:

I wanted to see if it was a fbcon-cfbX issue. It is not. Does it boot with
the default mode? Next try to see if it boots with the defualt mode except
change the color depth. Then try a different resolution but the color
depth is the default. This will give a clue to what is wrong.

[Linux-fbdev-devel] Re: mode change policy

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

On Fri, 15 Jun 2001, James Simmons wrote:
> > > > If you can't change modes, the rule is still to round up, if possible. So if
> > > > you try a mode where all parameters <= the only one supported mode, then you
> > > > should return the only one supported mode. Else you should return -EINVAL.
> > > 
> > > All the parameters? This makes for a meaty checking function. 
> > 
> > Yes, I've been thinking about providing a `staticfb' core for drivers that
> > support one video mode only. Vesafb and offb (and a few of the PA-RISC drivers
> > IIRC) can be build on top of that, with minimal additional code.
> 
> Guess what. I already have something like this in the console CVS. sfb.c
> (Simple frame buffer device). It needs some work tho. Also I pretty much
> have made every function in fb_ops a option.

OK, so vesafb and offb just don't fill in a set_var function, right?

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