Re: redhat-config-xfree86
Of course, it is resulted by Driver.(SiS 661) It may be resulted by someone touch wrong bits during programing DDC info That someone should be not contained in driver,because I had inspected during all of outb micro in the driver. May XFree86 provide get DDC info function.(maybe XFree86 get which registers contral I2C)?? Does any tool have break point I/O address in Linux? Thanks for suggesting - Original Message - From: Mike A. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 16, 2004 7:02 AM Subject: Re: redhat-config-xfree86 On Thu, 15 Jan 2004, harry wrote: Date: Thu, 15 Jan 2004 13:56:18 +0800 From: harry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary==_NextPart_000_001B_01C3DB6F.5971F840 Subject: redhat-config-xfree86 Hello all, I have a problem during run redhat-config-xfree86 under Xwindow : monitor will be closed (include sync). But run it normally under text console mode. I think that may be brought by driver , because it's ok under Xwindow if using vesa driver. I found exec redhat-config-xfree86 will run python2.2 xconf.py and monitor will closed in cv = FX86HardwareState(xconf) this step May someone know Which XFree86 functions will be called by FX86HardwareState(xconf).Or Where may I find hints? Doesn't sound like an XFree86 problem per se, unless the X server is crashing when r-c-x starts up possibly. What video hardware (brand and model) are you using, and what version of Red Hat Linux? Also try doing: redhat-config-xfree86 --reconfig After this, try to start up X using startx and if it fails, please put your X server log and config file somewhere viewable via http or ftp, and post URLs to the files here. It's possible your particular video card model is not supported, however I'll need the above info first in order to determine/advise. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XGrabButton() BadAccess error
Hi Mark,
I suspect that you are right - I think MetaCity is grabbing it, and causing
my grab to crash. Is it easy to install another window manager, and which
one would you recommend?
Thanks,
Greg
Greg Knight B.Sc.(Hons), C.Eng., C.I.S.P.
Email: [EMAIL PROTECTED]
URL: www.ConsultGregKnight.com
INTERNET MAIL CONFIDENTIALITY
This E-mail is covered by the Electronic Communications Privacy Act, 18 U.
S. C. 2510-2521 and is legally privileged. This information is confidential
information and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mark Vojkovich
Sent: Thursday, January 15, 2004 11:51 PM
To: [EMAIL PROTECTED]
Subject: Re: XGrabButton() BadAccess error
This is not my area of expertise, but the man page and X-server code
suggest that this only happens when this button is already grabbed by
another client. That means either you double grab in your app using
separate display connections, or another app is grabbing it. Have you tried
running with a different window manager?
Mark.
On Thu, 15 Jan 2004, Greg Knight wrote:
Hi Folks,
I have inherrited some old(ish) code, and am having some trouble
getting it working. I am assured this code has worked in the past, but
I now get a BadAccess error running the code with XFree86 in RedHat v9
Professional. As I am not an expert in X/Xt, I would appreciate some
help in telling me where it is wrong, and suggestions for quickly
getting it working again! Many thanks!
I have summarised the key calls of the failing code below. As you can
see, the program opens a control panel via Xt, then opens a Big window
(for graphics text) via X. Mouse events in the Big window used to be
read via the XtAppNextEvent() call, after an XGrabButton() call had
been made, but the call to XGrabButton() is now failing with a
BadAccess, so we never see the events from the Big window.
If I use the CWOverrideRedirect option (which seems a strange thing to
do on a big display window like this), then the XGrabButton works OK,
but (as you might expect) the Big window has no title or borders is
always on top (not what we want).
Here is the sequence of the major calls:
toplevel = XtAppInitialize(XControlPanel,XB,
options,XtNumber(options),GlobalArgC,GlobalArgV,
NEfallback_resources,APargs,SIX);
/* open another channel to the server via the same application context
-
hence allowing the toolkit to process the mouse (etc.) events */
if((TheXDisplay = XtOpenDisplay(XControlPanel,NULL,
XB,ACompany,options,XtNumber(options),GlobalArgC,
GlobalArgV)) == NULL)
{
// error handling tidy up
}
XRootWin = DefaultRootWindow(TheXDisplay);
ScreenNumber = XDefaultScreen(TheXDisplay);
XBigWindowAttr.backing_store = Always;
XBigWindowAttr.save_under = True;
XBigWindowAttr.event_mask = ButtonReleaseMask;
XBigWindow =
XCreateWindow(TheXDisplay,XRootWin,0,0,BITMAPWIDTH,BITMAPHEIGHT,XWINBO
RDERWI
DTH,
BigWindowDepth,InputOutput,(Visual
*)XBigWindowVisual,
CWSaveUnder | CWBackingStore | CWBackPixel|
CWBorderPixel | CWColormap
| CWEventMask,
XBigWindowAttr);
/* now let's map the window */
if((XIntError = XMapRaised(TheXDisplay,XBigWindow)) != Success)
{
// error handling
}
if((XIntError =
XGrabButton(TheXDisplay,JNSBUTTONS,JNSKMODS,XBigWindow,False,
Button1Mask,GrabModeAsync,GrabModeAsync,None,None)) != Success)
{
// error handling
}
// Event Handling ...
while(0 == 0)
{
XtAppNextEvent(XControlPanel,TheEvent);
// etc
}
--
The exact error message from XGrabButton() is:
X Error of failed request: BadAccess (attempt to access private
resource
denied)
Major opcode of failed request: 28 (X_GrabButton)
I'm hoping this is something simple, and I appreciate help in getting
this running again.
Many thanks,
Greg
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Question regarding dual headed machines with two keyboards and two mice
Hello! I'm wondering if its possible to set up a dual headed system with two keyboards and two mice? Essentially what I'm after is being able to have two users with two X consoles independently using the same computer. I've found some hints on the 'net that this will work, but it required patches against some old XFree 4.0 code. I've also had a look in the mailing list archives and again have found some hints that it may work... Can anyone provide any hints or tips on how to make this work? I'm pretty sure it can be done, as there is an Internet workstation in the lobby of our building that runs linux and has two monitors, keyboards, and mice on one Linux box. Thanks! Mark Mark Cuss, B. Sc. Real Time Systems Analyst CDL Systems Ltd Suite 230 3553 - 31 Street NW Calgary, AB, Canada Phone: 403 289 1733 ext 226 Fax: 403 282 1238 www.cdlsystems.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
--- Mark Cuss [EMAIL PROTECTED] wrote: Hello! I'm wondering if its possible to set up a dual headed system with two keyboards and two mice? Essentially what I'm after is being able to have two users with two X consoles independently using the same computer. I've found some hints on the 'net that this will work, but it required patches against some old XFree 4.0 code. I've also had a look in the mailing list archives and again have found some hints that it may work... Can anyone provide any hints or tips on how to make this work? I'm pretty sure it can be done, as there is an Internet workstation in the lobby of our building that runs linux and has two monitors, keyboards, and mice on one Linux box. here's one link: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/ Search for multiuser xfree86 or multiuser X on google for more links. There is no standard support for this in xfree86 yet. still just hacks. Alex Thanks! Mark __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
Okay - thanks! I did find the link you sent, but was wondering if this was supported in the new 4.4.0 release... Is there support planned in a future release? Mark - Original Message - From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED]; X Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:16 AM Subject: Re: Question regarding dual headed machines with two keyboards and two mice --- Mark Cuss [EMAIL PROTECTED] wrote: Hello! I'm wondering if its possible to set up a dual headed system with two keyboards and two mice? Essentially what I'm after is being able to have two users with two X consoles independently using the same computer. I've found some hints on the 'net that this will work, but it required patches against some old XFree 4.0 code. I've also had a look in the mailing list archives and again have found some hints that it may work... Can anyone provide any hints or tips on how to make this work? I'm pretty sure it can be done, as there is an Internet workstation in the lobby of our building that runs linux and has two monitors, keyboards, and mice on one Linux box. here's one link: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/ Search for multiuser xfree86 or multiuser X on google for more links. There is no standard support for this in xfree86 yet. still just hacks. Alex Thanks! Mark __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
shared XvMC lib
What does the future hold for XvMC? I've been playing around with the open source savageXvMC lib that S3/VIA released. As I understand it now, you have to explicitly link you application with the particular XvMC lib you want to use. Are there any plans to make this more like Xv? That way apps could just link against libXvMC.so.1 or whatever and be able to use whatever XvMC support is available. There are getting to be quite a few XvMC inplementations available. what is needed to move this forward? XvMC support: i810/15 (open source) savage (open source) via (open and closed libs) nvidia (closed libs) ati (closed libs) Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
On Fri, 16 Jan 2004, Mark Cuss wrote: Okay - thanks! I did find the link you sent, but was wondering if this was supported in the new 4.4.0 release... Is there support planned in a future release? You can run a single X server with two screens, two mice (mice, not pointers/cursors) and (I think) two keyboards. You could run two X servers each with a screen keyboard and mouse, the problem is that normally there is only a single console, and only one *active* virtual terminal (I'm thinking Linux, but this is true for most if not all supported OSes). Try this; it works but you have to switch VTs with CtlAltFn to see both X servers. As I see it this is an OS issue, not an XFree86 issue - XFree86 turns a text head into a graphics head. If the OS only provides one text console at a time, XFree86 only gives you one graphics head at a time. (OK maybe it would be possible for an Xserver not to use a VT). I understand that 2.5.x kernels can support multiple text consoles, and I understand that in this case two X head can be done. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: shared XvMC lib
It would need to be more like the DRI than Xv. It needs a library that determines what underlying library needs to be used based on the X server driver. So something like: detect the X renderer, dlopen an XvMC### library based on that information, hook up a dispatch table from the XvMC symbols to the dlopened HW specific symbols and go. I think the basics are not a big deal. If you wanted to handle any type of multi-head setup there are probably bigger problems to solve. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Deucher Sent: Friday, January 16, 2004 10:44 AM To: [EMAIL PROTECTED] Subject: shared XvMC lib What does the future hold for XvMC? I've been playing around with the open source savageXvMC lib that S3/VIA released. As I understand it now, you have to explicitly link you application with the particular XvMC lib you want to use. Are there any plans to make this more like Xv? That way apps could just link against libXvMC.so.1 or whatever and be able to use whatever XvMC support is available. There are getting to be quite a few XvMC inplementations available. what is needed to move this forward? XvMC support: i810/15 (open source) savage (open source) via (open and closed libs) nvidia (closed libs) ati (closed libs) Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XGrabButton() BadAccess error
I usualy hack configuration files, but there is probably an
easier way to do that in RedHat. They used to have a utility
called switchdesk. I'm not sure if they still do.
I'm probably not the best one to ask about which window
manager to use since I'm still using the ancient TWM.
Mark.
On Fri, 16 Jan 2004, Greg Knight wrote:
Hi Mark,
I suspect that you are right - I think MetaCity is grabbing it, and causing
my grab to crash. Is it easy to install another window manager, and which
one would you recommend?
Thanks,
Greg
Greg Knight B.Sc.(Hons), C.Eng., C.I.S.P.
Email: [EMAIL PROTECTED]
URL: www.ConsultGregKnight.com
INTERNET MAIL CONFIDENTIALITY
This E-mail is covered by the Electronic Communications Privacy Act, 18 U.
S. C. 2510-2521 and is legally privileged. This information is confidential
information and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mark Vojkovich
Sent: Thursday, January 15, 2004 11:51 PM
To: [EMAIL PROTECTED]
Subject: Re: XGrabButton() BadAccess error
This is not my area of expertise, but the man page and X-server code
suggest that this only happens when this button is already grabbed by
another client. That means either you double grab in your app using
separate display connections, or another app is grabbing it. Have you tried
running with a different window manager?
Mark.
On Thu, 15 Jan 2004, Greg Knight wrote:
Hi Folks,
I have inherrited some old(ish) code, and am having some trouble
getting it working. I am assured this code has worked in the past, but
I now get a BadAccess error running the code with XFree86 in RedHat v9
Professional. As I am not an expert in X/Xt, I would appreciate some
help in telling me where it is wrong, and suggestions for quickly
getting it working again! Many thanks!
I have summarised the key calls of the failing code below. As you can
see, the program opens a control panel via Xt, then opens a Big window
(for graphics text) via X. Mouse events in the Big window used to be
read via the XtAppNextEvent() call, after an XGrabButton() call had
been made, but the call to XGrabButton() is now failing with a
BadAccess, so we never see the events from the Big window.
If I use the CWOverrideRedirect option (which seems a strange thing to
do on a big display window like this), then the XGrabButton works OK,
but (as you might expect) the Big window has no title or borders is
always on top (not what we want).
Here is the sequence of the major calls:
toplevel = XtAppInitialize(XControlPanel,XB,
options,XtNumber(options),GlobalArgC,GlobalArgV,
NEfallback_resources,APargs,SIX);
/* open another channel to the server via the same application context
-
hence allowing the toolkit to process the mouse (etc.) events */
if((TheXDisplay = XtOpenDisplay(XControlPanel,NULL,
XB,ACompany,options,XtNumber(options),GlobalArgC,
GlobalArgV)) == NULL)
{
// error handling tidy up
}
XRootWin = DefaultRootWindow(TheXDisplay);
ScreenNumber = XDefaultScreen(TheXDisplay);
XBigWindowAttr.backing_store = Always;
XBigWindowAttr.save_under = True;
XBigWindowAttr.event_mask = ButtonReleaseMask;
XBigWindow =
XCreateWindow(TheXDisplay,XRootWin,0,0,BITMAPWIDTH,BITMAPHEIGHT,XWINBO
RDERWI
DTH,
BigWindowDepth,InputOutput,(Visual
*)XBigWindowVisual,
CWSaveUnder | CWBackingStore | CWBackPixel|
CWBorderPixel | CWColormap
| CWEventMask,
XBigWindowAttr);
/* now let's map the window */
if((XIntError = XMapRaised(TheXDisplay,XBigWindow)) != Success)
{
// error handling
}
if((XIntError =
XGrabButton(TheXDisplay,JNSBUTTONS,JNSKMODS,XBigWindow,False,
Button1Mask,GrabModeAsync,GrabModeAsync,None,None)) != Success)
{
// error handling
}
// Event Handling ...
while(0 == 0)
{
XtAppNextEvent(XControlPanel,TheEvent);
// etc
}
--
The exact error message from XGrabButton() is:
X Error of failed request: BadAccess (attempt to access private
resource
denied)
Major opcode of failed request: 28 (X_GrabButton)
I'm hoping this is something simple, and I appreciate help in getting
this running again.
Many thanks,
Greg
Re: [GATOS]how to check if hardware mpeg2 decoder is working
-the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older =266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of written right away splits in two parts written right away, even a single byte (used for access to registers) and written right away, grouped into blocks for fast transfer (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to written right away, even a single byte and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev Christopher Crawford Peace, William --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
Thanks for the info... I understand that this is an OS issue; I have found some links that provide patches to the 2.4.x kernel which allow multiple consoles, but from what I understand this still requires a modified X server as well. I didn't know that the new kernel had built in support for this - If I can avoid a patch against 2.4.x that would be good - thanks! Mark - Original Message - From: Dr Andrew C Aitchison [EMAIL PROTECTED] To: Mark Cuss [EMAIL PROTECTED] Cc: X Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:53 AM Subject: Re: Question regarding dual headed machines with two keyboards and two mice On Fri, 16 Jan 2004, Mark Cuss wrote: Okay - thanks! I did find the link you sent, but was wondering if this was supported in the new 4.4.0 release... Is there support planned in a future release? You can run a single X server with two screens, two mice (mice, not pointers/cursors) and (I think) two keyboards. You could run two X servers each with a screen keyboard and mouse, the problem is that normally there is only a single console, and only one *active* virtual terminal (I'm thinking Linux, but this is true for most if not all supported OSes). Try this; it works but you have to switch VTs with CtlAltFn to see both X servers. As I see it this is an OS issue, not an XFree86 issue - XFree86 turns a text head into a graphics head. If the OS only provides one text console at a time, XFree86 only gives you one graphics head at a time. (OK maybe it would be possible for an Xserver not to use a VT). I understand that 2.5.x kernels can support multiple text consoles, and I understand that in this case two X head can be done. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
Hello! As I see it this is an OS issue, not an XFree86 issue - XFree86 turns a text head into a graphics head. If the OS only provides one text console at a time, XFree86 only gives you one graphics head at a time. (OK maybe it would be possible for an Xserver not to use a VT). Last time I tried to run two X servers simultaneously (by writing a simple patch disabling the console switching magic), very mysterious things were happening as each X server was trying to disable I/O ports and memory of the other card :-) I understand that 2.5.x kernels can support multiple text consoles, and I understand that in this case two X head can be done. I think that the right way is to teach the X server how to run without attaching to a text console (assuming you have a card which doesn't need access to VGA registers) and use the Linux input layer for keyboard input. Should work with any 2.4.x or newer kernel. The only problematic place seems to be initialization of the secondary card(s) by calling their BIOS, which is almost guaranteed to require exclusive access to VGA ports, but it can be done once during system boot. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A mathematician is a machine for converting coffee into theorems. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
re[10]
Lowered prices for custom programming ($8-10/hr) http://61.104.49.188:1704/sl/services.php?og=1wk=1163da=13op=web and design ($15/hr) http://61.104.49.188:1704/sl/services.php?og=1wk=1163da=13op=design We use MS project and qualified project managers to create correct architecture of the project and track its development. We care about deadlines and business logic - so that the project started bringing you money quite soon after launch. We'll provide you contacts for references in Europe and the USA. We're located in Eastern Europe. Please, contact us to get functional software for your needs. * * * * * * * * * * uw rtbnhxcd cnuo cl ayv mgtmg kq goy xrf cu k ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: shared XvMC lib
--- Mark Vojkovich [EMAIL PROTECTED] wrote: Xv is not direct rendered so it's not a meaningful comparision. The question is when it will be more like OpenGL, with separate libXvMC and libXvMCcore. I've not really given the implementation much thought, and I'm not convinced that the DRI example is a correct one. To do things correctly you'd want to be able to handle multiple heads using different drivers, which is something I suspect the DRI OpenGL implementation cannot do. To work with multihead, you'd have to have some sort of dispatch lib that would optimally divide, or just dispatch the data to the appropriate head's renderer. the DRI would need something similar. If you solve the problem once you could solve it twice and fix both. Still, it seems like a lot of work. I didn't fully realize how XvMC worked. Alex Currently, the assumed decoder implementation is one that links to libXvMC and dlopens the vendor-specific library like my mpeg2play demo does. This isn't much different from how you'd ideally want things to work, though you'd want the dlopen part to be handled transparently by libXvMC. Mark. On Fri, 16 Jan 2004, Alex Deucher wrote: What does the future hold for XvMC? I've been playing around with the open source savageXvMC lib that S3/VIA released. As I understand it now, you have to explicitly link you application with the particular XvMC lib you want to use. Are there any plans to make this more like Xv? That way apps could just link against libXvMC.so.1 or whatever and be able to use whatever XvMC support is available. There are getting to be quite a few XvMC inplementations available. what is needed to move this forward? XvMC support: i810/15 (open source) savage (open source) via (open and closed libs) nvidia (closed libs) ati (closed libs) Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
