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

Re: [Linux-fbdev-devel] Supporting various depth

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

> > int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> > {
> >     int oldbpp, err;
> > 
> >     if (memcmp(&info->var, var, sizeof(var))) {
> >         if ((err = info->fbops->fb_check_var(var, info)))
> >                 return err;
> 
> This is not correct, since it first overwrites the old var, then checks whether
> the new one is valid. If that test fails, you're left with an invalid var in
> info->var.

That is a memory compare. It checks to see if the purposed mode is the
same as the current mode. If not then fb_check_var is called to test the
new var. info->var = var only if var->activate == FB_ACTIVATE_NOW and
their is a set_par function. You can set info->var = *var before set_par
is called because we trust check_var did its job. 
 

Re: [Linux-fbdev-devel] Supporting various depth

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

On Wed, Jun 13, 2001 at 05:29:44PM +0200, Geert Uytterhoeven wrote:
> On Wed, 13 Jun 2001, Sven LUTHER wrote:
> > On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > > the fbdev/fbcon layer ?
> > > 
> > > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> > > 
> > > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > > and support both internally, is there a requirement that
> > > > CFB16 is one or the other, ... ?
> > > 
> > > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> > 
> > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > RGBA5551 mode ? 
> 
> No, -depth actually means bits-per-pixel in fbset (yes this is a bug).

Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
setting RGB5551 ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Supporting various depth

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

On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 08:47:21AM -0700, James Simmons wrote:
> > > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > > RGBA5551 mode ? 
> > > 
> > > BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> > > support 8, 16, and 32 bpp ?
> 
> > > should only fbset -depth 32 be supported ?
> 
> mmm, well, the problem is that most current 'millions of color' modes are in
> truth depth 24 ones, which are internally either 32bpp (as in the permedia3
> case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to
> do some shifting).
> 
> Now, if a user wants to set a depth of 24, what does he mean ? mostly it is
> RGB 888, but for the user the presence of an alpha channel (32bpp) or not
> (24bpp) may not be that important. Especially Since X is using per default
> depth 24 with bpp 32.
> 
> So what should happen if you try to set depth 24 with fbset ? Silently set 32
> bpp ? reject it ?

Round it up to 32.

> Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> rejected ?

You cannot specify `depth 15', only `bits per pixel 15', which will be rounded
up to the driver to 16 (in most cases).

Set {red,green,blue,transp}.length to indicate which 16 bpp mode you really
want.

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] Supporting various depth

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

On Wed, 13 Jun 2001, James Simmons wrote:
> > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > RGBA5551 mode ? 
> > 
> > BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> > support 8, 16, and 32 bpp ?
> 
> fb_set_var should be done in two parts. The first part checks the purposed
> var and sees if the hardware can support it. The second part should set
> the resolution if the mode is supported. This is what I have done for the
> new api. Basically we have something like this: 
> 
> int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> {
>     int oldbpp, err;
> 
>     if (memcmp(&info->var, var, sizeof(var))) {
>         if ((err = info->fbops->fb_check_var(var, info)))
>                 return err;

This is not correct, since it first overwrites the old var, then checks whether
the new one is valid. If that test fails, you're left with an invalid var in
info->var.

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] Supporting various depth

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

On Wed, Jun 13, 2001 at 08:47:21AM -0700, James Simmons wrote:
> 
> > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > RGBA5551 mode ? 
> > 
> > BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> > support 8, 16, and 32 bpp ?

> > should only fbset -depth 32 be supported ?

mmm, well, the problem is that most current 'millions of color' modes are in
truth depth 24 ones, which are internally either 32bpp (as in the permedia3
case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to
do some shifting).

Now, if a user wants to set a depth of 24, what does he mean ? mostly it is
RGB 888, but for the user the presence of an alpha channel (32bpp) or not
(24bpp) may not be that important. Especially Since X is using per default
depth 24 with bpp 32.

So what should happen if you try to set depth 24 with fbset ? Silently set 32
bpp ? reject it ?

Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
rejected ?

> > Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> > the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> > ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> > would be really happy with it).
> 
>    Not really. You could make it reset the card when unloading the module.

or when loading it ?

> Log in remotely or use a serial console to do this. 

BTW, if dual head was really working i could do that, wait no, they both would
be using pm3fb. 

Would it be possible to run the vga text console on one head, and a pm3fb on
the other ? (same chip).

>   In theory when you run the program reset. It should reset your console
> back to the default mode. Unfortunely the console system doesn't work that
> way :-(  

Well, the real problem here is not so much to reset to default mode, but to do
a hardware reset on the chip, and initialize it again, to see if the problem
goes away.

The porblem only appears from time to time (but stays if i only do a reboot
:(((), and it seems that either the memory has some problem, or more probably
the accel unit, as this happens only when accel is enabled, and there are
areas where various pixels get some of their bits sets to 1.

Friendly,

Sven Luther
> 

Re: [Linux-fbdev-devel] Supporting various depth

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

> So i suppose saying fbset -depth 15 could be done to switch the fb to
> RGBA5551 mode ? 
> 
> BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> support 8, 16, and 32 bpp ?

fb_set_var should be done in two parts. The first part checks the purposed
var and sees if the hardware can support it. The second part should set
the resolution if the mode is supported. This is what I have done for the
new api. Basically we have something like this: 

int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
    int oldbpp, err;

    if (memcmp(&info->var, var, sizeof(var))) {
        if ((err = info->fbops->fb_check_var(var, info)))
                return err;

        if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
                oldbpp = info->var.bits_per_pixel;
                info->var = *var;

                if (info->fbops->fb_set_par)
                        info->fbops->fb_set_par(info);

                if (info->cursor.enable) {
                        info->cursor.set = FB_CUR_SETALL;
                        info->fbops->fb_cursor(info, &info->cursor);
                }

                if (oldbpp != var->bits_per_pixel) {
                        if ((err = fb_alloc_cmap(&info->cmap, 0, 0)))
                                return err;
                        fb_set_cmap(&info->cmap, 1, info);
                }
        }
        var->activate = 0;
    }
    return 0;
}
 
> should only fbset -depth 32 be supported ?

If that is all the card can support then yes. Say you pass a var that is
correct in everyway except for the depth then you could have the check_var
funciton alter the var and pass it back to userland (by changing var.activate).
This way if userland does a FB_ACTIVATE_TEST check_var only gets called
when testing the mode. Yes it is for 2.5.X but current drivers could
follow a similar layout now. It will also save much work in porting stuff
over when 2.5.X comes out.  

> Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> would be really happy with it).

   Not really. You could make it reset the card when unloading the module.
Log in remotely or use a serial console to do this. 

  In theory when you run the program reset. It should reset your console
back to the default mode. Unfortunely the console system doesn't work that
way :-(  

Re: [Linux-fbdev-devel] Supporting various depth

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

On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > the fbdev/fbcon layer ?
> > 
> > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> > 
> > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > and support both internally, is there a requirement that
> > > CFB16 is one or the other, ... ?
> > 
> > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> 
> So i suppose saying fbset -depth 15 could be done to switch the fb to
> RGBA5551 mode ? 

No, -depth actually means bits-per-pixel in fbset (yes this is a bug).

> BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> support 8, 16, and 32 bpp ?

Fbset should do nothing special, the fbdev should round up
fb_var_screeninfo.bpp to 32.

> should only fbset -depth 32 be supported ?

Huh?

> Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> would be really happy with it).

You can add a fbdev specific ioctl until you fixed the bug/worked around it.

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] Linux fbcon.c

[Florian L. <f.l...@ti...>]

Dear Mr Theron,

	sorry for answering so late. I'm just using the fbvga16. But I think
I'm gonna write a speciallized driver for the chip in the near future...

Regards Florian

Herman Theron wrote:
> 
> Hi Florian
> 
> Sorry, can't help you with your problem but just want to ask you something. I notice that your embedded board uses a C&T 65550 display chip, I assume
> you use the VESA framebuffer? I've got a POS system with the same chip,
> but I can't get to work properly for resolutions bigger than 640x480.
> I change the lilo.conf file with the vga=  parameter, and it boots, but the result is a 800x600 image displayed on 640x480 screen (right and bottom borders are clipped). Do you get the same result? What parameters do you use in your lilo.conf (maybe the append= line?)
> 
> Thanks very much for any info!
> 
> Herman
> 
> ****************************************
> Herman Theron
> Hermanus Magnetic Observatory
> CSIR
> PO Box 32
> Hermanus
> 7200
> South Africa
> E-mail: het...@cs...
> Phone: +27 28 3121196
> Fax: +27 28 3122039
> Cel: +27 82 697 8546
> 
> >>> Florian Lechner <f.l...@ti...> 06/08/01 03:04PM >>>
> ANYBODY OUT there to help me?
> 
> So my Question:
> 
>         I'm trying to rotate the fb by 180°.
> 
> Reason:
>         I have an embedded board ElanSC400, C&T 65550, etc.
> 
> I'm reading the driver/video code for a couple of days now, and pinned
> down myself to three points where I have to do changes to rotate the
> display.
> 
>         fbcon.c --> fbcon_putc
>         fbcon.c --> fbcon_putcs
>         fbmem.c --> fb_write
> 
> Is that correct?
> 
> Kind regards Florian
> 
> ANYBODY OUT there to help me?
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] Supporting various depth

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

