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

Re: [Linux-fbdev-devel] video overlay in fbdev, take 3, plus fbcon question

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

On Fri, Jul 13, 2001 at 04:10:28PM +0200, Romain Dolbeau wrote:
> Hello,
> 
> Here's a third draft of a possible interface for overlay support
> in fbdev. I added a stride parameter suggested by Gerd Knorr,
> and a way to specify a color or alpha key for overlay clipping/
> blending. If someone is interested, I have a small app
> that use the interface to put a JPG as video overlay
> on the console.
> 
> I have a question on the subject of alpha: how is fbcon
> and the driver supposed to deal with the alpha channel ?
> Is the _clear function supposed to clear the alpha channel
> or to left it alone ? What about the _putc, do they set
> the alpha at a specific value (foreground and background),
> or should they left the alpha alone ? Same question for invert,
> too :-)

have we functionality to do rectangle lists, as X does ? Could this be usefull ?

You need something similar if you want to add clipping support to video overlay.

Well at least for complexe clipping, i guess that for most fb apps, you would
clipp out only a rectangular region, and nothing more complex.

That said, this is how most Xv driver handle this (well at least the
glint/permedia3 one, but i inspired myself from the mga one).

We either do opaque or alpha blended i(if supported) overlay.

in the opaque case, if the hardware supports it, we can do clipping.

Clipping is currently done by writting a value to the alpha channel for each
pixel that will show (or not show) the overlay. Then we can do alpha keyed 
overlay on them. Cards that don't support alpha keyed overlay or in mode without
alpha channel (depth 8, 16 or 24) you have to choose a color and use color keyed
overlay.

In the case of alpha blending, we can provide a alpha blend value (prefereably
an 8 bit one, since that is what permedia3 supports, altough it really uses only
the top 2 bits) and the overlay is blended. In this case it is not really necessary to do clipping, altough some cards support per pixel bledning using the alpha channel.

Friendly,

Sven Luther

[Linux-fbdev-devel] sstfb : voodoo1 and initial voodoo2 support

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

Hi all,

Just to let you know that i have an updated version of my sstfb driver, for
3dfx' voodoo1 and voodoo2

the latest version is avaiable only on cvs , and i still have some issues
with the voodoo2 support, but
well... it mostly works :-)
(sory for thelong url, this is the webcvs interface on sourceforge...)
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sstfb/sstfb/sstfb.c?rev=1.21&
content-type=text/vnd.viewcvs-markup

once i find why i can progam the pll the first time and not afterwards
(basicaly you're stuck with the
default video mode pll settings, making any subsequent fbset hazardous) ,
i'll make a nice tarball ...

ghoz

[Linux-fbdev-devel] how to drop access to an ioremapped area ?

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

Hi all ...

I'm looking for  a way to somehow "drop" all access to a specific ioremaped
area ,
for a time , and then "reenable" it .. is there a way to do something like
that ?

mmh .. an explanation of what i'm trying may be more clear :
I'm working on a voodoo1 /voodoo2 fb driver, and i'd like to let it
cooperate with
userland accel programs (namely : glide apps).

Glide initialises completely the board, messing up with the fb driver, but
as glide is using a /dev/3dfx in order to access the board, i guess i can
hack the
/dev/3dfx so it calls an ioctl on the fb driver before letting glide
initialise everything.
The driver can save the state of the board, shutdown the board, and let
glide do
whatever it has to do . at the end of glide, /dev/3dfx would call another
ioctl to restore
the fb driver status . Let's imagine that this is done, and works, now  the
question is
how do i disalow FB applications (namely X_FBDev)  to acces the frame buffer
?

if i unmap the frame buffer when one application is still using it, i'm
quite sure  it'll
die horibly , so i 'd like to somehow redirect all access to uh .. /dev/null
so when glide
is active, the fb app don't mess with the board memory, as the odds are that
glide is using
this memory ...

any advices ? clues,anyone ?

thank you  in advance ,

ghoz

Re: [Linux-fbdev-devel] Dual display on framebuffer with i810e andET6000

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

