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

RE: [Linux-fbdev-devel] fbdev API problems

[Matt S. <mat...@ho...>]

>> Currently mmio and fb pointers are in a PUBLIC data structure, a data
>> structure that is defined for everyone using the fb interfaces, both
>> kernel side and user side. 

>That is so you can do things like use the physical memory address of
>the framebuffer to display a image from a TV card into it.

No doubt, as you state, there are applications that would need the
physical framebuffer address. The problem is that when you just leave
a pointer laying around in a public data structure there is no way
for a user application to know when the pointer is valid and when it
is not. If a unsuspecting TV capture card tried to use my physical
address without knowing that I only have 64k banks the whole system
would come down hard.

I could see a physical pointer in a mode based data structure (similar
to "var") with the knowledge that it can be 0 if the fb is not
directly accessible. Also such a data structure would be where you
could find an "offset" and "size" to use as mmap parameters. "size"
being 0 if mmap isn't possible.

>The framebuffer itself is pretty safe to export to userland.

I assume you mean to allow people to mmap the framebuffer? Yes this can
usually be safe, but only the screen data. Most chips use graphics
memory of some type for dma command buffers. Most chips cannot safely
give you full access to such memory areas. The sysmem_start and
sysmem_length seem to cover the whole graphics region, not just the
visible framebuffer. This is likely not safe.

MMap is essential for lots of applications. I'm all in favor of allowing
it where possible. This isn't the kind of direct access I was against.
Mmap IS a driver interface. I can do all kind of tricks in the driver to
make sure a user who mmaps the framebuffer only gets access to what they
are supposed to.  In my stolen memory driver I have zero-page fault
handlers to map and unmap regions while changing memory banks on the 
fly.  I can't do this when the kernel dereferences a kernel-virtual
address as is done in the logo code. There is no page fault handler for
me to catch.

>MMIO can be tricker. The area of graphics resource management is really
>complex. For now I'm just aiming to get a clean seperation of the
>console system out of the framebuffer layer. 

MMio is a very different animal. Most mmio regions are not safe for
untrusted userspace binaries to access. This is why such access is 
limited to root. Further there is no generic use for these mmio regions,
only a userspace driver would know what to do with them. Certainly a
userspace driver and kernelspace driver that are working together should
be able to work out a way to share the locations they need without
leaving them lay around in public.

>Personally I like to see the day when DRI and the fbdev layer are
>merged but that will be awhile.

Yes me too, but a lot of cleanup needs to be done in fb land before
anyone should consider it. The drm code is pretty well designed and
doesn't have the kind of cruft that has built up on the fb interfaces.

I would really like to get as many people looking at the whole fb
interface with a very critical eye. 2.5.x is the best opportunity we
will have to make drastic changes. We will have a very long time
before 3.0.0(?) to get things in shape. I don't want to settle for
half-done redesign when we could really make a good solid base to
build on for the next several years.

-Matt

[Linux-fbdev-devel] Latest atyfb driver?

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

Where can I find the latest atyfb driver? I like to test out with my ruby
tree.

[Linux-fbdev-devel] Re: Scaling registers on r128

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

On Mon, 2001-11-12 at 10:23, Adrian Cox wrote:

> The attached patch turns on the panel scaling registers of the R128.
> I've run this on my iBook2, and I've been able to display 640x480 and
> 800x600 modes on the panel successfully.

So have I, but they both flicker noticeably, and there is corruption in
X with the server built-in modes, but not with modes generated with
fbset -x. Both effects are only slightly noticeable in 800x600 but more
so in 640x480.

Nice work though!


--=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] fbdev API problems

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

> Currently mmio and fb pointers are in a PUBLIC data structure, a data
> structure that is defined for everyone using the fb interfaces, both
> kernel side and user side. 

That is so you can do things like use the physical memory address of the
framebuffer to display a image from a TV card into it. The frmaebuffer
itself is pretty safe to export to userland. MMIO can be tricker. The area
of graphics resource management is really complex. For now I'm just aiming
to get a clean seperation of the console system out of the framebuffer
layer. 


Personally I like to see the day when DRI and the fbdev layer are merged
but that will be awhile.

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

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

