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

[Linux-fbdev-devel] Re: Framebuffer API with backlit displays

[<jg...@pa...>]

The issue is that we really may need a new interface to control the
backlight/frontlight, rather than relying on the VESA levels for
control.

Turning on the frontlight/backlight does not affect the visibility of
the screen (in bright sunlight a reflective screen is very visible with
it entirely disabled).

Front light/backlight control is therefore orthogonal to VESA levels,
which really describe visibility of the screen (even though there are
four levels).  I'm nervous about overloading the VESA interface in this
fashion; if it is overloaded, then the current driver has difficulties,
as it always goes to the "full on" vesa level, which if it is overloaded,
implies the frontlight/backlight, which the user may not want on at all.

Having the driver not go to the full on vesa level also has trouble:
on many monitors, your screen won't be visible at all....

So trying to cram this into the exisiting interface is causing real problems,
and I think it is time for a new additional interface to control frontlight
backlight, rather than try to bandaid things as we have to date.
				- Jim


--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg...@pa...

Re: [Linux-fbdev-devel] Network transparent API Concept Design

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

Sorry for the delay. Finally I found time to read the document and write my
comments...

Caveat: some comments are random thoughts...

On Fri, 30 Nov 2001, Sottek, Matthew J wrote:
> struct fb_display_info {
>    u32 id;
>    u32 xres;
>    u32 yres;

Are these visible xres and yres?

>    u32 xoffset;
>    u32 yoffset;
>    u32 orientation;
>    u32 refresh;
>    u32 left_margin;
>    u32 right_margin;
>    u32 top_margin;
>    u32 bottom_margin;

Are these the sync margins? What about hsync_len and vsync_len?

>    u32 status;
>    u32 flags;
> }

> struct fb_mode_info {
>    u32 width;
>    u32 height;

Are these virtual width and height?

>    u32 pixel_format;
>    u32 flags;
> }

> pixel_format: This is a unique identifier for the arrangement of 
> data in the framebuffer. The pixel_format values will be defined 
> in a logically grouped fashion so that a user-space table can be 
> used to obtain descriptions of the bits within the format. i.e.
> 
> #define DEVICE   0x80000000
> #define NONSTD   0x40000000
> #define RGB      0x20000000
> #define YUV      0x10000000
> #define GRAY     0x08000000

There exist many different variants of YUV: 4:4:4, 4:2:2, 4:2:0, ...
Depending on the hardware, YUV modes can be interlaced and/or interleaved.
E.g. some Set Top Box S(TB) hardware splits the YUV data in four parts: Y even,
Y odd, UV even, and UV odd.

What about RGBA?

> #define PSEUDO   0x04000000
> #define TRUE     0x02000000
> #define DIRECT   0x01000000
> 
> #define 1BIT     0x00000001
> #define 2BIT     0x00000002
> #define 4BIT     0x00000004
> #define 8BIT     0x00000008
> #define 12BIT    0x0000000c
> #define 16BIT    0x00000010
> #define 24BIT    0x00000018
> #define 32BIT    0x00000020
> #define 64BIT    0x00000040

Are these all packed?
What about planar modes and interleaved planes?

> #define ID_MASK  0x000fff00
> 
> #define PSEUDO_RGB_8 (PSEUDO | RGB | 8BIT)
> 
> formats that are only usable by device drivers, such as depth 
> buffers, should use a pixel_type with bit 31 == 1 (device 
> specific). Well defined, but not easy to describe, pixel formats 
> should be numbered sequentially with the NONSTD bit turned on. 
> The defined bits are not expected to uniquely define a pixel 
> type, rather they allow for a user application to deal with an 
> unknown type based on its attributes and additional information 
> from a table or library.

So Amiga HAM6 and HAM8 can be considered NONSTD.

What about weird endianness? E.g. RGB565 can look very weird
(GGGBBBBBRRRRRGGG) if bytes have to be swapped, but not 16-bit words.

On some architectures (e.g. ARM), video memory accesses must always be x-bit
wide.

> For instance. If only the above example definitions are present, 
> both 24 bit packed (RGBR GBRG BRGB) and 24 bit sparse (RGB_ RGB_ 
> RGB_) have the same attributes. RGB | TRUE | 24BIT. However the
> bits available from (pixel_format & ID_MASK) will be different. 
> Even if the user application was not familiar with the bit field 
> locations in 24 bit sparse, it could look up such information in 
> a relatively small table of 24 bit RGB pixel format bit 
> definitions.

Don't you need bit field positions? Other fields than R, G, B, and A.

> fb_cursor_info
> If the framebuffer supports a hardware cursor the pixel format 
> and location of the cursor can be set with this data structure. 
> As with other structures the hardware will alter the values if 
> an exact match cannot be supported.
> 
> struct fb_cursor_info {
>    u32 width;
>    u32 height;
>    u32 pixel_format;
>    u32 status;
>    struct fb_palette_info palette;
> }

No XOR index (index of the color entry that inverts the underlying pixel)?
Flashing cursors?

Perhaps hardware animation (some STBs have that)?

> fb_surface_info
> The framebuffer provides a generic surface view of all 
> framebuffer and non framebuffer graphics memory. For simplicity 
> sake the framebuffer will not provide complex surface allocation 
> and management schemes, only the most basic representation of 
> available memory will be provided such that a higher level 
> graphics interface can make intelligent use of the available 
> resources.

This part I found quite interesting...

> #define FB_SURFACE_TYPE_FB       0x00000000
> #define FB_SURFACE_TYPE_CURSOR   0x00000001
> #define FB_SURFACE_TYPE_OVERLAY  0x00000002
> #define FB_SURFACE_TYPE_BACK     0x00000003
> #define FB_SURFACE_TYPE_DEPTH    0x00000004
> #define FB_SURFACE_TYPE_COMMAND  0x00000005
> #define FB_SURFACE_TYPE_SCRATCH  0x0fffffff

So different layers/planes are different surfaces.
STBs can do different layers (a few YUV, a few RGB/CLUT for OSD, cursor), with
alpha blending between the layers, changeable order, ...