On Mon, 16 Jul 2001, Herman Theron wrote:
> The reason whyt I say this is after I insmod i810fb, I want to map a virtual console to the i810fb. I used con2fb:
> 
> con2fb 1 2
> 
> to map virtual console 2 to frame buffer device 1(/dev/fb1)
> 
> But, I see nothing happening on the screen connected to the i810fb. The screen stays blank. Am I missing something??

con2fbmap 2 1

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] Dual display on framebuffer with i810e andET6000

[Herman T. <HEt...@cs...>]

Makes sense.

I changed my BIOS setting to choose the ET6000(pci device). When the =
kernel boots, the system loads the VESA framebuffer (showing the bootlogo).=


OK. I compiled my kernel with module support for the i810fb.
I login as root, then do a modprobe i810fb. The module gets loaded(lsmod), =
and dmesg says(i810 ... loaded). cat /proc/fb gives something like:
0: VESA
1: i810
(this is just out of my head).

So it looks as if everyting is fine. What am I supposed to see in the =
screen connected to the i810 adapter when I insert the module? It doesn't =
look like if the adapter gets initialised since my monitor's led stays =
yellow(which normally turns green when the adapter is working). Windows =
normally display a message to say that "if you can see this message, ... =
adapter is initialised..." or something to that effect. Can we do the same =
for Linux?

The reason whyt I say this is after I insmod i810fb, I want to map a =
virtual console to the i810fb. I used con2fb:

con2fb 1 2

to map virtual console 2 to frame buffer device 1(/dev/fb1)

But, I see nothing happening on the screen connected to the i810fb. The =
screen stays blank. Am I missing something??

Thanks for the help.
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

>>> James Simmons <jsi...@tr...> 07/13/01 04:51PM >>>

> Now, how can I setup the ET6000 to work alongside the i810e framebuffer.=
=20
> Firstly, is it possible?=20

It depends on how much the graphics hardware depends on the BIOS.=20

> I know the ET6000 works with the VESA vga driver.

Which means that the ET6000 has to be the first card initializied in your
system. VESA always maps to this. The i810e will have to be your secondary
card. Look in your BIOS to see if their is a option to select which card
gets booted first (AGP or PCI). Make sure the PCI is booted first. You
have to do a few tricks with con2fb or use the map setup option to get the
right VCs maps to the right framebuffer devices, but that is the easy
part.

> Can somebody point me to a document, or give advise on setting this =
up.=20
> Or do I need a specialised driver for the ET6000? If so, I would like to
> try to write one. But I need some help.

It would be nice to have a ET6000 driver :-) I never found docs for this
card tho :-/


_______________________________________________
Linux-fbdev-devel mailing list
Lin...@li...=20
http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel=20

Re: [Linux-fbdev-devel] Dual display on framebuffer with i810e and ET6000

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

On Fri, 13 Jul 2001, James Simmons wrote:
> > Can somebody point me to a document, or give advise on setting this up. 
> > Or do I need a specialised driver for the ET6000? If so, I would like to
> > try to write one. But I need some help.
> 
> It would be nice to have a ET6000 driver :-) I never found docs for this
> card tho :-/

I checked with Koen Gadeyne who used to work on the XFree86 ET6000 driver, and
he has no PDF docs. He sent the paper docs to XFree86 when he stopped working
on the driver.

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] SiS630

[Jeroen C. <jer...@ho...>]

Hi,
I'd like to know if there's any active development going on with the sis630
fb. I'm no programmer but if I can help with testing patches and stuff, I
hereby offer my services! :)
Greetings Jeroen

[Linux-fbdev-devel] i810/i815 FB Problem.

[Nicu P. <pa...@ra...>]

Hi,

Trying to do some cosmetic :) changes to my machine I generated a
linux_logo.h to hold an bigger image.
If this image has the exact size (1024x768,800x600) as the
resolution to boot with i810fb the kernel crashes on boot with ooops just
when is trying to init fb device.
If this image is lower then the resolution to boot all is ok.
Also I modify in fbcon.c the #define values to something like 790x590 for
a 800x600 image in a 800x600 resolution at boot (modified in i810fb.c
driver) and the kernel booted ok but the image of course was trashed.
The only work aroud that I manage to do is to make a 790x590 image when
booting at 800x600 resolution.
 I know this is just cosmetic but I am afraid that this hides a BUG.


