linuxconsole-dev

Re: ANNOUNCE ATI 128 port of new api

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

> > I just finished and tested the ATI 128 driver for the ruby tree which uses
> > the new fbdev api. Works like a charm. No acceleration tho. I will add
> > that in later. Please give it a try. Also use it as a example for porting
> > other drivers.
> 
> I removed some more old PPC cruft (COMPAT_XPMAC, vmode/cmode handling), but I 
> cannot get it to boot, cause it crashes early with a corrupted video mode, so 
> I cannot see anything.

Thanks for removing the crud. I tried the driver on my ix86 box and it
worked. The only difference is the macmode stuff. Try commenting that out
to see what happens. If it works then we have a bug with the mac mode
stuff.

> Have you tried it without any other CONFIG_*_CONSOLE besides 
> CONFIG_FRAMEBUFFER_CONSOLE?

Yes. VGAcon and MDAcon work fine. In fact I run my machine with mdacon and
fbcon at the same time, with mdacon as my VT console. This way if it oops
mdacon prints out what happens. Plus I can debug fbcon or a framebuffer
driver without any problems. 

Re: ANNOUNCE ATI 128 port of new api

[Franz S. <Fra...@la...>]

On Wednesday 21 November 2001 01:50, James Simmons wrote:
> I just finished and tested the ATI 128 driver for the ruby tree which uses
> the new fbdev api. Works like a charm. No acceleration tho. I will add
> that in later. Please give it a try. Also use it as a example for porting
> other drivers.

I removed some more old PPC cruft (COMPAT_XPMAC, vmode/cmode handling), but I 
cannot get it to boot, cause it crashes early with a corrupted video mode, so 
I cannot see anything.

Have you tried it without any other CONFIG_*_CONSOLE besides 
CONFIG_FRAMEBUFFER_CONSOLE?

Franz.

Re: console switching

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