> pitch: The length in bytes from a point on the framebuffer to 
> the same point one line below. This value may not be the same as 
> (width*bytes_per_pixel) as it is common in graphics hardware to 
> optimize operations by limiting pitch to powers of 2. When using 
> the physical address in another driver or hardware care must be 
> taken to make sure that the correct pitch is used.

This is for packed pixels only. For (interleaved) bitplanes you need an offset
to the next line and next plane.

> At this time it is expected that a command will be issued in 
> this manner:
> 1: The command file is opened read/write, if already opened 
> the client can lseek the file back to the 0 position.
> command_fd = open("/dev/gfx/fb0/command", O_RDWR);
> 2: The 4 byte command number (each command will have a well 
> defined number) is written to the file followed by the data 
> needed for the command. Pointers are worthless here because 
> in order to insure network transparency the kernel cannot 
> do a copy_from_user(). If the value returned is -1 errno 
> will contain the return value.
> buf[0] = command_number;
> memcpy(&buf[1],&data_struct, sizeof(data_struct));
> ret_val = write(command_fb, buf,
>                 sizeof(data_structure) + 4);
> if(ret_val == -1) {ERROR!}
> 4: If the return value indicates that data will be returned 
> the client should seek the file back to 0 and read the 
> returned data.
> lseek(command_fd, 0, SEEK_SET);
> size = read(command_fd, &data_structure,
>             sizeof(data_structure));

Is the lseek() really needed? This means we need 2 syscalls (context switches)
instead of 1.

> KERNEL INTERFACE:
> The kernel interface is that which is used by the kernel outside 
> of the framebuffer infrastructure to access the display device. 
> The kernel should not be permitted to access any of the graphics 
> hardware directly. The kernel can only write to surface 0 (The 
> actual framebuffer) so it is not necessary to supply surface 
> information to functions who's user-space counterparts require 
> such information.

No overlay console? ;-)

> fb_set_palette(struct fb_cmap *cmap): Sets the internal palette 
> or pseudo-palette to the values indicated by the provided 
> fb_cmap structure.
> 
> fb_set(u32 value, u16 x, u16 y, u16 width, u16 height, u32 rop): 
> Sets a region of the framebuffer to the value provided. Raster 
> operations as specified will also be applied to the data. 
> 
> fb_put(u8 *data, u16 srcx, u16 srcy, u16 width, u16 height, u16 
         ^^^^
	 void *?

> destx, u16 desty): Puts the data provided in the framebuffer at 
> the location provided. (Raster ops?)
> 
> fb_copy(u16 srcx, u16 srcy, u16 width, u16 height,
>         u16 destx, u16 desty, u32 rop): Copies the one area of 
> the framebuffer or a surface to another possibly applying a 
> raster operation.
> 
> fb_get(u8 *data, u16 x, u16 y, u16 width, u16 height): Get a 
         ^^^^
	 void *?

> region of the framebuffer and store it at the provided data 
> pointer.
> 
> Additionally the framebuffer infrastructure will provide a
> "struct consw" interface for console operations if the 
> underlying driver is able to support it.

> fb_console
> This structure represents a console being displayed on the 
> framebuffer device. There can only be one console on the 
> framebuffer device at a time, but the console does not have to 
> occupy the entire visible area. The console rendering will 
> contain itself to the boundaries specified in the fb_console 
> structure. There will be a different struct fb_console for each 
> active console.
> 
> struct fb_console {
>    u32 xoffset;
>    u32 yoffset;
>    u32 width;
>    u32 height;
>    u32 fontwidth;
>    u32 fontheight;
>    u8 *fontdata;
>    u8 fg;
>    u8 bg;
>    struct fb_cmap *cmap;
>    void *priv;
> }

BTW, on many STBs, the whole screen is not one pixmap, but you can have
multiple non-overlapping regions (windows), using different pixel formats.

Perhaps this can be considered a generalization of fb_console?

> fbcon_ops
> Provides the entry points such that the di layer can access the 
> console operations functions.

> bmove: Move an area represented by the source region to the 
> location represented by the destination region. All coordinates 
> are in character units. QUESTION: Is this really a move? Or is 
> it a copy? A move would imply that it sets the area left 

-> copyrect

> uncovered with zeros. FIXME: This should be "copy". If it really 
> is a move then we should break that up into "copy" + "set".

-> fillrect

> putc: Put a character represented by "c" at the location 
> specified. FIXME: Is it too slow to make this a special case of 
> putcs?

No, console mainly uses putcs

> putcs: Put the line of characters references by *s at the 
> location provided.

-> imageblit

> fb_base: This is a kernel-virtual address that points to the 
                   ^^^^^^^^^^^^^^^^^^^^^^^^???

> beginning of the framebuffer. This address can be written to in 
> a manner such as this "*fb_base = 0;". Typically this is an 
> ioremapped version of the physical base address of the 
> framebuffer.

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] Fluctuating PCI ID for Ati Rage 128

[Pavel R. <pr...@gn...>]

Hi again!

> +    {"Rage128 RF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RG, rage_128},

                 ^^

Sorry, this should be RG of course.

-- 
Regards,
Pavel Roskin

Re: [Linux-fbdev-devel] Fluctuating PCI ID for Ati Rage 128

[Pavel R. <pr...@gn...>]

Hi, Geert!

> > 1002:5246 is recognized as ATI Rage 128 RF by pciutils-2.1.8-23 from
> > RedHat 7.2 (file /usr/share/pci.ids), by kudzu-0.99.23-1 (file
> > /usr/share/kudzu/pcitable) and by Linux-2.4.17-rc1 (file
> > include/linux/pci_ids.h).  By the way, I'm surprized by the number of
> > different PCI databases on the same system!
> 
> Please look in drivers/pci/pci.ids instead of include/linux/pci_ids.h.
> That file is shared with pciutils (well, pciutils and the kernel are not always
> in sync, but it's better than before because they now use the same file
> format).

Great idea.  drivers/pci/pci.ids lists 1002:5247 as ATI Rage 128 RG.  
List means that my card is legitimate (not a bastard :-)) and should be
supported!  1002:534b is listed as Rage 128 SK.

I'm synchronizing those records as well as the adjacent records in
assumption that pci.ids has priority over pci_ids..  This patch should be
safe to apply.  I'm also adding the maintainer of PCI ID database to Cc:

By the way, the framebuffer driver could support whole blocks of IDs, e.g.  
all 1002:52xx.  I think it should be possible.  You could find all devices 
by ATI and then cycle through them.

===============================
--- linux.orig/drivers/video/aty128fb.c
+++ linux/drivers/video/aty128fb.c
@@ -150,6 +150,7 @@ static struct aty128_chip_info aty128_pc
 {
     {"Rage128 RE (PCI)", PCI_DEVICE_ID_ATI_RAGE128_RE, rage_128},
     {"Rage128 RF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RF, rage_128},
+    {"Rage128 RF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RG, rage_128},
     {"Rage128 RK (PCI)", PCI_DEVICE_ID_ATI_RAGE128_RK, rage_128},
     {"Rage128 RL (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RL, rage_128},
     {"Rage128 Pro PF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_PF, rage_128_pro},
--- linux.orig/include/linux/pci_ids.h
+++ linux/include/linux/pci_ids.h
@@ -237,9 +237,11 @@
 /* Rage128 GL */
 #define PCI_DEVICE_ID_ATI_RAGE128_RE	0x5245
 #define PCI_DEVICE_ID_ATI_RAGE128_RF	0x5246
-#define PCI_DEVICE_ID_ATI_RAGE128_RG	0x534b
-#define PCI_DEVICE_ID_ATI_RAGE128_RH	0x534c
-#define PCI_DEVICE_ID_ATI_RAGE128_RI	0x534d
+#define PCI_DEVICE_ID_ATI_RAGE128_RG	0x5247
+#define PCI_DEVICE_ID_ATI_RAGE128_SK	0x534b
+#define PCI_DEVICE_ID_ATI_RAGE128_SL	0x534c
+#define PCI_DEVICE_ID_ATI_RAGE128_SM	0x534d
+#define PCI_DEVICE_ID_ATI_RAGE128_SN	0x534e
 /* Rage128 VR */
 #define PCI_DEVICE_ID_ATI_RAGE128_RK	0x524b
 #define PCI_DEVICE_ID_ATI_RAGE128_RL	0x524c
===============================

-- 
Regards,
Pavel Roskin

Re: [Linux-fbdev-devel] Fluctuating PCI ID for Ati Rage 128

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

On Fri, 14 Dec 2001, Pavel Roskin wrote:
> I have an ATI Rage 128 card that shows a very interesting behavior.  
> Immediately after power-on it has PCI id 1002:5247, but after reboot it
> has PCI id 1002:5246.  This number doesn't change during the system
> uptime.

Strange...

> 1002:5246 is recognized as ATI Rage 128 RF by pciutils-2.1.8-23 from
> RedHat 7.2 (file /usr/share/pci.ids), by kudzu-0.99.23-1 (file
> /usr/share/kudzu/pcitable) and by Linux-2.4.17-rc1 (file
> include/linux/pci_ids.h).  By the way, I'm surprized by the number of
> different PCI databases on the same system!

Please look in drivers/pci/pci.ids instead of include/linux/pci_ids.h.
That file is shared with pciutils (well, pciutils and the kernel are not always
in sync, but it's better than before because they now use the same file
format).

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] Fluctuating PCI ID for Ati Rage 128

[Pavel R. <pr...@gn...>]

Hello!

I have an ATI Rage 128 card that shows a very interesting behavior.  
Immediately after power-on it has PCI id 1002:5247, but after reboot it
has PCI id 1002:5246.  This number doesn't change during the system
uptime.

1002:5246 is recognized as ATI Rage 128 RF by pciutils-2.1.8-23 from
RedHat 7.2 (file /usr/share/pci.ids), by kudzu-0.99.23-1 (file
/usr/share/kudzu/pcitable) and by Linux-2.4.17-rc1 (file
include/linux/pci_ids.h).  By the way, I'm surprized by the number of
different PCI databases on the same system!

There is a disagreement about the meaning of 1002:5247.  Only kuzdu
recognizes it as ATI Rage 128 RG.  Linux and pciutils don't recognize it.  
Linux thinks that ATI Rage 128 RG is 1002:534b.  Pciutils doesn't even 
know about ATI Rage 128 RG.

My problem is that because of that the framebuffer doesn't work in the
first boot after power-on.  Here's the patch.  It works for me but it's
not intended to be applied as is.  I hope that the right name will be 
found for this card or that the name will indicate that it's a "mutant" 
Rage128 RF.

==========================
--- linux.orig/drivers/video/aty128fb.c
+++ linux/drivers/video/aty128fb.c
@@ -150,6 +150,7 @@ static struct aty128_chip_info aty128_pc
 {
     {"Rage128 RE (PCI)", PCI_DEVICE_ID_ATI_RAGE128_RE, rage_128},
     {"Rage128 RF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RF, rage_128},
+    {"Rage128 R? (AGP)", 0x5247, rage_128},
     {"Rage128 RK (PCI)", PCI_DEVICE_ID_ATI_RAGE128_RK, rage_128},
     {"Rage128 RL (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RL, rage_128},
     {"Rage128 Pro PF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_PF, rage_128_pro},
==========================

It is an AGP card in a motherboard KT-133 by AOpen with Athlon 1GHz.  
There are no problems with the card except that it changes the id and 
Kudzu notices it every time.

The video BIOS has the following strings in the beginning:

RAGE128 VR AGP P/N 113-66501-101                                                          
(C) 1988-99, ATI Technologies Inc. BK1.0.15 VR001.001.001.015.000.022 
rft4b2x.115 v611
R128AGP SGS2UN

-- 
Regards,
Pavel Roskin

Re: [Linux-fbdev-devel] non-english console fonts

[Jani M. <ja...@as...>]

Thanks
I see this was a user(land) problem after all :)
It will work as I want after I RTFM on these console tools.
Jani.

> And do you load your fonts into kernel?
>
> for a in `seq 1 24`; do
> setfont --tty=/dev/tty$a -f $FONTNAME -u $SFMNAME
> charset --tty=/dev/tty$a G0 $ACMNAME
> done
>
> Doing setfont/charset without /dev/tty* does not set fonts on all
> consoles, it sets up only console you are watching. And VT reset
> resets font too.
>                                                     Petr Vandrovec
>                                                     van...@vc...
>
>

Re: [Linux-fbdev-devel] non-english console fonts

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

On 14 Dec 01 at 13:03, Jani Monoses wrote:
> easter-european fonts are not shown when my fb driver is loaded as a
> module.When compiled in or when using vesafb there's no problem.
> Is sme of the font data freed on boot?Maybe not even a kernel issue.
> I use tridentfb which is currently beta.

And do you load your fonts into kernel?

for a in `seq 1 24`; do 
setfont --tty=/dev/tty$a -f $FONTNAME -u $SFMNAME
charset --tty=/dev/tty$a G0 $ACMNAME
done

Doing setfont/charset without /dev/tty* does not set fonts on all
consoles, it sets up only console you are watching. And VT reset 
resets font too.
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

[Linux-fbdev-devel] non-english console fonts

[Jani M. <ja...@as...>]

Hi

easter-european fonts are not shown when my fb driver is loaded as a
module.When compiled in or when using vesafb there's no problem.
Is sme of the font data freed on boot?Maybe not even a kernel issue.
I use tridentfb which is currently beta.
Thanks
Jani.

[Linux-fbdev-devel] 1920x1440 resolution with matroxfb

[<rw...@ea...>]

I want to thank the developers of the Linux frame buffer!
The amount of text that fits on the screen using matroxfb
is very cool.  

I want to share the video settings that are working well for 
me, in case it helps other users or the developers.

Monitor: 22" ViewSonic PF815
Matrox G400 with 32MB RAM

These settings give 90x240 text with the default font.

video=matrox:vesa:0x11C,depth:32,fh:115,fv:92,xres:1920,yres:1440,left:344,right:120

I put the line above into a lilo "append" directive.

The "fh" (horizonal frequency) and "fv" (vertical) are the max 
this monitor supports.  They would be a bad values if your 
monitor doesn't have these specifications.

Kernel config:

CONFIG_FB=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G100=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FBCON_MFB=y
CONFIG_FBCON_CFB2=y
CONFIG_FBCON_CFB4=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y

Have fun!
-- 
Randy Hron

[Linux-fbdev-devel] Re: Framebuffer API with backlit displays

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

On Tue, 11 Dec 2001, Christian, Andrew wrote:
> I'm one of the maintainers the Linux distribution on the Compaq iPAQ
> handheld computer.  We use a generic framebuffer device for the
> StrongARM processor, in the ARM-Linux tree (drivers/video/sa1100fb.c).
>  
> The current framebuffer driver has very limited support for turning on
> and off the screen backlight (or frontlight, in the case of the iPAQ
> H3600).  The iPAQ has reflective LCD screen, so users frequently turn
> off the backlight to save power. I have a few hacks in place to save and
> restore the state of the backlight and screen through suspend and resume
> cycles.
>  
> My question: has thought been given to extending the framebuffer API to
> support backlight/frontlight control?  It seems to be an integral part
> of power management on LCD displays. Currently framebuffer devices
> support VESA blanking: four levels from NO_BLANKING to POWERDOWN. The
> LCD backlight/frontlight seems to fit in as sublevels within the
> "NO_BLANKING" level.

Right now there's no standardized way to control backlight.

Some drivers support backlight control, but usually they just disable backlight
when the screen is blanked.

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] API prototype doc

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

>> The dri works this way already but on a per client basis, we need
>> it on a per VT basis.

>All commands your fbdev API presents are not context sensitive.
>At least it looks that way to me. After console switch all
>on-screen and off-screen memory is lost. 

I wasn't really talking about my API, but rather _any_ future API.

Specifying context isn't necessary as it is with the dri because we
only save state on a VT basis. The di knows which VT you are on
and tells the driver to restore the correct settings. If we are
only talking about mode/display settings the di layers of both my
API and all current API's already send enough information to
accomplish this task.  If we are talking about advanced acceleration
then another VT private data structure needs to be sent as well.

On screen memory isn't required to be restored in most virtualizatons.
As long as the "rules" include that the application may be required to
refresh the entire screen at any time. Offscreen memory can either
obey the same "rules" or be allocated to specific VT's. It is
easiest to say that all memory on or off screen has to be refreshed
if it is "dirty". My API allows the client app to detect that the
surfaces are dirty and the client would then refresh them. We would
need to add in the signals so that the app doesn't have to poll
the status.

>Only thing we can do is that if app told us that it uses new semantic 
>(/dev/null mmap replacing, f.e.), after framebuffer returns back it 
>must confirm it with some action (mmaping of /dev/fb, or some fb API 
>action), and until it confirms it, decline to execute any of commands
>submitted, as it is 100% sure that app did not restore its context yet.

Good idea, once the app gets the signal it should send a command down
to tell the driver that it has populated all of the "content".

Note the difference between "Context" and "Content". The driver can
restore the context. That includes the mode/display settings. The
size/location of command buffers. The cursor settings. (and if you
want to include advanced acceleration in the mix, it could include
the size/location of textures, video surfaces, etc). The problem is
that while we can restore all of the "Context" the "Content" is
something the driver would not have.
 "Content" is the contents of the frambuffer, cursor, and offscreen
textures or scratch memory. The app has to put that all back.

RE: [Linux-fbdev-devel] API prototype doc

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

On  5 Dec 01 at 10:43, Sottek, Matthew J wrote:

> The dri works this way already but on a per client basis, we need
> it on a per VT basis.

All commands your fbdev API presents are not context sensitive. At least
it looks that way to me. After console switch all on-screen and off-screen
memory is lost. 

Only thing we can do is that if app told us that it uses new semantic 
(/dev/null mmap replacing, f.e.), after framebuffer returns back it 
must confirm it with some action (mmaping of /dev/fb, or some fb API 
action), and until it confirms it, decline to execute any of commands
submitted, as it is 100% sure that app did not restore its context yet.

> >I think that replacing mapping with /dev/null one (and delivering
> >signal) is better
> 
> So you are saying, instead of blocking the app when it writes, just
> map it over to /dev/null and allow the app the continue.

Yes.
                                                Petr Vandrovec
                                                van...@vc...
                                                

RE: [Linux-fbdev-devel] API prototype doc

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

>No. fbdev app can leave hardware in any state.

Right, but the fbdev driver needs to save the full context between
VT's. The di portion saves all the mode info but you may have to
save a bunch of other context information if you are doing accel.

The dri works this way already but on a per client basis, we need
it on a per VT basis.

>I think that replacing mapping with /dev/null one (and delivering
>signal) is better

So you are saying, instead of blocking the app when it writes, just
map it over to /dev/null and allow the app the continue.

I like this better than blocking the app. Blocking can cause
unexpected behavior since almost no app is expecting to block on
a memory write.

-Matt
                                                

RE: [Linux-fbdev-devel] API prototype doc

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

On  5 Dec 01 at 8:38, Sottek, Matthew J wrote:

> And a fb based installer that needs kernel messages on another
> terminal plus a console just in case.
> And an embedded controller that runs a diagnostic app on a different
> VT from the main display without shutting down the main display.
> 
> I can not see how this is a good idea.

Fb apps can close /dev/fb* when they receive switch info. But then
we are again where we were before - you must be trusted app to
catch VT switch.
 
> That's what I thought, but that doesn't work for our needs because
> VT switch handlers are for trusted apps. The X server runs as root,
> so do the old svgalib apps. The point is, that something with direct
> hardware access needs to be trusted to leave the hardware in a known
> safe state when leaving. That isn't what we have here. 

No. fbdev app can leave hardware in any state. You can always run fbset
after it exits. Problem is when fbdev app running on background still
fills framebuffer with black color again and again - and I think
that it is user problem. Only thing we need is to execute
'fuser -k /dev/fb*' and 'chmod 600 /dev/fb*' on console logout, and 
then each user can screw only itself.

> The best alternative I see at this time is to, on a VT switch, remove
> any mappings that clients may have and install a zero page fault
> handler that blocks applications that attempt to write until the
> VT is switched back. This only impacts mmaped clients as the other
> interfaces are easy to block. We could also have the client request

Such as busmaster clients? :-)))

> to be signaled so they can do something other than block, and are
> notified on return so they can refresh... but the signal handling
> has to be optional.

I think that replacing mapping with /dev/null one (and delivering
signal) is better - app has to query framebuffer state again after 
it gets control back, and it also has to repaint screen, so an 
additional mremap during these actions is not a big problem.
Only problem is that write(fd, framebuffer, sizeof(framebuffer))
may yield incorrect (black) result - but it is what you get if
you have shared resource, and you refuse to serialize accesses due to
security concerns.

I'd vote for suspending app when kernel is able to restore screen
contents, mapping and fb state after fb is available again, but as 
it does not do that, there is no reason for suspend - you'll get invalid
data anyway, only difference is when write() finishes.
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] API prototype doc

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

On Wed, Dec 05, 2001 at 10:55:55AM +0100, Geert Uytterhoeven wrote:
> On Tue, 4 Dec 2001, Sottek, Matthew J wrote:
> > >>The only reason to not allow mmap is that it is hard to force apps
> > >>to stop writing when they shouldn't.
> > 
> > >Why to stop them? If we do not provide full virtualization for them,
> > >we should not put any additional policy on their behavior.
> >  
> > I'm ok with leaving out policy, but the problem is that we have no
> > way to notify the client in a timely manner either. They would
> > have to poll the surface to look at the status.
> > 
> > So what should be done on a vt switch?
> > I think it may be ok to zap() someone's mmap during a vt switch but
> > otherwise make them work out their own policy. vt switches are
> > slow anyway.
> 
> That's why for 2.5.x we wanted to disable VT switching for a VT that has its
> /dev/fb* opened by some application.

Does that mean we cannot anymore switch away from X to console ?

Friendly,

Sven Luther
> 
> > I am unsure of how XFree handles this. Does the X server trap the
> > vt switch sequence, call leave_vt() then switch the vt?
> 
> The X server indeed installs a VT switch handler, and releases access to the
> hardware and does the VT switch.
> 
> 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 mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] API prototype doc

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

On Tue, Dec 04, 2001 at 09:15:01AM -0800, Sottek, Matthew J wrote:
> 
> >>The only reason to not allow mmap is that it is hard to force apps
> >>to stop writing when they shouldn't.
> 
> >Why to stop them? If we do not provide full virtualization for them,
> >we should not put any additional policy on their behavior.
>  
> I'm ok with leaving out policy, but the problem is that we have no
> way to notify the client in a timely manner either. They would
> have to poll the surface to look at the status.
> 
> So what should be done on a vt switch?
> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.
> 
> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

Well, X handles it in two ways :

1) X is not fbdev aware ...

  => it simply use vesa to save the text screen status and content, and hopes
     that fbdev did save the data before.

  (notice, on the glint driver is not fbdev aware for boards other than pm2
   one, but X cohabits nicely with pm3fb in this way)

