Re: The PCI device 0x10de087d (ION) at 02@00:00:0 has a kernel module claiming it.
On Wed, Nov 23, 2011 at 4:48 AM, Anatolii Ivashyna t...@aurora.com.ua wrote: Thanks for reply, as you told there is nouveau driver block my driver. Is this possible to unload it? All the best, Anatolii Ivashyna Is it not possible to just use the nouveau driver instead of nv? nv is pretty much unmaintained at this point, but nouveau is supported by the nouveau team, and more importantly, your distro apparently supports nouveau too. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Help: XF86DGAGetVideo:failed to map video memory. I used libXxf86dga-1.1.1 on Ubuntu 10.04 on intel GMA 4500MHD(Intel GM45 chipset)
On Mon, Oct 10, 2011 at 6:12 PM, Focus.Luo luoyanq...@sjtu.org wrote: Hi all, 1, Does the intel GM45 chipset support DGA(direct graphic access)? 2, If it supports, why I used the function XF86DGAGetVideo(dis, DefaultScreen(dis), addr, width, bank, ram); and It returen XF86DGAGetVideo:failed to map video memory. But I used the function XF86DGAQueryDirectVideo, It work well. Does somebody can help me? thanks, DGA(direct graphic access) Lib: libXxf86dga-1.1.1 Xserver: xorg Graphic Driver: intel_drv.so 2.9.1 OS: Ubuntu 10.04 Gpaphic: intel GMA 4500MHD(Intel GM45 chipset) Hi, DGA 1, with all of the direct video access, is dead in the core server. (Blessedly.) The DGA 2 mouse stuff lives on, though. Is this for a new application, or are you maintaining legacy code? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Building NV driver from git
On Sun, Oct 9, 2011 at 3:07 PM, Harry Putnam rea...@newsguy.com wrote: Running Debian wheezy After cloning the git repo for: git://anongit.freedesktop.org/xorg/driver/xf86-video-nv I got a slug of errors when running ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:33: error: must install xorg-macros 1.8 or later before running autoconf/autogen configure.ac:33: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: /usr/bin/autom4te failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 So is it just the macros I must have? And where are they obtained If you don't mind me asking, why are you using nv? Debian offers nouveau. Also, is there a problem with Debian's nv or nouveau? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: X Window system on Handheld devices
Responding inline. On Jul 17, 2011 9:38 AM, David Jackson djackson...@gmail.com wrote: You are making assumptions, that no company will ever produce a hardware device that has a monochrome screen. Yet, a monochrome screen would be suitable for ereader devices such as a kindle. No such assumption was made; Xorg still supports low color depths. As for code, memory today is cheap. I've looked closely at X memory useage and it seems from what i can see anyway that X server code consumes less than 10 MB, with all of the compability infrastructure. Maintaining code for compatability and backwards compatability has value greater than saving some kilobytes or a megabyte in the age of hundreds or thousands of megabytes. Yes, we know. Only a few of us have been pursuing lower memory footprints... If a handheld device manufacturer has very limited memory to work with, maybe they could do their own custom compile X, if necessary, without some sections of code. But I am doubtful that will often be the case that this is necessary. But, for a desktop system today, it simply does not make sense whatsoever, the backwards compatability with older X applications is far more valuable. ...and those guys work for Nokia. Nokia, of course, is the cell phone manufacturer which put Xorg on some of their phones. Ive been using X since the days of 90 MB of RAM. X memory usage has never been a big issue, the idea that X, including code for backwards compatability, uses a lot of RAM is an old lie that refuses to die. Blowing up baclwards compatability to save a megabyte or 2 of RAM makes no sense whatsoever. We aren't claiming this at all. On Sun, Jul 17, 2011 at 2:33 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 07/16/11 06:43 PM, David Jackson wrote: Has the X.org organisation ever thought of promoting X.org for use by companies on thier handheld devices such as phones? You mean like back in the days when Jim Gettys was one of the leaders of handhelds.org and doing research at the Compaq/HP labs on the iPaq? Yes, I think there might have been a bit of thinking, especially when they hosted the X.org Developers Conference there - as hard as it is for some people to believe we ever do any thinking here. Or perhaps you mean the last couple of years, when Nokia's (now Intel's) Meego developers have been one of the major contributors to X.Org. Years ago, in their infinite wisdom, X.org developers removed monochrome support and low colour support, Nope, sadly, both are still there, though I think the mobile developers like those on the Meego project wish we'd dump more code like that which just bloats their embedded systems, since no one wants to browse the web or play Angry Birds on 1, 4, or 8 bit screens. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: mostawesomed...@gmail.com ___ 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: X Window system on Handheld devices
Feel free to ask the Android Linux teams why they didn't feel Xorg was a good fit for their distributions. The answers might surprise you. Sending from a mobile, pardon my terseness. ~ C. On Jul 16, 2011 6:43 PM, David Jackson djackson...@gmail.com wrote: Has the X.org organisation ever thought of promoting X.org for use by companies on thier handheld devices such as phones? X has really missed the boat on this one. Years ago, in their infinite wisdom, X.org developers removed monochrome support and low colour support, things that would have been perfect for many handheld devices such as kindles. There is really no good reason why X cannot be used on handheld devices and it woule encourage more use of a standardized platform like X rather than yet more proprietary systems. Another issue with possible use of X by other companies is the need to provide a device driver facility that supports backwards compatability, that a device driver will continue to work on newer X servers, without being recompiled. That would go for all drivers for all parts of an OS. One thing corporations do not want to do is have to distribute 40 different versions of a device driver and end up with a huge mess where device drivers packaged with older devices no longer work. In relation to Linux and X, the only way to get these systems to be useable for most people is to have hardware companies provide drivers for it, since they can do all of the testing to make sure the driver works well with the hardware. This is the only way to get timely hardware support. Average people dont want to use Linux because of how shoddy the hardware support is. If its anything slightly unusual, it wont work. Some corporations may want to distribute binary drivers, thats just a necessary evil to help get an open source OS more widely used, and as well, eventually open source replacements would still get developed anyway. In fact binary drivers from companies would make Linux more useable to more people, so we would see in increase in user use of Linux, and more opportunities for open source companies to be able to fund open source driver development. Ive been watching Linux for over 10 years and I have seen virtually no progress on the desktop. The big reason it still is not useable is the hardware problems. And the attitude of the Linux community as a whole is the cause of that, the reason why so few people use Linux today, I have to recommend people who want to use Linux to not use it and stay with Windows, because I know what a hassle it is, it really is still hard thing to use because it does not work right with so much hardware out there. And thats due to the attitude of Linux developers who have a knee jerk reaction against 3rd party drivers, when 3rd party drivers could make Linux useable to far more people and actually increase potential to fund Linux development. Both Linux kernel itself and X.org, if they were really serious about making Linux practical to common users, would make it easier for third party drivers to be developed, including better documentation of the APIs so a company does not need to spend a year trying to understand it. ___ 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: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? Sending from a mobile, pardon my terseness. ~ C. On Jun 27, 2011 4:01 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) -- ___ 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: mostawesomed...@gmail.com ___ 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: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
On Mon, Jun 6, 2011 at 2:10 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: However I'm not a computer scientist and the only way that makes sense for me to implement this is lots of inefficient loops to check every penguin against every other penguin. That's a beginners game writing question not surprisingly. Games often solve this in simple form by keeping all their sprites (penguins in your case) in a sorted list (eg top to bottom, left to right). You still have to do a bit of scanning as obviously the top of one penguin can land on the feet of another, but you can do a lot less scanning that way. Indeed, this is a classic question in games: How does one efficiently and quickly search for spatial collisions? Alan's answer is great for your case. If you're feeling adventurous, you could create a spatial dictionary -- an associative array which stores all of the penguins by coordinates, using buckets which correspond to spatial areas. This massively reduces collision checking time for one-against-many, especially when you have lots of sprites to check. It might be overkill here, unless you're planning on making thousands of penguins. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: programming WM problems
Hi, Why are you writing a new WM? ~ C. On Wed, Jun 1, 2011 at 11:36 AM, pauline martin 321enil...@gmail.com wrote: Hi, I am trying to create a window manager that uses xcb and as few other dependencies as possible. I do know that I could use toolkits but I want it to be as independent of other projects as possible. The only dependency I really want included is the X-server and libraries to interact with it, like xcb. I do not intend to include any icon-capabilities at the moment, just barely enough so that panels (like tint2 and fbpanel) can get the names of the windows. I consider it to be in pre-alpha development, I hope to make it is standards compliant as possible and to include virtual desktops. However, my primary concern at the moment is getting it to retrieve and hand off the names of the windows to the panels. I have looked at the examples and tutorials available on the x.org site. Also, I have read over the deprecated xcbwm code, I am still confused on how to implement this feature best. I have also attempted reading through the only window manager's code in C (the language I am using) that uses xcb (the window manager awesome) but I can not get it to work. You can find the last working source on sourceforge at: sourceforge.net/projects/xlitewm/. Thank you for all your help. :) Pauline123 ___ 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: mostawesomed...@gmail.com -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Ideas for X improvement.
/me trudges through the rest On Wed, May 25, 2011 at 12:53 PM, David Jackson djackson...@gmail.com wrote: Backwards compatability is always a must. It has become clear that X graphics primatives today are outgrown today by some applications today which have intense graphics needs. Current X protocol must continue to be supported however new mechanisms can always be offered. The solution to this that provides the most flexibility for users is for the X Window System to provide more advanced and more diversity of vector graphics rendering facility over the X protocol, and that is already being done to an extent with GLX. The X Window System xlib, xcb, glx libraries and so on provide access to these features. The reason for this is that it applications should be encouraged to offload as much graphics operations and processing to the X provided library APIs as possible and do as little of that as possible in the applications own code or in 3rd party toolkits. It should be recommended that applications avoid in application and 3rd party toolkits rasterisation and rendering as much as they can. This means that more data is being sent as higher level vectors which use less bandwidth over the wire rather than the application sending bitmaps it has created in application code and 3rd party driver code. That increases flexibility when display an application remotely and locally, and also allows as much vector and 3D graphics processing to be done by the video card as possible. Another feature that can speed up and increase flexibility of displaying locally or remotely is allowing the application to upload a frequently used bitmap once and storing it in the server, adn referring to it later on with a token. The application can delete the bitmap when no longer needed, and if the user sets a limit to X server memory usage, the X server could delete long unused bitmaps and ask for the bitmap again if the application uses the token for it. The user could also completely disable this in which the server will ask for the bitmap (or just the damaged region) with each redraw. This concept could also be used for vector graphics as well or any other data the client sends to the server. By avoiding placing low level graphics rasterisations in applications own code or 3rd party libraries and having apps use X window system provided libraries for that whenever possible, it makes it more flexible to use applications over different mediums and display targets. It works well for both local desktop display and remote display. Hey, cool, sounds like you discovered Xrender and Xft. Yay! We already know why Xrender's far more awesome than core rendering. Nobody's disputing that, and our current plan *is* to keep core rendering for protocol compatibility while encouraging application developers to use toolkits which offload rendering and use modern rendering techniques. You also seem to have guessed that backing store is no longer used by the server. Or I think that's what you said; that's a really big wall of text to dig through. the above plan preserves the ability to do both network transparent display, direct rendering, and also preserves the ability to do rasterisation in the server, in the application, or in the hardware. This is due to the fact that applications should use Xlib, XCB, and GLX libraries API for rendering provided by the X Window System. The Xlib libraries can then according to a users runtime selection, send graphics it recieves over X protocol to a remote X server, or do direct rendering one of two ways: rasterise the graphics in application into bitmaps to send directly to video hardware, or send the vector graohics commands directly to video hardware. The applications still have an X socket connection to the server in the case of direct rendering, the server can still coordinate things. The rasterisation in the X server as well can either utilise its own rasterisation facilities in server or send the vector commands to video hardware to be rasterised there. and quite a bit of that is done already with GLX. Alpha transparency, blurring and antialiasing are common features needed by many apps, and an application needs these as well as complex vector graphics provided by further expanded GLX capabilities. The user can then select at runtime the target the aplication should display to, with the -display flag to select their X server. if the X server supports direct rendering, it will notify the X client of this over the X connection, then the graphics API calls from the application to xlib can be sent directly to video hardware. The X server can manage and coordinate. Both remote X socket apps and direct rendered apps could co-exist on the display. Yes, this all already exists in the current, modern X11 desktop. Which part of this isn't already done by Compiz? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin
Re: Mirror Driver
I don't know what you mean by mirror driver, but you could always use VNC. x11vnc is the thing that springs to mind for this particular scenario. ~ C. On Mon, May 9, 2011 at 3:13 AM, ankur jain samy...@gmail.com wrote: Hi all, I wish to project the display of local machine onto the screen of remote machine through network. I wanted to know how good it would be to use mirror driver to achieve the same? Thanks and Regards, Ankur ___ 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: mostawesomed...@gmail.com -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Is there a defined xpixmap width limit?
On Fri, Apr 22, 2011 at 8:44 AM, Emmanuel Thomas-Maurin manutm...@gmail.com wrote: On 04/22/2011 04:48 PM, Michael Stapelberg wrote: Hi Emmanuel, Excerpts from Emmanuel Thomas-Maurin's message of 2011-04-22 14:31:04 +0200: I've been searching for this for a while: Is there a width and height limit for xpixmaps? I'm using GTK and I know GDK pixmaps and windows can't be wider than 65535. And I suspect for X, it's 32767. As the width/height fields in the CreatePixmap request are CARD16s, the highest value is (2^16)-1 = 65535. This is documented in the X protocol, see http://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.pdf (page 56 in the pdf). Best regards, Michael Thanks Michael, that's what I was looking for. Maybe the results I got from the test come from some specific implementation that's not 100 % fully compliant with the protocol but that's really not that important anyways. IIRC there is a sign bug in the wire protocol which halves the actual limit. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: [Bug 34004] New Account Request
On Thu, Feb 10, 2011 at 8:12 AM, Luc Verhaegen l...@skynet.be wrote: On Thu, Feb 10, 2011 at 07:25:21AM -0800, Alan Coopersmith wrote: On 02/10/11 07:07 AM, Luc Verhaegen wrote: It seems that a useful and representative X.org board is needed, and that their primary responsibility should be the funding and maintenance of dependable infrastructure for the free software projects on both x.org and fd.o. Hey, what do you know, there are elections coming up. Elections in which it was difficult to find enough people willing to put in the time and deal with crap like this to fill a full slate of candidates for the available seats. (The initial deadline was extended when there were only two candidates for 4 seats.) I don't see the X.Org board trying to stage a coup and take over freedesktop.org though, no matter who gets elected. There's a separate organization for that, and we don't have the legal right to take their property away no matter what we think about how they're managing it. So it is better to leave this current situation as is, and have a major part of the infrastructure that X.org and others depend on what i honestly cannot describe as a organization? Well, after the outage a few years ago, we jokingly talked about moving fd.o's stuff down to Corvallis, OR, where the Open Source Lab could keep a closer eye on the machines. The ultimate reason for not going down that route was that Portland was a better place as far as having people who were actually involved with FreeDesktop nearby in case of emergency. This is starting to sound like the kind of thing that should definitely involve the rest of the fd.o members. If you have serious concerns about the quality of hosting that fd.o's property is receiving, then not just X.org, but all fd.o members need to be in this discussion. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: how can one build X without libxcb, or libxcb without python, or python without tcl/tk, or tcl/tk without X ?
I know I'm biased, but Python is generally available on systems. RPM-based systems and Gentoo require it, and most other distros need it in their base layout. (Slack might be the exception here.) I'm deeply sorry that you don't like Python, but it's not a dependency anybody feels like working around. Sending from a mobile, pardon the brevity. ~ C. On Feb 7, 2011 7:31 AM, matti christensen mat...@iki.fi wrote: yes - well i am afraid and don't like snakes. i downloaded libX 1.3.2 i really hope you get rid of such dependency to something that may or may not be in one's system = keep to basics /mc Quoting Peter Harris phar...@opentext.com: On 2011-02-05 15:55, matti christensen wrote: - it appears to me that i'm not able to compile libxcb 1.7 without Python ( which i do not need or want on my system ) You only need Python to compile; you do not need it to run libxcb. Feel free to remove python when you are done, or cross-compile from another system. Peter Harris -- Open Text Connectivity Solutions Group Peter Harris http://connectivity.opentext.com/ Research and Development Phone: +1 905 762 6001 phar...@opentext.com Toll Free: 1 877 359 4866 ___ 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: mat...@iki.fi keep-IT-simple ___ 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: mostawesomed...@gmail.com ___ 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: how can one build X without libxcb, or libxcb without python, or python without tcl/tk, or tcl/tk without X ?
You appear to be roughing it for some reason. Since the normal pieces of advice aren't things you want to hear, maybe this will help: You can disable Tk support when building Python. You can also exclude XCB by building an Xlib from the 1.3 series instead of 1.4. Sending from a mobile, pardon the brevity. ~ C. On Feb 5, 2011 1:52 PM, matti christensen mat...@iki.fi wrote: i'm new with this list but compiled X on Linux from Linux kernel 1.2.13 - and now i have my first real problem as i downloaded source from http://www.x.org/releases/X11R7.6/src/everything/ = - it seems to me that i'm unable to compile libX 1.4.0 without libxcb - that's perfectly ok for me, but do i need libxcb is unclear ( i have SiS 315PRO on Lemote Fuloong 2F ) - it appears to me that i'm not able to compile libxcb 1.7 without Python ( which i do not need or want on my system ) - it also looked lot like impossible to build Python 2.7.1 without TCL/TK ( which i do not need or want on my system ) - as tried to compile TK 8.5.9 i bumbed to errors telling me i ought to have X on my system would some nice person be kind enough to give me some feedback and comments on this ( using some package management system is no answer as i have no and am not going to install any ) matti christensen keep-IT-simple ___ 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: mostawesomed...@gmail.com ___ 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: Documentation
On Mon, Jan 3, 2011 at 9:28 AM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: Nima Sahraneshin unix.n...@gmail.com writes: Hi I want to write a program based on X .I need some documentation about X (using X) . Assuming that you want to make an ordinary application that is going to run under X, you really want to use a toolkit. These days, Qt (http://qt.nokia.com/) and Gtk (http://www.gtk.org/) are probably the best alternatives. They are much easier to work with than coding directly for X, and they do a lot of things for you that is otherwise a royal pain to get right. they both have serious shortcomings, and bugs, which make target application either non-functional after routine API changes (nokia) or bloated, buggy and slow (gtk). coding either directly for X or using lighter toolkits (i.e. fltk) has some point, and saves royal withdrawal after royal painkillers. Are you *seriously* recommending that people code raw Xlib? I can understand if you yourself are a masochist, but please, don't make other people suffer just because you have bad taste. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Xorg video driver for SGX535
I've actually wanted to do this, since I haven't been tainted. I was going to ask Xorg for hardware, but given my track record, I think it'd be better if I bought it myself. Sending from a mobile, pardon the brevity. ~ C. On Nov 11, 2010 4:04 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Thu, 11 Nov 2010 16:36:59 +0530 vijay singh testmrs@gmail.com wrote: Hello, is thei... I believe vendors can purchase a proprietary (ie non-free in both senses) license and access from the device vendor. Otherwise you are pretty much out of luck. There is enough info the public domain to probably write an acceptable 2D driver, maybe even to do a compositing 2D driver by staring hard at the kernel bits that have been released (because they had to GPL them), but not enough for 3D. Alan ___ xorg@lists.freedesktop.org: X.Org support Archives... ___ 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: Xorg Problem with Intel DH55HC on board VGA
Are you using KMS? Have you considered a more modern kernel or Xorg? Sending from a mobile, pardon the brevity. ~ C. On Oct 20, 2010 8:56 AM, Mark Mark mark...@hotmail.com wrote: Hello Everyone I am working on Xwindow-7.2.0 , on a LFS system (lfs6.6- blfs-6.3), on a X86_64 bit machine, DH55HC Intel motherboard , with onboard VGA. When trying to start Xorg, or to test the configuration the screen hangs up, and no response from the PC, even (ALT+CTRL+Bkspce) is not working. I installed the intel driver , and choose the intel as driver in xorg.conf , but same .. I also used a new kernel : linux-kernel-2.6.34.2 . But same problem , try to install the intel driver , but nothing changed. Also I tried to use the vesa driver. Note that : - when I tried the same LFS on a virtual machine and it works succesfully even before the new kernel, which means is a hardware or driver problem . - Another X window system (fedora core 13) is running on the same hardware , which I compiled my LFS on . I hope I can find an answer here . Kindly find attached a copy of the xorg.conf , and also two log files, first one when choosing intel driver, and second one , when choosing vesa . Also if important find attached a copy of the kernel configuration file . NOTE: the Xorg.0.vesa.log seems to be damaged , but it opens with VI. Thanks in advance Mark ___ 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: Info about X-architecture
Which hardware, specifically? If Linux has already been ported, and a framebuffer driver exists, then X will work perfectly already, using the fbdev X driver. Sending from a mobile, pardon the brevity. ~ C. On Oct 4, 2010 3:18 AM, vijay singh testmrs@gmail.com wrote: On Mon, 2010-10-04 at 13:11 +0300, Timo Juhani Lindfors wrote: vijay singh testmrs@gmail.com writes: I would like to know is their any document available which will explain about X-architecture. Even just http://en.wikipedia.org/wiki/X_Window_System gives a rough overview. if i want to add any new X-client then what is the way. Things like evolution and firefox usually work as X clients on gnu/linux. You can take a look at them or google for GTK hello world or QT hello world to get something simpler. Thanks for the info.. If i want to build test filesystem for new HW (In my case it is ARM11)where some basics X-client (xterm,xeyes..) should work, in this case how i should configure X to work. If more details about what all kernel dependency, how X can be test will be helpful. ___ 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: mostawesomed...@gmail.com ___ 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: headless 3D
We generally do not care about fglrx, especially on hardware that is no longer supported by it (fglrx dropped support for X1950 and earlier, last year) and highly recommend the open-source driver. I do not know if it works, but Mesa has EGL code for both classic and Gallium drivers, and IIUC you should be able to build an EGL driver that does not need X to be running. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: Zapping the Xorg server
On Wed, Aug 25, 2010 at 5:45 PM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Thu, 26 Aug 2010 08:44:46 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: Also, assuming that if we ditched input features somehow Gallium or other graphics parts would be finished sooner is a logical fallacy. I'm not talking about sooner. It's more like running into one direction, then realizing you've to go back, because things took a different direction. What I see on the horizon, I may be utterly wrong and misguided, is a concept I'd call console sets. Instead of somehow managing a number of input/output devices by means of helper deamons (consolekit *york*), which systems like X.org (but also others) have to use individually, it makes much more sense, to aggregate sets of devices into a Console Set, where each of them has it's own number of VTs. Think of multihead on the VT level, which is possible already, but through a rather clumsy interface. And Xorg, but also other things, then would simply run on top of that. Looking at Gallium and other things, to me it looks like the X server will transistion from a graphics driver/subsystem into something simpler, namely a network transparent graphics interface and windowing system. Maybe in the end we'll end up with some sort of Gallium kdrive on a Console Set. Abstracting away input hotplugging into the kernel, so that more programs can easily take advantage from it. Peter's been working solely on input handling and the XInput 2 stuff since he got started. If you want more work put into Gallium, you should find people like Marek, Luca, or me, that currently work on Gallium unpaid in our spare time, and pay us to focus on it. (You also might have to convince us to take the money -- I for one have decided to keep my current lower-stress local job rather than work all the time on graphics, and I bet the other amateurs are the same way.) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: [drm] drmOpen failed; MACH64(0): [dri] DRIScreenInit Failed
The DRI drivers are userspace. The DRM component for mach64, a kernel driver, isn't included in the standard Linux kernel. You are probably on your own as far as obtaining and building it. Sending from a mobile, pardon the brevity. ~ C. On Aug 3, 2010 9:41 PM, lesl...@ozemail.com.au lesl...@ozemail.com.au wrote: Thanks for your reply, Alex. SliTaz has available a package that it calls mesa-dri-ati and that it describes as Mesa DRI drivers for AMD/ATI Radeon and mach64 (include Rage128). My system reports that I have that package installed and that one of the files in the package is called mach64_dri.so. If I load that driver, will that overcome my problem? If yes, how do I do that, by editing xorg.conf in some way? (I should add that I just tried to load it using modprobe, but that didn't work. Sorry, I'm not too good at these things!) Thanks again, Leslie -- To see papers written by me on, among oth... On Wed Aug 4 14:22 , Alex Deucher sent: On Tue, Aug 3, 2010 at 11:45 PM, lesl...@ozemail.com.au lesl...@ozemail.com.au wrote: I'm usi... ___ 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: problems with multiple threads and XSync
Just do XInitThreads once at the top of your program. Not that difficult. Posting from a mobile, pardon my terseness. ~ C. On Jul 20, 2010 12:53 AM, Francesco Abbate francesco@gmail.com wrote: Hi all, I've a problem with a multi threaded application were multiple threads access to Xlib concurrently. In order to make things safe I've implemented a lock mechanism but I still experiment some intermittent (rare) problems with XSync that hang sometimes. Let me explain how I have arranged the locks for the multiple threads. There is a thread, lets say the main thread that poll the events and process them as needed. In order to make things safer all the operations are locked and the thread unlocks only during the blocking event polling. So I have something like that: ... my_application_unlock(); XNextEvent(m_display, m_event); my_application_lock(); ... The other thread, lets say the secondary thread, perform other stuff not related to the Xlib but, in some cases it does need to force an update on the Window. In order to perform this operation it does acquire the lock (the same as the main thread of course) and perform two operations: an XPutImage and an XSync with a true flag to discards incoming events. So I have something like that for the second thread: my_application_lock(); XPutImage(...); XSync(m_display, true); my_application_unlock(); The logic of this approach is that we let the secondary thread perform the XPutImage, XSync operation only when the main thread is polling events and is probably blocked anyway. This approach does not work and sometimes the XSync hang I don't know why. Should I use the XInitThread functions and the related locks to fix the problems or I need to adopt some other approach ? Any help or suggestions is highly appreciated. Thank you in any case. Best regards, Francesco Abbate PS: may be I can mention that on M$ Windoze the same kind of approach is apparently working without any problem. ___ 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: mostawesomed...@gmail.com ___ 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: problems with multiple threads and XSync
On Tue, Jul 20, 2010 at 7:55 AM, Francesco Abbate francesco@gmail.com wrote: 2010/7/20 Corbin Simpson mostawesomed...@gmail.com: Just do XInitThreads once at the top of your program. Not that difficult. Posting from a mobile, pardon my terseness. ~ C. Hi Corbin, You mean that XInitThreads is enough and I don't need to use XLockDisplay()/XUnlockDisplay() ? thank you very much for your help. http://www.manpagez.com/man/3/XInitThreads/ Read the man page. Also, don't email off-list; it limits the amount of people who can help you. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: devices support site?
On Mon, Jul 19, 2010 at 11:04 AM, Aljoša Mohorović aljosa.mohoro...@gmail.com wrote: i'm sure that this kind of site exists somewhere but i just can't find it. so what exactly am i looking for? any xorg user can identify device (with lspci, lshw, dmidecode or something else) and then it should be able to get information on this site: - recommended driver to use and current driver state - mailing list with support and development discussions - support information and availability on linux distributions, bsd and any other OS with xorg this site would also have list of top supported devices with best driver support and supported opengl version. i'm often in situation where i can't decide if i should buy a new (probably without a good driver) or an old graphics card with stable drivers. can somebody post a link to site with similar functionality? If I get bored enough, I suppose I could whip something up, but is it really that important? We put a lot of effort into making sure distros Do the Right Thing magically without user intervention. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: X Server Cursor Option
On Fri, Jul 9, 2010 at 11:29 AM, Chris Healy cphe...@gmail.com wrote: Simon, Sorry about that. I completely overlooked your first comment regarding emailing the Xorg mailing list. I'll take a look at the Xfixes Hidecursor code. I'm hoping I can do something that is global within X for all my windows. Other people have recommended using unclutter but that has a number of undesirable attributes, such as when a button is depressed, the cursor is visible and depending on how fast you want it to remove the cursor after inactivity, it starts to each more and more CPU cycles polling. Is it not possible to just remove -nocursor from your debugging machine's X incantations? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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: WebGL on linux
On Thu, Apr 22, 2010 at 5:25 AM, Sven Arvidsson s...@whiz.se wrote: On Tue, 2010-04-20 at 19:44 +0200, Aljoša Mohorović wrote: i'm trying to get WebGL (OpenGL ES 2.0 for the Web - http://www.khronos.org/webgl/) to work under linux but with no success. i don't mind buying a new card just to get this working, can anybody recommend a card with excellent open-source driver? but i'm also interested what can be expected for other cards on linux with opengl support 2.0? i'm interested because it will result in linux having bad support for webgl and mac and win excellent support. any comments appreciated. Hi, For WebGL in Firefox, it seems you need git master of the xserver, and a patch for Firefox: https://bugs.freedesktop.org/show_bug.cgi?id=24093#c9 I'm not really sure what's required for WebGL in Google Chrome? (Adding mesa-dev to the cc.) -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 Dunno if there's any real good reason to CC us. Kristian nailed it on those bugs -- pbuffers weren't supported on the server side until recently, but now they are and they work fine. That Fx bug is pretty serious, as there's a fair number of drivers that have no multisampled configs and will fail with WebGL. I'm kind of glad I saw this, though, because it makes me feel a bit better about my failed attempt to test WebGL a few weeks ago. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Google Summer of Code 2010 Project Idea
2010/3/22 Marcelo Galvão Póvoa marspeoples...@gmail.com: Hello, I'm a student interested in participating in GSoC 2010 and I would like to submit a new idea for a project but I don't know if it is feasible because of technical or proprietary source code issues with Apple. My project would concern in providing a better Mac OS and X integration in some user-oriented aspects such as: - Separate every application window in its own dock icon and make it fully featured, including drag and drop files, exposé, etc. - Transform X windows into native windows, so they accept features such resize and move using Universal Access and dragging content into it. - Provide smoother scrolling via mouse/trackpad. This would benefit mostly users of GTK or wine applications like me. Any help/hint will be appreciated. Note: I'm resending this email to this list because the first time I did I guess it wasn't delivered because of Rich Text formatting. Sorry for any inconvenience. You may want to resend to xquartz-dev (see http://xquartz.macosforge.org/trac/wiki/MailingLists). As mentioned on our GSoC wiki page (http://www.x.org/wiki/SummerOfCodeIdeas), Apple is fairly friendly to us, and willing to help. Good luck! ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How configure dual head on different graphic cards?
On Fri, Mar 19, 2010 at 4:44 AM, Frantisek Hanzlik fra...@hanzlici.cz wrote: I'm trying configure two monitors on my several desktop systems (Fedora 12 or Fedora 13 beta i686, kernels 2.6.31/2.6.32/2.6.33, Xorg server 1.7.5.901, XRandR 1.3, desktops have integrateg graphics (Intel G35 or Radeon Xpress 200G[RS480]), 1-4GB RAM, PCIe busses). Somewhere on net I found, X server version = 1.7 can support multiple different graphics card (not only dual/triple link ones), then I tried configure systems with internal + one add-on card. Until now I'm unsuccessful. Fedora's tool system-config-display do not detect secondary video card, I experiment with some dynamic configuration (xrandr) or static with xorg.conf, but without success. Some experiments with adding dual-link MGA G550 card wasn't successful too, I wasn't able supress integrated graphic card. As I have no big experience with actual up-to-date X configuration, please, is there any cookbook/Howto how do this tasks? It would be best with some troubleshooting knowledge. What I found on net, was all about dual-link cards and RandR 1.2. Or, for some direct suggestion from this list, which information I should post here? To autodetect all working graphics cards, and generate a multicard setup, use Xorg's builtin autoconfiguration system: $ Xorg -configure This is all it took for me on F12 with three cards. Hope this helps. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote: Modularized dri drivers and an SDK enabled mesa tree are available in my personal git repos at http://cgit.freedesktop.org/~libv/ The SDK enabled mesa tree adds to the mesa build system to create shared libraries libmesadri and libmesadricommon. It creates the relevant .pc files and installs the necessary headers include/mesa/ (and updates glcore.h). The patch is about 300 lines each time, and only adjusts the build system. The modularized drivers are fully autotooled and can be built and installed the familiar way once the dependencies are available (currently, libdrm and the dri sdk, and some driver specific libdrms for i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx and unichrome. This work was done for currently 16 versions between mesa 7.0 and the freshly tagged 7.8-rc1, all were extensively and oft repeatedly built through. 5 versions were also run tested (glxinfo, glxgears) for the radeon and unichrome drivers, and the swrast driver was also tested several times. Such a large range of versions was handled to prove the long term feasability of this. This work satisfies my requirements from my TODO: Mesa slide from my fosdem talk, for which the slides are available at: http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$ This only handles the DRI part of things, gallium seems to be more in flux atm, and from what i hear, it should be easier to have modular drivers there. Comments, additions, changes? Thanks, Luc Verhaegen. After giving the mesa3d-dev list the opportunity to have a whole day of deafening silence, maybe the other lists should join in on that fun :p Hey Luc, Wow. This is pretty nifty. Lots of work here, obviously. I do have a couple of questions, though: ~) Did you know about or use the automake branch that Eric and I have had floating around for a while? ~) Do you think it's gonna be tenable to ship the drivers with lots of shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like we might run into the situation we've got right now with the X server and DDX drivers, where it might be easier to move some drivers back in. Also (warning: sore subject!) it reminds me of the mesa/drm tree and the same problems with keeping code in two locations... Maybe that's just me. As far as Gallium goes, I really wouldn't worry about it. From what I can tell, the people that actually care about header stability have been using really specific versions of the interface in their own shipped bundles, and there's far too much mainline work going on right now to really even attempt this kind of splitting. I think there's a total of five branches right now that will change the entire Gallium interface, all getting prepared for merge? Lots of churn. Gallium's all mix'n'match though, so it shouldn't be a big deal further down the road. Sorry for not speaking up sooner; it's finals week and my attention to every single email in my box is rather limited. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Posting w/o quotes because, frankly, there's a lot of text here. MIT-Sundry-Nonstandard never was on any Xorg server I can recall; I remember UT2k4 bitched bitterly at me over it, back when I was still an fglrx user. Google and git suggest that it's been disabled since before 2006 and was finally nuked in 2008. Xprint client code still lives on in Mozilla; have you checked in with them? They may have working server patches. AFAIK the only reason it has bitrotted to the current state is because of a lack of actual clients using it; any intrepid person could probably keep it alive. IIUC RECORD supersedes XTrap and XEvIE although I'm not really up-to-date on the input stuff. Admittedly, I'm kind of young, but I had to go Google all the other extensions to even get a hint of what they do. That's probably not a good sign. :3 -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On Sun, Feb 28, 2010 at 8:13 PM, Richard Brown rbrown1...@gmail.com wrote: Alan Coopersmith wrote: On the client side we've pretty much preserved API ABI compatibility, even when that required major gyrations for the XCB effort - while we encouarage migration to the new XCB libraries, it will be a couple decades before libX11 fades away. I do not expect xlib to ever go away. There is so much written for it, its sort of pointless to refactor apps because we can. If one makes a new app, XCB may be a good choice, when it is mature. I am not sure what benefits XCB has however. It could be as well, the way things often go, someone will forget some needed feature in XCB and Xlib may end up being a better choice in some situations. Ive often seen things like that happen. Case in point ., i upgraded t KDE 4.0. The new Konsole does not take the escape codes for setting the title bar with program name/path name i have sent by tcsh precmd and postcmd. I deleted KDE 4 and went back to KDE 3. Someone didnt understand the importance of this and didnt include this. KDE 4 for me was a downgrade, it actually regressed. XCB cannot possibly omit any protocol information because of the way it's crafted: It is directly generated at build-time from descriptions of the X wire protocol. It also is far more intelligent about avoiding round-trips to the server and such. That said, people generally wait until the very last minute to switch away from legacy software, so it's not like people are switching in droves. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dual-DPU XRandR almost working, DVI-0 stays blank (was: Screen 1 deleted because of no matching section)
You'll have to Zaphod the head. Good luck. :3 Posting from a mobile, pardon my terseness. ~ C. On Feb 22, 2010 11:37 AM, martin f krafft madd...@madduck.net wrote: also sprach martin f krafft madd...@madduck.net [2010.02.22.1317 +0100]: Based on the auto-configuration idea, I found that XRandR wants me to have just two Device secti... A reboot of the machine fixed that. Now it seems like the only remaining problem now is that Screen 1, which is the Radeon 9200 card, provides a display spanning both monitors, but it appears to my window manager (awesome) as a single head. xorg.conf and log attached. xrandr again shows everything as I'd expect it, but something is preventing X from creating two heads for the screen: % xrandr -display :0.1 -q #1,10022 Screen 1: minimum 320 x 200, current 2560 x 1024, maximum 4096 x 4096 DVI-1 connected 1280x1024+... How can I split the screen into two heads? Note that I do not want to return to pure-Zaphod and duplicating Device/Screen sections for each of the two ports of the Radeon 9200 (using Screen 0/1 lines), because I'd just run into the problem described here again: http://lists.freedesktop.org/archives/xorg/2010-February/049355.html Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ the early bird may get the worm, but the second mouse gets the cheese in the trap. spamtraps: madduck.bo...@madduck.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkuC3OEACgkQIgvIgzMMSnVZxACgpHR5I+8AdupvRDmN7ruMYzca JhsAoOLpQuqYX7OhammBica84Imr+9jo =DpvV -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Screen 1 deleted because of no matching section
On Sun, Feb 21, 2010 at 8:07 AM, martin f krafft madd...@madduck.net wrote: Hello, I am trying to make my triple-head setup work with Xorg 7.5, using KMS with kernel 2.6.33-rc8. This is on Debian sid. My problem is that I can make it work such that Xinerama works, but the screens are out of order (1/3/2). If I change the configuration, X.org seems to delete one of the screens and it all reverts to single head. The message in the log is that of the subject line. I have two Radeon RV280 cards in the system. A Radeon 9200PRO (:00:0c.0) drives an Acer LCD on the DVI port, and a Radeon 9200 (:01:00.0) drives an identical Acer LCD on the DVI port, and an ancient VGA LCA on the VGA port. I have CONFIG_VGA_ARB set, and the radeon kernel module loads long before X.org is started. While the kernel cannot read the EDID off the old VGA monitor connected to VGA-2 of the second card (and hence there is anger in the logs, see attached), it seems that KMS is correctly set up before X.org starts. I am using the attached xorg.conf file to drive the setup. The reason why I (think I have to) use a configuration file is to instruct X.org to address both Radeon RV280 cards in the system — without the configuration file, only the second of the two cards is initialised, and the display on the first card's DVI port stays blank. The xorg.conf file defines three screens named Screen[0] through Screen[2], and the appropriate devices and monitors. I am using the Screen option in the Device section to address the different outputs of a single card. For years, this used to work just fine, but I suppose KMS causes the screens on the 9200 to be reversed. While previously, DVI/VGA were screens 0/1, with KMS ist seems that DVI/VGA are 1/0 respectively. This might be reflected in the lspci output, where .0 is the VGA display, while the secondary is just a display adapter: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01) If I start up X.org with the attached xorg.conf, the middle and right-most LCDs are swapped, and the mouse moves off the right off the left-most screen directly onto the right-most, and off the right edge of that directly onto the middle screen. The attached log file for this scenario is Xorg.0.log.ok.132.gz. I am failing to rearrange the order. I tried all of the following: - swapping the Screen options in the two R9200 Device sections such that line 56 reads Screen 1 and line 64 reads Screen 0. - swapping the Device options in the two Screen sections referencing the 9200 devices, such that line 25 reads 'Device Radeon 9200[1]' and line 36 reads 'Device Radeon 9200[0]' - changing lines 6-7 such that for Screen 1, it's Screen[2] RightOf Screen[0] and for screen 2 it's Screen[1] RightOf Screen [2] In all three cases, only the left-most screen (Screen[0]) is activated. It seems that the 9200 card is completely ignored. The log (also attached as Xorg.0.log.screen-1-deleted.gz) says: (EE) Screen 1 deleted because of no matching config section. Any idea what is going on? Is there a different way I should be trying to get multiple GPUs to work with X.org 7.5? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ the problem with america is stupidity. i'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? -- seen on irc spamtraps: madduck.bo...@madduck.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkuBWjUACgkQIgvIgzMMSnXCTwCfVjaqGyfWsA6HlT9OhKTxZaZK GGAAn1s/4NZ6csBJl2BljWFdV6NoXsTZ =2SSB -END PGP SIGNATURE- Try using Xorg's builtin configuration detection. Bring down X, then from a VT, do: # Xorg -configure Xorg should report finding a multicard setup, and the resulting xorg.conf should work. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Board voting ends today, but...
Quick list: x12, shatter, 3d for the Big Three, million char/s for Big Three, multigpu xrandr, move some drivers back in. I think that's the bulk of what we've talked about. Posting from a mobile, pardon my terseness. ~ C. On Feb 18, 2010 2:21 PM, Peter Winston pe...@ics.com wrote: The thing that suprises me is that there has been no discussion of how do we update the vision and goals of x.org The fact that we might be spending too much for hosting, or doing a poor job of accounting for expences is interesting, but secondary to where do we want to be in 3 years, and how are we going to get there. IMHO Peter Sent from my iPhone On Feb 18, 2010, at 4:45 PM, Daniel Stone dan...@fooishbar.org wrote: Hi, On Thu, Feb 18, ... ___ members mailing list memb...@foundation.x.org ... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.Org Foundation Board of Directors 2010 Election
Regarding hosting, the possibility of OSUOSL is still on the table. At least one sysadmin is on our side, and I'm increasingly looking towards the seven-year plan, so there are two of us here. Posting from a mobile, pardon my terseness. ~ C. On Feb 16, 2010 1:05 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Chris Ball wrote: expo (the 2U machine) was there originally, and this serves the need... From my old e-mail, the order we submitted for then in 2005 was for 2 systems, each with: Sun Fire V40z AMD Opteron 3U Rack Mnt x86 Server:2xAMD Opteron 850 CPUs, 4 DDR1/333 Registered ECC DIMMs (4x1GB), 1x73GB 10K RPM Ultra320 SCSI disk, 2x 10/100/1000 Ethernet ports, RAID 1,LOM, 4xFull Hght/Full-Lgth 64 bit/133 MHz PCI-X slots, 1xFull Hgt/Full-Lgth and 1xFull Hgt/Half-Lgth 64-bit /100MHz slots,1xHalfHght/Half Lgth 64-bit/66MHz PCI-X slot, DVD/flpy incl- 2 redundant plus 4 additional 300GB 10K 300GB 10K RPM Ultra320 SCSI disks to split between them. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X... members mailing list memb...@foundation.x.org http://foundation.x.org/cgi-bin/mailman/listinfo/membe... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.Org Foundation Board of Directors 2010 Election
That's a good question. I know at least one admin, warthog9, has full control of his machines. I think it varies depending on the group and the extent of the hosting. Posting from a mobile, pardon my terseness. ~ C. On Feb 16, 2010 2:58 PM, Chris Ball c...@laptop.org wrote: Hi Corbin, Regarding hosting, the possibility of OSUOSL is still on the table. At least one sysadmin... Last time I looked at OSUOSL for hosting, they wouldn't let people have root on hosted machines -- do you know if that's still the case? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.Org Foundation Board of Directors 2010 Election
I think I'm allowed to disclose at least three serious job offers I've received just for my Mesa contributions. I don't think I will have an employment problem when I finally leave school. Posting from a mobile, pardon my terseness. ~ C. On Feb 15, 2010 11:53 AM, David Nicol davidni...@gmail.com wrote: On Mon, Feb 15, 2010 at 1:21 PM, Daniel Stone dan...@fooishbar.org wrote: (If people want to g... You must be exaggerating. Anyway, I'm running as the outsider. ___ xorg mailing list xorg@lists.freedesktop.org http://... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: FOSDEM DevRoom schedule updated.
Sounds so fun. I wish I could go. :C On Thu, Jan 21, 2010 at 5:56 PM, Luc Verhaegen l...@skynet.be wrote: http://wiki.x.org/wiki/fosdem2010 The current schedule (as it will be printed in the booklet too): * 10.00: ... * 11.00: ... * 12.00: ... * 13.00: Daniel Stone : Polishing X11 and making it shiny. * 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack. * 15.00: Jerome Glisse : GPU Userspace - kernel interface Radeon kernel modesetting status. * 16.00: Mikhail Gusarov : X on e-Paper. I'm sure that the DevRoom will be brimmed when there are talks, but the FOSDEM organizers are not exactly thrilled with the coverage on even a single day, and I don't think that we will get a 6th devroom next year. Anyway, hope to meet some of you there. Mail me for contact info for friday evening supper meet-up on the grand place. Luc Verhaegen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: FOSDEM DevRoom schedule updated.
It's totally a lack of spare time, just like XDC two years ago. Sure, money's tight, but I wouldn't have hesitated to ask if there were actually time in my schedule to take from school and work. On Thu, Jan 21, 2010 at 8:08 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: If you or someone else had a talk they were ready to give and were just blocked by lack of funding, you could ask the X.Org Foundation Board for travel sponsorship - we have done that for FOSDEM before. (Letting us know how much it will cost will improve response time to any request, now that time is getting tight. No promises we'll say yes, but the odds are much higher if you ask than if you don't.) -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Corbin Simpson wrote: Sounds so fun. I wish I could go. :C On Thu, Jan 21, 2010 at 5:56 PM, Luc Verhaegen l...@skynet.be wrote: http://wiki.x.org/wiki/fosdem2010 The current schedule (as it will be printed in the booklet too): * 10.00: ... * 11.00: ... * 12.00: ... * 13.00: Daniel Stone : Polishing X11 and making it shiny. * 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack. * 15.00: Jerome Glisse : GPU Userspace - kernel interface Radeon kernel modesetting status. * 16.00: Mikhail Gusarov : X on e-Paper. I'm sure that the DevRoom will be brimmed when there are talks, but the FOSDEM organizers are not exactly thrilled with the coverage on even a single day, and I don't think that we will get a 6th devroom next year. Anyway, hope to meet some of you there. Mail me for contact info for friday evening supper meet-up on the grand place. Luc Verhaegen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: The current dualseat status for radeon?
Fedora has accelerated r600. Posting from a mobile, pardon my terseness. ~ C. On Jan 4, 2010 10:13 AM, Xavier Bestel xavier.bes...@free.fr wrote: On Mon, 2010-01-04 at 16:24 +0200, Marius Gedminas wrote: On Sat, Jan 02, 2010 at 01:26:14PM +... Even r600 aren't supported by current distros (except as glorified framebuffers), so I guess if you want something working now (as in not in a year or so), try buying some used r500 on ebay instead. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiseat with VGAArbiter on 2 Radeon cards
Multicard and multiseat for radeon doesn't need vgaarb; use KMS instead and your cards will both come up at boot. Posting from a mobile, pardon my terseness. ~ C. On Dec 5, 2009 9:30 AM, Tiago Vignatti tiago.vigna...@nokia.com wrote: On Fri, Dec 04, 2009 at 09:00:19PM +0100, ext Steffen Schaumburg wrote: Hi everyone, I'm trying ... yes. And the log says you're indeed using it. The current status of my work is: From pressing the power button to kdm loading it displays i... humm, seems not issue with vga arbitration. I'd guess maybe missed mode setting. Try to start an app on the monitor black and see if connects. If this succeeds then the arbiter is doing its job okay. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
You're right. We need a Generic Userspace Configuration Kit, which could talk to the Session Hotplug Infrastucture Posting from a mobile, pardon my terseness. ~ C. On Dec 2, 2009 5:09 AM, olafbuddenha...@gmx.net wrote: Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session mana... Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
And thus marks the last time I attempt to be sassy on my Droid. But as I was saying, the Generic Userspace Configuration Kit. If we're going to add a Session Hotplug Infrastructure Tasklet, which is desktop-agnostic, in order to configure the X server across multiple platforms, you're going to need a Generic Userspace Configuration Kit to talk to the kernel, since that's where the devices live. Being desktop-aware has a lot of benefits, mostly in the realm of policy control and convenience, and letting the DE configure things is not as bad as, say, having GNOME-specific code in the server. On Wed, Dec 2, 2009 at 9:34 AM, Corbin Simpson mostawesomed...@gmail.com wrote: You're right. We need a Generic Userspace Configuration Kit, which could talk to the Session Hotplug Infrastucture Posting from a mobile, pardon my terseness. ~ C. On Dec 2, 2009 5:09 AM, olafbuddenha...@gmx.net wrote: Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session mana... Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://... -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: HD-Video Hardwar Acceleration?
I don't feel like digging through emails and writing point-by-point replies, so I'm just going to do point-by-point talking-to-myself. - The APIs for accelerating full decoding and not just colorspace conversion and scaling (Xv) are: -- VA-API -- VDPAU -- XvBA -- XvMC Of those, only VDPAU is worth implementing. XvMC can be done in terms of VDPAU if you're creative enough. - OpenCL would be fine for video, but stupid and slow, just like OpenGL-based video decoding. - The current plan is to *not* add any more video decoding to any DDX, but to do it in Gallium using a state tracker. Expand g3dvl to be a true pipeline, let drivers fill in the pipeline with whatever they can accelerate, and then expose VDPAU and XvMC to userspace. Of course, only radeon (me, MrCooper) and nouveau (marcheu, ymanton) have actually agreed that this is a good idea, but the intel devs will probably keep maintaining their XvMC and VA-API implementation either way. - It's not done because we've been working on other things. If it makes you feel better, 3D support *is* required for this kind of work, since we don't have documentation on the dedicated video decoders onboard most GPUs, and we haven't reverse-engineered them, so we'll have to use 3D shaders instead. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Hiding the X cursor?
On 07/16/2009 01:30 PM, Tyler McClung wrote: I am unaware of the issues with animated cursors, but it works great for normal ones. I noticed a bug where calling the hide cursor multiple times causes a stacking effect. In order to make the cursor visible, you have to call show cursor that many times before the effect is noticed. Also, if show cursor was called when the cursor wasn't hidden, a Bad Match error was thrown. Hm. Wonder if that can be made a bit more flexible. I may look into that. Additionally... You're working with an Ozzie, right? CC these things to oswald-dev, please, so that Tim and Ben can see them too. :3 ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
On 07/05/2009 02:49 PM, Gene Heskett wrote: On Sunday 05 July 2009, Alex Deucher wrote: On Sun, Jul 5, 2009 at 3:20 PM, Matt Turnermatts...@gmail.com wrote: On Sun, Jul 5, 2009 at 4:11 PM, Casey Jonesjonescas...@gmail.com wrote: Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. No, the radeon-rewrite branch (which has been merged recently) wouldn't change anything, as it doesn't support R6/700. If it's happening with 2D, it's not a problem with Mesa anyway -- unless you're using compiz, then it may be. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. Yes, XAA is also available. Only EXA is available on r6xx/r7xx hardware. Alex Can we expect that to change eventually? If your question is actually, XAA for r600+? then the answer is never. XAA is just not a good fit for these cards. Additionally, XAA is kind of on the way out, and with recent EXA improvements, there's really no reason to stick with it. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X withtout DRI
Olivier Martin wrote: Just a little question to clarify my understanding of XServer design ... From the DRI website, I can read this article about DRI without X ( http://dri.freedesktop.org/wiki/DriWithoutX). But is it possible to have a 3D-enabled XServer with GLX extension and without DRI extension (and module) ? Yes. You'll still need something to provide the bindings between GLX and the kernel/lower-level hardware drivers, though. On Introduction to the Direct Rendering Infrastructure ( http://dri.sourceforge.net/doc/DRIintro.html), it says about XFree86 DRI Extension: The XFree86-DRI X server extension is basically used for communication between the other DRI components (the X server, the kernel module, libGL.so and the 3D DRI drivers). The DRI module maintains DRI-specific data structures related to screens, windows, and rendering contexts. When the user moves a window, for example, the other DRI components need to be informed so that rendering appears in the right place. Does it means any OGL implementation within the server-side must supply a DRI module ? What about the OGL Mesa library with SW rasterization only ? Does it supply a DRI module (for managing a lock on the framebuffer) ? Yes, Mesa now provides a swrast_dri.so which X can use to provide direct rendering to software, as well as AIGLX. Is it possible to use Mesa driver with a non-DRI backend in the server-side ? There are non-DRI Mesa drivers, but I do not think that any of them interact in the same way with Xserver. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
tv wrote: It's so wonderful when essential features like saveunders are removed. Save-under and backing store have never been guaranteed to be honored by the Xserver. Now you'll get hordes of people complaining and thinking your software is buggy because applications are constantly redrawing under it... You are not a hordes. You're not even a single horde. You completely and totally lack the horde-ness. You are not one with the horde. the assholes in power removed essential features without providing a subsitute, like a generic CM that isn't a complete joke. (And CMs are overall a fucking joke and a waste of CPU cycles and memory... unless you can somehow emulate just saveunders etc. without storing all the hundred windows in memory... but all this has *piss-poor* documentation in a typical fashion.) Dude, you're talking about compositing managers being a waste of cycles and memory, but are you even aware of how much of our time you're wasting? My compositing manager is xcompmgr, and it makes dragging windows around a bit slow if my EXA is turned off. You, on the other hand, require me to actually physically get up, walk over to the computer that has my email, sit down again, scratch my head for a few minutes thinking up suitable flames that gently point out why you're being lame while also attempting to embarrass you (all the while mourning the fact that by writing said flames I regrettably lower myself to the level of your trolling,) type out these dozens of lines of writing, and click Send. I could be writing code right now! Or playing music! Talking on the phone, riding my bike, hitting on girls... I could be living out life to the fullest, but instead I'm here replying to your troll. Now *that* is a waste of cycles and memory. There's just no way to keep up with all the shit the FOSScracy throws at you, unless you're one of the big projects with immense resources, and indeed part of the FOSScracy. Write an application that understands that backing store is an optimization that the server may not actually honor, and no pain would have ever befallen you. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Tuomo Valkonen wrote: On 2009-04-07, Ross Burton r...@burtonini.com wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. Pollute my system with KDE or Gnome? Rather install Windows. Sounds like a plan. Enjoy your Cleartype. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: No fragment shader?
Markus Strobl wrote: Roland Scheidegger wrote: On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland Thanks, Roland. That helped in that I found I had an old parallel install of googleearth installed that I cleaned out and I also found a newer 32-bit mesa (the machine is 64-bit). Unfortunately it still doesn't work. The googleearth screen comes up but when it tries to render the earth it crashes with this: Warning: Unable to create prefs directory '/home/markus/.googleearth'. File exists. libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) I tried setting the R300_SPAN_DISABLE_LOCKING var but it did the same thing (the R300_SPAN_DISABLE_LOCKING line in the console printout disappeared, otherwise the same). Anything else I can try? /Markus In driconf, disable low-impact fallbacks. This will eliminate at least one of the error messages, and keep it from falling back to software rendering. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [EDIT] Why do I need mouse acceleration to move windows and click buttons?
Dirk wrote: The bottom sticker of my mouse says 2000 DPI... so I want to move the pointer 2000 pixels when i move the mouse an inch... NO MATTER HOW FAST I MOVE THE MOUSE. These are device pixels, not screen pixels. I really hope you didn't need me to explain this. Well... the thing I tried to explain is that I (and other people) don't want to /have/ to give a f***... 1) I plug in 2000 dpi mouse 2) I move mouse 1 inch horizontally and/or vertically 3) pointer moves 2000 pixels horizontally and/or vertically NO MATTER HOW FAST I MOVE THE MOUSE that really is all that one cares about when he wants to use Linux for gaming. PRECISION! Not useless Desktop features that interfere and make one seriously freak out during an important match. You could completely remove mouse acceleration from the codebase and increase the quality of Linux as a gaming system. People who believe they need an accelerated pointer to click buttons or move windows are not bright enough to realize the absence of acceleration anyways. I know Windows has mouse acceleration too... but just because they call it a feature it shouldn't be part of a Linux Desktop and enable itself, randomly, over and over again. Right now I run a script that calls xset 30 times a minute with sleeps as a cronjob to make sure it stays disabled. Before, I even sent my mouse back to the manufacturer because I thought it was broken before I realized it was a problem with Linux so I guess I /am/ a little annoyed. Not as much as i (e.g.) was before i uninstalled HAL to get control over my Linux back. But still... I'll check out http://www.x.org/wiki/Development/Documentation/PointerAcceleration Thanks. You wrote up this entire flame before reading the manual? http://xkcd.com/293 comes to mind. Additionally, acceleration's presence can always be made negligible by changing the rate of acceleration. (Ah, the joys of calculus.) It's definitely an enhancement, not a feature. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
John Tapsell wrote: 2009/2/18 Matthias Hopf mh...@suse.de: On Feb 06, 09 01:56:19 +, John Tapsell wrote: glxgears is not a benchmark. At openSUSE we print out a warning now (well, this change went into *after* 11.1, unfortunately), that this is not a benchmark. We got really tired of these statements. Except that it _is_ a benchmark. Or rather waas before the change. No, it never was. If for example, without vsync, a user gets just 100fps on their new nvidia card, then that is clearly showing that something is wrong. So it is a validation tool, but not a benchmark. A benchmark - by definition - gives you performance figures that can be compared with other systems, which gives you a reasonable notion of which of the systems is better. Right. If one system gets 100fps and another gets 1,000fps, then you compare the two systems and say that one is better than the other. All you are saying is that it's not an accurate comparison if the numbers are close. A benchmark also measures specific hardware performance and tests optional features. glxgears only tests clear speed and the rate at which a modest-sized vertex buffer can be rendered. A useful sanity test, but nothing more. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XRandR: Screen Rotation animation effect
Bipin George Mathew wrote: Corbin, I agree that any transition effect belongs in the compositor. But we have two exclusive methods here to achieve screen rotation 1) the windows are rotated by the compositor-the one thing to note here is that the xserver currently does not allow mouse inputs to be redirected, even if visually the windows are rotated. 2) the xserver itself does the rotation by talking to the driver ( using xrandr) I guess the best way would be to show the transition using the compositor and then use xrandr to do the rotation (if the driver issue can be fixed and prevent the flicker as Keith pointed out). Comments? You took the words right out of my mouth. (Well, figuratively.) Do the xrandr rotation first, to make sure that it succeeds. Then, if it does, the compositor could do its funky effects. With proper driver support for flicker-free rotate, that should work. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XRandR: Screen Rotation animation effect
Bipin George Mathew wrote: Currently, when we use Xrandr to rotate the screen, the screen goes blank for a second or two and then shows the screen in the new orientation. I was exploring if it was possible to avoid the flicker and substitute it with a relevant animated effect - Is this code change even do-able, given the way xserver interfaces with the video drivers? Any pointers? The alternative would be not to use XRandR at all, and let the window manager do the effect - but this requires the Input redirection patches (which has limitations) Going off the top of my head; I'm sure somebody will correct me. The flicker could be avoided if load detection were skipped, but I think that discussion's already been had. An animation could be done by a compositor, but at that point the compositor (not xrandr) would be handling the rotation. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XRandR: Screen Rotation animation effect
Keith Packard wrote: On Fri, 2009-02-13 at 19:44 -0800, Bipin George Mathew wrote: Currently, when we use Xrandr to rotate the screen, the screen goes blank for a second or two and then shows the screen in the new orientation. That's just a bug; there's no reason to have it blank for a long period of time as we're not setting a new mode, just changing the frame buffer pointer. Fixing the driver API to keep this from reprogramming the video hardware would make the switch instantaneous at least, even if it doesn't have a cool transition effect. After giving it a bit more thought, I'm actually going to have to say that it *must* be up to a compositor to do any effects. After all, since modes aren't square, windows have to be shifted around and such, and it just seems like incredibly bad form to do that at any level lower than the window manager. Also, even on a square mode, the actual viewing area that would be consistently viewable would be circular and there would be undefined areas of screen space at certain points. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping
Amos Tibaldi wrote:
Hello,
I am trying to use the Xv extension in order to display images on windows.
I have obtained the image formats with
xvc.fo = XvListImageFormats( xvc.display, xvc.port, (int *)formats );
and I have chosen the format
id: 0x59565955 (UYVY)
guid: 55595659--0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
I'd like to convert from RGB to UYVY and I have found that for the struct
typedef struct {
int id; /* Unique descriptor for the format */
int type;/* XvRGB, XvYUV */
int byte_order; /* LSBFirst, MSBFirst */
char guid[16]; /* Globally Unique IDentifier */
int bits_per_pixel;
int format; /* XvPacked, XvPlanar */
int num_planes;
/* for RGB formats only */
int depth;
unsigned int red_mask;
unsigned int green_mask;
unsigned int blue_mask;
/* for YUV formats only */
unsigned int y_sample_bits;
unsigned int u_sample_bits;
unsigned int v_sample_bits;
unsigned int horz_y_period;
unsigned int horz_u_period;
unsigned int horz_v_period;
unsigned int vert_y_period;
unsigned int vert_u_period;
unsigned int vert_v_period;
char component_order[32];/* eg. UYVY */
int scanline_order; /* XvTopToBottom, XvBottomToTop */
} XvImageFormatValues;
that image format has: ysb 8; usb 8; vsb 8; hyp 1; hup 2; hvp 2; vyp 1; vup
1; vvp 1; 'UYVY'slo: 0
So I'm trying to convert the bytes from rgb with:
void RGBToUYVY(unsigned short int r,
unsigned short int g,
unsigned short int b,
unsigned short int * u,
unsigned short int * y,
unsigned short int * v)
{
//cout r= r g= g b= b;
r = 0x00FF; g = 0x00FF; b = 0x00FF;
*y = (unsigned short
int)(0.299f*(float)r+0.587f*(float)g+0.114f*(float)b);
*u = (unsigned short
int)(-0.147f*(float)r-0.289f*(float)g+0.436f*(float)b);
*v = (unsigned short
int)(0.615f*(float)r-0.515f*(float)g-0.100f*(float)b);
*y = 0x00FF;
*u = 0x00FF;
*v = 0x00FF;
//cout y= *y u= *u v= *v endl;
}
and to display the image with
void XVWindow::Redraw()
{
unsigned short int u, y, v;
RGBToUYVY(255,255,0,u,y,v);
unsigned short int thecolor = u 12 | y 8 | v 4 | y;
for ( int y=0; yImageHeight; y++ )
for ( int x=0; xImageWidth; x++ )
((unsigned short int *)BGimage-data)[ y * ImageWidth + x ] =
thecolor;
counter++;
XvPutImage( xvc.display, xvc.port, window, gc,
BGimage, 0, 0, ImageWidth, ImageHeight,
0, 0, WindowWidth, WindowHeight );
}
but the colors are always different. I have tried to use the blue, the red
and the green to see if I could obtain them separately but the mapping was
always wrong and different colours were showing on the window with respect
to those that I'd like to use in RGB.
What can I do? Is my RGB to UYVY correct? Why do I obtain on the screen
different colours. There are some kind of manual on how to map colors with
XV images?
Which driver, exactly? Most drivers provide RGB Xv formats, and those
that don't probably could be hacked to add it.
~ C.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [suggestion] mailing list for newbies
Mikhail Gusarov wrote:
Twas brillig at 15:50:35 08.12.2008 UTC+00 when [EMAIL PROTECTED] did gyre
and gimble:
CL Well certainly something (whether newbies or not) is preventing the
CL 'devs' from seeing the wood through the trees.
Lack of devs.
Lack of dev time, as well. Out of {agd5f, airlied, glisse, nha, me,
osiris, onestone}, only two are not students IIRC, and of all of us,
only Alex is actually assigned to Radeon stuff. This is why we're behind
the Intel drivers all the time. :C
Well, okay. That, and I suck. But my point still stands.
~ C.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Daniel Stone wrote: On Mon, Dec 01, 2008 at 10:47:06AM +0500, Alexander E. Patrakov wrote: Also, currently, for unconfigured Xorg, such newly-added keyboard gets the us layout. This is also a hard-coded policy, should we remove it? Ignoring both the rhetoric and the fact that neither of the input maintainers are American (thanks for the assumption, but Peter's an Austrian living in Australia, and I'm an Australian who's spent the last couple of years living in Finland), this will be build-time configurable soon. In fact, I would consider any default other than completely unusable keyboard that doesn't produce any events a policy. Reason: I want US developers eat their own dogfood. I was going to write something in reply to this, but then I realised I have better things to do. Spare us the drama, please. Disclaimer: I'm American. However, I think I'd prefer dog biscuits to dogfood. Have you ever eaten dog biscuits? They're delicious. Anyway... Would a udev analogy be appropriate? udev is a userspace program that manages a very low-level policy for the kernel. It's responsible for setting sensible defaults, but can be fully customized in order to fit the needs of anybody who wants custom layouts. Why userspace? Because policy shouldn't live in the kernel. Why usable defaults? Because customization shouldn't be mandatory. Why use dbus to talk to the rest of userspace? Because, like it or not, dbus is probably the best way to do so. Now, the big difference between HAL and udev is that udev sets its defaults based on LSB. I don't know whether or not LSB has anything to say about keyboard layouts, or what the default keyboard layout should be. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AMDs new AMDXvBA library
Torgeir Veimo wrote: I had a quick look at the libAMDXvBA.so.1.0 library that comes with the latest fglrx driver from AMD (Catalyst v8.10) with gdb and it seems to be a quite comprehensive library implemented in C++. There are quite a good number of classes, with names such as R600CmdBuf, R600ColorEnchanceFilter, R600Plane, R600SubstreamBlendFilter, R600UpSampleShader, ShaderManager, Subpicture, but much more interesting are classes such as UVDBufferPool, UVDCodec, UVDCodecH264, UVDCodecMpeg2, UVDCodecVC1, UVDCodecVLD, etc. Am wondering if someone on the list with connections to AMD knows when / if header files will be made available for this library? Here's a sample output from gdb. It's easy to get the list by starting gdb as 'gdb libAMDXvBA.so.1.0' then typing Break ' and press tab for autocompletion. XvBADecodeLinux::CreateCompressedBuffers(DeviceLinux const*, int, XVBA_BUFFER_DESCRIPTOR**, CompressedBuffer**) XvBADecodeLinux::CreateDecodeBuffers(XvBADecodeData*) XvBADecodeLinux::DecodePicture(DeviceLinux const*, unsigned int, XVBA_BUFFER_DESCRIPTOR**) XvBADecodeLinux::DestroyDecodeBuffers(unsigned int, XVBA_BUFFER_DESCRIPTOR*) XvBADecodeLinux::EndDecodePicture(DeviceLinux const*) XvBADecodeLinux::StartDecodePicture(DeviceLinux const*, XvMCSurface const*) XvBADecodeLinuxH264::Create(DeviceLinux*, XvMCContext const*, XvBADecodeLinux**) XvBADecodeLinuxH264::CreateCompressedBuffer(DeviceLinux const*, XVBA_BUFFER_DESCRIPTOR const*, CompressedBuffer**) XvBADecodeLinuxH264::FillPicParamsBuffer(xvba_picture_descriptor const*, MMD_PicParams_H264*) XvBADecodeLinuxH264::Init(DeviceLinux*, XvMCContext const*) XvBADecodeLinuxH264::Release(DeviceLinux const*) XvBADecodeLinuxMPEG2::ConvertCreateDecodeBuffers(XVBA_BUFFER, int*, int*) XvBADecodeLinuxMPEG2::Create(DeviceLinux*, XvMCContext const*, XvBADecodeLinux**) XvBADecodeLinuxMPEG2::CreateCompressedBuffer(DeviceLinux const*, XVBA_BUFFER_DESCRIPTOR const*, CompressedBuffer**) XvBADecodeLinuxMPEG2::StartDecodePicture(DeviceLinux const*, XvMCSurface const*) XvBADecodeLinuxVC1::Create(DeviceLinux*, XvMCContext const*, XvBADecodeLinux**) XvBADecodeLinuxVC1::CreateCompressedBuffer(DeviceLinux const*, XVBA_BUFFER_DESCRIPTOR const*, CompressedBuffer**) XvBADecodeLinuxVC1::FillPicParamsBuffer(xvba_picture_descriptor const*) XvBADecodeLinuxVC1::Release(DeviceLinux const*) XvBADecodeLinuxVC1::StartDecodePicture(DeviceLinux const*, XvMCSurface const*) XvBADecodeLinuxVLD::ConvertCreateDecodeBuffers(XVBA_BUFFER, int*, int*) XvMCDecodeLinux::Create(DeviceLinux*, XvMCContext const*, XvMCDecodeLinux**) XvMCDecodeLinux::CreateBlocks(XvMCContext const*, unsigned int, XvMCBlockArray*) XvMCDecodeLinux::CreateMacroBlocks(XvMCContext const*, unsigned int, XvMCMacroBlockArray*) XvMCDecodeLinux::DestroyBlocks(XvMCBlockArray*) XvMCDecodeLinux::DestroyMacroBlocks(XvMCMacroBlockArray*) XvMCDecodeLinux::FillInterMCControlBuffer(XvMCMacroBlock const*, short const*, bool, unsigned int) XvMCDecodeLinux::FillIntraMCControlBuffer(XvMCMacroBlock const*, short const*) XvMCDecodeLinux::FillPicParamsBuffer(unsigned int, XvMCSurface const*, XvMCSurface const*, XvMCSurface const*, unsigned int) XvMCDecodeLinux::Init(DeviceLinux*, XvMCContext const*) XvMCDecodeLinux::PackIdct(short const*, int) XvMCDecodeLinux::Release(DeviceLinux const*) XvMCDecodeLinux::RenderSurface(DeviceLinux const*, unsigned int, XvMCSurface const*, XvMCSurface const*, XvMCSurface const*, unsigned int, unsigned int, unsigned int, XvMCMacroBlockArray const*, XvMCBlockArray const*) Hmm. No idea, really. Our AMD contacts are busy trying to clear r600 docs for the public at the moment, so UVD and UVD2 stuff will have to wait. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular: Changes to 'master'
Miles Bader wrote: Corbin Simpson [EMAIL PROTECTED] writes: radeon doesn't just have r5xx, r6xx, and r7xx support grafted on, as you imply. The support is provided through AtomBIOS, and the acceleration for the r5xx chipsets is nearly identical to the r4xx, with the sole exception of the programmable fragment shader unit. radeon's support of all Radeon chipsets is fairly unified and consolidated. Er, isn't that a bit of a weak statement given that it does _no_ acceleration for the more modern chipsets? Which driver provides a better path for future work in that sense? The lack of acceleration on HD chipsets, for both drivers, is due to waiting for AMD to release corresponding documentation, rather than anything else. I couldn't really say for sure how much code's been written on the NDA side, but I hear that there's a working bit of r6xx DRI already. (And after noticing your email address, I should throw in that RE is not planned for these chipsets except where absolutely necessary. :3 ) ~ C. -- ~ Corbin Simpson [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel Mode Setting DRMFB?
Mike Lothian wrote: Hi There's been a lot of talk about kernel mode setting including setting the correct resolution at boot and nice VT switching I was just wondering if there is some sort of DRM FB option to do this? If so where are the patches and is it being pushed for 2.6.28? Or am I completely misunderstanding the feature? If so how do you use it :D You need GEM+KMS for Radeons. Not sure on the Intel requirements. (The KMS stuff *isn't* going upstream this cycle IIUC.) But yeah, you get a nice radeondrmfb for free. It looks pretty nice, actually. :3 ~ C. -- ~ Corbin Simpson [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. What do you think? Should Xorg change this key sequence? Please vote yes or no. You can add comments too. If you reply only to me by private mail, I will eventually summarize your reply to the list. Seems like it's a problem with emacs. Sure glad I use vi. :3 Seriously, no. Zap once, learn forever. No different than anything else, really; ever heard of press Alt+F4 to make it go faster? ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYYdMACgkQeCCY8PC5utCneQCeObXX+/9MERbrN3xo41h40Niq u8UAn2Y3U2VWSwV4irduJp1UMm1t31fn =OZ96 -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Corbin Simpson mostawesomedude at gmail.com writes: ... Seriously, no. Your vote has been duly noted. Zap once, learn forever. No different than anything else, really; I still believe that Xorg should make it harder to make the mistake of an accidental zap. ever heard of press Alt+F4 to make it go faster? Yes. Note, though, that Firefox now displays a confirmation dialog when you try to quit when there are multiple tabs open. That featureis a good protection against the press Alt+F4 to make it go faster jokesters. AIM, StarCraft, Dreamweaver... those were the things of my youth, and they all died when Alt+F4 was pressed. Consequently, I got *very* good at not casually pressing those two buttons together except when I really meant to do it. That's all. Need sleeps now. ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYaeoACgkQeCCY8PC5utBKwgCfXOhawfMNm2gW0sq5Q9fndk7j olIAnjp9idMQETU0cSTUuoaRFr1pNn0N =fSQQ -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Plus, due to the psychological effect called groupthink, people who would have said yes are now less likely to admit it to the entire list, since IIRC three have already said no and only one (me) has said yes. :( Ctrl+K+X may not work on some keyboards. Ctrl+Alt+Z, Ctrl+Alt+A, Ctrl+Alt+P may be a legitimate sequence in some program. We are not talking about a reboot, we are talking about killing, and optionally restarting, the graphics subsystem. This is not something any casual user should *ever* have to do. Ever. If somebody *needs* to kill X using an emergency key combo, and they are not devs, then something is wrong somewhere down the line. Or, to put it another way, distros should default to DontZap, except for Gentoo. :3 (And Slackware, and Arch, and LFS. Sheesh.) ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYew0ACgkQeCCY8PC5utDzDQCdHD8WAk25da2bYerVQiUX1UnZ 5VkAn1xPsLSMnYgqdMJjQMIMTeUgrhxA =p2mD -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon Mobility X1600 texture garbage w/ compiz skydome
Michel Dänzer wrote: On Sun, 2008-09-21 at 13:35 +0200, Soeren Sonnenburg wrote: ( this is a resend to xorg-driver-ati. this message got posted to xorg as I was not aware this list exists as it is not listed on http://lists.freedesktop.org/mailman/listinfo/ ) lists.x.org != lists.freedesktop.org :) I am on debian-experimental (xorg 1.5, mesa 7.1, xserver-xorg-video-ati 6.9.0+git20080826.a3cc1d7a-2 ) and running compiz 0.7.6. While things work mostly OK, the skydome displays random garbage and the bottom and top texture of the cube/cylinder displays more or less the texture distorted (some lines are ok, some not) + random garbage inbetween. [...] (**) RADEON(0): Option GARTSize 64 (**) RADEON(0): Option FBTexPercent 0 Try without these two options. For the former, values larger than 32 (which is also the default now) aren't handled correctly automatically for PCIe cards. For the latter, the Mesa r300 driver doesn't properly handle GART texturing, so it needs to have texture space in video RAM. For compiz, make sure your skydome isn't larger than MAX_TEX_SIZE/2 in any dimension. For your chipset, it would be 2048x2048. Any larger, and you'll get a very, um, fun skydome glitch. (Compiz doesn't properly check this...) Also, for UT2004, turning off FBTexPercent should do the trick. ~ C. -- ~ Corbin Simpson [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