> just a quick curiosity:
> how does one detect when a console switch occurs?  we are writing an 
> application that needs to stop drawing on the framebuffer when it is no longer 
> in the correct console. (ie, we run app in console 1, we then switch to console 
> 2.  app needs to not draw all over console 2's screen (1 fb device))
> 
> normally, i would try to avoid such a dumb question, but i haven't found an 
> obvious solution immediatly.

Fancy signal handling. The ioctl values you need to play with are VT_RELDISP. 
See libsvga for a example of how this is handled.

Re: [Linux-fbdev-devel] ANNOUNCE ATI 128 port of new api

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

> I think this may be a good time to bring this topic up.  I am curious if
> this new "ruby" tree and new fbdev api are going to be blanket accepted
> into the 2.5 tree?  

The api has been discuss many times before on this list. In fact part of
the new api did go in. Its just not to many people take advantage of it.
Others like Russell King have used it. I have also talked to embedded
developers for mips and sh devices, many which have written framebuffers,
and they also support it. 

> If so, is this the decision of a few or a generalized
> vote of many fbdev driver maitniners (I have been in and out of
> linux-fbdev lists so if there was some sort of general acceptance please
> let me know)?  

Only one person that I know of doesn't support it. Everyone else who has
seen and responded to the proposal has accepted it. I have posted several
times the proposed api and I have gotten feedback which I have used to
shape the api. Yes some people haven't bothered in any way. As 2.5.X
approachs I hope they do. 

> Also, I maintain the aty128fb driver and while I
> appreciated the help with the driver, will this new api or whatever
> changes in the "ruby" tree go over the heads of driver maintainers and go
> into 2.5 without their knowledge? Perhaps I'm being anal about it, but
> I'd like to know about changes (if they go into the official kernel) to
> the drivers I maintain, it makes life easier for patches and updates and
> version control, as I'm sure other driver maintainers will agree.

I ported the driver because it was requested so testing for ruby can be
done on the PPC. Several drivers have been ported for testing. I have NOT
sent any patches to the mainline tree nor would I send them except with
the authors permission. 

> >From what I hear the long awaited 2.5 is around the corner so I think its
> best to discuss this asap.

I agree. Which is why I have posted example code such as the new aty128
driver here and other code as well. I have had some feedback. Now with me
porting drivers over I hope to have more. 

Re: [Linux-fbdev-devel] ANNOUNCE ATI 128 port of new api

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

Hi James,

I think this may be a good time to bring this topic up.  I am curious if
this new "ruby" tree and new fbdev api are going to be blanket accepted
into the 2.5 tree?  If so, is this the decision of a few or a generalized
vote of many fbdev driver maitniners (I have been in and out of
linux-fbdev lists so if there was some sort of general acceptance please
let me know)?  Also, I maintain the aty128fb driver and while I
appreciated the help with the driver, will this new api or whatever
changes in the "ruby" tree go over the heads of driver maintainers and go
into 2.5 without their knowledge?  Perhaps I'm being anal about it, but
I'd like to know about changes (if they go into the official kernel) to
the drivers I maintain, it makes life easier for patches and updates and
version control, as I'm sure other driver maintainers will agree.

From what I hear the long awaited 2.5 is around the corner so I think its
best to discuss this asap.


Thanks,

ani


On Tue, 20 Nov 2001, James Simmons wrote:

>
> I just finished and tested the ATI 128 driver for the ruby tree which uses
> the new fbdev api. Works like a charm. No acceleration tho. I will add
> that in later. Please give it a try. Also use it as a example for porting
> other drivers.
>
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

ANNOUNCE ATI 128 port of new api

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

I just finished and tested the ATI 128 driver for the ruby tree which uses
the new fbdev api. Works like a charm. No acceleration tho. I will add
that in later. Please give it a try. Also use it as a example for porting
other drivers. 

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

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

Nick Kurshev wrote:

> Some time ago I wrote about the future of framebuffer and video extensions for that.
> Roman Dolbeau suggested me to use following interface:

Please note there's a newer (more documented) version in
the linux-console CVS.

-- 
DOLBEAU Romain               |  Who made you God to say                   
ENS Cachan / Ker Lann        |    "I'll take your life from you!"         
Thesard IRISA / CAPS         |       -- Metallica,                        
dol...@cl...    |           'Ride the Lightning'

console switching

[<cw...@so...>]

just a quick curiosity:
how does one detect when a console switch occurs?  we are writing an 
application that needs to stop drawing on the framebuffer when it is no longer 
in the correct console. (ie, we run app in console 1, we then switch to console 
2.  app needs to not draw all over console 2's screen (1 fb device))

normally, i would try to avoid such a dumb question, but i haven't found an 
obvious solution immediatly.

thanks in advance =)

chris

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello!

Some time ago I wrote about the future of framebuffer and video extensions for that.
Roman Dolbeau suggested me to use following interface:

/*
 *  linux/include/linux/fbvid.h -- linux Framenuffer Video Interface
 *  
 *  Copyright (C) 2001 Romain Dolbeau <do...@ir...>
 *
 *  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.
 *
 *  $Header: /home/pm3fb/pm3fb/Attic/fbvid.h,v 1.1.2.13 2001/09/27 09:22:11 dolbeau Exp $
 *
 */

#ifndef _LINUX_FBVID_H
#define LINUX_FBVID_H

#include <linux/fb.h>
#include <asm/types.h>
#include <asm/ioctl.h>

/* FOURCC #define, from the MPlayer list (see <http://mplayer.sourceforge.net/> */
/* RGB/BGR Formats */
#define FB_VIDOVERLAY_FOURCC_RGB (('R'<<24)|('G'<<16)|('B'<<8))
#define FB_VIDOVERLAY_FOURCC_BGR (('B'<<24)|('G'<<16)|('R'<<8))

/* Planar YUV Formats */
#define FB_VIDOVERLAY_FOURCC_YVU9 0x39555659
#define FB_VIDOVERLAY_FOURCC_IF09 0x39304649
#define FB_VIDOVERLAY_FOURCC_YV12 0x32315659
#define FB_VIDOVERLAY_FOURCC_I420 0x30323449
#define FB_VIDOVERLAY_FOURCC_IYUV 0x56555949
#define FB_VIDOVERLAY_FOURCC_CLPL 0x4C504C43

/* Packed YUV Formats */
#define FB_VIDOVERLAY_FOURCC_IYU1 0x31555949
#define FB_VIDOVERLAY_FOURCC_IYU2 0x32555949
#define FB_VIDOVERLAY_FOURCC_UYVY 0x59565955
#define FB_VIDOVERLAY_FOURCC_UYNV 0x564E5955
#define FB_VIDOVERLAY_FOURCC_cyuv 0x76757963
#define FB_VIDOVERLAY_FOURCC_YUY2 0x32595559
#define FB_VIDOVERLAY_FOURCC_YUNV 0x564E5559
#define FB_VIDOVERLAY_FOURCC_YVYU 0x55595659
#define FB_VIDOVERLAY_FOURCC_Y41P 0x50313459
#define FB_VIDOVERLAY_FOURCC_Y211 0x31313259
#define FB_VIDOVERLAY_FOURCC_Y41T 0x54313459
#define FB_VIDOVERLAY_FOURCC_Y42T 0x54323459
#define FB_VIDOVERLAY_FOURCC_V422 0x32323456
#define FB_VIDOVERLAY_FOURCC_V655 0x35353656
#define FB_VIDOVERLAY_FOURCC_CLJR 0x524A4C43
#define FB_VIDOVERLAY_FOURCC_YUVP 0x50565559
#define FB_VIDOVERLAY_FOURCC_UYVP 0x50565955

/* for depth_avail */
#define FB_VIDOVERLAY_DEPTH_1BPP               0x0001
#define FB_VIDOVERLAY_DEPTH_2BPP               0x0002
#define FB_VIDOVERLAY_DEPTH_4BPP               0x0004
#define FB_VIDOVERLAY_DEPTH_8BPP               0x0008
#define FB_VIDOVERLAY_DEPTH_12BPP              0x0010
#define FB_VIDOVERLAY_DEPTH_15BPP              0x0020
#define FB_VIDOVERLAY_DEPTH_16BPP              0x0040
#define FB_VIDOVERLAY_DEPTH_24BPP              0x0080
#define FB_VIDOVERLAY_DEPTH_32BPP              0x0100

/* for capability_avail */
#define FB_VIDOVERLAY_CAPABILITY_EXPAND   0x0001 /* if overlay can be bigger than source */
#define FB_VIDOVERLAY_CAPABILITY_SHRINK   0x0002 /* if overlay can be smaller than source */
#define FB_VIDOVERLAY_CAPABILITY_BLEND    0x0004 /* if overlay can be blended with framebuffer */
#define FB_VIDOVERLAY_CAPABILITY_COLORKEY 0x0008 /* if overlay can be restricted to a colorkey */
#define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY 0x0010 /* if overlay can be restricted to an alpha channel */
#define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISRANGE    0x0020  /* if the colorkey can be a range */
#define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISRANGE    0x0040  /* if the alphakey can be a range */
#define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISMAIN     0x0080  /* colorkey is checked against framebuffer */
#define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISOVERLAY  0x0100  /* colorkey is checked against overlay */
#define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISMAIN     0x0200  /* alphakey is checked against framebuffer */
#define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISOVERLAY  0x0400  /* alphakey is checked against overlay */

/* below, for ioctl, <- is driver-to-app, -> is app-to-driver, <-> is bidirectional (*can* be changed by driver) */

struct fb_vidoverlay_avail {
        __u32 max_buf_size;             /* <- maximum size of buffer */
	__u32 xmax;                     /* <- max width of a buffer in _pixels_ */
	__u32 ymax;                     /* <- max height of a buffer in line */
	__u8  xalign;                   /* <- required alignement of width of buffer in _byte_ */
	__u8  yalign;                   /* <- required alignement of height of buffer in line */
	__u8  min_n_buf;                /* <- minimum number of available buffer */
        __u8  num_fourcc;               /* <- number of available FOURCC */
};

struct fb_vidoverlay_fourcc {
	__u32 id;                       /* <- FOURCC id (see <http://www.webartz.com/fourcc/>) */
        __u16 depth_avail;              /* <- available depth(s) for this FOURCC */
	__u16 capability_avail;         /* <- available capability(s) for this FOURCC */
};

struct fb_vidoverlay_buf {
	unsigned long omem_start;       /* <- Start of overlay frame buffer mem (phys add) or 0 (failure) */
        __u32 omem_len;                 /* <- length of overlay frame buffer mem or 0 (failure) */
        __u32 xsize;                    /* <-> X size of buffer */
        __u32 ysize;                    /* <-> Y size of buffer */
	__u32 stride;                   /* <- line lenght in byte (can be longer than X*pixelsize due to hardware restriction */
	__u32 fourcc_id;                /* -> FOURCC that'll go in the buffer  */
	__u16 depth;                    /* -> depth that'll go in the buffer */
	__u8  n_buf;                    /* <-> number of the buffer to use (or -1 for any) */
};

struct fb_vidoverlay_set {
	__u32 oxsize;                   /* -> overlay size in pixels */
	__u32 oysize;
	__u32 dxbase;                   /* -> destination base in pixels */
	__u32 dybase;
	__u32 dxsize;                   /* -> destination size in pixels */
	__u32 dysize;
	__u32 fourcc_id;                /* -> FOURCC to use */
	__u16 depth;                    /* -> depth to use */
	__u16 capability;               /* -> what capability to use */
	__u16 blend_factor;             /* -> blending factor */
	__u16 r_key[2];                 /* -> red component of color key */
 	__u16 g_key[2];                 /* -> green component of color key */
	__u16 b_key[2];                 /* -> blue component of color key */
                                        /* note: alpha should be put in all component
					   alpha cannot be used if there's no alpha channel,
					   i.e. CI8 in 8Bpp or RGBA5650 in 16bpp
					   [0] is low-end of range
					   [1] is high-end of range
					   for single value, [0] shouldbe equal to [1] */
	__u8  n_buf;                    /* -> number of the buffer to use, must have been allocated before */
};

/* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */ 
#define FBIOGET_VIDOVERLAY_CAP           _IOR( 'F', 0xF0, struct fb_vidoverlay_avail)
/* get the list of available FOURCC. variable-length data, use FBIOGET_VIDOVERLAY_CAP before */
#define FBIOGET_VIDOVERLAY_FOURCC        _IOR( 'F', 0xF1, struct fb_vidoverlay_fourcc)
/* get an offscreen memory buffer. 'struct fb_vidoverlay_buf' as input/output */
#define FBIOGET_VIDOVERLAY_ALLOCATEBUF   _IOWR('F', 0xF2, struct fb_vidoverlay_buf)
/* free the memory buffer. '__u8' number of buffer to free */
#define FBIOGET_VIDOVERLAY_FREEBUF       _IOW( 'F', 0xF3, __u8)
/* start the overlay. 'struct fb_vidoverlay_set' as input */
#define FBIOPUT_VIDOVERLAY_START         _IOW( 'F', 0xFE, struct fb_vidoverlay_set)
/* stop the overlay */
#define FBIOPUT_VIDOVERLAY_STOP          _IO(  'F', 0xFF)

#endif /* LINUX_FBVID_H */

But he was not sure the future of this stuff:
>Anyway, I'm not sure adding all and every possible features
>to the FB driver will be seen kindly by those-in-charge
>(aka Linus T. and maybe Alan C.) I'm not even sure they'll
>agree on video overlay...

Currently I've implemented the first public release of
radeon_vid driver:

http://mplayerhq.hu/cgi-bin/cvsweb.cgi/main/drivers/radeon/

In this connexion I have question:
Can I use fbvid.h stuff as standard interface for further
improvements of my radeon_vid driver or this stuff will
never accepted into linux and this interface is meaningless?

Best regards! Nick

P.S. Please CC me

input patch

[Johann D. <jo...@Do...>]

Hello,

I made a patch for kernel 2.4.12 containing only the input part of
linuxconsole.
This patch is available at
http://www.docs.uu.se/~johannd/projects/ff/patch-2.4.12.bz2

The goal is to allow users to use the input drivers, which are quite
stable, without forcing them to use the totality of the linuxconsole
project (which still needs some work before being usable by end-users).

James, if you want to put this patch in the download area, please do so.

I am a bit late, as the current version of the linux kernel is 2.4.14, but
having a patch that actually includes all needed files, but no more, was
not especially easy.

About the directory hierarchy, I decided to keep linus' hierarchy. Not
that this is a better choice, but it first appeared to me being easier
(fewer changes to makefiles). However, I think I will try to move to the
linuxconsole hierarchy in the next version.

Feel free to try this file, and tell me if something goes wrong. This
serie of patches has been available for quite a long time now, and I
discovered only recently that it was hardly usable for anyone but me.

-- 
Johann Deneux

Re: pm3fb (was: pm2fb driver)

[Johann D. <jo...@Do...>]

On Wed, 14 Nov 2001, James Simmons wrote:

> 
> > > - key repeat: does not work well. Only 2 characters can be repeated. Is it
> > > a bug, or a default behaviour I can change ?
> > 
> > Can you describe it more precisely? The key repeat should be the same as
> > AT keyboards do.
> 
> I bet it is the mk_sound function problem. I have disabled it in the

It seems it was indeed. Now it works.

-- 
Johann Deneux

Re: [Linux-fbdev-devel] Re: New API

[Patrick M. <mo...@in...>]

I am only half-paying attention and I saw my name...


On Fri, 16 Nov 2001, James Simmons wrote:

> 
> > >Where can I find this work or is it vaporware? As how stable is it? Will
> > >it be the final solution that will go in? I like to port a few subsystems
> > >in my CVS to it.
> > > 
> > >> Speaking of this.. do you know what the plans for ddfs are?
> > >
> > >Yet another device filesystem? The nice thing about a new unified device
> > >interface is it will make the device filesystems I plan to work much
> > >easier to implement.
> > 
> > Ask Patrick and the linux mailing list. AFAIK, His current patches not
> > only provide the unified struct device with PM hooks, but also the
> > device filesystem.
> 
> Good. I sent out the email. Also if he has a very mature device filesystem
> that will make our lives easier.

The code lives on kernel.org:

	ftp://ftp.kernel.org/pub/linux/kernel/people/mochel/device

There is a document that should be relatively up to date describing what's
going on. 

The gist of it is that it provides a unified device tree based on
locality. Nodes are added by the bus drivers on which a device sits. So,
the PCI layer adds nodes for all devices that it finds when probing the
bus. 

There is also a filesystem that goes along with it and presents this
unified view to userspace.

The power management code is not explicitly included in that code. I have
implemented one suspend/resume transition, but it is in the ACPI
subsystem, which you can get from Intel:

	http://developer.intel.com/technology/IAPC/acpi/index.htm

I have thought about doing a general PM imeplementation, but probably will
not, since there are too many platform-specific things that you must worry
about to make it elegant..

	-pat

Re: [Linux-fbdev-devel] Re: New API

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

> >Where can I find this work or is it vaporware? As how stable is it? Will
> >it be the final solution that will go in? I like to port a few subsystems
> >in my CVS to it.
> > 
> >> Speaking of this.. do you know what the plans for ddfs are?
> >
> >Yet another device filesystem? The nice thing about a new unified device
> >interface is it will make the device filesystems I plan to work much
> >easier to implement.
> 
> Ask Patrick and the linux mailing list. AFAIK, His current patches not
> only provide the unified struct device with PM hooks, but also the
> device filesystem.

Good. I sent out the email. Also if he has a very mature device filesystem
that will make our lives easier.

Re: [Linux-fbdev-devel] Re: New API

[Benjamin H. <be...@ke...>]

>Ask Patrick and the linux mailing list. AFAIK, His current patches not
>only provide the unified struct device with PM hooks, but also the
>device filesystem.

I mean linux-kernel mailing list of course ;)