> You don't intent to run X ontop of your fbdev, do you ?
> X uses the mmio & memory pointer to do its stuff, the same happens for other
> apps (all of them) that use the fbdev. Even the DRI/DRM stuff is mostly
> userspace, and the OpenGL access the board memory/mmio, trough the dma engine
> though.

Sottek it isn't such a bad system if you place in the driver safety nets.
For example if a userland process hose the graphics engine then the driver
would reset the engine. 

> And getting all image stuff into the driver is nto the _right way_, at least
> that is what linus decreted as he boycotted every attemps to do so, and most
> people would agree with him, doing the minimal thing in the driver/kernel
> space and the rest in userpsace.

Agree. The only reason we are moving to basic accel functions is because
it is lighter weight then the current system and its more driver
transparent. The accel functions choosen are the ones we absolutely need.

RE: [Linux-fbdev-devel] fbdev API problems

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

> >In fact imageblit is from a newer implementation, and meant for 2.5.x.
> 
> Geert,
>   Does this imply that in the newer version there is no high level
> drawing functions that are touching my mmio and memory pointers. It
> is all contained inside the driver? I certainly hope so.

TIme to explain the new api a little bit. The new api is designed to
seperate the console code from the framebuffer code. This allows you two
things, a simpler api to work with and second you can run fbdev by itself
on embedded devices. To do this the first thing to go was the fbcon-cfb*
stuff. Instead the driver writer provides 3 basic accel functions which
if you use the fbcon layer uses these functions to preform console
functions. I abstracted it to be based around a graphics cards abilties to
encourge people to implement and plus it does hide more the hardware
features. It will avoid the problems you are having.

>   To add to the point these pointers should not even be visible to
> the outside-of-driver world. It someone can see a virtual pointer,
> at some point they will try to use it. In some drivers this would
> cause bad things to happen.

Another nice featue planned for 2.5.X is that the console system will be
"shutdown" when you explictly open /dev/fb. This will prevent any
conflicts between the console system and using graphics hardware in
userland. As for userland programming hardware. Well that is DRI domain
and it is a touchy subject I like to avoid. 

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
>

[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] fbdev API problems

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

>You don't intent to run X ontop of your fbdev, do you ?
>X uses the mmio & memory pointer to do its stuff, the same happens
>for other apps (all of them) that use the fbdev. Even the DRI/DRM
>stuff is mostly userspace, and the OpenGL access the board
>memory/mmio, trough the dma engine though.

Yes I am aware of how the X server works. You have misunderstood
the issues I want to resolve. see below...

BTW: The X server gets mmio access because it runs as root. The
DRM interfaces do not allow the userspace drivers to access anything
that is insecure, most mmio regions fall into the insecure category.
Also, the DRM does not have any driver private information visible
in public data structures. Only device independent information is
in public structures the rest are in structures that are privately
defined in both the kernel portion and the X server portion of the
driver.

>And getting all image stuff into the driver is nto the _right way_,
>at least that is what linus decreted as he boycotted every attemps
>to do so, and most people would agree with him, doing the minimal
>thing in the driver/kernel space and the rest in userpsace.

It isn't a user vs. kernel space issue. It is a public vs. private
data structure issue. Drivers have intimate knowledge of the hardware
regardless of if they reside in userspace or are part of the kernel.

Currently mmio and fb pointers are in a PUBLIC data structure, a data
structure that is defined for everyone using the fb interfaces, both
kernel side and user side. This is the wrong thing to do. The current
fb interfaces have traded away code separation in order to achieve
code reuse. This could have been done better without losing any
of the easy-to-implement code reuse features.

Let me offer some other ways:
#1 Nobody without intimate hardware knowledge should have access to
the mmio region. If they don't know how to use it, they have no reason
to touch it, right? So why put it in a user visible, public data
structure? It should be up to the kernel driver and the userspace
driver to work out a way of passing this information. A device private
ioctl is a way to go. Even a well defined get_driver_private() ioctl
is fine.

