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

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

Hello, Romain!

On Thu, 22 Nov 2001 10:45:29 +0100 you wrote:

> Nick Kurshev wrote:
> 
> > Sorry! This part was taken by me from mga_vid driver
> > and this part is still not clear for me :(
> > IMHO if such branch will be in the Linux this problem
> > will disapeared.
> 
> I don't think bew /dev/ entry with new major will ever
> get integrated, there's been a lot of discussion in LK.
> The idea in linux-console is to add a new FS that would
> allow for such stuff dynamically. But it won't happen
> tomorrow...
> 
As I already wrote - implementing VID driver within framebuffer's one
is not good for me. I need with standalone driver :(
Simply because radeon_vid need with VESA BIOS as graphics server
to get working TV-out.
(radeonfb doesn't enable TV-out and probably will never do that)
> > In the future - it would be better to write into documentation:
> >        __u16 depth_avail;              /* <- available depth(s) for this FOURCC: FB_VIDEOVERLAY_DEPTH* */
> > simply because AFAIK - there are no driver which were implemented with using
> > this standard and first implementation ( of driver and app ) will cause
> > a lot of questions, like: __u16 capability_avail what should be here and so on.
> 
> yes, you're right. It's only a draft :-/
> 
> > These "atoms" exist in X11 project for the same lots of stuff ;)
> > IMHO driver can ingnore unknown fields.
> 
> but you need a way to tell the app that field so-and-so
> are ignored.
> 
It would be better to move such parameters into separate structure
which could be passed into driver through other ioctl (changing
brightness, saturation, ... on the fly). From other side - each
member of this structure is optional for driver.
Maybe it would be even better to pass each such atom as independed
one into driver:

struct hw_video_tuneup
{
  char parameter[40]; // or uint32_t
  uint32_t value;
  uint32_t min_range,max_range;
  uint32_t flags;
};

In the future it ould be possible easy expand this by:
#define BRIGHTNESS 1
#define SATURATION 2
#define HUE        3
/* year after 1-st implementation */
#define SGI_SPECIFIC_PARM123    0xFFFF8888 /* vendor specific addition */

> > P.S.: Maybe it would be better to rename fbvid.h to something other
> > like: linux_video_overlay.h or linux_vid.h
> > Because:
> > framebuffers were designed to get linux console on non x86 systems
> > but it's perfectly other technology and is useful for x86 system too.
> > But: my radeon_vid doesn't require any framebuffer to be loaded and
> > can be loaded from text-mode of x86 systems.
> > I use it over VESA's output driver of mplayer. It's trickly but it's
> > only solution to get working TV-out on radeon chips. Simply because
> > ATI will never open TV-out related documentation due macrovision concerns.
> > But after terminating - VESA will switch display back to text-mode
> > (it's radeon specific thing). If someone will use radeon_vid over
> > framebuffer and tried to use VESA then result will be predictable, imho.
> 
> The new FB layer in linux-console is not dependant on console code,
> you can have console without FB or FB without console. That's was
> the idea behinf fbvid.h : add the ability to overlay video (or
> still image) on the FB, not in the console. if there's also a
> console, fine.
> 
I prefer don't mix framebuffer and video overlay which is useful
on x68 systems too.

> Again, feel free to add this subject to the current discussion
> on the new API in linux-fbdev and linux-console, I think it's
> worth public discussion, as there's obviously interest in
> FB and/or console video. My draft was only a suggestion and
> a way to get the discussion started, not something cast in
> iron that can't be improved/reworked.
> 
Done
> Anyway, radeon stuff interest me a lot, I just bought a
> PowerBook G4 with a radeon mobility M6 in it :-) :-)
> 
Unfortunately - radeon_vid currently is useless for you
simply because only mplayer works with it and only through
VESA. (Currently mplayer is far from standards in console video
overlay stuff :( But I hope that after implementing such standard
it would be possible to add corresponding stuff to mplayer).

> -- 
> DOLBEAU Romain               | Nothing is real but the way that I feel  
> ENS Cachan / Ker Lann        | And I feel like going down, down, down   
> Thesard IRISA / CAPS         |   -- Rainbow,                            
> dol...@cl...    |                 'Self Portrait'
> 


Best regards! Nick