Ben.

Re: [Linux-fbdev-devel] Re: New API

[Benjamin H. <be...@ke...>]

>> > You may want to sync with Patrick Mochel who is working on the new
>> > PM scheme for 2.5 along with the new unified device interface.
>> > AFAIK, pm_dev will be gone and all devices will have PM hooks as
>> > part of the standard "struct device" that _any_ HW driver will
>> > be supposed to implement.
>
>Where can I find this work or is it vaporware? As how stable is it? Will
>it be the final solution that will go in? I like to port a few subsystems
>in my CVS to it.
> 
>> Speaking of this.. do you know what the plans for ddfs are?
>
>Yet another device filesystem? The nice thing about a new unified device
>interface is it will make the device filesystems I plan to work much
>easier to implement.

Ask Patrick and the linux mailing list. AFAIK, His current patches not
only provide the unified struct device with PM hooks, but also the
device filesystem.

Ben.

Re: Synced to 2.4.14

[<twi...@su...>]

On 13 Nov 2001, at 14:52, James Simmons wrote:
> 
> > I'm recovering from a HDD crash, but will be finally getting around
> > to messing with it after I'm up.... been lurking on this list for a
> > few months, but haven't attempted to do much as of yet..
> > 
> > So.... you have one more tester *grins*
> 
> Great. Alot of work is ahead of us. I really like to start porting
> more fbdev drivers over. I think I will be placing mor eof them in
> CVS. Understand they will be gradually coverted over so they will be
> broken for some time. 