On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields. 
> > 
> > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> 
> How does the user tell the system what he wants, then ? Will fbset
> recognize both -depth 15 and -depth 16 and fill the fields properly ?

No, use the -rgba option to specify the bitfield lengths.

> Right now, pm3fb just disregard whatever is in the length fields
> and use RGB8888/RGB565/CI8 for 32/16/8bpp (shame on me). Is there any
> requirements on the userland/the kernel about what is acceptable ?
> One could require RGB10_10_10_2 or RG232 or RGB4444, what is
> the driver supposed to to in case it doesn't support the required
> mode : change to a similar mode, do nothing,... ?

Driver should round up values until they fit, or return an error.

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] Supporting various depth

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

On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > the fbdev/fbcon layer ?
> 
> Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> 
> > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > and support both internally, is there a requirement that
> > CFB16 is one or the other, ... ?
> 
> Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.

So i suppose saying fbset -depth 15 could be done to switch the fb to
RGBA5551 mode ? 

BTW, what is fbset -depth 24 supposed to do, especially if the chip only
support 8, 16, and 32 bpp ?

should only fbset -depth 32 be supported ?

Also, i am experiencing some (maybe hardware) bugs, and would like to reset
the graphic chip. Is there an existing way to do this kind of stuff via ioctl
ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
would be really happy with it).

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Supporting various depth

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields. 
> 
> Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.