#2 What about frambuffer size/location pointers? This is the same issue,
but with far greater consequences. A user driver can obtain the physical
pointers through a driver private structure, but the var structure
currently has a kernel virtual address to the framebuffer! This allows
parts of the kernel outside the driver to write to the framebuffer!
(The logo code is an example)  This is a real problem if for instance,
like the i810, you can make use of banked memory modes. In those modes
(The only ones available without programming the gart) there IS NO
framebuffer pointer/size combination that will work. You cannot write
to the framebuffer without intimate knowledge of the hardware.
If you give people easy access to pointers they WILL use them.


#3 Keep your code reuse. The fb drivers have three layers (at least)
the fb infrastructure, the hardware driver, and various subdrivers.
The struct display_switch is one set of subdrivers that are reused
for most drivers (and rightly so). However they obtain their driver
layer pointers from the fb infrastructure layer, skipping a layer of
separation. The logo code accesses pointers (that belong to the driver)
to go straight to hardware, again skipping a layer. Something like
this fixes up this problem.

struct display_switch {
    (some function pointer *)setup;
    (some function pointer *)putc;
     ...
    void *priv;
}

struct generic_ds_priv {
    u32 fb_base;
    u32 fb_size;
    u32 fb_pitch;
    u32 *pseudo_palette;
    ...
}

Driver calls something like this:
my_fb_info.display_sw = create_generic_ds(base,size,pitch,depth);

The generic code keeps the "secret" pointers in a private data
structure. These pointers are provided directly from the driver layer.
Each display_switch function is passed the "void *priv" as an argument
which is then cast to the generic_sw_priv type. Drivers that don't use
the generic display_switch subdirver can create their own private
strictures to pass to the subdriver, or they can pass their whole
driver private structure.

 Let me sum up the problem discussed here as I see it. The #1 rule
of driver writing is that only a driver should touch the hardware.
Anything that is device independent should go through a driver
interface to access the hardware. This interface could be in
userspace (i.e. OpenGL which then has a userspace hardware driver
that is allowed to access secure features of the hardware from
userspace) or in the kernel.

-Matt

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

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

On Mon, Nov 19, 2001 at 08:10:09AM -0800, Sottek, Matthew J wrote:
> 
> >In fact imageblit is from a newer implementation, and meant for 2.5.x.
> 
> Geert,
>   Does this imply that in the newer version there is no high level
> drawing functions that are touching my mmio and memory pointers. It
> is all contained inside the driver? I certainly hope so.
>   To add to the point these pointers should not even be visible to
> the outside-of-driver world. It someone can see a virtual pointer,
> at some point they will try to use it. In some drivers this would
> cause bad things to happen.
> 
>   So what am I to do in the mean time? Is there a way to keep people
> from using the pointers?

You don't intent to run X ontop of your fbdev, do you ?
X uses the mmio & memory pointer to do its stuff, the same happens for other
apps (all of them) that use the fbdev. Even the DRI/DRM stuff is mostly
userspace, and the OpenGL access the board memory/mmio, trough the dma engine
though.

And getting all image stuff into the driver is nto the _right way_, at least
that is what linus decreted as he boycotted every attemps to do so, and most
people would agree with him, doing the minimal thing in the driver/kernel
space and the rest in userpsace.

Friendly,

Sven Luther

RE: [Linux-fbdev-devel] fbdev API problems

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

>In fact imageblit is from a newer implementation, and meant for 2.5.x.

Geert,
  Does this imply that in the newer version there is no high level
drawing functions that are touching my mmio and memory pointers. It
is all contained inside the driver? I certainly hope so.
  To add to the point these pointers should not even be visible to
the outside-of-driver world. It someone can see a virtual pointer,
at some point they will try to use it. In some drivers this would
cause bad things to happen.

  So what am I to do in the mean time? Is there a way to keep people
from using the pointers?

 -Matt

Re: [Linux-fbdev-devel] atyfb and the Mach64 LT PRO

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

>BTW: if you are adventerous and if the Mach64 stretch registers are
>anything like those iin Rage128 or Radeon, you can check out the latest
>patches to either to see how this is done for those ATI cards and try to
>implement it yourself if you want to.
>
>A recent post to this mailing list (see the archive for a post whose
>subject is "Scaling registers on r128" from Adrian Cox) supplied a patch
>to the Rage128 that did exactly this.  You may be able to modify it easily.
>
>Just a thought.