cool.. I'm going to set aside a partition dedicated to testing stuff I'm 
interested in that's likely to be broken (like this CVS tree.. the 
XFree CVS tree, etc..) ... I should also be setting up another box 
soon... Then I can cover testing a decent spread of the fbdev stuff... 
This machine has a Geforce 2 GTS, and sitting around I have a 
TNT, and some older Matrox cards: a Millenium 2, a Mystique and 
a Millenium... and I believe an AGP ATI Rage something-or-other 
too...  

BTW, is anybody doing any work on moving the event-driver for 
xf86 (tuntitko) to the 4.x tree?


James Gibson
twi...@su...

aty 128

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

I partially converted it over but I have alot more to go. Give me another
day and it should be ready.

Re: [Linux-fbdev-devel] Re: New API

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

> > You may want to sync with Patrick Mochel who is working on the new
> > PM scheme for 2.5 along with the new unified device interface.
> > AFAIK, pm_dev will be gone and all devices will have PM hooks as
> > part of the standard "struct device" that _any_ HW driver will
> > be supposed to implement.

Where can I find this work or is it vaporware? As how stable is it? Will
it be the final solution that will go in? I like to port a few subsystems
in my CVS to it.
 
> Speaking of this.. do you know what the plans for ddfs are?

Yet another device filesystem? The nice thing about a new unified device
interface is it will make the device filesystems I plan to work much
easier to implement.

