Re: RFC: OpenGL + XvMC
On Mon, Jun 02, 2003 at 01:09:59AM -0400, Mark Vojkovich wrote: >Extending GL to recognize a relatively unknown XFree86 format > is a hard sell. I wouldn't even be able to convince my own company > to dirty their code for it seeing as how relatively nobody is using > XvMC. Do you implement this without touching the GL driver code? Seems difficult to avoid touching the driver in the general case, when the format and location of pbuffer memory is intentionally opaque. >Of course you really want these things in objects that are > entirely within the OpenGL namespace, such as textures. Speaking > of slowly adopted extensions, if there's GLX_ARB_render_to_texture > that sort of solves that problem. Haven't been paying much attention > to super buffers (doesn't effect me yet). You can bind a pbuffer > to a superbuffer in some way can't you? No. There is a WGL_ARB_render_texture extension but we never finished the GLX version due to lack of interest + the expectation that super buffers will enable similar functionality. Jon ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
On Sun, 1 Jun 2003, Jon Leech wrote: > On Fri, May 30, 2003 at 05:42:20PM -0700, Ian Romanick wrote: > > Mark Vojkovich wrote: > > > I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > > >to XvMC. I have implemented this in NVIDIA's binary drivers and > > >am able to do full framerate HDTV video textures on the higher end > > >GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > > >contents into a texture. > > > > This shoulds like a good candidate for a GLX extension. I've been > > wondering when someone would suggest somthing like this. :) Although, I > > did expect it to come from someone doing video capture work first. > > I don't think it makes much difference whether it's considered as > XvMC functionality or GLX functionality, but if you do it in XvMC I > suggest paying as much attention to a detailed specification as OpenGL > and GLX extensions do. In particular since the X and GL rendering > streams are generally asynchronous, making sure apps can get repeatable > behavior across drivers. > You might want to think about how this could carry over to the > upcoming super buffers extension, too, since that will probably replace > pbuffers for most purposes within a few years. Since super buffers There are alot of people who are just discovering pbuffers now. I would guess it would take years before superbuffers were widely used. > operate entirely within GL, and the GL namespace doesn't involve XIDs > and is dependent on the current context, it might make more sense to > pass the XvMC objects into GL than vice versa. > Jon Leech > SGI Extending GL to recognize a relatively unknown XFree86 format is a hard sell. I wouldn't even be able to convince my own company to dirty their code for it seeing as how relatively nobody is using XvMC. Of course you really want these things in objects that are entirely within the OpenGL namespace, such as textures. Speaking of slowly adopted extensions, if there's GLX_ARB_render_to_texture that sort of solves that problem. Haven't been paying much attention to super buffers (doesn't effect me yet). You can bind a pbuffer to a superbuffer in some way can't you? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
On Fri, May 30, 2003 at 05:42:20PM -0700, Ian Romanick wrote: > Mark Vojkovich wrote: > > I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > >to XvMC. I have implemented this in NVIDIA's binary drivers and > >am able to do full framerate HDTV video textures on the higher end > >GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > >contents into a texture. > > This shoulds like a good candidate for a GLX extension. I've been > wondering when someone would suggest somthing like this. :) Although, I > did expect it to come from someone doing video capture work first. I don't think it makes much difference whether it's considered as XvMC functionality or GLX functionality, but if you do it in XvMC I suggest paying as much attention to a detailed specification as OpenGL and GLX extensions do. In particular since the X and GL rendering streams are generally asynchronous, making sure apps can get repeatable behavior across drivers. You might want to think about how this could carry over to the upcoming super buffers extension, too, since that will probably replace pbuffers for most purposes within a few years. Since super buffers operate entirely within GL, and the GL namespace doesn't involve XIDs and is dependent on the current context, it might make more sense to pass the XvMC objects into GL than vice versa. Jon Leech SGI ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
FW: Problem diplaying a pixel
Title: Message Hello Every one ! Iam trying to put one pixel on the scrren with the attached program. The program runs fine ,but Iam not able to see the pixel on the screen. Is there somehting which Iam missing? Or what can be the problem ?Can u lpease help me out tof this? Thanking u in advanace, Regards, Nitin Mahajan Socrates Software India Pvt Ltd... mail:[EMAIL PROTECTED] Ph:51101667. Mobile : 9448260513 == The Lord gave us two ends -- one to sit on and the other to think with. Success depends on which one we use the most. putpixel.c Description: putpixel.c
Re: Bugzilla #306 (Building with #define BuildRender NO)
I did something very similar, but also had to make changes in other parts of the code. In the end I gave up because of the myriad of problems in fb. Instead I just defined 'Option "RenderColormapMode" "mono"' in the ServerFlags section of the config file. My reason for disabling the Render extension at compile time was to prevent it from using up space in the colour map, but setting the mode to mono basically achieves the same thing. Regards, Lindsay Haigh Matthieu Herrb <[EMAIL PROTECTED] To: [EMAIL PROTECTED] anadoo.fr> cc: Sent by:Subject: Bugzilla #306 (Building with #define BuildRender NO) [EMAIL PROTECTED] 86.Org 01/06/03 23:20 Please respond to devel Hi, I've attached a proposed patch to Bugzilla #306. Please review and comment. I may have missed something important... Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
Juliusz Chroboczek wrote: > Is it me, or are we really shipping 1200dpi bitmap fonts as part of > XFree86? > > xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf The *.pmf files are no real fonts, they contain only the metrics for printer builtin fonts (those are usually scaleable, however the metrics in the PMF files are usually calculated for the maximum DPI supported by the matching Xprint DDX (PS DDX in this case). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, C&&JAVA&&Sun&&Unix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
On Sun, Jun 01, 2003 at 07:20:57PM +0200, Juliusz Chroboczek wrote: > Is it me, or are we really shipping 1200dpi bitmap fonts as part of > XFree86? > > xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf These have always been there. It's part of the Xprint server. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
It's not another adaptor. I lets you copy video surfaces rendered with an existing XvMC adaptor into a GLXPbuffer. It's possible to both display in the overlay and save off to a Pbuffer. A while ago, I started getting inquiries from a couple film companies who store their rendered animated features as jpegs. They decompress them in software and copy them into textures so they can do post processing on them in OpenGL. I think mostly they're interested in doing things like adding film grain and doing color correction. The software decode is really a significant expense if you're trying to do 1920x1080 sized jpegs in real time. Unfortunately, I don't think the quality of 4:2:0 video is really is up their standards, but there are lower quality applications such as HDTV and DVD post processing that can benefit from accelerated decode of mpeg streams into an OpenGL drawable. There are probably some interesting multimedia projects as well. Mark. On Sun, 1 Jun 2003, Alex Deucher wrote: > Just curious, as I'm not too familiar with XvMC yet, but would this > provide another Xv adapter that used the 3D texture engine to display > videos rather than othe video overlay? or something else. Sorry for > my ignorance. > > Thanks, > > Alex > > --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > >I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > > to XvMC. I have implemented this in NVIDIA's binary drivers and > > am able to do full framerate HDTV video textures on the higher end > > GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > > contents into a texture. > > > > > > Status > > XvMCCopySurfaceToGLXPbuffer ( > > Display *display, > > XvMCSurface *surface, > > XID pbuffer_id, > > short src_x, > > short src_y, > > unsigned short width, > > unsigned short height, > > short dst_x, > > short dst_y, > > int flags > > ); > > > >This function copies the rectangle specified by src_x, src_y, > > width, > > and height from the XvMCSurface denoted by "surface" to offset > > dst_x, dst_y > > within the pbuffer identified by its GLXPbuffer XID "pbuffer_id". > > Note that while the src_x, src_y are in XvMC's standard left-handed > > coordinate system and specify the upper left hand corner of the > > rectangle, dst_x and dst_y are in OpenGL's right-handed coordinate > > > > system and denote the lower left hand corner of the destination > > rectangle in the pbuffer. > > > > "Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or > > XVMC_FRAME_PICTURE. > > If flags is not XVMC_FRAME_PICTURE, the src_y and height are in > > field > > coordinates, not frame. That is, the total copyable height is half > > the height of the XvMCSurface. > > > > XvMCCopySurfaceToGLXPbuffer does not return until the copy to the > > pbuffer has completed. XvMCCopySurfaceToGLXPbuffer is pipelined > > with XvMCRenderSurface so no explicit synchronization between > > XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed. > > > > The pbuffer must be of type GLX_RGBA, and the destination of the > > copy is the left front buffer of the pbuffer. Success is returned > > if no error occured, the error code is returned otherwise. > > > > Possible Errors: > > > >XvMCBadSurface - The surface is invalid. > > > >BadDrawable - The pbuffer_id is not a valid pbuffer. > > > >BadMatch - The pbuffer is not of type GLX_RGBA or the > > pbuffer does not have a front left buffer. > > > > XvMCCopySurfaceToGLXPbuffer is supported if the following flag: > > > > #define XVMC_COPY_TO_PBUFFER 0x0010 > > > > is set in the XvMCSurfaceInfo's flags field. > > > > I'd like to bump the API version up to 1.1 and add this. > > Comments? > > > > > > Mark. > > > > > __ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
On Sun, 1 Jun 2003, Andrew C Aitchison wrote: >> Just curious, as I'm not too familiar with XvMC yet, but would this >> provide another Xv adapter that used the 3D texture engine to display >> videos rather than othe video overlay? or something else. Sorry for >> my ignorance. > ... ... ... >> --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: >> >I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function >> > to XvMC. I have implemented this in NVIDIA's binary drivers and >> > am able to do full framerate HDTV video textures on the higher end >> > GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer >> > contents into a texture. > >I don't really know any more than you but my guess is that while >this may be presented as another Xv adapter, what it really does is >make a video source available as a texture. >This would allow you to, for instance, display a virtual reality >living-room and whenever the camera falls on the TV it would be >showing live pictures from a video feed. Another more useful use would be CNN like video effects where the fullscreen shrinks to an inset and then rotates on a 3D angle, etc. Various nifty 3D video effects for video editing/production could be done. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: > I have several problems with the ATI Radeon drivers in XFree on my Mac G4 > Windtunnel (dual 1.4GHz). > > Summary: > 1) CRT + TMDS dual head configuration doesn't work > 2) In all configurations colors are completely wrong > 3) closing X blanks all monitors > > I have tested following versions of XFree86: > Debian sid "officail" 4.2.1 Isn't expected to work with this. > Michel Daenzer's 4.2.1 DRI build 4.2.1? Haven't you tried my current packages for sid? > Debian "inoffical" 4.3.0 > latest CVS build (by myself) as of yesterday (4.3.99...) > > The first two worked even worse (no image at all), so in the following I'll > refer to the later two which produce exactly the same results. > > Problem 1) > I have a TMDS flat panel (DVI-D) on the DVI port of the card and an analog > flat panel on the ADC port (via ADC2VGA cable). Both panels get correctly > detected (see attached log file), but the analog one gets no signal after X > is started. > > Option "MonitorLayout" "CRT, TMDS" doesn't help (nothing really changes, since > both monitors get correctly detected even wihtout this). I tried all tricks I > could think of, but the analog one (on the ADC port) gets no signal (even > after X closes). > > Funny enough, using a DVI2VGA adapter and analog input of the *digital* panel > causes both panels to work - i.e. changing the mode of the *panel that works* > causes the other one to start working as well. This means that "CRT, CRT" > combination works. It is really annoying since I have a digital panel and I > don't want to run it in analog mode which sucks. Have you looked at the code for how the type of one head might have an influence on the other one? > Probelm 2) > No matter what combination (dual or single head) the colors are always wrong. > This is independent of the depth used (every time differently "wrong" colors > of course). > > I analyzed it for the 24-bit mode for the digital panel. Although 24-bit mode > is enabled (and the server uses 4-bytes per pixel see log below), in fact > only 3x4=12 bits are used. I wrote a small proggy that writes directly to the > frame buffer and the sequence to set RGB colors (each 4 bit) is 0x00G0RB00 > (beware, Macs are big-endian), that is 0x00f0 is fully saturated green, > 0xf000 fully saturated red etc. Hmm, sounds like the palette is programmed incorrectly. Hui Yu or Kevin E. Martin might know more about these problems, but I'm not sure if they're reading either of these lists. You could file a bug to the XFree86 bugzilla. > Problem 3) > Shutting down X blanks both screens - i.e. the frame buffer is not correctly > restored. This is somewhat painful since after closing X you can access the > box via ssh only. > > Other relevant info: > kernel is 2.4.20-ben10 (the devel versions crash), frame buffer works only > with "video=ofonly". Have you reported radeonfb not working to Benjamin Herrenschmidt or the linux-fbdev-devel list? It may also a bug in the radeon driver that it doesn't restore the console mode correctly though. PS: Posting once is enough... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
1200dpi bitmap fonts in the tree
Is it me, or are we really shipping 1200dpi bitmap fonts as part of XFree86? xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 968 with IBM 526 DAC
On Sun, 1 Jun 2003, Andrew C Aitchison wrote: > On Sat, 31 May 2003, Tothwolf wrote: > > > I haven't been able to follow development lately, but is anyone > > actively working on adding IBM 526 support to the new S3 server? I > > have a number of Diamond Stealth 64 VRAM boards that use the S3 968 > > with an IBM 526, and I'd really like to put them to use. > > I'm not, as I don't have any such cards, but I consider it one of the > more interesting S3 cards, as the IBM 526 is one of the few chips which > supports 8+24 overlays. They are pretty nice boards, though the 4MB of ram limits what you can do somewhat. You can still do far more with them than the typical 2MB cards from the same era. I noticed that the IBM 524 was also a popular DAC for the 968 cards, which leads me to believe that the 524 just lacks some of the extra features of the 526. Some of these boards I bought new back in 1996-97 or so, and I still remember what they originally cost ;) > I see that the i128 driver supports the IBM 526. I noticed that myself, but without documentation, I finally gave up trying to walk though the code. I think with docs, I could probably understand the old 3.x S3 server drivers enough to port quite a bit of code. Speaking of which, is there a comprehensive list of S3 chipset based cards anywhere? Such a list would be a very good starting point for collecting cards/documentation and porting/rewriting the drivers. I guess some of the reasons the drivers haven't been ported is a lack of cards and/or interest. S3 cards were extremely popular in the mid to late 1990s, and tons of the cards are still in use in older systems. Since XFree86 and Linux/*BSD run so well on those older systems, I really think its important to get the S3 code up to date. > I have detailed docs of the IBM 526 (and differences from the 524 and > 624) but my i128 has a SilverHammer DAC, which i128IDMDAC.c says is > essentially the same as the IBMRGBxxx DACs, but with fewer options and a > different reference frequency. > Do you know anything more about this chip? I know nearly nothing about the programming of DACs and such, but I'd still like to find docs. Worst case, I guess I'm going to have to learn to program them just to get my boards working. I have been told the 526 docs are more or less an add-on to the 524 docs. I also don't have docs for the 968, which I imagine I'll really need to find too. Getting docs from S3 will be nearly impossible, since they've likely disposed of such things. IBM tends to be a little better in that regard, so I may have to contact them. -Toth ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
On Sun, 1 Jun 2003, Alex Deucher wrote: > Just curious, as I'm not too familiar with XvMC yet, but would this > provide another Xv adapter that used the 3D texture engine to display > videos rather than othe video overlay? or something else. Sorry for > my ignorance. ... ... ... > --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > >I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > > to XvMC. I have implemented this in NVIDIA's binary drivers and > > am able to do full framerate HDTV video textures on the higher end > > GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > > contents into a texture. I don't really know any more than you but my guess is that while this may be presented as another Xv adapter, what it really does is make a video source available as a texture. This would allow you to, for instance, display a virtual reality living-room and whenever the camera falls on the TV it would be showing live pictures from a video feed. -- Andrew C. Aitchison Cambridge [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
Just curious, as I'm not too familiar with XvMC yet, but would this provide another Xv adapter that used the 3D texture engine to display videos rather than othe video overlay? or something else. Sorry for my ignorance. Thanks, Alex --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: >I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > to XvMC. I have implemented this in NVIDIA's binary drivers and > am able to do full framerate HDTV video textures on the higher end > GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > contents into a texture. > > > Status > XvMCCopySurfaceToGLXPbuffer ( > Display *display, > XvMCSurface *surface, > XID pbuffer_id, > short src_x, > short src_y, > unsigned short width, > unsigned short height, > short dst_x, > short dst_y, > int flags > ); > >This function copies the rectangle specified by src_x, src_y, > width, > and height from the XvMCSurface denoted by "surface" to offset > dst_x, dst_y > within the pbuffer identified by its GLXPbuffer XID "pbuffer_id". > Note that while the src_x, src_y are in XvMC's standard left-handed > coordinate system and specify the upper left hand corner of the > rectangle, dst_x and dst_y are in OpenGL's right-handed coordinate > > system and denote the lower left hand corner of the destination > rectangle in the pbuffer. > > "Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or > XVMC_FRAME_PICTURE. > If flags is not XVMC_FRAME_PICTURE, the src_y and height are in > field > coordinates, not frame. That is, the total copyable height is half > the height of the XvMCSurface. > > XvMCCopySurfaceToGLXPbuffer does not return until the copy to the > pbuffer has completed. XvMCCopySurfaceToGLXPbuffer is pipelined > with XvMCRenderSurface so no explicit synchronization between > XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed. > > The pbuffer must be of type GLX_RGBA, and the destination of the > copy is the left front buffer of the pbuffer. Success is returned > if no error occured, the error code is returned otherwise. > > Possible Errors: > >XvMCBadSurface - The surface is invalid. > >BadDrawable - The pbuffer_id is not a valid pbuffer. > >BadMatch - The pbuffer is not of type GLX_RGBA or the > pbuffer does not have a front left buffer. > > XvMCCopySurfaceToGLXPbuffer is supported if the following flag: > > #define XVMC_COPY_TO_PBUFFER 0x0010 > > is set in the XvMCSurfaceInfo's flags field. > > I'd like to bump the API version up to 1.1 and add this. > Comments? > > > Mark. > __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
re: [PATCH] radeon mergedfb support for cvs
BTW, bugzilla reference for this feature is here: http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=276 Please test and post any comments or issues. Thanks, Alex --- The attached patch adds mergedfb support (a single framebuffer with two viewports looking into it) to the radeon driver. the options are consistant with the sis and mga drivers. I've also replaced the old clone mode with the clone mode supplied by the mergedfb code. It's behavior follows that of the previous previous clone code. I've tested it on an a radeon m6. HW accelerated 3D works on both heads. Please consider for inclusion in xfree86 cvs. Thanks, Alex __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