In fact, that depends if you have an LT-G, an LT-Pro or a Mobility M1.

A friend of mine have been hacking with those lately, he'll send more
some more detailed infos once he gets something working.

Ben.

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'

Re: [Linux-fbdev-devel] ATI Rage Mobility M4

[Bryce R. <br...@be...>]

> >
> > The M4 is a Radeon based video card.
>
> That's not correct. The M4 is very similar to the M3. I'm surprised
> aty128fb doesn't support it, maybe it's just a matter of adding the PCI
> ID somewhere though?

Yeah, X uses all the 128 drivers and even calls it a Rage 128 Mobility.
The kernel headers for PCI IDs has the id of my card as something with
Radeon in it.

I did try adding the PCI ID to the aty128fb, but it didn't work (the screen
was garbled).  I think there are some more changes between the M3 and M4.

Re: [Linux-fbdev-devel] ATI Rage Mobility M4

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

On Sun, 2001-11-18 at 10:14, Brad Douglas wrote:
> On Sat, 2001-11-17 at 10:05, Bryce Riner wrote:
> > What is the support for this card?
> >=20
> > I have tried the aty128fb, radeonfb, and atyfb drivers but none of them
> > work.
> > This card is supported by X very well and I thought it was just a rewor=
k of
> > another mobile 128 to have AGP 4x support.
>=20
> The M4 is a Radeon based video card.

That's not correct. The M4 is very similar to the M3. I'm surprised
aty128fb doesn't support it, maybe it's just a matter of adding the PCI
ID somewhere though?


--=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] atyfb and the Mach64 LT PRO

[Kevin B. H. <khe...@iv...>]

Hi,

BTW: if you are adventerous and if the Mach64 stretch registers are 
anything like those iin Rage128 or Radeon, you can check out the latest 
patches to either to see how this is done for those ATI cards and try to 
implement it yourself if you want to.

A recent post to this mailing list (see the archive for a post whose 
subject is "Scaling registers on r128" from Adrian Cox) supplied a patch 
to the Rage128 that did exactly this.  You may be able to modify it easily.

Just a thought.

Kevin