Re: [Linux-fbdev-devel] Re: New API

[Paul M. <pm...@mv...>]

On Wed, Nov 14, 2001 at 11:56:10PM +0100, Benjamin Herrenschmidt wrote:
> You may want to sync with Patrick Mochel who is working on the new
> PM scheme for 2.5 along with the new unified device interface.
> AFAIK, pm_dev will be gone and all devices will have PM hooks as
> part of the standard "struct device" that _any_ HW driver will
> be supposed to implement.
>=20
Speaking of this.. do you know what the plans for ddfs are?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-fbdev-devel] Re: New API

[Benjamin H. <be...@ke...>]

>
>Hm. Code in fbmem.c can handle this. Actually I like to make the blank
>code more robust. I like to see real power management on alot of levels. 
>For example many hand held devices have hooks to lower the pixclock when
>in power saving mode. This is needed when you lower the CPU clock speed. 
>We really should be making use of the struct pm_dev I placed into struct
>fb_info. So to deal with this issue in fbmem we could atomically read
>struct pm_dev state field. 
>
>P.S 
>   No power management function to read the current state?

You may want to sync with Patrick Mochel who is working on the new
PM scheme for 2.5 along with the new unified device interface.
AFAIK, pm_dev will be gone and all devices will have PM hooks as
part of the standard "struct device" that _any_ HW driver will
be supposed to implement.