2) X is fbdev aware, and using fbdevhw.

  => again, fbdev is supposed to save its stuff when leaving the vt.

When leaving X again, it is Xs turn to save it's stuff.

Some syncing is involved, which slows down things.

Friendly,

Sven Luther

RE: [Linux-fbdev-devel] API prototype doc

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

>That's why for 2.5.x we wanted to disable VT switching for a VT
>that has its /dev/fb* opened by some application.

Geert,
  I agree that just disabling VT switching makes things very easy,
but you are eliminating behavior that I would say is very
required. It just isn't a good trade.
  Lots of people run an X server on one virtual terminal and 
leave the other terminals as consoles, or run two X servers at
different depths. You can't do this if you can't VT switch
while an application is running.
And what happens when an app locks up with the device open? Forget
VT switching.
And a fb based installer that needs kernel messages on another
terminal plus a console just in case.
And an embedded controller that runs a diagnostic app on a different
VT from the main display without shutting down the main display.

I can not see how this is a good idea.

>> I am unsure of how XFree handles this. Does the X server trap the
>> vt switch sequence, call leave_vt() then switch the vt?

>The X server indeed installs a VT switch handler, and releases
>access to the hardware and does the VT switch.

That's what I thought, but that doesn't work for our needs because
VT switch handlers are for trusted apps. The X server runs as root,
so do the old svgalib apps. The point is, that something with direct
hardware access needs to be trusted to leave the hardware in a known
safe state when leaving. That isn't what we have here. We are
eliminating the need for direct hardware access. We are virtualizing
the graphics device and providing safe interfaces for user applications
that are not trusted. If you want to trust user apps then just run
them as root and forget the kernel.

