Re: 8k resolution video causes X Error
/usr/lib64/xorg/modules/drivers/nvidia_drv.so [ 180.902] (II) Module nvidia: vendor=NVIDIA Corporation [ 180.902] compiled for 4.0.2, module version = 1.0.0 [ 180.902] Module class: X.Org Video Driver [ 180.902] (II) NVIDIA dlloader X Driver 285.05.09 Fri Sep 23 17:33:35 PDT 2011 [ 180.902] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs So I take it we are running the nvidia driver, not the nouveau driver. You are - so you need to discuss that case with Nvidia not Xorg if you want to make much progress on that driver. Alan ___ 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: Problem with Intel emgd (GMA500)
xrandr: Failed to get size of gamma for output default xrandr: screen cannot be larger that 640x480 (desired size 800x600) xrandr: Configure crtc 0 failed xrandr won't allow you to change modes on the fbdev interface. The libdrm tools will if it detected any other modes, however it tries to default to the reported LCD panel size so you ought to get the size of your panel as the default behaviour. Alan ___ 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: Problem with Intel emgd (GMA500)
I've no idea what is wrong. With vesa driver it works, but very slowly. Any help will be appreciated. The current kernel has a GMA500 KMS driver that will give you sensible native modes with the framebuffer driver as well as support multiple outputs properly. There are some basic 2D accel hooks but at the moment they are not being used anywhere, in part because it appears that for X the CPU + fbdev + shadowfb performance is as fast anyway. 3.0 is fairly stable except for suspend/resume, 3.1 should have that fixed, and I hope for 3.2 to have wickedly fast console scroll acceleration merged upstream as well. The 3D is closed third party non Intel stuff which means it's not supported and probably never will be. There are (as you have found) a couple of ancient rather wobbly setups using a kernel driver plus proprietary firmware and closed X server, but those are all old, and all contain known security holes so are not much of an option either. Alan ___ 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: xf86-video-dummy with randr support - is anyone else interested? Alternatives?
Alternatives? I cannot find any other driver that would act as a virtual screen like xf86-video-dummy, but would provide a RandR-compliant framebuffer for me. I don't think Xephyr, Xdmx, Xvnc, x2x and whatnot others can help me here, Awesome needs to see something as a regular RandR screen next to the built in panel. Or is it possible to fake this display somehow while being forwarded to another Xserver copy? Actually they can do. The way I have my little one set up for debugging and devel work is to create separate X server for it and then I can bind input devices to it or use x2x as well as using the input filters to make it grab the actual touchscreen. If you want it to just hotplug you'll need udev rules as well, and depending upon your auth needs possible gdm scripting. If you want persistence you could look at making your main desktop bigger than the display and then using x11vnc to export the undisplayed corner to the displaylink server ? In case any awesome devs are here, would it actually make sense to patch it on awesome side? Which work list is greater? The big problem with RandR and friends is that the moment you include a Displaylink device all your 3D vanishes on all the desktops. This is quite limiting and will force various apps into software rendering or just not working as they were before. If you use x2x + dual server you can't move apps between the displaylink device and the main display but your 3D etc still work. The proper solution is an X server setup which can handle 2D only DRI capable devices in multihead by using one of the 3D devices to do offscreen rendering for the 2D head. That however seems to be a big project. Alan ___ 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
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. Except that you need to write a lot of input drivers - for Linux, for OpenBSD, for NetBSD, for Dragonfly etc.. In the Linux case yes you could write an fpit to Linux input layer ldisc but that only fixes the world for a single OS. Re; polling - a lot of these fpit devices have weird IRQs for the serial, you may find they are not in fact polled but need a suitable IRQ forcing. ___ 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.
Can anyone think of a nice way to handle this? The only thing I can think of is to do some sort of collision/overlapping detection and then be careful about the bits of background that gets copied between the penguins in question. Or accumulate all your updates then merge them and do them 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. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing X really doesn't care mich about lots of windows. A modern X server should also handle lots of penguins Ok. The old X implementation was very bad at complicated shaped windows but nowdays it seems much better. ___ 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: 3D in Display link based devices?
I think the underlying framework is already there. You can create a GEM surface for the 3D card to render into which doesn't need to be a display surface, then you need to get it onto the USB graphics device. Alan ___ 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: Set the application always on top
I have only one screen. The machine has no keyboard and no mouse : only a touchscreen. The flash application IP is connected to a java application. Flash application and/or Java server have to restart in order to change parameters (language ...) I will look to your solution :) In which case override redirect should do the trick as it'll let you open a full sized window without the WM meddling ___ 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: Set the application always on top
On Tue, 22 Feb 2011 18:37:04 +0100 MONDON Daniel daniel.mon...@lpgsystems.com wrote: Hi, I am looking for an X command (?) to set my program on top level. In fact, this is a SplashScreen shown during transition between two program execution : in order to mask windows during closing and loading. You can override the window manager if you must and place the window yourself but the rest is normally to annoy the users even more than watching windows change. Plus if they have multiple screens or displays onto one screen you are almost guaranteed to do something daft like land the splash screen across a monitor join. Why not just unmap the old windows, open a simple progress bar in a window the user can hide and defer mapping the new windows until everything is actually ready ? ___ 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: Failed to Initialize the NVIDIA graphics device - Samsung TV LN46A650
On Mon, 14 Feb 2011 19:20:48 + (UTC) moodyj...@frontiernet.net wrote: I'm running Fedora 12 kernel 2.6.32.26-175 and can't get Xorg to initialize my Samsung TV LN46A650. No nVidia splash screen, just a black screen with fast blinking cursor. The system does boot and Xwindows is running - I can VNC in to a full GUI desktop. Here are my system details: If you are using the Nvidia proprietary driver you probably want to ask this on the Nvidia forums. ___ 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
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). Gtk is usually faster than the naïvely programmed Xlib apps because it does actually have a modicum of sense about things like batching. Some of the stuff built (or perhaps congealed is a better word) on top of Gtk is a mess, but Gtk itself does the job rather well. coding either directly for X or using lighter toolkits (i.e. fltk) has some point, and saves royal withdrawal after royal painkillers. Yes you can possibly write a finely tuned Xlib app that beats Gtk on some cases, but you'll have to write your own handling for window manager negotiation, client side fonts, resources, and so on. You could also no doubt make it faster by rewriting the entire app in hand tuned assembler. Neither is a smart idea if you want to get work done. Apps don't get written in Xlib normally, and haven't for years. Even the game people rarely touch Xlib because OpenGL is better for that job nowdays. Alan ___ 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: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) I think that is a little naïve. There is a difference between vendors attempting to use Xorg as a dump and run for crap code, and being a bit more relaxed about obscure drivers that are otherwise unmaintained. The latter makes a good ground for people to learn the craft, as indeed can staring at some of the finest vendor Vogon poetry and turning it into something resembling C to help get it upstream. X is a bit odd in other ways - it's history has been rather closed at times which hasn't helped as it means there isn't a long standing large developer base. It consists (for much of the relevant stuff) of a very small number of very large and very complex drivers for insanely complex bits of hardware. That doesn't have the same scaling for newbies the kernel does where there are hundreds of random USB widgets you never knew you needed that make good starting points. Maintaining the old Voodoo2 driver was a bit like minor kernel hacking. I can't even imagine how KeithP fits everything he needs to know for the intel drivers into his head. Alan ___ 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: Respository vandalism by r...@...fd.o
See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? He ensured the problem was noticed, and that it got out to people who depend upon the repository being secure and properly managed. In this case that turns out to have ensured the offender admitted to something silly but if it had been a more serious attack it would also have ensured people relying on the repository knew what was going on. Security through bad mouthing the messenger for raising the issue is normally reserved for government ministers, IMHO it has no place here. ___ 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: Respository vandalism by r...@...fd.o
It's on a separate branch, not master. (Doesn't mean it's right, just that it's not actually going to cripple anything or waste time for anyone who doesn't ask for it.) And how many other un-noticed commits did this person make ? Until you know that you have to assume a complete compromise. Alan ___ 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: Respository vandalism by r...@...fd.o
What would you suggest should be done next? Checking logs for traces of this? Those which could reveal this information might be gone already. Looking for anything which is in the tree but not in or not matching the mail archive. Sounds like a job for a perl nutter 8) And chasing down who did it - because if its someone who did something silly while drunk one night they could save a whole lot of harm by just owning up and apologising. Alan ___ 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: mixed OpenGL vendor drivers
So I read this as, redistribution is fine with at least Nvidia and AMD. And for legal purposes allow me to remind you that the Linux kernel is subject to the GNU public license v2. This has specific constraints on derivative works and large numbers of contributors (me included) have never given anyone permission to ignore that. Whether the Nvidia binary driver is a derivative work is a matter for lawyers, but you should be aware of the licensing requirements for the kernel. (and I am advised to inform anyone of this when it comes up so that if it ever does end up in court it can be demonstrated that the infringement was likely to have been knowing) Alan ___ 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: siliconmotion driver hacking [xf86-video-siliconmotion-1.7.4]
What I would like to do is compile a 'portrait' video driver. Essentially, I think I just want to swap the x and y values for each pixel, thus creating an output for a display in portrait mode. See xrandr I figure that there is a bit more to it than just doing a global replace data_x with data_y and change screen resolutions to 600x800, but is there any show stopper that would prevent a plan like this working? I guess I would lose the hardware video decoding, but aside from that this idea could work, right? Depends on the hardware and what video acceleration it has. Colour conversion and scaling are not for example orientation dependent in the same way as a full offload. ___ 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
On Thu, 11 Nov 2010 16:36:59 +0530 vijay singh testmrs@gmail.com wrote: Hello, is their any link or input which can give me Xorg video module driver for PowerVR chipset (SGX535). 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: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Some ideas
This already exists, it's just not bundled with X.Org due to the different license - TigerVNC uses current Xorg sources to build both Xvnc and a vnc.so loadable extension module that are compatible with current servers and extensions. http://www.tigervnc.com/ (Providing you don't have any non GPL compatible drivers loaded - eg some vendors binary only ones...) You don't actually need so urgently with the damage/compositing extensions because you've got a pretty good idea what needs adjusting. X11vnc is quite passable without being part of the server. 2) Low priority: Dynamic runtime loadable and unloadable drivers. With the possibility of hot pluggable devices, has this been considered? Already done for input devices. Graphics is harder, but do you really have systems where you're often hotplugging PCI-E cards while the system is running? (Yes, I know about USB-connected DisplayLink devices, but most work around hotplugging those has been configuring them as separate X seats/sessions, not incorporating them into a running server.) Unfortunately - although to use them properly is tricky anyway as the expectation is that the main video card composites the image in off screen ram and you then fire at at the USB, possibly using nutty 3D card hacks on the way to work out which chunks changed. That means you are trying to allocate resources on one device for rendering for another. Doubly fun if you hotplug the device doing the rendering work. Some of this also needs kernel work - being able to give up a device and claim a device reliably when it is being passed between users requires a couple of bits the Linux kernel currently lacks except for tty devices. This is much of the same stuff you need to run X as the user not as its own user or root. Alan ___ 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
To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. PEX was dropped in what was it 2004, so six years ago... taken you a while to notice and it was dropped because nobody could actually find a single user of it. By the time PEX stuff ever approached any real implementation OpenGL had buried it because of the need for things like texture mapping. But then if you wanted people to believe you were genuine you wouldn't I susppect be posting from what the analysis tools say is a new google account and without naming the company. You'd have approached X.org as a company through management and had a rational discussion about the best way to support the extensiosn you need (or had that discussion with your Linux vendor) and spent a lot less by making sure the commercial justification was there for someone to support it. Still if you'd rather rewrite all your code, pay Microsoft zillions and not pay a consultant to do the updating on the modules you need for resubmission (or even pay an undergrad minimum wage to knock you off a package of an old build) don't let me stop you ;) Alan ___ 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
disabled, removed extensions. How many of these are disabled as a result of actual broken code, vs, how many are disabled because, we don't like how it looks? Most are disabled because they don't work (and often havent worked for ages, or have been disabled by distributions by default for years and nobody noticed), others are just not shipped by default and probably work (eg Xprint still gets some love now and again). There are other things to think about - eg X extensions that are old and unmaintained often pre-date the world of the 'leet hacker dude' and the coding isn't neccessarily as robust as it should be. Enabling such things by default is exposing people to a risk with no economic justification. Really the only way to maintain an X extension is to have someone who uses it and has a true self interest in keeping it working, whether because they work for a vendor whose customer pays good money for a system that delivers the feature, or because they need it in-house. The extensions are still there in the history of the codebase. It just needs someone who needs that extension to check it out, rebuild test and debug it. If it's cheaper to maintain it than port the code using it then it makes sense for those who can save money to maintain it or pay someone to do so, if not then it's probably time to go. Rational economic behaviour ought to resolve such questions (ok given perfect information I admit) Some of the ancient video drivers would certainly be more expensive to port than to simply replace the few remaining cards for example. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.Org Foundation Board of Directors 2010 Election
On Tue, 16 Feb 2010 17:07:32 +0100 Matthias Hopf mh...@suse.de wrote: On Feb 16, 10 07:26:35 -0800, Keith Packard wrote: Our outstanding obligations today are MIT hosting for this year ($3000) and travel expenses for FOSDEM 2010 ($660). Not that it matters too much, but $3000 sounds pretty hefty for hosting. OTOH I don't know hardware, bandwidth, or what is included (backup etc.). Seems pretty extrodinary. Exactly what can't say bluehost provide at $3.95 a month that MIT can at $250/month ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) (or use Xcb if you aren't quite so serious) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. And how is your Gujerati and accessibility ... ? I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. A lot of queries you can avoid the overhead because you can batch queries and answers. You can also stall one thread on a query while others do things. You might be waiting for one window to expose but that doesn't mean you can't be querying other stuff or rendering into other windows at the same time. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. Outside of dinosaur land someone already did - its called xcb. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pocket pc as X screen?
On Wed, 27 Jan 2010 12:12:19 -0500 Dave Bender codeh...@gmail.com wrote: Hi, I was wondering if there was a way to use a WiFi or USB connected CE/Mobile PocketPC as another X screen. It would be a good use for old PDAs. VNC.. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
For all: is there a policy about it ? Ignore it. If it really bugs you add it to your spam filter matches and they'll never trouble you again. They have at least kept it shorter than some of the gems attached by companies and used the word please ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
On Sun, 26 Jul 2009 12:06:41 -0700 David Moffatt david.moff...@access-company.com wrote: Responding to the thread about mapping hardware scan codes -- X key codes and keyboards with 248 keys. Perhaps the solution is to take the hardware scan code -- Symbol problem out of the X layer entirely. Let the OS deal with that in its own manner. X has to be OS independent. It is perfectly sane in the X world to type a key on one OS for an application running on another because you have remote display functionality. Please don't top post and in particular don't attach entire digests to your mail or we'll all soon be using bittorrent to read the list. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: cyrix driver
On Tue, 14 Apr 2009 16:21:14 -0400 Cliff Brake cliff.br...@gmail.com wrote: It seems that the xf86-video-cyrix is not in X 7.4. Is this the case, and is there any way to get the cyrix driver working with 7.4? Or is there another driver that should work? I'm using a old geode board. If you have VSA2 firmware then the geode driver ought to work. If you have VSA1 firmware you'll need to resurrect the cyrix driver which as the VSA firmware is very sensitive to the order of vga emulated writes and the newer Xorg ordering confuses it might be quite hairy - or if you don't need acceleration use the vesa driver and have a quieter life. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
if someone massively resizes a window with backing store (remembering it can be mostly offscreen) your X server explodes. Remind us why turning it on for all windows all the time (Composite) is better than for one window? ;o) There is nothing in composite that requires you redirect everything. Backing store was mostly a mistake at the time of introduction (as opposed to save unders which are a least reasonably resource bounded). It was overused, sure, but the idea suggested elsewhere in the thread of using a pixmap and setting that as the window background is essentially doing the same thing (a form of double buffering). Without all the horrendous complexity and bugs that save unders caused. The fact you can do it better other ways is even more argument for the fact they are no longer on. (Not that save unders actually worked properly in most XFree/Xorg releases in all cases) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, 9 Apr 2009 13:22:45 +1000 Torgeir Veimo torg...@pobox.com wrote: 2009/4/9 Alan Cox a...@lxorguk.ukuu.org.uk For proving fancy anti-aliasing isn't just for new apps or integrating it into old ones, KeithP's rework of twm with render is glorious... Is there a screenshot somewhere of the rework version? keithp.com/~keithp - A New Rendering Model For X - in the more info and pictures bit ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
He might have. His response doesn't contain any useful information. I think you are confusing not containing information with not understanding it tie-in on the web-page, that's problematic since it's only the portion of the API which has been unchanging for an extended period of time that would be (in the normal sense of the word) stable. For bears of very little brain it works like this During development people add new ideas. If some of those turn out to be dumb then they don't make the stable release but are taken out again. They are taken out before the new release. If you download the development version of the program you will find interfaces that will then be dropped or changed. They will be dropped or changed before the next stable release. If you use the official stable releases then you do not have to worry about this. Interfaces that make the stable release will remain stable. If any of the words I have used are too long please ask for help. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
That's http://keithp.com/~keithp/talks/ Nice pictures. I also like how they demonstrate anti-aliased fonts are unusable at small sizes. Each to their own, I know which I find easier to read and I know what extensive studies say people prefer as well. Also be careful with the images to view them full size - if your browser is scaling them because of their size you'll get very funny and misleading results. Not of course that anti-aliased fonts are really an X issue anyway - it a client side matter... Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
= there can't be that many applications using it if it was moving all the time So the fact there are lots of applications using it should have told you that your interpretations were suspect = there can't have been much testing by real applications at that point See above. Pretty much the same way you tend to avoid new! improved! filesystems until at least one of the big distributions has switched on it as default. Not widely used code is not stable code yet. Such as Fedora Core.. umm (searches back and back) 6 and RHEL5 ? quite a while ago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
I've always wondered why. It makes no sense. The network-oriented nature of X means you should do your best to send as little data as possible, and prerendered pixmaps are nowhere near minimal. Why isn't fontconfig/xft and even pango in the server where it seems to belong? It turns out to be a win on round trips (latency) to put it client side, it keeps the complex hard work on the client and suprisingly it turns out to be pretty even on bandwidth for most cases. Latency is the big one - networks get faster but the speed of light doesn't show any sign of altering too much. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Is there equivalent functionality with Xft? And whose responsibility it is now, if this functionality is not here: applications, toolkits or something else? Xft provides the DPI information, the desktop permits the DPI to be configured providing some muppet hasn't decided that is too complicated and taken it away from you. From memory Gtk and Qt use Xft values if available and the server reported DPI for the display if not. In the perfect world the monitor would report the DPI reliably to the Xserver which would adopt it and everything would just work. Unfortunately monitors report rather varied things, the dominant OS product appears to ignore the monitor value entirely (so the monitor doesn't get corrected) and everyone forces an OS dependant DPI in their desktop ignoring all the monitor info. Wile for most purposes the end result of that entire process is 96 Pango and friends deal in points so can provide what you want. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
And in the past, we never had the viewing distance in X11's design: our presumption was then always desktop monitors, viewed at the usual desktop distance). It is entirely missing from the core protocol. One problem is that this is application dependant. I will be at normal viewing distance for typing and editing. However I suspect I am not alone in having other apps (eg the mail status icon, movie players, ...) that I view with the chair further away (working on other parts of the desk) or when walking past the display from a distance Nor I suspect will tracking help this - a display that zooms based on user distance is probably going to induce motion sickness rather than joy ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Dropping support for automatic backing store while at the same pushing for a design, composite, that is all backing store all the time means one of three things : lazyness, incompetence, or a big honking design issue in the server. So, which one is it? Backing store has long been off by default in Xfree/Xorg. Fundamentally its a dumb design issue in the concept of backing store - it means the server has to consume huge amounts of memory keeping copies of stuff and if someone massively resizes a window with backing store (remembering it can be mostly offscreen) your X server explodes. Backing store was mostly a mistake at the time of introduction (as opposed to save unders which are a least reasonably resource bounded). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
if someone massively resizes a window with backing store (remembering it can be mostly offscreen) your X server explodes. Hence the pleasure that is composite. Compositing only has to deal with the visible resources. The design very carefully keeps the rendering determined by the size of the bounding heirarchy managed by the compositor. Different model and as a result a rather more effective and controlled use of resources. Note that your compositor doesn't have to do fancy 3D effects, its pefectly valid to have a local compositor wm using a compositor solely to mask network latency and implement utterly boringly conventional 2D window behaviour. What you can't do with it is backing store, because the semantics are different and have to be to avoid the backing store unbounded resource problem. SaveUnder is a good deal more elegant, although horribly nasty stuff to get right as you have to redirect drawing into a different offscreen pixmap. Once you are trying to do anything interesting and modern the delights of mixing direct rendering and saveunders are perhaps best left to the horror movies. Again compositing handles this cleanly and elegantly, and you can use compositing solely for simple 2D resource buffering and management far more effectively without breaking everything else interesting. If you want to appreciate the joy of saveunder just scan bug databases of all the vendors of X servers for saveunder bugs... Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
How standard is Cairo? The proof-of-concept app from 15 years ago still works fine because it's only got two dependancies: Xlib and libc. It works everywhere for the same reason. If I added Cairo as a dependancy, would apps still work on 100% of Linux systems, and would they still work unmodified 15 years from now? I don't think anyone here can promise you any given piece of software will last 15 years, but given GTK and Firefox use Cairo (gecko not widget-side only), OpenOffice.org is being converted to use it, and they're all massive codebases with huge install bases, I'd say the and evince and inkscape and various other key apps chances of cairo not being deployed on a current system, or going away in the next 5 years, are pretty slight. It also seems like the original question has a small confusion. Cairo and render go together, but cairo is perfectly happy with a non render capable server (or win32 or all sorts of targets), just a bit slower. Similarly pango sits on top of cairo. Render coverage is pretty good - even X-Win32 and the like support it. However even without render a cairo app should display correctly on the 15 year old X server, although a cairo using app might take a while to run on a 15 year 25MHz 386 PC :) Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Why would an application programmer want to be using Xlib directly ? There is good documentation for things like pango and cairo but then you've clearly not looked. I would imagine nobody bothered to reply to such queries because they though you should learn to use a search engine. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. I'd be very surprised if I was alone in this situation. Probably not although I suspect the need to provide accessibility in much software today is finally burying the hatchet. Being condescending and insulting is not helpful. I was replying in a style consistent with your email In a fairer universe, I'd be able to step up and offer the time necessary to learn the changes and write the documenation folks like me seek for X.Org. Though, that may be the help that is needed -- I've been told more than a few times that documentation I write is not easily understood :-(. I'd be happy if I had the time to support the back-compatibilty in X core functionality that we're depending on. Alas, this universe is not so kind. There shouldn't be any breakage of compatibility in old old apps. You may have problems with fonts and with some extra libraries where the distribution vendors no longer ship those extensions by default or at all. That is much more a distribution change and since extensions are exactly that quite allowable (if annoying in some cases) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, 24 Mar 2009 17:33:16 +0100 Tino Keitel tino.keitel+x...@tikei.de wrote: On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: [...] be possible to use DRI and Xinerama in this configuration, or is that The Intel Xorg driver doesn't work with Xinerama anymore. It just crashes if you enable Xinerama. The last version of the Intel driver I know that works with Xinerama is 1.7.4. Is that due to xinerama or is that the broken dual head support ? Forcing Option Noaccel seems to fix the hang in X if you have 2048 pixels width of display on Intel video (even though it claims anyway to be disabling acceleration it apparently doesn't do it right) Without that hack you can't do large displays on things like Fedora 10, only on Fedora 9 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
I have looked at the source code for X.org and the savage driver. I cannot really quite understand it at all. Is there a guide to describe and document the X.org internals in detail? There are documents for EXA and XAA. The majority of each driver is shared code so if you've got a chipset specific leak as it sounds then you can should only need to look at the driver specific code. If its platform related you may need to dig into os/hw but again this is all isolated from the core code. Fortunately most drivers do very little private memory allocation so it shouldn't take long to check all the cases. Also worth running the same test on another OS to pin down the trigger ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Wed, 18 Feb 2009 18:22:21 -0800 (PST) milnser43...@yahoo.com milnser43...@yahoo.com wrote: There are very serious and severe memory leaks under X.org with the savage driver You forgot to attach the fixes At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, You forgot to volunteer to maintain them - not that I find you believable. The idea that anyone uses PEX is rather implausible. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current support and roadmap for discrete graphics card hot switching
On Thu, 15 Jan 2009 10:21:53 + Albert Vilella avile...@gmail.com wrote: Hi all, What is the current support and roadmap for discrete graphics card hot switching in Xorg? OLPC does automatic switching of display controller for power management. There are currently ~40 users of Sony Vaio Z series using Linux that would like this feature to be implemented. See: https://launchpad.net/~sony-vaio-z-serieshttps://launchpad.net/%7Esony-vaio-z-series Perhaps they can all extract the documentation from Nvidia 8) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current support and roadmap for discrete graphics card hot switching
On Thu, 15 Jan 2009 10:39:44 + Albert Vilella avile...@gmail.com wrote: What is the current support and roadmap for discrete graphics card hot switching in Xorg? OLPC does automatic switching of display controller for power management. Interesting. So the OLPC also has a discrete and an integrated graphics card? Are these Intel or what brand? It has a dumb frame buffer that can run with the main video card turned off, so the image can be updated on the dumb fb and the main video powered down as much as possible. None of it is Intel, Intel are the folks who compete with OLPC ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current support and roadmap for discrete graphics card hot switching
Right, which reduces it to a simple power management issue akin to powering down the 3D core on any modern chipset when you're not doing any rendering. Adding different devices with separate drivers is another matter altogether. Isn't dual driver support logically equivalent to xrandr mirrored to both with either one or the other currently a 'switched away' vt ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: More Displaylink stuff
- The key is likely 16 bytes, which are sent as a control transfer. They appear to be random, but the same 16-byte string can appear repeatedly, esp. if the device is initialized immediately after bootup. If these 16 bytes are equal, then all bulk transfers are also identical byte-for-byte. Changing a single byte in this transfer causes the device to stop working. So is this a hash (eg SHA1 or MD5) or crypto - does the same image generate different patterns as if it is a key ? - The bigger data blocks show a surprising regularity: every 4095 bytes, significant portions of the blocks repeat. This can be found by comparing every byte i with the byte at i+offset and increasing a counter if the two bytes are equal. Do this for all offsets from 1 to n. The result is a series of maxima at 4095 and multiples thereof. Might be worth looking to see if the protocol in use is RDP based, that would be natural way to implement a Windows device with a low bandwidth USB connection for image transmission. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: More Displaylink stuff
so are the subsequent image blocks. However, when I change the background image and reboot the VM, I can get the same key at startup, but different image blocks. So I'm quite sure it can't be any kind of hash. So both encrypted VNC or RDP variants are candidates. It doesn't sound like VNC because you'd expect a series of small messages first - key negotiation. However, assuming for a moment that they just took a big bunch of VNC code and hacked their driver out of that, that could possibly be a reason. or if they are using standard RDP code from Windows likewise. One other question: as mentioned, I suspect that the first big block (which seems to be very regular, and contain some kind of counter every 10 bytes) is a sort of RAM initialization. So, does that mean that it's SRAM, DRAM or something else? And where (some Xorg driver?) could I find an example for such RAM init code? There are probably more samples of that in the Linux kernel. Lots of device firmware downloads are of them form [offset] [some fixed number of bytes] [checksum] Do you know what chip is in the device ? Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Fix sis driver to compile with -Werror=format-security
better patch. On the other hand, if you guys feel there is nothing to be fixed here I'll just keep the patch for the Mandriva package and let it go. Change str to a macro and use that: #define MSG_SEP **\n ... xf86DrvMsg(pScrn-scrnIndex, X_ERROR, MSG_SEP); ... #undef MSG_STR GAK Thats horrible on so many levels 1. It uglifiers the code enormously 2. You are trying to hide a compiler thing by confusing the tools, and the tools will get smarter and work that out Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
We could also investigate using a slab allocator approach for things like data structures that are a fixed size, to keep them from ending up between pixmaps, and hopefully reducing fragmentation that way, but that's also more glibc already does this and you can set a size theshold for mmap backed (thus releasable) objects. See mallopt. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
Why should it be a KDE bug if the X server is leaking memory? I used to The KDE app told X to cache all those pixmaps. X is just doing what it was asked to. The alternative would be that it decided to kill off that client for being dumb. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
On Tue, 9 Dec 2008 16:08:33 + John Tapsell [EMAIL PROTECTED] wrote: 2008/12/9 Alan Cox [EMAIL PROTECTED]: Why should it be a KDE bug if the X server is leaking memory? I used to The KDE app told X to cache all those pixmaps. X is just doing what it was asked to. The alternative would be that it decided to kill off that client for being dumb. There seems to be a little bit of confusion here. It seems to me that Oscar is saying that the memory usage of X remains high even after closing Okular. Even if Okular told X to cache those pixmaps, shouldn't they be fully released after Okular quits? Implementation detail of the memory management. Depending how objects are laid out in memory the pages may not be reclaimable entirely, and the glibc memory manager also makes decisions based upon performance versus swap usage tradeoffs. Those you can btw configure. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
On Tue, 09 Dec 2008 17:06:04 +0100 Óscar Fuentes [EMAIL PROTECTED] wrote: Alan Cox [EMAIL PROTECTED] writes: Why should it be a KDE bug if the X server is leaking memory? I used to The KDE app told X to cache all those pixmaps. X is just doing what it was asked to. The alternative would be that it decided to kill off that client for being dumb. So in your opinion using X as a cache for 500 MB of pixmaps is dumb. I tend to agree, but it is reasonable to expect that when the app closes and the pixmaps are freed, all that memory is returned to the OS? In other words, is a bug that under this usage mode the memory asigned to X grows monotonically? Possibly in the way your vendor has tuned their C library. That isn't X policy or X making the decision but your C library. In the glibc case the behaviour is controllable via mallopt N_MMAP_MAX and N_TRIM_THRESHOLD ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
What is there to maintain, exactly? Fonts are not generated out of thin hair and they need to be updated to keep up with the environment. Only if you keep breaking the environment carelessly. Environment changes can be changes in encoding standards (unicode is still evolving and even low-level hardware stuff such as USB identifiers uses unicode), changes in font formats (use the same And not many USB devices have description strings in linear-B so why does it matter. format as everyone else if you want to tap in the common maintenance pool), changes in hardware capabilities (hardware pixel density is not a physical constant and any change there invalidates the existing pool of bitmap fonts). All non issues. In case you've not noticed every time you use a vectorised font you turn it into a bitmap to suit a changing variety of hardware and encodings. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
In case you've not noticed the so-called kernel console userspace is totally unable right now to turn standard vectorised fonts into bitmaps suiting a changing variety of hardware and encodings, and relies on manually pre-processed bitmap fonts precious few people maintain and adapt to environment changes. Look I really don't give a hoot about your personal font politics, but trying to bring in bogus technical arguments on the assumption that writing a short bit of code to generate bitmap fonts is too hard for people is a bit of a joke. Your other assumptions are crap too. If people need to do the work then the work will be done. Someone will take an hour to zap out the new bitmap fonts and all will be done. The day it gains parity with xorg on this front In the areas the matter it is far superior to X11. It renders consoles faster, it renders on text only hardware, it renders font based VGA consoles (ie most of them) outside of bitmap mode and it uses comparatively tiny amounts of memory. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Just check the console on any random selection of non-us or uk systems and you'll see the current garbage is the console output. Sure it is not a blocker because all the different encodings agree on the ASCII part, but anything outside the 127 first codepoints has a high probability of being mis-rendered. You mean you don't know how to work the console or put it in unicode mode. Diddums. There are things you can't do in character console mode - arabic is quite tricky, most indian languages are a no-go, but the console isn't designed for that so we don't care. The problem is not rendering the font data, it's to get the right font data in the first place. You have not-so-trivial problems like the The font data is out there already thank you. As you keep conveniently forgetting X can already render those fonts to bitmaps suitable for such a screen so the problem doesn't exist except in your mind. limited number of glyphs allowed in console fonts, the fact 4:3 15 VGA screens are not manufactured anymore, etc Untrue but rather irrelevant really. The font size in VGA consoles is defined by the hardware on the video card. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
I mean this is broken every Fedora release or so just by applying system updates without any user-level intervention. I don't think that So file a Fedora bug. The font data is out there already thank you. As you keep conveniently forgetting X can already render those fonts to bitmaps suitable for such a screen so the problem doesn't exist except in your mind. If you're saying X is now needed to render the console I think people will object. Of course not - the majority of Linux systems don't even run X. However for complex languages you probably end up wanting it in user space so you might as well use all the pango and vector font support. Whether you use X as your renderer at that point is just a design trade off. I suspect most PC oriented Linux distributions would go that way. I know the discussions I've had with distributions on these subjects they are thinking X is the user interface full stop, except for debug/things gone wrong. Untrue but rather irrelevant really. The font size in VGA consoles is defined by the hardware on the video card. And the userspace that loads it which is limited to 512 codepoints right now IIRC. They are limited to 512 because the kernel interface uses 512 because most PC video hardware is limited to 512. It's not exactly hard to fix if necessary. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
I just observe few people are working on them anymore, because most applications use something else. I see few people working on them because they are not broken and don't need work. Same with the consoles. We get almost no console patches because the kernel consoles do what people need already. That is the joy of not making random incompatible changes every release - the old stuff doesn't need fixing. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Apriori, there is no sensible default keyboard layout. Yes, there is, and it's called US. This isn't being Anglo-centric or Which US layout - there are several and then you get all the variants with extra funny buttons for internet etc ? anything, and I'm not going to argue the point. Your analogy about Russian versions of Windows holds true still: Russian distributions can change the default to ru. Everyone's a winner. The keyboard default can be deduced from the locale default in most cases so the problem can be solved far more elegantly than praying the user is in one particularly random mid sized country. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
b) given that we're talking about font rendering, how we talk about Linux systems that actually render fonts? The subset that do: Framebuffer drivers, nanogui, and X (particularly non embedded devices). Kernel side font handling is bitmaps or font tables with the work done by the video card and anything else is best pushed out to user space anyway as a browse of the pango source quickly shows. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
But we do that anyway for all the offscreen pixmaps, because unlike windows, we're not allowed to lose their contents. Sounds like another good reason to have DRI manage that and X aware screen switching so you only have to save console stomped areas. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular: Changes to 'master'
On Tue, 21 Oct 2008 09:51:45 -0700 Keith Packard [EMAIL PROTECTED] wrote: On Tue, 2008-10-21 at 18:15 +0200, Luc Verhaegen wrote: Is there a single technical reason why shipping both is a problem? For the same reason the kernel avoids shipping multiple drivers for the same hardware We don't. We have various transitions where we ship multiple drivers for the same identifiers so that users can pick old/tested versus new/featured during transitions. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
On Fri, 19 Sep 2008 08:57:13 -0500 Clayton Shepard [EMAIL PROTECTED] wrote: ... I don't believe this anywhere near the functionality that I am talking about. If I am mistaken please elaborate on how to do it with xrandr. Set the virtual desktop nice and large in size, define both displays as pointing to the same desktop and then xrandr will let you decide which rectangle of the display is on each monitor (and these may overlap) On Fedora you just select multihead in system-config-display to do this. Once you've got the virtual desktop then xrandr will let you move displays around with xrandr --output whatever --pos XxY You need drivers which support randr 1.2 and I believe currently you need a video card with multiple outputs - you can't do this across two cards, but that may have changed by now. Alan -- Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 4096 x 2048 VGA connected 1600x1200+1600+0 TMDS-1 connected 1600x1200+0+0 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
Yes, but that won't display the application bar on each monitor or allow you to rotate workspaces independently will it? What gets displayed on each desktop depends what you put there. If it doesn't do what you want send the relevant application authors patches. As to rotation - yes xrandr lets you rotate or mirror displays individually. I don't know which drivers support individual rotation as I've no real need to rotate displays. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