Ben.

Re: New API

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

>    *      Note: If screen is blanked, all other functions (setcolreg,
>    *      imageblit) may be still invoked, and must work. This needs
>    *      special care if you are blanking by programming DAC to all black.
> 
> or something like that.   

See other email.

> >  *      Returns negative errno on error, or zero on success.
> 
> If driver does not support specified powerdown mode, should it
> use nearest mode with greater power consumption, nearest mode with
> smaller power consumption, or should it report an error?

> ?   * If we have no hardware acceleration, we provide an unaccelerated
> ?   * functions in fbcon-cfb*.c modules. You can use these functions
> ?   * as fallbacks if hardware unsupported action is requested.

Yes this is the case. I have three different files each with a soft accel
for each possible accel function. The reason for breaking them up is
because in theory you could have a device with only fillrect support. Then
you can plug in the other two generic accel functions. As for non pack
pixel and non accelerated cards you have to provide your own functions.

> Move #endif up below xxxfb_init, as these macros works correctly
> when code is built into kernel, and we want to make sure that nobody
> will remove #ifdef MODULE when doing cleanup, as we still call
> init explicitly from global fb initialization. 

Done :-)

Re: [Linux-fbdev-devel] Re: New API

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

> > What about:
> >
> >    *      Note: If screen is blanked, all other functions (setcolreg,
> >    *      imageblit) may be still invoked, and must work. This needs
> >    *      special care if you are blanking by programming DAC to all black.
> >
> > or something like that.
> 
> Or the upper layer could take care of that.