The best alternative I see at this time is to, on a VT switch, remove
any mappings that clients may have and install a zero page fault
handler that blocks applications that attempt to write until the
VT is switched back. This only impacts mmaped clients as the other
interfaces are easy to block. We could also have the client request
to be signaled so they can do something other than block, and are
notified on return so they can refresh... but the signal handling
has to be optional.

 -Matt

RE: [Linux-fbdev-devel] API prototype doc

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

On Tue, 4 Dec 2001, Sottek, Matthew J wrote:
> >>The only reason to not allow mmap is that it is hard to force apps
> >>to stop writing when they shouldn't.
> 
> >Why to stop them? If we do not provide full virtualization for them,
> >we should not put any additional policy on their behavior.
>  
> I'm ok with leaving out policy, but the problem is that we have no
> way to notify the client in a timely manner either. They would
> have to poll the surface to look at the status.
> 
> So what should be done on a vt switch?
> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.

That's why for 2.5.x we wanted to disable VT switching for a VT that has its
/dev/fb* opened by some application.

> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

The X server indeed installs a VT switch handler, and releases access to the
hardware and does the VT switch.

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] API prototype doc

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

On  4 Dec 01 at 11:12, Sottek, Matthew J wrote:
> >App uses all (or needed of) VT_LOCKSWITCH/VT_UNLOCKSWITCH ioctls + 
> >VT_SETMODE (fields acqsig, relsig) ioctl if it needs direct access to
> >fb.
> 
> Ah, but we have an issue here. The X server is a trusted binary,
> therefore we can rely on it to behave. Fb apps are not trusted
> therefore we have to make sure they behave. Just like the DRI only
> allows access when you have the lock, and you can't get the lock
> when you are switched away.