-- 
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay & fbtv

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

> If it's not possible via the fbdev API because the
> device is exclusively opened, then I'll hack another mecanism in
> the kernel, probably via /proc/pmu like I do for backlight. It may
> be ugly, but it works and I don't want to wait for proper support in X.

Hum. I know I want to make opening /dev/fbX disable VC switching, if we
have VT console. As for the multiple opens. I think we have no choose but
to leave it as such. It will also break OpenGL. Unfortunely the proper
solution to handling multiple process to graphics hardware is very
complex. It would be sometime before this is all sorted out.

Re: [Linux-fbdev-devel] mmap()ing of FB memory area

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

> No, this is too rigid.
> 
> what we need is a onboard memory manager, which will know if we make 
> reservation of memory, and don't allow another app to use that memory,
> but allow another app to use memory that is not overlapping.

Basically you described emulating window IDs. This is tricky but can be
done. The trick I have seen to emulate window IDs is to mmap a region of
the framebuffer to a process. Then those page tables belong to it. If
another process accesses it it segfaults. Of course this limits your
window sizes a bit. They have to be alignied on 4K page boundaries. 

> The DRI/drm folk may do something such, but my understanding is that the 
> ressource management used is just a joke, since in truth it is the X
> server who does all of this. I may be wrong though.

I haven't looked at SAREA in detail. I have to look over the DRI 2 specs
in detail. The white paper is pretty crappy.

[Linux-fbdev-devel] Re: IBM E15 framebuffer patch for kernel 2.4.6

[Pim Z. <P.Z...@ma...>]

> > Now the E15 frambuffer patches for kernel 2.2.18 that SuSE use
> > (http://www.amberdata.demon.co.uk/carolina/ibm_e15fb.diff.gz)
> > won't apply at all to kernel 2.4. And it also seems the
> > interface has changed.
> > 
> > So, has anyone ported this framebuffer code to kernel 2.4?
> 
> Never heard of this driver. Thanks for pointing it out. I guess I can take
> a look at it. Please note I don't have this hardware.

Well, I had never heard of the Linux Fbdev development list
(and http://www.linux-fbdev.org/). Thanks for pointing this out.

Of course, I'd be happy to test anything you produce.

Regards,
Pim

Re: [Linux-fbdev-devel] mmap()ing of FB memory area

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

> Do you suggest we're better off waiting for the availability
> of the FB filesystem, and _then_ try to implement a video
> extension to the FB layer ?

We can implement it now. It's just extending fb to other types of buffers
will get trick without a filesystem

> BTW, could /dev/fv/overlay0 belong to the _same_
> memory area than /dev/fb/frame0 ? In this case
> how and when are the respective size defined ?

Hum. This is similar to the problem of window IDs. How do we handle this.
Also some higher end cards have buffers per window where each window is
defined by a window ID.

[Linux-fbdev-devel] Re: IBM E15 framebuffer patch for kernel 2.4.6

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

> Now the E15 frambuffer patches for kernel 2.2.18 that SuSE use
> (http://www.amberdata.demon.co.uk/carolina/ibm_e15fb.diff.gz)
> won't apply at all to kernel 2.4. And it also seems the
> interface has changed.
> 
> So, has anyone ported this framebuffer code to kernel 2.4?

Never heard of this driver. Thanks for pointing it out. I guess I can take
a look at it. Please note I don't have this hardware.

Re: [Linux-fbdev-devel] Dual display on framebuffer with i810e and ET6000

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

> Now, how can I setup the ET6000 to work alongside the i810e framebuffer. 
> Firstly, is it possible? 

It depends on how much the graphics hardware depends on the BIOS. 

> I know the ET6000 works with the VESA vga driver.

Which means that the ET6000 has to be the first card initializied in your
system. VESA always maps to this. The i810e will have to be your secondary
card. Look in your BIOS to see if their is a option to select which card
gets booted first (AGP or PCI). Make sure the PCI is booted first. You
have to do a few tricks with con2fb or use the map setup option to get the
right VCs maps to the right framebuffer devices, but that is the easy
part.

> Can somebody point me to a document, or give advise on setting this up. 
> Or do I need a specialised driver for the ET6000? If so, I would like to
> try to write one. But I need some help.

It would be nice to have a ET6000 driver :-) I never found docs for this
card tho :-/

[Linux-fbdev-devel] video overlay in fbdev, take 3, plus fbcon question

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

Hello,

Here's a third draft of a possible interface for overlay support
in fbdev. I added a stride parameter suggested by Gerd Knorr,
and a way to specify a color or alpha key for overlay clipping/
blending. If someone is interested, I have a small app
that use the interface to put a JPG as video overlay
on the console.

I have a question on the subject of alpha: how is fbcon
and the driver supposed to deal with the alpha channel ?
Is the _clear function supposed to clear the alpha channel
or to left it alone ? What about the _putc, do they set
the alpha at a specific value (foreground and background),
or should they left the alpha alone ? Same question for invert,
too :-)

All this in case an app want to put some alpha to clip an
overlay...

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] Re: fbdev, console, (video) overlay/underlay & fbtv

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