Hm. Code in fbmem.c can handle this. Actually I like to make the blank
code more robust. I like to see real power management on alot of levels. 
For example many hand held devices have hooks to lower the pixclock when
in power saving mode. This is needed when you lower the CPU clock speed. 
We really should be making use of the struct pm_dev I placed into struct
fb_info. So to deal with this issue in fbmem we could atomically read
struct pm_dev state field. 

P.S 
   No power management function to read the current state?

Re: fb_disable_mtrr ?

[Paul M. <pm...@mv...>]

On Wed, Nov 14, 2001 at 08:25:58AM -0800, James Simmons wrote:
> Is this funciton used or should we remove it?
>=20
Er, it was meant to be used, I just hadn't gotten around to ever actually
using it.. was planning on using it in the generic setup routine.. but was
still pondering the sanest way to deal with handing off an fb_info pointer.=
. I
suppose it can be commented out for now until I get time to fix it..

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-fbdev-devel] New API

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

> > Hi folks. I finally hammered a newer api for framebuffer devices. I
> > adapted skeletonfb.c to show it off. Feedback welcomed.
> 
> Good news!

A few drivers have been converted over to it :-) 


> >     /*
> >      *  If your driver supports multiple boards, you should make these
> >      *  arrays, or allocate them dynamically (using kmalloc()).
> >      */
> 
> Perhaps make it more clear that this applies to all 3 (4?) variables below

I should. In reality all of them can be dynamically allocated. 

> > /**
> >  *      xxxfb_check_var - REQUIRED function. Validates a var passed in.
> 
> Is this function really required? Imagine a graphics card with a fixed
> resolution (e.g. old Sun3 bwtwo), or vesafb/offb.
> 
> If it's NULL, you cannot change var, and upper layer can check that an
> identical var was passed (using memcmp()).

Wait. Your right. In CVS I made it optional. I missed updating this. If
you can change the mode it just returns the current mode instead.

        if (!info->fbops->fb_check_var) {
                *var = info->var;
                return 0;
        }

> >  *  	xxxfb_setcolreg - REQUIRED function. Sets a color register.
> 
> Is this function really required? Imagine static pseudocolor (fixed palette)
> hardware.

I never thought about that. Your right. Will fix. 

> >     /* Truecolor has hardware independent palette */
> >     if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> >        u32 v;
> >
> >        if (regno >= 16)
> >            return 1;
> >
> >        v = (red << info->var.red.offset) |
> >            (green << info->var.green.offset) |
> >            (blue << info->var.blue.offset) |
> >            (transp << info->var.transp.offset);
> >        if (info->var.bits_per_pixel == 16)
> >            ((u16*)(info->pseudo_palette))[regno] = v;
> >        else
> >            ((u32*)(info->pseudo_palette))[regno] = v;
> >        return 0;
> 
> What about info->var.bits_per_pixel == 8? Some handhelds are RGB332 truecolor.

Your right again. Even the Matrox millenium could do this mode. I will add
as a example. Made changes to skeletonfb.c.

Re: [Linux-fbdev-devel] New API

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

On Wed, 14 Nov 2001 he...@ho... wrote:
> James Simmons writes:
>  > Hi folks. I finally hammered a newer api for framebuffer devices. I
>  > adapted skeletonfb.c to show it off. Feedback welcomed.
>  >
>  > /*
>  >  * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
>  >  *
>  ...
>  > /**
>  >  *      xxxfb_imageblit - REQUIRED function. Can use generic routines if
>  >  *                        non acclerated hardware and packed pixel based.
>  >  *                        Copies a image from system memory to the screen.
>  >  *
>  >  *      @info: frame buffer structure that represents a single frame buffer
>  >  *	@image:	structure defining the image.
>  >  *
>  >  *      This drawing operation draws a image on the screen. It can be a
>  >  *	mono image (needed for font handling) or a color image (needed for
>  >  *	tux).
>  >  */
>  > void xxxfb_imageblit(struct fb_info *p, struct fb_image *image)
>  > {
>  > }
>
> Which bit ordering will be used? Leftmost = MSb (as in console fonts)
> or leftmost = LBb (as in XFree, at least in nVidia driver, which I'm
> familiar with)?

Kernel fonts wider than 8 pixels have always been big-endian.

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