Anything what can mess my console must be trusted. More or less.
If application does not have these right, kernel must not postpone
VT switch until app answers, so only unmapping & delivering signal (SIGBUS) 
to app is possible.

> Two apps on one VT is policy, two apps of different VT's is supposed
> to behave like two apps on different computers. It isn't policy,
> it is kernel enforced.

It is impossible. VTs are virtual terminals, fully virtualized, while
there is only one underlying fb - so apps have to know about each
other, and have to know about VT concept, if they want to support it.
If they do not -> suid & LOCKSWITCH.

> >Why do you think that VT switches are slow? And tearing down existing
> >mappings is not trivial.
> 
> A vt switch console<->XFree takes a couple seconds on some hw,
> plus you may have to resync the display anyway. zap_page_range()
> happens very fast in comparison, not trivial but shouldn't be
> eliminated on grounds of slowness. Perhaps eliminated because
> it is scary, but not slowness :)

It is bug in X, not anything else. It is true that XFree mga driver
reads whole 64KB EEPROM through i2c on startup - but it is just
silly driver. I can switch from fbtv to another console in less than
20ms (== sooner than TV field finishes).

> >You need physical address for mmap on /dev/kmem, while you
> >need busaddress for doing DMA transfers from other PCI
> >busmasters to videoram. 
> 
> Right, but we don't need to tell anyone where to mmap on /dev/kmem.
> If they want to mmap they should use the fb. We only need to
> provide them a way to do DMA... so that's a bus address for PPC
> and a physical address on x86. We can just call it dma_address.

It is bus address on x86. It is just happy coincidence that bus address ==
== physical address. It is bus address by definition...
 
> This all depends on what Network Transparent means to you. Doing
> read/write on a character file works over NFS and then you don't
> need to worry about authentication. Network connections from an
> untrusted machine need some other layer of authentication but that
> should happen in some root daemon. Assuming that some filesystem
> can be network exported you should be able to use the device from
> another trusted machine, that's all I was trying to achieve.

And who is listening on other end of wire if you'll use NFS read+lseek+write
solution? How you'll ensure that change is propagated through wire,
and not cached back? Besides that no system I have interconnected offers
NFS for writting - it is far too dangerous without hardcoded ARP tables.
 
> When you want to set a mode you have to see if it fits, including
> the information about what the other context is using up. If you
> can't fit the new mode you do one of two things. Either don't

It fits. Only VT level knows resolution of other VTs. And if fbdev
should know this itself - then do not change API at all... I see no
reason for change then...

> In the case where this happens without the user requesting it.
> (Vt switching to the two "large" modes) you'll get a fb_set_mode()
> from the di layer. The driver can either change the requested
> mode and apply it, or change the "other_context" and set the
> requested mode. Either way one VT is altered... can't make
> them both happy.

Driver will refuse to set mode you requested on console switch.
 
> The driver is supposed to return success at all costs when it
> gets a fb_set_mode(), even if it has to alter the mode greatly.
> The driver gets to decide what is best, if the user wants to
> be sure, it should test the mode first.

He tested it. It worked. Then he changed something else, and now 
kernel refuses previously working mode. It is possible to split
memory on driver load for 24MB for fb0 & 8MB for fb1 - but why if
you can do it dynamically. At least I hoped that it will be possible
with new APIs.

And no, I cannot change mode greatly, current console will not survive
if you'll change vc_cols/vc_rows in console switch, besides that it
violates layering.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

RE: [Linux-fbdev-devel] API prototype doc

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

>App uses all (or needed of) VT_LOCKSWITCH/VT_UNLOCKSWITCH ioctls + 
>VT_SETMODE (fields acqsig, relsig) ioctl if it needs direct access to
>fb.

Ah, but we have an issue here. The X server is a trusted binary,
therefore we can rely on it to behave. Fb apps are not trusted
therefore we have to make sure they behave. Just like the DRI only
allows access when you have the lock, and you can't get the lock
when you are switched away.

Two apps on one VT is policy, two apps of different VT's is supposed
to behave like two apps on different computers. It isn't policy,
it is kernel enforced.

I am willing to admit that we may _have_ to fall back on the
"everyone please behave" method, but I would like to be sure we've
exhausted all other methods first.

>Why do you think that VT switches are slow? And tearing down existing
>mappings is not trivial.

