[ANNOUNCE] xf86-video-ati 6.10.99.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is an xf86-video-ati RC release for 6.11.0 Major changes between 6.10.0: - - major output rework - - fix bug in rs780 MC setup that could lead to memory corruption - - lots of bug fixes Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Alex Deucher (49): Fix colors on tv-out properly handle EnableYUV Make sure we hit the right bios reg missed one in last commit Allow arbitrary tv-out modes ATOM: rework object table parsing ATOM: handle cases where TMDS uses linkb ATOM: Adjust PLL setup for recent atom changes ATOM: refactor output dpms ATOM: rework encoder/transmitter setup Bump version post release RV280: add another AGP quirk RV280 Add another AGP quirk DCE30: LVTMA requires DIG2 encoder ATOM: combine DAC setup functions ATOM: switch to define for external tmds start to re-org outputs ATOM: round 1 of output rework First pass at converting legacy code to encoder objects clean up encoder setup Fixup encoder setup on pre-ATOM chips ATOM: more output cleanup Switch legacy output code to use new encoder objects ATOM: fix encoder init fix legacy crtc routing and add some debugging info More legacy rework Fix logic cut and paste error Move active_device setup to detect() Fix compilation with RADEON_TRACE_FALL set few more logic pasto's bits I missed Remove TMDSType, DACType, LVDSType from output rec track encoder state Remove some unused cruft Remove OutputType and other cruft Additional output cleanup Fix off by one when printing encoder name Move legacy output setup functions to legacy_output.c Warning fixes ATOM: print useful output info for DPMS events Fix legacy output setup Encoders not assigned yet, use supported devices Move encoder specific data to encoder dev_priv Return NULL for encoder if no active device is assigned Fix bad rv710 pci id Fix encoder accounting AVIVO: fix rotation AVIVO: better fix for rotation Add some missing r6xx/r7xx pci ids Bump for rc release Christiaan van Dijk (1): R3xx/R4xx: Maximize the use of clipped triangles for Xv rendering Dave Airlie (3): radeon: r500 PAL timings are slightly incorrect r500: re-enable TV out radeon: r500 tv-out force scaler values to nice set that looks correct Maciej Cencora (1): Make sure gb_num_pipes is initialized when DRI is disabled Michel Dänzer (3): Don't transform EXA Composite mask coordinates when there's no mask. Drop memcpy fallbacks from EXA UploadToScreen and DownloadFromScreen hooks. EXA: Accelerate Composite of RepeatPad/Reflect pictures when possible. Nicos Gollan (1): Fixed enumerations in radeon-output.c Thomas Jaeger (1): Fall back to software for unsupported repeat modes Tormod Volden (1): Add yet another AGP quirk for RV280 Wolke Liu (1): AVIVO: Save/restore vga pll registers airlied (1): rs780: include RS780 in the InitMemory to leave alone git tag: xf86-video-ati-6.10.99.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.10.99.0.tar.bz2 MD5: 4c32a782d0d43e81318347155104d78c xf86-video-ati-6.10.99.0.tar.bz2 SHA1: e6e1ab7acd27d6de501fed034d0fbc8a06677beb xf86-video-ati-6.10.99.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.10.99.0.tar.gz MD5: bc62be84ae411eea1a95d30c9a5baf9d xf86-video-ati-6.10.99.0.tar.gz SHA1: 15ad692cbfe6392d04d63372c3342a65913346c3 xf86-video-ati-6.10.99.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJkKLHm07k+YR03kARAkKYAKDMUDf92aw3BQHbEQ1kcEJumhWqzACgtFl2 2PTHrrEUOW35jFc1yYUnarc= =n9/W -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: XCopyArea clip bug
On Sat, 2009-02-07 at 22:04 +0100, Maarten Maathuis wrote: I comitted a slightly different patch. I found out that all clipping possibilities are converted to regions in the end, so this should be enough. http://cgit.freedesktop.org/xorg/xserver/commit/?id=00226d0b589595cdd45c75e7e28237334a8883b1 You can put the patch on the wiki (http://wiki.x.org/wiki/Server16Branch) for xserver 1.6 inclusion if you are seriously bothered by the issue. I can't rely on this being fixed in X anyway, so my code has to workaround this issue. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: memory leak?
DM wrote: Today I clicked in firefox 3.0.6 (fedora 10 / gnome / yum-updated / amd64 / 2GiB main memory / no swap) on http://de.wikipedia.org/wiki/Datei:Www_Beo_cc.jpg this URL: http://upload.wikimedia.org/wikipedia/commons/f/ff/Www_Beo_cc.jpg Download took quite long and the box' responsiveness was not as good as usual... So I clicked the close-window box in the title of the firefox window. The firefox window disappeared and the process, too. But the box had just 10% free main memory now (usually 80% r free after a fresh login); Xorg used 1.8GiB according to ps. So I installed xrestop, which told me that about 2 pixmaps (20MiB) belong to an unknown process. 1. xrestop (and X generally) doesn't deal with processes, but clients. Is it possible that a client spawned a child process which inherited the X connection and still exists? The X server won't free resources until the corresponding connection is closed, which only happens when *no* process has a descriptor for the remote end of the connection. 2. 20MiB isn't significant; it's ~1% of your main memory. What is significant is that the X server needed to enlarge its heap, and is now keeping hold of that memory in case it needs it in the future. This wouldn't normally be a problem, as it will just get swapped out if it isn't being used. Except that you say that you don't have any swap. Normally it takes a day until the Xorg process (VSZ RSS: 431952 88772 -- 474472 123508) and other processes get too large. Then I log off and in and everything is OK again. How can I avoid that logoff/login procedure? Add swap. Then, any memory which is allocated to the X server but isn't actively being used will get swapped out, allowing the physical memory to be used for something else. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How can I obtain the type of an object by its identifier ?
Hello all. How can I obtain the type of an object by its identifier (XID)? E.g., window, picture, etc. Thank you. -- Regards, Alexei Babich, circuit engineer, OOO NPP Rezonans, Chelyabinsk, Russia http://www.rez.ru Jabber ID: imp...@jabber.ru ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Resolution 1360x768 not selected
Hi, I need assistance in finding out just why on earth xorg decides not to use 1360x768 despite the monitor returning this in the DDC and having it in the Modes/PreferredMode option. Xorg.0.log: http://pastebin.ca/1329034 xorg.conf: http://pastebin.ca/1329035 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Resolution 1360x768 not selected
On Monday 2009-02-09 12:47, Jan Engelhardt wrote: I need assistance in finding out just why on earth xorg decides not to use 1360x768 despite the monitor returning this in the DDC and having it in the Modes/PreferredMode option. Xorg.0.log: http://pastebin.ca/1329034 xorg.conf: http://pastebin.ca/1329035 I sort of solved this, but not quite happy with how it's done. Quoting xorg.conf(5): Specifying video modes is optional because the server will use the DDC or other information provided by the monitor to automatically configure the list of modes available. Further, When modes are specified explicitly in the Monitor section (with the Modes, ModeLine, or UseModes keywords), built-in modes with the same names are not included. So according to this, removing the explicit ModeLines should give priority to the DDC-provided modes. But - the PreferredMode or Subsection Display Modes list will _NOT_ make use of these DDC modes, leaving me to having to explicitly specify the ModeLine for 1360x768 (at least that dose work). That is _bad_. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Resolution 1360x768 not selected
On 2009/02/09 12:47 (GMT+0100) Jan Engelhardt composed: I need assistance in finding out just why on earth xorg decides not to use 1360x768 despite the monitor returning this in the DDC and having it in the Modes/PreferredMode option. Xorg.0.log: http://pastebin.ca/1329034 xorg.conf: http://pastebin.ca/1329035 Finding out the meaning of the (EE) lines should tell. I see several, but don't know their significance. If it was me, I'd try changing PreferredMode to 1280x768, since that's what a quick Google turned up as the native mode. If it doesn't work that way, I'd try adding 'Option NoDDC' to 'Section Device' and try again. Next I'd try rerunning sax2, and select a generic LCD 1440x900 and see what happens, since most wide 19 (closest to probed dimensions in Xorg.0.log) displays are natively 1440x900, 1360x768 doesn't compute directly to either of the common 16:10 or 16:9 modes, and if still no go try selecting 1440x900 or 1280x768 In SaX2. If still no go, I'd goto DKT web site to see if any assistance might be available. Looking at the probed DDC and the stats I found with Google, I have to think the stats or EDID and/or probed DDC is broken. What is it, 26? 19? Is it new? If it is, I'd take it back and get something that uses a standard 16:9 or 16:10 native mode. cf. http://fm.no-ip.com/auth/displays.xhtml http://www.hdtvreview.com/Decktron-DL26-B00P-hdtv.html -- Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up. Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] XI2 draft protocol specification (v 0.1)
Peter Hutterer wrote:
FP1616
Fixed point decimal in 16.16 format as 32 bit integer. The client is
required to convert to 16.16 decimal format.
Maybe it's just me, but I don't really get what 16.16 decimal format
means.
┌───
XIChangeDeviceHierarchy
num_changes: CARD8
changes: LISTofHIERARCHYCHANGES
└───
HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, CHANGEATTACHMENT }
HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, ChangeAttachment }
CHANGEMODE { Float, Attach }
I'd split HIERARCHYCHANGE into four: CM, RM, DetachSlave, AttachSlave -
thereby getting rid of CHANGEMODE.
The server processes the changes one by one and applies changes
immediately. If an error occurs, processing stops at the current change
and the error is returned to the client.
The point it stopped might be interesting to the client (only if it's
easy to report)
┌───
XISetClientPointer
win: Window
▶
set: BOOL
deviceid:DEVICEID
└───
Query the ClientPointer for the client owning 'win'.
I guess XI*G*etClientPointer is meant.
┌───
RawEvent
EVENTHEADER
eventtype: RAWTYPE
detail:CARD32
buttons_len: CARD16
valuators_len: CARD16
buttons: SETofBUTTONMASK
valuators: SETofVALUATORMASK
valuators_unaccel: SETofVALUATORMASK
axisvalues:LISTofFP3232
axisvalues_unaccel:LISTofFP3232
└───
RAWTYPE { Motion, KeyPress, KeyRelease, ButtonPress, ButtonRelease }
A RawDevice event provides the information provided by the driver to the
client. RawDevice events are only generated for slave devices.
Unaccelerated and accelerated valuator data is provided if applicable.
Of course acceleration is, right now, the only thing that could happen
to valuators after the driver is finished, but I'd avoid a direct
reference to it in the spec. (un-)transformed or adjusted seems a better
choice to me. Or 'raw'.
valuators
Bitmask of valuators provided in 'axisvalues'.
valuators_unaccel
Bitmask of valuators provided in 'axisvalues_unaccel'.
It might make sense to say something about their correlation, i.e. will
both be reported when available? The description: 'Unaccelerated and
accelerated valuator data is provided if applicable.' may mean: 'If an
axis is accelerated/translated, the server may/must omit the
untranslated value'.
IOW, what exactly is 'applicable'?
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel memory leakage
Anyway the problem appears only with UXA , with EXA I could start Xorg, but have no direct rendering. But that seems to be more due to some missing visuals, isn't it? Exactly. Bye Marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Resolution 1360x768 not selected
On Monday 09 February 2009 11:47:44 Jan Engelhardt wrote: Hi, I need assistance in finding out just why on earth xorg decides not to use 1360x768 despite the monitor returning this in the DDC and having it in the Modes/PreferredMode option. Xorg.0.log: http://pastebin.ca/1329034 xorg.conf: http://pastebin.ca/1329035 But that log appears to show the server using that mode (lines 779 onwards show 1360 x 768 mode being set)? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
GL_EXT_framebuffer_object on Intel GM45 with 2.6.1 drivers
Hello, I'm currenly owner of a 6530b laptop with an Intel Graphics Media Accelerator 4500MHD also known as the chipset GM45 in Linux, I currently use the following setup: xorg 1.5.3 server video-intel 2.6.1 drivers mesa 7.2 libdrm 2.4.3 dri2proto 1.99.3 And I would like to know if it is possible to have the following extension using this video card: *GL_EXT_framebuffer_object* VMWare seems to need it to get 3D acceleration working, and I'd like to know if there's any development on this extension? If not, can I add it to the wishlist? And I would just like to add that compiz is very very very slow on this card, but at least works :) Any improvement scheduled yet? Thank you, I hope you have all the informations you need to answer. Jérôme ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XDamageAdd problem with xserver-1.6-branch
Hi!
Attached is a simple program that repeatedly calls XDamageAdd with a
rectangle in the upper left corner, in a way very similar to what's done
when a DRI client runs glxSwapBuffers().
The problem I'm seeing with this is that an xterm window gets corrupted
when placed either to the right of
or below the region in question. I'm not sure whether this is a usage
problem, an X server problem or an xterm problem, but i can't really
recall seeing it before.
Any insight would be appreciated.
Thanks,
Thomas
#include X11/Xlib.h
#include X11/extensions/Xfixes.h
#include X11/extensions/Xdamage.h
int main()
{
Display *dpy;
int scrnum;
Window root;
dpy = XOpenDisplay(XDisplayName(NULL));
scrnum = DefaultScreen(dpy);
root = RootWindow(dpy, scrnum);
while(1) {
XRectangle rect;
XserverRegion region;
rect.x = 5;
rect.y = 5;
rect.width = 300;
rect.height = 300;
region = XFixesCreateRegion(dpy, rect, 1);
XDamageAdd(dpy, root, region);
XFixesDestroyRegion(dpy, region);
}
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Resolution 1360x768 not selected
On Monday 2009-02-09 16:33, Bill Crawford wrote: On Monday 09 February 2009 11:47:44 Jan Engelhardt wrote: Hi, I need assistance in finding out just why on earth xorg decides not to use 1360x768 despite the monitor returning this in the DDC and having it in the Modes/PreferredMode option. Xorg.0.log: http://pastebin.ca/1329034 xorg.conf: http://pastebin.ca/1329035 But that log appears to show the server using that mode (lines 779 onwards show 1360 x 768 mode being set)? As I found out [ http://lists.freedesktop.org/archives/xorg/2009-February/043598.html ] it did not use 1360x768 because it seems that the Modes option in the Display subsection completely ignores DDC-obtained modelines. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How can I obtain the type of an object by its identifier ?
On Mon, 2009-02-09 at 16:24 +0500, Alexei Babich wrote: Hello all. How can I obtain the type of an object by its identifier (XID)? E.g., window, picture, etc. From the client side? You don't. You could infer it by doing a bunch of GetWindowAttributes or similar and inspecting error codes, I suppose. I'm curious why you need to do this though. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GL_EXT_framebuffer_object on Intel GM45 with 2.6.1 drivers
On Mon, 2009-02-09 at 12:08 -0500, Jérôme Poulin wrote: Hello, I'm currenly owner of a 6530b laptop with an Intel Graphics Media Accelerator 4500MHD also known as the chipset GM45 in Linux, I currently use the following setup: xorg 1.5.3 server video-intel 2.6.1 drivers mesa 7.2 libdrm 2.4.3 dri2proto 1.99.3 And I would like to know if it is possible to have the following extension using this video card: GL_EXT_framebuffer_object VMWare seems to need it to get 3D acceleration working, and I'd like to know if there's any development on this extension? If not, can I add it to the wishlist? I see this extension listed in my glxinfo output.. I'm using mesa 7.3, perhaps you could try updating? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel memory leakage
Jesse Barnes wrote: Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? You are probably right here, Jesse: Letting Xorg run with UXA on my GM945 turns out to show a similar problem after a couple of hours or similar. sudo lsof | grep drm mm object | wc -l shows the incredible number of 2407... Cheers, Johannes. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GL_EXT_framebuffer_object on Intel GM45 with 2.6.1 drivers
Wow, that is unbelivable, since I updated to the latest Mesa, VMWare works, Compiz is working a 60 fps full speed, and everything just seems faster! Sorry, I talked too fast! Thank you for your suggestion, and good work to all the devs! On Mon, Feb 9, 2009 at 1:53 PM, Peter Clifton pc...@cam.ac.uk wrote: On Mon, 2009-02-09 at 12:08 -0500, Jérôme Poulin wrote: Hello, I'm currenly owner of a 6530b laptop with an Intel Graphics Media Accelerator 4500MHD also known as the chipset GM45 in Linux, I currently use the following setup: xorg 1.5.3 server video-intel 2.6.1 drivers mesa 7.2 libdrm 2.4.3 dri2proto 1.99.3 And I would like to know if it is possible to have the following extension using this video card: GL_EXT_framebuffer_object VMWare seems to need it to get 3D acceleration working, and I'd like to know if there's any development on this extension? If not, can I add it to the wishlist? I see this extension listed in my glxinfo output.. I'm using mesa 7.3, perhaps you could try updating? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-ati 6.10.99.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is an xf86-video-ati RC release for 6.11.0 Major changes between 6.10.0: - - major output rework - - fix bug in rs780 MC setup that could lead to memory corruption - - lots of bug fixes Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Alex Deucher (49): Fix colors on tv-out properly handle EnableYUV Make sure we hit the right bios reg missed one in last commit Allow arbitrary tv-out modes ATOM: rework object table parsing ATOM: handle cases where TMDS uses linkb ATOM: Adjust PLL setup for recent atom changes ATOM: refactor output dpms ATOM: rework encoder/transmitter setup Bump version post release RV280: add another AGP quirk RV280 Add another AGP quirk DCE30: LVTMA requires DIG2 encoder ATOM: combine DAC setup functions ATOM: switch to define for external tmds start to re-org outputs ATOM: round 1 of output rework First pass at converting legacy code to encoder objects clean up encoder setup Fixup encoder setup on pre-ATOM chips ATOM: more output cleanup Switch legacy output code to use new encoder objects ATOM: fix encoder init fix legacy crtc routing and add some debugging info More legacy rework Fix logic cut and paste error Move active_device setup to detect() Fix compilation with RADEON_TRACE_FALL set few more logic pasto's bits I missed Remove TMDSType, DACType, LVDSType from output rec track encoder state Remove some unused cruft Remove OutputType and other cruft Additional output cleanup Fix off by one when printing encoder name Move legacy output setup functions to legacy_output.c Warning fixes ATOM: print useful output info for DPMS events Fix legacy output setup Encoders not assigned yet, use supported devices Move encoder specific data to encoder dev_priv Return NULL for encoder if no active device is assigned Fix bad rv710 pci id Fix encoder accounting AVIVO: fix rotation AVIVO: better fix for rotation Add some missing r6xx/r7xx pci ids Bump for rc release Christiaan van Dijk (1): R3xx/R4xx: Maximize the use of clipped triangles for Xv rendering Dave Airlie (3): radeon: r500 PAL timings are slightly incorrect r500: re-enable TV out radeon: r500 tv-out force scaler values to nice set that looks correct Maciej Cencora (1): Make sure gb_num_pipes is initialized when DRI is disabled Michel Dänzer (3): Don't transform EXA Composite mask coordinates when there's no mask. Drop memcpy fallbacks from EXA UploadToScreen and DownloadFromScreen hooks. EXA: Accelerate Composite of RepeatPad/Reflect pictures when possible. Nicos Gollan (1): Fixed enumerations in radeon-output.c Thomas Jaeger (1): Fall back to software for unsupported repeat modes Tormod Volden (1): Add yet another AGP quirk for RV280 Wolke Liu (1): AVIVO: Save/restore vga pll registers airlied (1): rs780: include RS780 in the InitMemory to leave alone git tag: xf86-video-ati-6.10.99.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.10.99.0.tar.bz2 MD5: 4c32a782d0d43e81318347155104d78c xf86-video-ati-6.10.99.0.tar.bz2 SHA1: e6e1ab7acd27d6de501fed034d0fbc8a06677beb xf86-video-ati-6.10.99.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.10.99.0.tar.gz MD5: bc62be84ae411eea1a95d30c9a5baf9d xf86-video-ati-6.10.99.0.tar.gz SHA1: 15ad692cbfe6392d04d63372c3342a65913346c3 xf86-video-ati-6.10.99.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJkKLHm07k+YR03kARAkKYAKDMUDf92aw3BQHbEQ1kcEJumhWqzACgtFl2 2PTHrrEUOW35jFc1yYUnarc= =n9/W -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
'Twas brillig, and Eric Anholt at 08/02/09 12:00 did gyre and gimble: With trying to match depths so that you didn't end up with a depth 24 fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth 24 X visual, which angered other applications. But in fixing that, the pickFBconfigs code for minimal also could end up breaking GLX visuals if the same FBconfig was chosen for more than one X visual. We have no reason to not expose as many visuals as possible, but the old all mode didn't match any existing X visuals to GLX visuals, so normal GL apps didn't work at all. Instead, replace it with a simple combination of the two modes: Create GLX visuals by picking unique FBconfigs with as many features as possible for each X visual in order. Then, for all remaining FBconfigs that are appropriate for display, add a corresponding X and GLX visual. This gets all applications (even ones that aren't smart enough to do FBconfigs) get all the options to get the visual configuration they want. The only potential downside is that the composite ARGB visual is unique and gets a nearly full-featured GLX visual (except that the root visual might have taken the tastiest FBconfig), which means that a dumb compositing manager could waste resources. Write compositing managers using FBconfigs instead, please. Well after trying the last patch (the one nominated on the 16branch page) things did kinda break for me with compiz (and even Mr not a benchmark himself, glxgears!) Applying this patch gives me back compiz. I'd nominate this for 1.6 soon, just in case Keith has a merging fit and grabs the other one by itself. Thanks Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (libtrans)
I don't see any errors or problems there in my builds, but perhaps there's a difference between the Solaris Linux headers that causes this issue. I did have to move the X11/Xos_r.h to before that function to correct errors that I did hit in the Solaris builds, which I did in commit cca91ddaa... Are the socket structure defines not included by that point on Linux? (It seems to be compaining about struct sockaddr_un.) I've gone ahead and applied your revert patch, since Paolo's patch causes problems on my Solaris builds (it makes trans_mkdir static in Xtranssock.c, but it's used in Xtranslocal.c which is included before Xtranssock.c). -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Chris Ball wrote: http://tinderbox.x.org/builds/2009-02-07-0001/logs/libICE/#build In file included from /home/cjb/xorg-build/include/X11/Xtrans/transport.c:62, from icetrans.c:31: /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c: In function '_IceTransGetMyNetworkId': /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c:258: error: dereferencing pointer to incomplete type /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c:261: error: dereferencing pointer to incomplete type (Would people prefer that I send these to xorg-devel@ instead? They have a possibly useful function to readers of xorg@, as they signify when not to bother trying to build HEAD, but I'm fine with either one.) - Chris. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
'Twas brillig, and Colin Guthrie at 09/02/09 21:56 did gyre and gimble: 'Twas brillig, and Eric Anholt at 08/02/09 12:00 did gyre and gimble: With trying to match depths so that you didn't end up with a depth 24 fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth 24 X visual, which angered other applications. But in fixing that, the pickFBconfigs code for minimal also could end up breaking GLX visuals if the same FBconfig was chosen for more than one X visual. We have no reason to not expose as many visuals as possible, but the old all mode didn't match any existing X visuals to GLX visuals, so normal GL apps didn't work at all. Instead, replace it with a simple combination of the two modes: Create GLX visuals by picking unique FBconfigs with as many features as possible for each X visual in order. Then, for all remaining FBconfigs that are appropriate for display, add a corresponding X and GLX visual. This gets all applications (even ones that aren't smart enough to do FBconfigs) get all the options to get the visual configuration they want. The only potential downside is that the composite ARGB visual is unique and gets a nearly full-featured GLX visual (except that the root visual might have taken the tastiest FBconfig), which means that a dumb compositing manager could waste resources. Write compositing managers using FBconfigs instead, please. Well after trying the last patch (the one nominated on the 16branch page) things did kinda break for me with compiz (and even Mr not a benchmark himself, glxgears!) Applying this patch gives me back compiz. I'd nominate this for 1.6 soon, just in case Keith has a merging fit and grabs the other one by itself. While this could be a red herring, I can no longer get full screen video with Flash. It could be this or one of the other patches from the 16branch wiki page that did it I'll try and isolate the problem but I wont be able to do so very easily right now. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (libtrans)
Alan Coopersmith wrote: I don't see any errors or problems there in my builds, but perhaps there's a difference between the Solaris Linux headers that causes this issue. I did have to move the X11/Xos_r.h to before that function to correct errors that I did hit in the Solaris builds, which I did in commit cca91ddaa... Are the socket structure defines not included by that point on Linux? (It seems to be compaining about struct sockaddr_un.) I've gone ahead and applied your revert patch, since Paolo's patch causes problems on my Solaris builds (it makes trans_mkdir static in Xtranssock.c, but it's used in Xtranslocal.c which is included before Xtranssock.c). Can you post the Solaris log of build error please? Btw lots of pepole prefer to say Paolo instead of Paulo, does my name sound wrong or funny in other languages? :-) The problem in Linux is indeed deferencing sockaddr_un fields without definition of that structure. is_numeric() and trans_mkdir() are static functions, and believe it or not, declared as such in Xtransint.h, but then there are other static definitions in Xtransint.h... But those functions are used in Xtranssock.c and Xtransutil.c, and given that those two files are included from transport.c, and the functions are close to trivial, I am having trouble understanding why moving the function definitions to before they are first used would cause any error on Solaris, as with my patch, build goes fine in Linux, without warnings. libxtrans probably should consist of just transport.c and Xtransint.h, IMO, and add the proper #ifdef's around data/functions defined there. libxtrans currently is something way too fragile... Nevertheless, thanks for applying the patch, as now one can build everything again without needing to fix libxtrans first. Well, almost everything as there are still a lot of uncompilable packages, ironybut they are least interesting packages, like xf86-input-keyboard/irony. -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Chris Ball wrote: http://tinderbox.x.org/builds/2009-02-07-0001/logs/libICE/#build In file included from /home/cjb/xorg-build/include/X11/Xtrans/transport.c:62, from icetrans.c:31: /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c: In function '_IceTransGetMyNetworkId': /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c:258: error: dereferencing pointer to incomplete type /home/cjb/xorg-build/include/X11/Xtrans/Xtransutil.c:261: error: dereferencing pointer to incomplete type (Would people prefer that I send these to xorg-devel@ instead? They have a possibly useful function to readers of xorg@, as they signify when not to bother trying to build HEAD, but I'm fine with either one.) - Chris. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
