| Summary: | Add DMX to X.Org | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Kevin E. Martin <kem> | ||||||
| Component: | Server/General | Assignee: | Kevin E. Martin <kem> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | high | CC: | ajax, roland.mainz | ||||||
| Version: | git | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | All | ||||||||
| URL: | http://dmx.sourceforge.net/ | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Kevin E. Martin
2004-06-22 18:34:43 UTC
After review, I will commit this to the X.Org CVS tree. Created attachment 411 [details] [review] Patch to add DMX support to X.Org Created attachment 412 [details]
Tar file of newly added files for DMX support
kevin, does this address bug 578 at all? specifically alan's point about mixing Mesa and Xinerama. also, does the glxproxy work to accelerate indirect rendering even for normal servers? (In reply to comment #4) > kevin, does this address bug 578 at all? specifically alan's point about mixing > Mesa and Xinerama. GLX Proxy acts as a proxy server and distributes GLX protocol to multiple back-end servers to which DMX is attached, so when Xinerama is used, I think it will address the OpenGL with Xinerama issue. However, Cromium is the best solution. > also, does the glxproxy work to accelerate indirect rendering even for normal > servers? No, it's just a proxy server, so it just takes advantage of whatever indirect rendering is available. If the back-end server already has accelerated indirect rendering, then GLX Proxy will take advantage of it, but if it isn't accelerated, then GLX Proxy won't be either. Comment on attachment 411 [details] [review] Patch to add DMX support to X.Org I see one nit with the patch - is it wise to use the cpp symbol |DMX| in such a large codebase ? IMHO something longer (e.g. more than three letters) may be better... (In reply to comment #6) > (From update of attachment 411 [details] [review]) > I see one nit with the patch - is it wise to use the cpp symbol |DMX| in such a > large codebase ? > IMHO something longer (e.g. more than three letters) may be better... The DMX cpp symbol is only used in the xdyinfo patch, and we were following the convention that others used (e.g., MITSHM, XKB, XF86VIDMODE, etc.). If there is a strong feeling against using DMX cpp symbol in xdpyinfo, we can certainly change it. kem@freedesktop.org wrote: > (In reply to comment #6) > > (From update of attachment 411 [details] [review]) > > I see one nit with the patch - is it wise to use the cpp symbol |DMX| in > > such a large codebase ? > > IMHO something longer (e.g. more than three letters) may be better... > > The DMX cpp symbol is only used in the xdyinfo patch, and we were following > the convention that others used (e.g., MITSHM, XKB, XF86VIDMODE, etc.). If > there is a strong feeling against using DMX cpp symbol in xdpyinfo, we can > certainly change it. If the |DMX| symbol is only used in xdpyinfo (which is itself a tiny application) then it is OK... I only feared - without checking that in detail - that this symbol is used all over the tree. Sorry for the false alarm... I should have this checked twice before running around and screaming... :) Support for DMX checked-in. Thank you to all who reviewed the patches. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.