A vt switch console<->XFree takes a couple seconds on some hw,
plus you may have to resync the display anyway. zap_page_range()
happens very fast in comparison, not trivial but shouldn't be
eliminated on grounds of slowness. Perhaps eliminated because
it is scary, but not slowness :)

>You need physical address for mmap on /dev/kmem, while you
>need busaddress for doing DMA transfers from other PCI
>busmasters to videoram. 

Right, but we don't need to tell anyone where to mmap on /dev/kmem.
If they want to mmap they should use the fb. We only need to
provide them a way to do DMA... so that's a bus address for PPC
and a physical address on x86. We can just call it dma_address.

>You can use UDP if you want same behavior on local - but I do not
>think that you'll get remote behavior same as local anytime. For remote
>access you must do authentication, authorization, encryption and couple
>of other things you do not require on local system because of someone
>else already took care of auth*, and you do not need encryption because
>of nobody without root priviledges can see what you are doing.

This all depends on what Network Transparent means to you. Doing
read/write on a character file works over NFS and then you don't
need to worry about authentication. Network connections from an
untrusted machine need some other layer of authentication but that
should happen in some root daemon. Assuming that some filesystem
can be network exported you should be able to use the device from
another trusted machine, that's all I was trying to achieve.

>They are same from my (and from G400) viewpoint. I have byte array,
>source color organization, and framebuffer color organization. And
>either hardware can do that conversion, or it cannot.

Right, I need to think of something for this.

Your last part provides a good corner case that can be summed up
as follows:
>What happens when you are supporting two fb's with one memory space,
>and you get into a situation where two modes are valid on their
>own (or with a small "partner") but they don't fit at the same
>time.

I would say that the best thing to do depends on how the driver
wants to behave. I would use two private structures but both one
has the context # for the "other" context. Like:

struct my_priv {
  stuff...
  u32 context;
  u32 other_context;
}

When you want to set a mode you have to see if it fits, including
the information about what the other context is using up. If you
can't fit the new mode you do one of two things. Either don't
set the mode and tell the user, or using the "other_context"
with difb*() change the other guy's mode so that you can now
fit. See how the context makes things nice? Just call
difb_set_mode(other_context...) and the other fb gets a call
from the di layer and has no idea that it really came from the
other context.

In the case where this happens without the user requesting it.
(Vt switching to the two "large" modes) you'll get a fb_set_mode()
from the di layer. The driver can either change the requested
mode and apply it, or change the "other_context" and set the
requested mode. Either way one VT is altered... can't make
them both happy.

The driver is supposed to return success at all costs when it
gets a fb_set_mode(), even if it has to alter the mode greatly.
The driver gets to decide what is best, if the user wants to
be sure, it should test the mode first.

-Matt

RE: [Linux-fbdev-devel] API prototype doc

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

On  4 Dec 01 at 9:15, Sottek, Matthew J wrote:
>  
> I'm ok with leaving out policy, but the problem is that we have no
> way to notify the client in a timely manner either. They would
> have to poll the surface to look at the status.
> 
> So what should be done on a vt switch?

App uses all (or needed of) VT_LOCKSWITCH/VT_UNLOCKSWITCH ioctls + 
VT_SETMODE (fields acqsig, relsig) ioctl if it needs direct access to
fb.

> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.

Why do you think that VT switches are slow? And tearing down existing
mappings is not trivial.
 
> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

LOCKSWITCH + SETMODE to deliver signals on console switches.
 
> >You need busaddress for this. Bus address != physical address
> >!= virtual address, see PPC.
> 
> Just copying what was there for sysmem_start. Bus address is confusing
> to platforms who don't have them just like physical address is
> confusing to you.

You need physical address for mmap on /dev/kmem, while you need busaddress
for doing DMA transfers from other PCI busmasters to videoram. 

> >fd = socket(PF_UNIX, SOCK_DGRAM, 0);
> >connect(fd, (struct sockaddr*)&(struct sockaddr_un){AF_UNIX, 20,
> >"/dev/gfx/fb0/command"}, 128);
> 
> While I do like the features of this one better, It scares me
> a little. I don't like having network behavior different than
> local, it should be transparent, and the complexity/overhead
> is a little higher. This could be bad for small
> fb_set_cursor_pos type commands.

You can use UDP if you want same behavior on local - but I do not
think that you'll get remote behavior same as local anytime. For remote
access you must do authentication, authorization, encryption and couple
of other things you do not require on local system because of someone
else already took care of auth*, and you do not need encryption because
of nobody without root priviledges can see what you are doing.

> >No. Kernel driver should provide only one API, unless new one is not
> >superset of old API.
> 
> I don't agree. The kernel needs to provide a consistent API. For
> ioctls this means you really should not be changing them after they
> become widely used.  Since we are moving to a more advanced command

It is userspace library business to do these conversions. Kernel should
support one, at most two for transition period, interfaces. If you are
upgrading kernel, upgrade your userspace too. If you are not going to
upgrade kernel - no problem, kernel API does not change.

> >(mainly) about monochrome -> current fb type for painting
> >characters on the screen. And couple of hardware can do YUV
> ><-> RGB on the fly.
> 
> I have to think about this. YUV<->RGB is probably going to need
> some other interface that goes with overlays. Color expanding
> blits are a valid thing that I missed.

They are same from my (and from G400) viewpoint. I have byte array,
source color organization, and framebuffer color organization. And
either hardware can do that conversion, or it cannot.
 
> >two displays are provided from one memory pool? Will di layer just
> >provide dummycon for VT which is incompatible with current hardware 
> >configuration?
> 
> I'm not sure what you mean about dummycon for VT?
> 
> Two framebuffers with two (or more) displays has two fb contexts. Just
> like now... you do the whole thing as two drivers, two privs and all.

You have two framebuffers, two displays, two fb contexts, and only one
memory they share. Now you do

VT #1  belongs to fb #0
VT #2  belongs to fb #0
VT #11 belongs to fb #1