>> control the mirroring on the VGA output.
>
>Shouldn't Xinerma be handling that. If it doesn't then as usual XFree86 is
>broken. 

It's not multihead. It's just enabling either the CRT output, the LCD
output, or both. Full multihead would require some support in the
X driver. I hate duplicating functionalities. I have that simple ioctl
to aty128fb that can toggle LCD/CRT outputs, I want it to work while
in X as well. If it's not possible via the fbdev API because the
device is exclusively opened, then I'll hack another mecanism in
the kernel, probably via /proc/pmu like I do for backlight. It may
be ugly, but it works and I don't want to wait for proper support in X.

>As for multiple access issues this is a huge topic. I plan to hold off until 
>2.5.X and when I start working on the framebuffer filesystem. Here we can
>have multiple files where each on can represent a specific type of 
>functionality. With this we can control which functionality can be used
>by only one process at a time versus functionality that can be managed
>between multiple process. 

That's a different issue. 

Ben.

Re: [Linux-fbdev-devel] mmap()ing of FB memory area

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

On Thu, Jul 12, 2001 at 10:22:10AM -0700, James Simmons wrote:
> 
> > But what if a framebuffer use 2 discontinuous memory area,
> > say one for the main framebuffer, one for offscreen stuff
> > like overlay buffer, Z-buffer, texture... how can an app
> > access that ?
> 
> Framebuffer filesystem :-) 
> 
> /dev/fb/frame0  
> /dev/fb/depth
> /dev/fb/overlay
> /dev/fb/stencil

No, this is too rigid.

what we need is a onboard memory manager, which will know if we make reservation of memory, and don't allow another app to use that memory, but allow another app to use memory that is not overlapping.

Maybe this is already possible, don't know though.

The DRI/drm folk may do something such, but my understanding is that the ressource management used is just a joke, since in truth it is the X server who does all of this. I may be wrong though.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay & fbtv

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

On Thu, Jul 12, 2001 at 10:12:00AM -0700, James Simmons wrote:
> 
> > >In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
> > >time, and VC switching is adisabled as long as /dev/fb* is open.
> > 
> > This can be a problem. For example, X will open /dev/fb*, so I won't
> > be able to open it from my command line tool to send it the ioctl that
> > control the mirroring on the VGA output.
> 
> Shouldn't Xinerma be handling that. If it doesn't then as usual XFree86 is
> broken. 

Huh ? what does Xinerama have to do with that ?

The only aim of Xinerama is to unit 2 displays so that it becomes one only. There is no interaction with fbdev or anything apart the 2 X screens. For your information, using Xv on both screens work well, provided both screen support Xv acceleration.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] mmap()ing of FB memory area

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

James Simmons wrote:
> 
> > But what if a framebuffer use 2 discontinuous memory area,
> > say one for the main framebuffer, one for offscreen stuff
> > like overlay buffer, Z-buffer, texture... how can an app
> > access that ?
> 
> Framebuffer filesystem :-)
> 
> /dev/fb/frame0
> /dev/fb/depth
> /dev/fb/overlay
> /dev/fb/stencil

Do you suggest we're better off waiting for the availability
of the FB filesystem, and _then_ try to implement a video
extension to the FB layer ?