How does the user tell the system what he wants, then ? Will fbset
recognize both -depth 15 and -depth 16 and fill the fields properly ?

Right now, pm3fb just disregard whatever is in the length fields
and use RGB8888/RGB565/CI8 for 32/16/8bpp (shame on me). Is there any
requirements on the userland/the kernel about what is acceptable ?
One could require RGB10_10_10_2 or RG232 or RGB4444, what is
the driver supposed to to in case it doesn't support the required
mode : change to a similar mode, do nothing,... ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Supporting various depth

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

On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> the fbdev/fbcon layer ?

Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.

> pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> and support both internally, is there a requirement that
> CFB16 is one or the other, ... ?

Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.

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] Supporting various depth

[Romain D. <do...@ir...>]

Hello,

Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
the fbdev/fbcon layer ?

pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
(RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
and support both internally, is there a requirement that
CFB16 is one or the other, ... ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] fbdev and exported symbols

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

On Wed, 13 Jun 2001, Jeff Garzik wrote:
> Geert Uytterhoeven wrote:
> > On Tue, 12 Jun 2001, Jeff Garzik wrote:
> > > The default behavior for a module is to export all public functions,
> > > when no explicit EXPORT_SYMBOL is present.
> > 
> > Is this `new' behavior? I never heard about that before.
> 
> nope, definitely not new behavior.
> 
> put a test module in export-objs of a Makefile, include a few public
> functions and include linux/module.h... then see what appears :)

Then we indeed have to explicitly disable symbol exporting, except for the few
drivers that need it (matroxfb).

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] fbdev and exported symbols

[Jeff G. <jg...@ma...>]

Geert Uytterhoeven wrote:
> 
> On Tue, 12 Jun 2001, Jeff Garzik wrote:
> > The default behavior for a module is to export all public functions,
> > when no explicit EXPORT_SYMBOL is present.
> 
> Is this `new' behavior? I never heard about that before.

nope, definitely not new behavior.

put a test module in export-objs of a Makefile, include a few public
functions and include linux/module.h... then see what appears :)

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: [Linux-fbdev-devel] fbdev and exported symbols

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

