Menu
▾
▴
linux-fbdev-devel
|
From: Benjamin H. <be...@ke...> - 2001-07-12 12:36:21
|
> >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. |
|
From: James S. <jsi...@tr...> - 2001-07-12 17:12:07
|
> >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. 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. |
|
From: Michel <mic...@ii...> - 2001-07-12 17:18:49
|
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. I rather suspect your knowledge about Xinerama is lacking... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-07-12 17:20:33
|
> I rather suspect your knowledge about Xinerama is lacking... I have seen it used before. Are you saying Xinerama lacks functionality to support mirroring. |
|
From: Michel <mic...@ii...> - 2001-07-12 17:24:47
|
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 |
|
From: Sven <lu...@dp...> - 2001-07-13 09:37:30
|
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 |
|
From: Benjamin H. <be...@ke...> - 2001-07-13 13:43:27
|
>> 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. |
|
From: James S. <jsi...@tr...> - 2001-07-13 15:39:07
|
> 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. |
|
From: Scott A M. <sam...@co...> - 2001-07-12 13:28:33
|
Geert Uytterhoeven 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. I do not understand... How will a user that is running a VC on /dev/fb start an application that uses the frame buffer? The VC will all ready have the device open? Scott |
|
From: Geert U. <ge...@li...> - 2001-07-12 14:31:49
|
On Thu, 12 Jul 2001, Scott A McConnell wrote:
> Geert Uytterhoeven 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.
>
> I do not understand...
>
> How will a user that is running a VC on /dev/fb start an application
> that uses the frame buffer? The VC will all ready have the device open?
The user just opens /dev/fb*. The VC subsystem doesn't really `open' /dev/fb*.
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
|
|
From: Sven <lu...@dp...> - 2001-07-11 17:13:10
|
On Wed, Jul 11, 2001 at 04:35:07PM +0200, Romain Dolbeau wrote: > > > __u16 blend_factor; /* blending factor */ > > > > add chroma key (rage) here ? > > The problem is, how to handle the mix between the overlay > and the console layer. If the FB doesn't have an alpha > channel (CI8, RGB565), one must use a color key. So one I think that the rage (and maybe mga also from the mga Xv driver) can only support color keyed overlay, not alpha keyed overlay. I think this comes because they use a packed representation anyway (24 bpp), but i could be wrong. > So I simply dodged the problem by saying, we display > the overlay in its area blended (0 to 100%) with > the current display. But we need a better way, > obviously. Yes, we need something better and more open here. Friendly, Sven Luther |
|
From: Sven <lu...@dp...> - 2001-07-11 17:09:53
|
Sorry if i lost older mails regarding this, but i just lost my harddisk here at work yesterday
and just got the replacement today. So i must have lost all incoming mails since monday or such.
On Wed, Jul 11, 2001 at 03:51:07PM +0200, Gerd Knorr wrote:
> > /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */
> > #define FBIOGET_VIDOVERLAY_CAP 0x4620
>
> Better use the _IOR / _IOW / _IOWR macros.
>
> > /* pixel type that can be overlaid */
> > #define FB_VIDOVERLAY_PIXELTYPE_CI8 0x0020
>
> What is this one?
Color Index 8, it is just like the pseudocolor 8bpp used by fbdev. I think maybe we could reuse
the same color indentification as FB use, without the need of FB_VIDOVERLAY stuff ? Or is adding
all the YUV modes there a problem ?
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV422 0x0040
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV444 0x0080
>
> packed pixel or planar? yuv420 should be there too, mpeg decompressed
> gives you planar yuv420.
Packed. Permedia3 don't support planar YUV, but even if the planar to packed unit worked, it would
be done trought the bypass unit. That said i guess other hardware kind support those.
In the Xv driver, i do the planar to packed conversion by hand at copying time. I guess it is not
very heavy, but am not sure, since it happens in the processor and main memory, and don't transit
over the AGP/PCI bus.
That said, you have to provide the source buffer to the Xv putimage function, which does the copying,
but maybe this is not the best way of doing this.
Mmm, my idea on this would have been to provide a user-land library which would contain the driver
thing for every supported card, i thought this was the right way of doing things.
Now, the Xv permedia3 driver uses some standard descriptors for the different supported YUV and co
modes, maybe we should support the same here ?
> > struct fb_vidoverlay_mem {
> > unsigned long omem_start; /* Start of overlay frame buffer mem (phys add) */
> > __u32 omem_len; /* (required) length of overlay frame buffer mem */
> > __u8 n_over; /* number of the overlay buffer to use */
> > };
>
> I'd pass pixeltype + width + height here and let the driver calculate +
> return the image size and scanline length. The driver can easily take
> care about alignment and related issues then.
Yes, the only meaningfull stuff to access memory is the bpp of the source buffer (which can be <>
from the one of the framebuffer), the width and the height of the buffer.
Also, don't forget, most hardware can do buffer flipping. The Permedia3 has 3 VidoOverlay bases. Xv
never uses more than 2 though. Don't know what the 3rd is for, maybe for interlacing ?
> n_over == -1 => "give me any free one" ?
>
> > struct fb_vidoverlay_set {
> > __u32 oxsize; /* overlay size in pixels */
> > __u32 oysize;
> > __u16 pixel_type; /* pixeltype to use */
>
> obviously not needed if every allocated memory area has a width and height
> as suggested above.
As X's offscreen memory manager does.
> > __u16 blend_factor; /* blending factor */
>
> add chroma key (rage) here ?
mmm, Permedia3 can do overlays as follows :
2bit alpha blending, either per pixel (using the alpha value of the pixel) or global. It can
also use keyed overlay, either the alpha channel of the framebuffer, or an RGB key for either the
framebuffer or the overlay source. The third possibility is opaque blending, but not much is needed
for it.
Will we support all of those ? In Xv i support only opaque with mask (using a alpha channel key in
the framebuffer) or globally alpha blended.
Also either filtering or mirroring is possible. You can mirror in X or Y, and filter either only in X
or bilinear.
Friendly,
Sven Luther
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X