BTW, could /dev/fv/overlay0 belong to the _same_
memory area than /dev/fb/frame0 ? In this case
how and when are the respective size defined ?

-- 
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] On i810/i815 fb issues

[Jeff H. <jha...@va...>]

James Simmons wrote:

>> "Agpgart doesn't have a interface so that any driver can ask for X amount of 
>> graphics memory. It assumes that only one client is using and he knows where 
>> he binded the memory."
> 
> 
> >From all the emails I have seen it is really strange how the system for
> agp is setup. On IRIX systems each OpenGL client allocates memory and uses
> a seperate library (udma) to lock down the memory. Then the OpenGL driver 
> for the card sends the kernel driver what memory to use. The driver sets
> it up and data is tranfered. Once done the client frees the memory.
> 
> 
> 
The IRIX implementers had access to much different hardware, agp is not 
as flexible as some of the uma stuff in SGI hardware.

Inserting random pieces of memory into the agp aperture requires a cache 
flush because of the use of write combining memory.  You want to avoid 
swapping memory in and out of cached and ucwc spaces, its terribly 
expensive.  Also if the client accesses the memory through its normal 
mappings while it is mapped into ucwc space, things will go boom.  This 
means that you have to invalidate the original mappings when you lock 
down the memory.  All this is feasible to handle with PAT, but it will 
perform like shit on an x86.  This sort of interface does not make sense 
for agp.  It should also be noted that removing pieces of memory from 
the agp aperture will normally require a graphics pipeline flush, so we 
don't want drivers doing that sort of operation too often.

Basically the agp interface has been well thought out, and I believe 
that it is the best solution considering all the problems and the fact 
that PAT isn't shipping with 2.4.  I'm sure some people might want a 
malloc type interface, but I don't want to be responsible for creating a 
driver which keeps tons of mm book keeping in the kernel where it can't 
be swapped.

-Jeff

Re: [Linux-fbdev-devel] On i810/i815 fb issues

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

> "Agpgart doesn't have a interface so that any driver can ask for X amount of 
> graphics memory. It assumes that only one client is using and he knows where 
> he binded the memory."

From all the emails I have seen it is really strange how the system for
agp is setup. On IRIX systems each OpenGL client allocates memory and uses
a seperate library (udma) to lock down the memory. Then the OpenGL driver 
for the card sends the kernel driver what memory to use. The driver sets
it up and data is tranfered. Once done the client frees the memory.

Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay&fbtv

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

James Simmons wrote:
> 
> > I rather suspect your knowledge about Xinerama is lacking...
> 
> I have seen it used before. Are you saying Xinerama lacks functionality to
> support mirroring.

Mirroring is none of Xinerama's business. Xinerama is an extension which
combines several physical screens to a single logical one.

Mirroring is a driver feature, most of the drivers support it AFAIK but it can
only be configured statically in XF86Config. So using /dev/fb to change it
dynamically makes sense.


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

Re: [Linux-fbdev-devel] mmap()ing of FB memory area

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

> But what if a framebuffer use 2 discontinuous memory area,
> say one for the main framebuffer, one for offscreen stuff
> like overlay buffer, Z-buffer, texture... how can an app
> access that ?

Framebuffer filesystem :-) 

/dev/fb/frame0  
/dev/fb/depth
/dev/fb/overlay
/dev/fb/stencil

etc.

Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay& fbtv

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

> I rather suspect your knowledge about Xinerama is lacking...

I have seen it used before. Are you saying Xinerama lacks functionality to
support mirroring. 

Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay& fbtv

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

> > Nope, X just closes /dev/fb in fbdevHWLeaveVT() ...
> 
> Chicken and egg. You can switch VT if you've closed
> fbdev, and upon changing VT you close fbdev...
> 
> Or is there any way to call fbdevHWLeaveVT
> _before_ changing VT ?

The bigger problem will be with systems without VTs and with a framebuffer. 
Very few embedded devices have keybaords so it makes no sense to have a VT
console on them. For example I run a iPAQ with just a serial console. I
still use the framebuffer tho. I found X not to be very happy with this. 
Now the "community" could force devices to have VT console systems to this
wouldn't go over very well since every byte of memory counts.