On November 18, 2001 09:41, Geert Uytterhoeven wrote:
> On Sun, 18 Nov 2001, Till Adam wrote:
> > # Thus spake Geert Uytterhoeven (ge...@li...):
> > > On Sat, 17 Nov 2001, Till Adam wrote:
> > > > So does the atyfb driver need to be extended to set the stretching
> > > > registers to a sane state to work properly with this card? If so,
> > > > is
> > >
> > > Yes.
> > >
> > > > there someone on this list for whom this would be a three minute
> > > > job and who'd be willing to hack this in? I'm willing to help and
> > > > test, but I'd appreciate the guidance of someone with more
> > > > experience in this.
> > >
> > > Some PPC people already started working on this.
> >
> > Any details on who to hook up with or where to find these folks? A
> > mailing list perhaps?
>
> lin...@li... (CC'ed in this message)
>
> Gr{oetje,eeting}s,
>
> 						Geert

Re: [Linux-fbdev-devel] atyfb and the Mach64 LT PRO

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

On Sun, 18 Nov 2001, Till Adam wrote:
> # Thus spake Geert Uytterhoeven (ge...@li...):
>
> > On Sat, 17 Nov 2001, Till Adam wrote:
> > > So does the atyfb driver need to be extended to set the stretching
> > > registers to a sane state to work properly with this card? If so, is
> >
> > Yes.
> >
> > > there someone on this list for whom this would be a three minute job and
> > > who'd be willing to hack this in? I'm willing to help and test, but I'd
> > > appreciate the guidance of someone with more experience in this.
> >
> > Some PPC people already started working on this.
>
> Any details on who to hook up with or where to find these folks? A
> mailing list perhaps?

lin...@li... (CC'ed in this message)

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] atyfb and the Mach64 LT PRO

[Till A. <ti...@ad...>]

# Thus spake Geert Uytterhoeven (ge...@li...):

> On Sat, 17 Nov 2001, Till Adam wrote:
> > So does the atyfb driver need to be extended to set the stretching
> > registers to a sane state to work properly with this card? If so, is
> 
> Yes.
> 
> > there someone on this list for whom this would be a three minute job and
> > who'd be willing to hack this in? I'm willing to help and test, but I'd
> > appreciate the guidance of someone with more experience in this.
> 
> Some PPC people already started working on this.

Any details on who to hook up with or where to find these folks? A
mailing list perhaps?

> > I also noticed that the vertical yres is weird when using atyfb. I found
> > this around line 950 of atyfb_base.c which I dont understand and which I
> > think causes this:
> >
> > if (var.yres == var.yres_virtual) {
> >     32 vram = (fb->total_vram - (PAGE_SIZE << 2));
> >     var.yres_virtual = ((vram * 8) / var.bits_per_pixel) / var.xres_virtual;
> >     if (var.yres_virtual < var.yres)
> >          var.yres_virtual = var.yres;
> > }
> >
> > What is the reasoning behind this?
> 
> You mean the virtual vertical resolution? It's made as large as possible, so
> the console driver can use the virtual screen to do fast text scrolling, using
> panning of the virtual screen.

Oh, that makes sense. Thanks for explaining that.

Cheers,

Till

-- 
mailto: ti...@ad...        
http://www.adam-lilienthal.de/till

Re: [Linux-fbdev-devel] atyfb and the Mach64 LT PRO

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

On Sat, 17 Nov 2001, Till Adam wrote:
> So does the atyfb driver need to be extended to set the stretching
> registers to a sane state to work properly with this card? If so, is

Yes.

> there someone on this list for whom this would be a three minute job and
> who'd be willing to hack this in? I'm willing to help and test, but I'd
> appreciate the guidance of someone with more experience in this.

Some PPC people already started working on this.

> I also noticed that the vertical yres is weird when using atyfb. I found
> this around line 950 of atyfb_base.c which I dont understand and which I
> think causes this:
>
> if (var.yres == var.yres_virtual) {
>     32 vram = (fb->total_vram - (PAGE_SIZE << 2));
>     var.yres_virtual = ((vram * 8) / var.bits_per_pixel) / var.xres_virtual;
>     if (var.yres_virtual < var.yres)
>          var.yres_virtual = var.yres;
> }
>
> What is the reasoning behind this?

You mean the virtual vertical resolution? It's made as large as possible, so
the console driver can use the virtual screen to do fast text scrolling, using
panning of the virtual screen.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

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

On Fri, 16 Nov 2001, Sottek, Matthew J wrote:
> I wrote my
> own character functions that are aware of my memory bank switching, and I
> have a
> mmap function that will use zero page fault handlers to bank switch, map,
> and unmap
> regions to provide a linear appearance to user space. BUT, it seems that the
> logo code,
> and possibly some other things still want to touch the video memory. This
> can't happen!
> I saw reference to an imageblit function in some documents but it may be
> from an older
> implementation. Clearly that is what I need since I cannot allow anyone
> outside my driver
> to directly access memory pointers.

In fact imageblit is from a newer implementation, and meant for 2.5.x.

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

Re: [Linux-fbdev-devel] ATI Rage Mobility M4

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

On Sat, 2001-11-17 at 10:05, Bryce Riner wrote:
> What is the support for this card?
> 
> I have tried the aty128fb, radeonfb, and atyfb drivers but none of them
> work.
> This card is supported by X very well and I thought it was just a rework of
> another mobile 128 to have AGP 4x support.

The M4 is a Radeon based video card.  I do not believe it is supported
by radeonfb at this time.

Brad Douglas
br...@ne...

[Linux-fbdev-devel] ATI Rage Mobility M4

[Bryce R. <br...@be...>]

What is the support for this card?

I have tried the aty128fb, radeonfb, and atyfb drivers but none of them
work.
This card is supported by X very well and I thought it was just a rework of
another mobile 128 to have AGP 4x support.

Re: [Linux-fbdev-devel] atyfb and the Mach64 LT PRO

[Till A. <ti...@ad...>]

Sorry for the reply to self, but I should have mentioned the kernel
version I've been using. It's 2.4.12.

Sorry,

Till

-- 
mailto: ti...@ad...        
http://www.adam-lilienthal.de/till