Re: TV Card + X11 = problem!?
On 08/22/2010 11:45 PM, Loukas Xanthos wrote: Hello World and please excuse my terrible English. As you can see here: https://bbs.archlinux.org/viewtopic.php?pid=812960 Users with a tv card (usb or PCI, with or without an IR receiver) have problems with X11. Some times the Shift key 'hangs' randomly and after a while it gets 'released'. Personally I've experienced this problem with Linux Ubuntu Desktop, Linux Ubuntu Server, Arch Linux, with different keyboards but only in X11 environment (not in any console). The Xorg log file doesn't contain any errors, neither the kernel ring buffer (dmesg). Does any one know anything about this problem? That is weird. I had this problem for a while, and I also have a TV card (analog). It never occurred to me that it might have something to do with the card. My TV card uses an SAA7130 chip. But I don't seem to suffer from this problem anymore. I'd say for a month or so now. Might have something to do with switching from kernel 2.6.34 to 2.6.35. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Transition from HAL to udev - mouse config
On 05/17/2010 11:05 PM, Simon Thum wrote: Am 14.05.2010 19:37, schrieb Dan Nicholson: On Thu, May 13, 2010 at 11:45 PM, Nikos Chantziarasrea...@arcor.de wrote: merge key=input.x11_options.FilterHalflife type=string5/merge merge key=input.x11_options.FilterChainProgression type=string2/merge merge key=input.x11_options.VelocityCoupling type=string0.15/merge merge key=input.x11_options.FilterChainLength type=string8/merge merge key=input.x11_options.Softening type=stringtrue/merge With X.Org server 1.8 and HAL disabled, how to I configure the above? In case you're referring to the exact settings, this is not possible. The filter chain approach was replaced in 1.8, but of course it doesn't hurt to keep the option values around. The coarser settings are unchanged however. Should your device really need such detailed tweaks, I'd like to hear about it. The new algorithm sohuld work reliably against a greater range of devices. It can be tweaked as well, the wiki page was updated accordingly. I've misplaced the link to the wiki entry, and I can't find the URL again :-/ I went to the wiki at http://www.x.org/wiki, and no matter what I search for (mouse tweaks, mouse, mouse settings, etc) it doesn't find anything. In the sense of teaching me to fish instead of just giving me one, how would one find the wiki entry for mouse tweaking in the first place? Last time I visited it (and bookmarked it) was because you gave me the URL in an email to me. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xv has color glitches with radeon driver
On 08/06/2010 01:57 PM, Thomas Lübking wrote: Am Friday 06 August 2010 schrieb Nikos Chantziaras: Does that mean that it could be a bug in KDE's compositor? .. The problem does never occur when compositing is active. ... Doesn't make much sense, yesno? :-) Now that I read it again, it was a bit confusing. I was thinking that the way the compositor unredirects fullscreen apps has a bug. However, I completely disabled compositing and restarted and the bug was there, so I guess it's not the compositor's fault. (It's rather likely that the indirect rendering works and the bug occurs on direct fb access through xv - tried other -vo sinks, eg. gl or x11?) Gl and x11 output work correctly. It's only Xv + direct rendering that triggers it. You could try by shutting down kwin (kquitapp kwin) and launching s (or rather maybe just) mplayer - then mplayer -fs some_movie.avi To restart kwin call kwin NOTICE: since w/o a WM you won't be able to pass the focus around, you might want to call all cmds in a row kquitapp kwin; mplayer - then mplayer -fs some_movie.avi; kwin do not attempt to fork mplayer to bg (won't show up then) If this (unexpectedly) works fine, you can try to suspend compositing (SHIFT+Alt+F12) before playing In both cases the bug shows. Really the only case where it doesn't is with compositing active (which means KWin must be running and desktop effects must be enabled.) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xv has color glitches with radeon driver
On 07/28/2010 01:10 AM, Nikos Chantziaras wrote: I'm not exactly sure when the problem first occurred, but it's been quite a while, definitely more than 6 months. Here's a screenshot of the problem: http://i25.tinypic.com/2vkxrh3.png This is with mplayer using Xv, on standard definition video in fullscreen. Note the gree, red and blue color bars at the bottom. They always appear, but naturally, they're most visible in dark scenes. It's not an mplayer bug it seems, since pausing the video and going out of fullscreen and then back makes them go away temporarily. Also, they never appear with AMD's binary fglrx driver or on non-radeon cards. The problem, as I mentioned already, is an old one. Right now, I'm at: Radeon HD4870 kernel 2.6.35_rc6 xf86-video-ati Git master Mesa Git master X server Git master I've made another observation (accidentally). The problem does never occur when compositing is active. KDE unredirects fullscreen applications by default (meaning that compositing gets disabled). However, if I disable that (for example by right clicking somewhere so that SMPlayer's or VLC's context menu appears, which also disables the unredirecting and re-activates compositing), then the colors are perfectly fine again. Does that mean that it could be a bug in KDE's compositor? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Xv has color glitches with radeon driver
I'm not exactly sure when the problem first occurred, but it's been quite a while, definitely more than 6 months. Here's a screenshot of the problem: http://i25.tinypic.com/2vkxrh3.png This is with mplayer using Xv, on standard definition video in fullscreen. Note the gree, red and blue color bars at the bottom. They always appear, but naturally, they're most visible in dark scenes. It's not an mplayer bug it seems, since pausing the video and going out of fullscreen and then back makes them go away temporarily. Also, they never appear with AMD's binary fglrx driver or on non-radeon cards. The problem, as I mentioned already, is an old one. Right now, I'm at: Radeon HD4870 kernel 2.6.35_rc6 xf86-video-ati Git master Mesa Git master X server Git master ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xv has color glitches with radeon driver
On 07/28/2010 01:46 AM, Alex Deucher wrote: On Tue, Jul 27, 2010 at 6:10 PM, Nikos Chantziarasrea...@arcor.de wrote: I'm not exactly sure when the problem first occurred, but it's been quite a while, definitely more than 6 months. Here's a screenshot of the problem: http://i25.tinypic.com/2vkxrh3.png Are you sure you uploaded the right image? I don't see any bars in that image, I'm pretty sure I don't have superhuman vision :-P They're there, I can see them quite clearly. Maybe your monitor is too dark or too low contrast? This is with mplayer using Xv, on standard definition video in fullscreen. Note the gree, red and blue color bars at the bottom. They always appear, but naturally, they're most visible in dark scenes. It's not an mplayer bug it seems, since pausing the video and going out of fullscreen and then back makes them go away temporarily. Also, they never appear with AMD's binary fglrx driver or on non-radeon cards. The problem, as I mentioned already, is an old one. Right now, I'm at: Radeon HD4870 kernel 2.6.35_rc6 xf86-video-ati Git master Mesa Git master X server Git master Does it happen with any other movie players (totem, vlc, etc.)? Didn't try totem, but it happens with VLC too. If it is a driver bug, can you bisect xf86-video-ati to see when the problem was introduced? I don't know which version introduced this; I guess I'll have to start trying them all. One thing I didn't mention is that the problem only appears when the video is being scaled. Watching in windowed mode (1:1 ratio) never triggers it. Only when zooming or going full-screen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xv has color glitches with radeon driver
On 07/28/2010 03:43 AM, Pat Kane wrote: I'm pretty sure I don't have superhuman vision :-P They're there, I can see them quite clearly. Maybe your monitor is too dark or too low contrast? On my display I might be able to see the artifacts that you mention, but it is hard to tell since I do not know what the correct image should be. There are 3 very subtle horizontal bands near the bottom of the image that might be part of the background or maybe not... OK, hope this one is clearer: http://i28.tinypic.com/2up36f9.png There's a blue bar to the left and some not-so-easy to spot green ones to the right. And yet another thing I didn't mention: they always appear at the bottom-half of the picture, never in the upper-half. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xv has color glitches with radeon driver
On 07/28/2010 03:56 AM, Nikos Chantziaras wrote: [...] OK, hope this one is clearer: http://i28.tinypic.com/2up36f9.png There's a blue bar to the left and some not-so-easy to spot green ones to the right. I hope I'm not spamming you guys too much with this :P I think there are specific color combinations/patterns that trigger this. In case this might help in figuring out the cause, here another screen: http://i27.tinypic.com/2d9xoas.png Note how the three glitches (two at top, one at bottom) are perfectly aligned with where the red color starts and the yellow ends. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Transition from HAL to udev - mouse config
I had the following HAL configuration for my mouse in X.Org server 1.7 for a 500DPI mouse: match key=info.capabilities contains=input.mouse merge key=input.x11_options.AccelerationProfile type=string2/merge merge key=input.x11_options.AdaptiveDeceleration type=string2/merge merge key=input.x11_options.ExpectedRate type=string500/merge merge key=input.x11_options.FilterHalflife type=string5/merge merge key=input.x11_options.FilterChainProgression type=string2/merge merge key=input.x11_options.VelocityCoupling type=string0.15/merge merge key=input.x11_options.FilterChainLength type=string8/merge merge key=input.x11_options.Softening type=stringtrue/merge With X.Org server 1.8 and HAL disabled, how to I configure the above? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel, h264 and XvMC
On 04/04/2010 06:30 AM, Yan Seiner wrote: I'm trying to understand if Intel XvMC can be used with h264 material. If not, is there any way to use Intel hardware acceleration with h264 source? VA-API does h264 bitstream decoding on the GPU, not XvMC. XvMC is only for motion compensation (which is what MC stands for.) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: a question about energy
On 03/01/2010 11:06 AM, Zhi Li wrote: All, I'm working in a project which study energy saving on PCs. I saw a strange thing which was opposite to my intuition: when PC working on graphic mode, it would be more energy saving. When in graphic mode, on my PC, it is 52w; when I switched to terminal mode(on linux alt-ctrl-1), it is 55w. I also tried to init 3, then startx, the result is same. Does anyone here know why? The X11 driver will usually reduce the clocks of your GPU (and possibly the voltages; depends on the driver you're using) when it's idle. When you switch to a TTY, the clocks/voltages are increased again since the framebuffer driver doesn't do power management. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow 2D with radeon KMS
On 01/30/2010 04:35 PM, Damien Mir wrote: Hi, I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. Used latest 2.6.33rc5 kernel + drm modules from : http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_11.2/x86_64/ http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/x86_64/ Relevant xorg.log : http://88.191.15.45/RVRV/Xorg.0.log.kms Is this normal due to early state of development, or am I missing something? It's normal. Radeon KMS is still experimental even in 2.6.33rc kernels. At least the R600/R700 part of it, not sure about R500 and below. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is it normal that X consumes 800 MB RAM?
On 12/17/2009 10:54 PM, dolphinling wrote: On 12/14/2009 04:44 PM, Nikos Chantziaras wrote: The longer the system runs, the more RAM X eats. After about 5 hours of uptime, I get this: http://i49.tinypic.com/wqu61j.png That's about 800MB memory usage. It gets worse as time passes. Is this normal? This looks like some memory leak to me. Does the graphics driver play a role here? I'm using AMD's binary blob for ATI cards (the radeon driver doesn't support my card.) Anything else that might be going on? This is on a Gentoo AMD64 system with X server 1.6.5, AMD Catalyst 9.11 drivers and kernel 2.6.31.6. DE is KDE 4.3.4 (in case it matters.) Typically high memory usage of X is caused by other programs asking X to store things for them. You can use the xrestop program to see how much is being used for each program. This problem may be because some other program is never telling X that it's done with resources. xrestop should be able to tell you which program it is. Of course theoretically it's possible there's a leak in one of the X components (especially the binary graphics driver), but this is far more common. This seemed to be the result of using a KDE 4.3 built against Qt 4.6 (this is not officially supported by KDE). I've since downgraded to Qt 4.5 and rebuilt KDE. This seems to have fixed the issue (mostly). X still uses more and more memory as uptime goes up, but not as dramatic as reaching 800MB after 5 hours. At boot-up, X starts with about 60MB of memory usage. Right now, after about 3 hours, it's at 170MB and slightly increasing with time. xrestop doesn't show anything interesting: adding up all the Total values reported only amounts to about 20MB or memory. Where the missing 90MB are spent, I've no idea. But in any case, we're now talking about 90MB unaccounted for instead of 700MB previously. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Is it normal that X consumes 800 MB RAM?
The longer the system runs, the more RAM X eats. After about 5 hours of uptime, I get this: http://i49.tinypic.com/wqu61j.png That's about 800MB memory usage. It gets worse as time passes. Is this normal? This looks like some memory leak to me. Does the graphics driver play a role here? I'm using AMD's binary blob for ATI cards (the radeon driver doesn't support my card.) Anything else that might be going on? This is on a Gentoo AMD64 system with X server 1.6.5, AMD Catalyst 9.11 drivers and kernel 2.6.31.6. DE is KDE 4.3.4 (in case it matters.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to test GLX performance?
Alan James Caruana wrote: Hi, I am writing an X Server for the company I work for, and I have implemented the GLX extension. I know that it works because 'glxinfo' gives output, 'glxgears' works, and some sample GLX programs I downloaded also do work, but now I want to test for performance. What programs/methods exist to test the performance of the GLX ? Try the Phoronix Test Suite. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: compiling 32bit libraries on x86-64 system
Dirk Hohndel wrote: I must be missing some 'configure' magic here... For some modules (like the X server) it's rather straight forward to build 32bit on a 64bit system. Something like LDFLAGS=-L/opt/X11R7-32/lib ./configure --prefix=/opt/X11R7-32 --enable-32-bit --build=x86-linux Actually you don't need to do anything else than just add -m32 to CFLAGS/CXXFLAGS/LDFLAGS. GCC will automatically pick 32-bit libs and produce 32-bit binaries. You don't need -L or --build. At least that's how it works here. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon supported resolutions?
Felix Miata wrote: On 2008/12/27 23:07 (GMT+0200) Nikos Chantziaras composed: Felix Miata wrote: I have DVI cards and displays and cables, but have never found reason to try them. Better picture quality. Many people can't make out a difference though. Exactly. How does any normal person find an opportunity to see any difference? Most of the internet is extreme lowfi designed for 1024x768 or below. It's only visible to me in extreme cases, like a red box on white background; there's a bit of red running in the black (I think that's called ghosting) or the default X background (this one always made my eyes cry with my old CRT). Nothing serious though. But since my monitor *is* digital (TFT) and my graphics card is also digital, it makes more sense to use DVI-D. With VGA, the graphics card converts its digital signal to an analog VGA signal and sends it over the cable. The monitor picks it up, and since it's a TFT monitor (they need a digital signal to display) it converts the analog signal back to a digital one. With DVI-D, the signal is just sent though the cable with no conversions and cable quality doesn't matter the least since it's digital. It makes more sense to me to use it that way rather than doing a totally useless and unneeded conversion from digital to analog and then back again. If you don't have a TFT monitor but a CRT instead, then this in not an issue at all. CRTs are analog (there's a few modern digital CRTs too, but you would know if you had one). It's only an issue with TFTs. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel graphics benchmarked by Phoronix
Devin Heitmueller wrote: On Tue, Dec 23, 2008 at 11:22 AM, Nikos Chantziaras rea...@arcor.de wrote: http://www.phoronix.com/scan.php?page=articleitem=intel_graphics_q408num=1 That test is wrong. You don't compare different drivers on different distros. You compare them on the same distro. Now I get to say that it's not the driver that is slower, but it's the newer Ubuntu version that slows it down. They should learn to benchmark :P And they should learn to also name the benchmarks appropriately (that it compares performance of two Ubuntu versions rather than Intel driver versions.) [...] Is it the Xorg team's perspective that, we'll only look into huge performance regressions if you first do all the work to prove that the huge slowdown cannot be anything but the Xorg stack? I'm not trying to be confrontational, but I think burying your head in the sand until you are given 100% proof that it's the Intel driver may not be the best approach here. Well, it's certainly possible that the driver became that much slower. But doing the benchmark right would be so easy, yet Phoronix didn't do it. All I need to do here, is simply remove the old driver and install the new one and re-run the benchmark. Everything else stays the same. Dead easy. Yet Phoronix didn't do it. Hopefully someone here with an Intel GPU can do it better. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Reduce/Eliminate Horizontal Tearing
Ross Vandegrift wrote: On Fri, Dec 12, 2008 at 12:00:17AM +0200, Nikos Chantziaras wrote: Markus Strobl wrote: That's not my experience. I've tested most of the possible combinations: Intel, ATI+fglrx, ATI+Radeon and closed-source NVidia. Only Intel has the tearing issue. All the others play video, including HD-Video, perfectly. BTW, my MediaPC has a cheap dual core Intel Core 2 @1.8 GHz and a $30 NVidia graphics card. It has no problems playing H.264 720p. The above is using XV, I don't use the OpenGL overlay as it had some issues. ATI does not. Only NVidia plays without tearing with Xv. mga does. Just watched a few hours of shows on an mga G-series and mplayer, tearing doesn't exist. Oops, sorry, you're right. These days we tend to think that there's only ATI, NVidia and a bit of Intel out there :) I also never had tearing my old Matrox. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Reduce/Eliminate Horizontal Tearing
Markus Strobl wrote: That's not my experience. I've tested most of the possible combinations: Intel, ATI+fglrx, ATI+Radeon and closed-source NVidia. Only Intel has the tearing issue. All the others play video, including HD-Video, perfectly. BTW, my MediaPC has a cheap dual core Intel Core 2 @1.8 GHz and a $30 NVidia graphics card. It has no problems playing H.264 720p. The above is using XV, I don't use the OpenGL overlay as it had some issues. ATI does not. Only NVidia plays without tearing with Xv. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Reduce/Eliminate Horizontal Tearing
Nick Nobody wrote: Hello, I'm using Ubuntu 8.10 with a GM945 (at 1920x1080) for my media center PC. The problem I'm running into is a bunch of horizontal tearing on higher resolution videos (720p or greater). From what I can tell it's not a CPU limitation but rather something related to the graphics card... Are there any options that I can enable in my xorg.conf to help reduce/eliminate this tearing? Or is this simply a hardware limitation? Can XvMC somehow help me here? I don't think it's possible to have video without tearing in X.Org with xv. You'll have to use a media player that can render in OpenGL and enable VSync. At least, that's how I was able to get acceptable video without tearing. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Reduce/Eliminate Horizontal Tearing
Nick Nobody wrote: That would be just a temporary solution with too many problems (since I assume a real solution will be in DRI2?) The OpenGL method with VSync works quite well. Can you recommend a media player that is able to use OpenGL? I've tried mplayer but even on a relatively fast cpu it can't playback the video fast enough (720p content). Unless I'm missing some magic switch that's buried deep within the man page :) I'm afraid there's no magic switch :P You can give VLC a shot but it never worked for me. Unfortunately, HD video and Linux still don't play along well. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: conflicting memory types in system logs
Halim Issa wrote: Hello, On X.Org X Server 1.5.3 with the Intel 2.5.1 driver on a Lenovo X200 laptop, I get quite a few error messages output in /var/log/messages where the kernel complains about conflicting memory types. Is this just warnings, or something to be taken seriously? If the latter, is it due to a config error on my part, or a version mismatch or bug somewhere? System information included at bottom. Thanks in advance for any insight. X:3052 conflicting memory types d000-e000 write-combining-uncached- minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:3052 conflicting memory types d000-e000 write-combining-uncached- minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:3058 freeing invalid memtype d000-e000 X:3052 conflicting memory types d000-e000 write-combining-uncached- minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:3059 freeing invalid memtype d000-e000 X:3052 conflicting memory types d000-e000 write-combining-uncached- minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:3060 freeing invalid memtype d000-e000 X:3052 conflicting memory types d000-e000 write-combining-uncached- minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:3061 freeing invalid memtype d000-e000 Some system information: X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Slackware 12.1 Slackware Linux Project Current Operating System: Linux asterix 2.6.27.6 #4 SMP Thu Nov 20 11:06:31 CET 2008 i686 Build Date: 14 November 2008 10:28:10AM (II) Module intel: vendor=X.Org Foundation compiled for 1.5.3, module version = 2.5.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset (--) intel(0): Chipset: Mobile Intel® GM45 Express Chipset (--) intel(0): Linear framebuffer at 0xD000 (--) intel(0): IO registers at addr 0xF200 (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB libpciaccess version 0.10.5 I get the same. I'm on 1.5.3 but with the xf86-video-radeonhd driver. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Cannot build libxcb from git
Trying to build git master of libxcb, I get this: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -Wall -pedantic -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wnested-externs -march=core2 -O2 -fomit-frame-pointer -pipe -MT xcb_out.lo -MD -MP -MF .deps/xcb_out.Tpo -c xcb_out.c -fPIC -DPIC -o .libs/xcb_out.o xcb_out.c: In function ‘get_socket_back’: xcb_out.c:61: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:61: error: ‘_xcb_out’ has no member named ‘socket_moving’ xcb_out.c:62: error: ‘_xcb_out’ has no member named ‘socket_cond’ xcb_out.c:63: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:66: error: ‘_xcb_out’ has no member named ‘socket_moving’ xcb_out.c:68: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:68: error: ‘_xcb_out’ has no member named ‘socket_closure’ xcb_out.c:70: error: ‘_xcb_out’ has no member named ‘socket_moving’ xcb_out.c:72: error: ‘_xcb_out’ has no member named ‘socket_cond’ xcb_out.c:73: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:74: error: ‘_xcb_out’ has no member named ‘socket_closure’ xcb_out.c: In function ‘xcb_take_socket’: xcb_out.c:270: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:271: error: ‘_xcb_out’ has no member named ‘socket_closure’ xcb_out.c: In function ‘_xcb_out_init’: xcb_out.c:308: error: ‘_xcb_out’ has no member named ‘socket_cond’ xcb_out.c:310: error: ‘_xcb_out’ has no member named ‘return_socket’ xcb_out.c:311: error: ‘_xcb_out’ has no member named ‘socket_closure’ xcb_out.c:312: error: ‘_xcb_out’ has no member named ‘socket_moving’ make[2]: *** [xcb_out.lo] Error 1 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