Your videocard has 8MB total. Now you select 1024x512/32bpp on all
VTs, each uses 2MB of videoram. VT#1 and VT#11 are visible. Now you change
VT#1 size to 1024x1536/32bpp - consuming 6MB + 2MB. Now you switch to VT#2,
and resize #11 to 1024x1536/32bpp - this is again valid resolution, as
2MB + 6MB <= 8MB. But now, when you switch back to VT#1 - oops, VT#1's
resolution needs 6MB, VT#11 needs 6MB, total 12MB. Impossible...
So *_set_var or how is it named in your API, fails, and VT layer must
be able to cope with that. Temporary moving VT from fbcon to dummycon,
or refusing to switch VT, are two possible solutions.
                                            Petr Vandrovec
                                            van...@vc...
                                            

RE: [Linux-fbdev-devel] API prototype doc

[Michel <mic...@ii...>]

On Tue, 2001-12-04 at 18:15, Sottek, Matthew J wrote:

> So what should be done on a vt switch?
> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.
>=20
> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

More or less, yes. It has a semaphore to guard hardware access.


--=20
Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

RE: [Linux-fbdev-devel] API prototype doc

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

>>The only reason to not allow mmap is that it is hard to force apps
>>to stop writing when they shouldn't.

>Why to stop them? If we do not provide full virtualization for them,
>we should not put any additional policy on their behavior.
 
I'm ok with leaving out policy, but the problem is that we have no
way to notify the client in a timely manner either. They would
have to poll the surface to look at the status.

So what should be done on a vt switch?
I think it may be ok to zap() someone's mmap during a vt switch but
otherwise make them work out their own policy. vt switches are
slow anyway.

I am unsure of how XFree handles this. Does the X server trap the
vt switch sequence, call leave_vt() then switch the vt?

>You need busaddress for this. Bus address != physical address
>!= virtual address, see PPC.

Just copying what was there for sysmem_start. Bus address is confusing
to platforms who don't have them just like physical address is
confusing to you.

>fd = socket(PF_UNIX, SOCK_DGRAM, 0);
>connect(fd, (struct sockaddr*)&(struct sockaddr_un){AF_UNIX, 20,
>"/dev/gfx/fb0/command"}, 128);

While I do like the features of this one better, It scares me
a little. I don't like having network behavior different than
local, it should be transparent, and the complexity/overhead
is a little higher. This could be bad for small
fb_set_cursor_pos type commands.

>> Could be done that way too but I see a couple issues. First a bitmap
>> has no priority, how do you know what the client really wanted? My
>> way the client can just poll until they get one they can live with.

>Highest one. 

I still don't like the "bitmap" idea. It is just a matter of preference
and really doesn't change much functionally.

>No. Kernel driver should provide only one API, unless new one is not
>superset of old API.

I don't agree. The kernel needs to provide a consistent API. For
ioctls this means you really should not be changing them after they
become widely used.  Since we are moving to a more advanced command
interface we have a little more flexibility. We can support consistent
interfaces while still accommodating design changes. Therefore the
kernel provides whatever API the client expects. An API that is
sufficiently unused do to age could be dropped.

This certainly doesn't give anyone license to abandon good interface
design. Kernel interfaces should change very rarely and really
should use a superset interface whenever possible. BUT, when you
just really need to change the behavior of a command this would
allow you to do so without breaking apps.

>Hardware can do that. We are not talking about RGB16->RGB32, but
>(mainly) about monochrome -> current fb type for painting
>characters on the screen. And couple of hardware can do YUV
><-> RGB on the fly.

I have to think about this. YUV<->RGB is probably going to need
some other interface that goes with overlays. Color expanding
blits are a valid thing that I missed.

I really don't like the idea of put() passing a format and expecting
the kernel to handle it. If we exposed some list of valid formats
in fb_surface_info(?) it might be acceptable.

>> that is shared. All shared resources need mutual exclusion. What
>> happens when the driver is updating the fb_display_info structure
>> and another process queries the structure. If it is shared you
>> could get invalid results. Then you could add a mutex so this
>> doesn't happen, but someone will forget and now you've got problems.

>But someone else can do it properly finegrained...

I agree, but the circumstances of when you call a difb*() are
when you need to set something out of the normal flow. Like
setting the display_info when you are in a set_mode_info()
function. It just doesn't happen on a regular basis, so the most
simple correct solution doesn't give up much (I'm sure it is
not even measurable).

>And when I thought about it during night, how this API address when
>two displays are provided from one memory pool? Will di layer just
>provide dummycon for VT which is incompatible with current hardware 
>configuration?

I'm not sure what you mean about dummycon for VT?

One framebuffer which feeds two displays with their own timings means
the driver just has two fb_display_infos. Notice how all the
*display_info() functions have an index so you can change the
displays independently.

Two framebuffers with two (or more) displays has two fb contexts. Just
like now... you do the whole thing as two drivers, two privs and all.

One framebuffer with two displays with the same timings (a-la the i810
with TV or LCD) has to multiplex the two displays into one
fb_display_info, probably using device private flags to mark valid
heads.  This behavior is just too different to wrap in a sane way, a
mode setting app will just have to be smart enough to allow hardware
specific extensions.

RE: [Linux-fbdev-devel] API prototype doc

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

On Mon, 3 Dec 2001, Sottek, Matthew J wrote:
> >oo, are there cases where extra pitch memory is used for things?  the area
> is 
> >so broken up and in small chunks that i didnt think any hardware developer 
> >would use it.  but if intel's do that, i'd imagine there is probably
> something 
> >there.  this certainly causes problems i wasn't aware of.
>  
> Well I don't use the extra, but I could :) I was looking for a cheap example
> of when you wouldn't want mmap to happen. Some hardware have tiled memory
> framebuffers that might not work correctly unless you knew about the
> tiling. Intel's tiled memory isn't a problem, but I think some might be.
> 
> The extra pitch-width area isn't useless. You can put other surfaces there.
> You think of the area as being broken up, but really it is just a thinner
> area with the same pitch as the framebuffer. i.e. if your framebuffer is
> 800x600 at 16bit, on Intel hardware you have a fb pitch of 2048. That
> is an area of 448x600 with a pitch of 2048 that can be used.

There exist PowerMac graphics cards that put the hardware cursor in that area.

Gr{oetje,eeting}s,

						Geert

P.S. Matt: I'm still reading your document (I'm halfway). I'll post my list of
     questions and comments after I've finished reading the whole document. So
     far it looks nice!
--
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