Re: Overlay
Thank you for your help. Derek Lukasik wrote: Hello, I've been going through how Xserver implements Overlay. I still find information on this very limited. So I'm hoping that this thread will enlighten me more about this. First of all the Chips and Technologies driver implements overlay using 2 different framebuffers. Unfortunatly I can't get my hands on one to see how it works. But here's my questions: Let's say you have 2 different visuals. One PseudoColor and one TrueColor. You have an application that runs only in PseudoColor. As I understand the 8 bit app will be drawn on the overlay surface. I need to confirm on how does it know where to draw itself. For example, when I move the window with a border that is TrueColor. How does it get updated? How does it know where to display the overlay surface? The app doesn't know anything about how to draw itself. All the work happens in the driver. All the app has to know is that it is rendering to a depth 8 PseudoColor surface. The driver must look at requests coming from clients, note that they're targeted at the overlay surface, and fulfill the request appropriately. When you mention moving a window with a TrueColor border, I assume you're referring to the window manager decorations as the border. A single window in X cannot have a border with a different depth. A parent window can have children with different depths, however. That is usually the situation with a window manager. When you move the parent window, its children (in whatever layer) move as well. The color key concept is confusing for me. For example: the driver has index 255 to be the color key. What does that mean for an 8 bit app? Anything with color index 255 will be transparent? Or does that mean that anything with that color index will be visible? Overlay is typically implemented by reserving one index in the PseudoColor palette for transparency. This allows clients to render transparency if they wish. That index is usually 255. It is indicated by the SERVER_OVERLAY_VISUALS property. Clients should decode that property to determine that transparent index value. The property tells you which visuals are overlay visuals and for each, what type of transparency they implement (as well as the transparent index). The X server may present multiple overlay visuals. One visual may implement transparency whereas another may not (again look at the SERVER_OVERLAY_VISUALS property). The point here is that within the same class of visual, you may encounter both overlay opaque (no transparency) and overlay transparent visuals. A client should choose the appropriate visual dependent upon their needs (i.e. if they don't want transparency, don't select a visual with transparency enabled). Not all drivers implement this functionality. Most implement only transparent visuals. So, when you get to that last entry (usually 255), you start seeing through to the image planes. There's overlay for diplaying an 8 bit app on a 24 bit surface. But there's also overlay when you want draw something over something you don't want to destroy. By reserving color cells for overlay. It doesn't seem the same kind of overlay. Not sure what you're asking here. Are you referring to the different types of overlay implementation? Where some drivers implement overlay within the alpha channel of the image planes verses those that use an entirely independent surface? Does anyone have some more apps that experiment with colormaps and overlays? L
Re: mioverlay
ok... So There's no implementation of overlay using an independent surface on any driver? Also, what is the xf8_32wid? I see that's it's an implementation of the xf8_16bpp but for an 8 over 32 surface. But what does the wid stand for? L Mark Vojkovich wrote: On Fri, 21 Feb 2003, Luugi Marsan wrote: So how does the chips driver implement overlay without mioverlay? It's not an overlay in my opinion. Yes, it puts one depth in the image plane and the other in the overlay plane, but windows in the overlay clip windows in the image plane and there's no transparency key. It's merely a system that can display two depths simultaneously, but it's not a traditional workstation overlay. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Luugi Marsan Linux Software Designer Matrox Graphics Inc. tel: 514-822-6000 ext: 7231 email: [EMAIL PROTECTED]
Overlay
Hello, I've been going through how Xserver implements Overlay. I still find information on this very limited. So I'm hoping that this thread will enlighten me more about this. First of all the Chips and Technologies driver implements overlay using 2 different framebuffers. Unfortunatly I can't get my hands on one to see how it works. But here's my questions: Let's say you have 2 different visuals. One PseudoColor and one TrueColor. You have an application that runs only in PseudoColor. As I understand the 8 bit app will be drawn on the overlay surface. I need to confirm on how does it know where to draw itself. For example, when I move the window with a border that is TrueColor. How does it get updated? How does it know where to display the overlay surface? The color key concept is confusing for me. For example: the driver has index 255 to be the color key. What does that mean for an 8 bit app? Anything with color index 255 will be transparent? Or does that mean that anything with that color index will be visible? There's overlay for diplaying an 8 bit app on a 24 bit surface. But there's also overlay when you want draw something over something you don't want to destroy. By reserving color cells for overlay.It doesn't seem the same kind of overlay. Luugi ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Xpert]8+24 Overlay Implementation
Dr Andrew C Aitchison wrote: On Mon, 11 Nov 2002, Luugi Marsan wrote: I thought about using the shadow framebuffer also. It seems like the easiest way. I need to get myself more acquainted with shadow framebuffer. For our new chip I need to specify an overlay surface and an underlay surface, the chip will take care of overlaying both surfaces. That is why I'm asking this. I hope that I'm thinking in the right direction. Shadow isn't accelerated. Another approach would be to think of the overlay and underlay as separate heads; clearly you don't want that to show at the top level, but compartmentalizing the memory like our mga driver does for dual-head might be appropriate. Indeed, shadow framebuffer is not what I need. I think the Dual Framebuffer that xaaOverlayDF.c uses will be more of use to me. It seems to create the underlay and overlay buffer that I need. Luugi
[Xpert]HW Rotation
Hi, We are thinking of implementing hw accelerated rotated screen. Anybody have any ideas on how we could implement this? Our hardware is able to handle it but our problems are with the XFree86 end. Does XFree86 have any features or extensions that could help us out? Anyone have any suggestions? What we thought of doing is having the XFree86 draw in offscreen memory and making our texture engine rotate the image into display memory. Either we do it a each vsync or hook it at each acceleration calls. Any ideas would be greatly appreciated. Luugi ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]8+24 Overlay Implementation
Hello everyone, The current implementation of Overlay for the G450 seem to write the 8bpp image by placing the pixel value at the top byte of each pixel. Then the G450 takes care of doing the overlay by specifying to the card the pixel configuration. If I wanted to have the overlay suface draw on an separate surface, how would I do that? Luugi ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]8+24 Overlay Implementation
Dr Andrew C Aitchison wrote: On Mon, 11 Nov 2002, Luugi Marsan wrote: The current implementation of Overlay for the G450 seem to write the 8bpp image by placing the pixel value at the top byte of each pixel. Then the G450 takes care of doing the overlay by specifying to the card the pixel configuration. If I wanted to have the overlay suface draw on an separate surface, how would I do that? The best solution might require writing support in the server, but here is some other brain-storming: At some level pretend it is a different head. Since it is an overlay X doesn't *have* to know that it is related to the underlay (although it would defeat obscured window optimizations). Use a shadow framebuffer, and blit into the 8bit framebuffer. You can probably do better by drawing directly into the 8bit fb, pretending it is pixmap in video memory, but shadow may be easier. I thought about using the shadow framebuffer also. It seems like the easiest way. I need to get myself more acquainted with shadow framebuffer. For our new chip I need to specify an overlay surface and an underlay surface, the chip will take care of overlaying both surfaces. That is why I'm asking this. I hope that I'm thinking in the right direction. XV does overlays; is it useful to use video memory as an XV source ? (I don't know much about XV) I don't know much about XV either. I think that (some of the) CT hardware (using the chips driver) have this cabability. I may be confusing it with another manufacturer (S3?) and I don't know whether we ever supported it. This might be productive lead, or it may be a red herring. I'll check it out. Thanks Luugi
[Xpert]256 megs board fails Validation,
Hi, There's a problem when validating a given mode. The board I have has 256 megs and it fails crying that it has insufficient memory for the given mode. This happens because the videoRam in bits is equal to 2^31 ( 256 megs). The number passes the numerical limit of an int. I believe that the videoRam should be an unsigned int instead of a signed int. What do you think? Will this change create other problems? Y2K all over again. :) Luugi ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]256 megs board fails Validation,
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode. Luugi Alexander Stohr wrote: RE: [Xpert]256 megs board fails Validation, sorry, but your number theory has some error. 2^1 = 2 (1 bit, counting from 0 to 1 = 2 values) 2^2 = 4 (2 bits, counting from 0 to 3 = 4 values) 2^4 = 8 (3 bits counting from 0 to 7 = 8 values) [...] 2^31 = 2 GB 2^32 = 4 GB an integer with 32 bits has 1 bit sign and 31 bits for numeric value. this is (-2GB) to (+2GB-1). so your 256 MB limit must arise from somewhere else. for your case you should better starting the printf debugger or real debugging. maybe PCI or AGP config caps, or MTRR caps are the limiting factor, or its just a driver bug. (wild guessing) -Alex. -Original Message- From: Luugi Marsan [mailto:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 21:33 To: [EMAIL PROTECTED] Subject: [Xpert]256 megs board fails Validation, Hi, There's a problem when validating a given mode. The board I have has 256 megs and it fails crying that it has insufficient memory for the given mode. This happens because the videoRam in bits is equal to 2^31 ( 256 megs). The number passes the numerical limit of an "int". I believe that the videoRam should be an "unsigned int" instead of a signed "int". What do you think? Will this change create other problems? Y2K all over again. :) Luugi ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]256 megs board fails Validation,
Marc Aurele La France wrote: On Mon, 4 Nov 2002, Luugi Marsan wrote: There's a problem when validating a given mode. The board I have has 256 megs and it fails crying that it has insufficient memory for the given mode. This happens because the videoRam in bits is equal to 2^31 ( 256 megs). The number passes the numerical limit of an "int". I believe that the videoRam should be an "unsigned int" instead of a signed "int". What do you think? Will this change create other problems? Y2K all over again. :) sorry, but your number theory has some error. 2^1 = 2 (1 bit, counting from 0 to 1 = 2 values) 2^2 = 4 (2 bits, counting from 0 to 3 = 4 values) 2^4 = 8 (3 bits counting from 0 to 7 = 8 values) [...] 2^31 = 2 GB 2^32 = 4 GB an integer with 32 bits has 1 bit sign and 31 bits for numeric value. this is (-2GB) to (+2GB-1). so your 256 MB limit must arise from somewhere else. for your case you should better starting the printf debugger or real debugging. maybe PCI or AGP config caps, or MTRR caps are the limiting factor, or its just a driver bug. (wild guessing) I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode. No, it doesn't. apertureSize is in bytes. Marc. apertureSize is indeed in bytes, but in xf86Modes.c, xf86InitialCheckModeForDriver() has this check. This is in XFree86 4.2.0. -- if (mode-HDisplay * mode-VDisplay * scrp-fbFormat.bitsPerPixel scrp-videoRam * (1024 * 8)) return MODE_MEM; -- where: scrp -videoRam = 256 * 1024 ( since videoRam is in Kbytes) When calculating the right hand side of the comparison, the right hand side is equal to 256*1024*1024*8 = 2^31. The left hand side is also calculated in bits, since it multiplies the display by the number of bits per pixel. Luugi
Re: [Xpert]Overlay, xf8_32bpp, documentation?
Thank You, I'm saying this hoping someone corrects me. It's seems to me that the G450 is not actually doing any hardware overlay? Where in the the Xserver code is the actually hardware overlay registers touched? I'm looking at the cfbDoBitblt8To32 function. And seems to me that everything is done in software. Actually can anyone tell me the difference between cfb and fb? Where does the cfb module lie in the Xfree86 architecture? I'm planning to make a little document explaining all of this because it seems that documentation about this is hard to find. Luugi Dr Andrew C Aitchison wrote: On Fri, 25 Oct 2002, Luugi Marsan wrote: Hi, I don't understand how X11 implements overlay. I'm trying to understand the xf8_32bpp module. Is their any documentation on this? I would like to get an explanation on how this module was implemented. Is it anything like how Window does Overlay? If I want to go through the code where should I start? Seems to me that the xf86overlay.c file is a good starting point. But how is this code structured. Is there anywhere I could find something to explain the big picture of the code? There is a bit more in xaaOverl/xc/programs/Xserver/hw/xfree86/xaa/xaaInit.c xaaOverlay.c and xaaImage.c - look for overlayFlags and OVERLAY_8_32_PLANAR. How does windoes do overlays ? For the big picture I'd be guessing, but my impression is that most of the overlay code is there to persuade XAA to draw in the top byte of each pixmap, sometimes with planemasks and sometimes by using a depth 8 pixmap with 32 bit pixels (xf86overlay:512 OverlayRefreshPixmap). I'd be interested in anything you find out, since I expect I'll need to duplicate much of it for PseudoColor on DirectColor.
[Xpert]Overlay, xf8_32bpp, documentation?
Hi, I don't understand how X11 implements overlay. I'm trying to understand the xf8_32bpp module. Is their any documentation on this? I would like to get an explanation on how this module was implemented. Is it anything like how Window does Overlay? If I want to go through the code where should I start? Seems to me that the xf86overlay.c file is a good starting point. But how is this code structured. Is there anywhere I could find something to explain the big picture of the code? I realize going through the mailing list that overlay is someting that has been discussed often, but I just can't seem to find the information I need. Any suggestion would be greatly appreciated. Luugi Marsan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: 8 over 24 app
Hi, For now I'm trying to investigate the support of Overlay in the mga drivers. Correct me if I'm wrong, Overlay is supported for the g-series. If not what are the problems? I'll try out your some of your apps. Thank you for your help. Luugi Dmitry Yu. Bolkhovityanov wrote: On Wed, 23 Oct 2002 16:59:43 -0400, Luugi Marsan wrote: Where can I find a simple app that uses Overlay 8+24? I can't seem to find any. What do you use to test overlay? Hi! As I understand, you need a proggie which is able to use 8bpp while 24bpp is available? One such program is "xv": "xv -visual pseudocolor". Another is Netscape 3/4, which accepts the same syntax. In old days "xfishtank" was able to run at 8bpp only -- at least the one in RedHat-5.2 is such. Does Matrox plan to fix overlay support in mga drivers? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]8 over 24 app
Dr Andrew C Aitchison wrote: On Wed, 23 Oct 2002, Luugi Marsan wrote: Where can I find a simple app that uses Overlay 8+24? I can't seem to find any. What do you use to test overlay? xv -visual PseudoColor filename xv -visual TrueColor filename will give you two programs showing the same image, the first in the 8bit overlay, and the second in the 24bit "underlay" Thanks, I tried the xv apps and Overlay seems to work. I'm not very familiar with Overlay so I now need to go a little deeper in the code to understand the mecanism regarding our hardware. Anyone have any suggesting on where I should start with? Luugi When I was writing the 8+24 overlay I used kview from Richard Gooch's Karma: http://www.atnf.csiro.au/computing/software/karma/ as a test tool since I could display the image with a 24bit DirectColor visual, and manipulate the palette with a tool showing in another window, but I can't find that feature on the current version. Unfortunately although Richard had a card (not Matrox) which was capable of supporting overlay visuals, it wasn't supported by XFree86 v4. Even now I'm not sure that XFree86 supports overlay on that card :-( which means that Richard couldn't use the feature; maybe that is why I can't find it with the current version.
[Xpert]8 over 24 app
Hi, Where can I find a simple app that uses Overlay 8+24? I can't seem to find any. What do you use to test overlay? Luugi ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