On Tue, 12 Jun 2001, Jeff Garzik wrote:
> The default behavior for a module is to export all public functions,
> when no explicit EXPORT_SYMBOL is present.

Is this `new' behavior? I never heard about that before.

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] fbdev and exported symbols

[Jeff G. <jg...@ma...>]

The default behavior for a module is to export all public functions,
when no explicit EXPORT_SYMBOL is present.

Correct me if I'm wrong, but don't most of the fbdev drivers need
EXPORT_NO_SYMBOLS?

This may be a mostly cosmetic thing, since the objects are not listed in
export-objs in the Makefile...

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: [Linux-fbdev-devel] Linux fbcon.c

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

> > Yes. Should I make you the other admin, since Brad left?
> 
> If you like, I can take care of some administrative stuff for a week or so.
> I'm fully recovered from the last surgery (which was unsuccessful) and
> waiting to be scheduled for the next...
> 
> Just thought I'd offer and take some of the mundane tasks off your hands.

If you feel up to it. 

Re: [Linux-fbdev-devel] Linux fbcon.c

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

> Rotating is on its progress, my vga16 console is allready upsidedown.
> 
> I sure will mail U any 65550 specificas.

Okay. I recommend placing the software rotation code in a seperate file
and having it as a loadable module.  

Re: [Linux-fbdev-devel] Linux fbcon.c

[Florian L. <f.l...@ti...>]

Dear Mr. Simmons,

	as far as I know I read the whole docu of the 65550 chip, there was
nothing like it. 

Rotating is on its progress, my vga16 console is allready upsidedown.

I sure will mail U any 65550 specificas.

Regards Florian

James Simmons wrote:
> 
> What would be nice if we could give them CVS access to linux-fbdev and
> they could work out of a common area.
> 
> > If you end up making any C&T 65550 specific changes, would you mind sending
> > them to Adrian Cox <ad...@hu...> and myself?  We are working on
> > drivers for the 69XXX chips and I would love to include any rotating code if
> > I could.
> 
> P.S
> 
>   Rotation is starting to appear in hardware on different device. Perhaps
> a ioctl call?

Re: [Linux-fbdev-devel] Linux fbcon.c

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

On 12 Jun 2001 07:46:36 +0200, Geert Uytterhoeven wrote:
> On Mon, 11 Jun 2001, James Simmons wrote:
> > > > That would be most excellent if we could get that set up.
> > > 
> > > Make sure they have a SourceForge account and the linux-fbdev administrators
> > 
> > I believe you are one of the admins. Brad being the other.
> 
> Yes. Should I make you the other admin, since Brad left?

If you like, I can take care of some administrative stuff for a week or so.
I'm fully recovered from the last surgery (which was unsuccessful) and
waiting to be scheduled for the next...

Just thought I'd offer and take some of the mundane tasks off your hands.

Brad Douglas
br...@ne...

Re: [Linux-fbdev-devel] Linux fbcon.c

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

> > I believe you are one of the admins. Brad being the other.
> 
> Yes. Should I make you the other admin, since Brad left?

Sure. I been using sourceforge for a while so I know my way around.

Re: [Linux-fbdev-devel] Linux fbcon.c

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

On Mon, 11 Jun 2001, James Simmons wrote:
> > > That would be most excellent if we could get that set up.
> > 
> > Make sure they have a SourceForge account and the linux-fbdev administrators
> 
> I believe you are one of the admins. Brad being the other.

Yes. Should I make you the other admin, since Brad left?

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] Help with finding vertical refresh strobe

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

> I'd like to get hard real-time frame-by-frame control of video.
> 
> I have RTLinux working and would like it to poll (in real-time) for either the
> 
> current horizontal scanline position, a horizontal refresh or a vertical
> 
> refresh.  I realize this is probably in the structure 'display' somewhere
> 
> but havent found it or references to it.  Any help would be appreciated.
> 
> Please cc a copy of replies to me as I do not subscribe to this list.

If you have a matrox card you can do this. Take a look at 
include/linux/matroxfb.h and fb.h. Their is a api for this as long as
the card supports it.

Re: [Linux-fbdev-devel] framebuffer driver patch in fbcon-cfb8.c

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

> Added support for fontwidth 10.
> Check for /* 01.06.01 hersche */

This is going to get ugly if we keep adding more hacks to get various font
sizes to work. Luckly the new api fixes this problem :-)