Re: X11 fullscreen
On Fri, Jan 29, 2010 at 06:34:37PM +0600, Mikhail Gusarov wrote: Twas brillig at 23:29:43 29.01.2010 UTC+11 when rjs...@netspace.net.au did gyre and gimble: RS xcb is designed to preserve the Xlib api. I prefer to architect RS things completely new and efficient. Laughed out loud. Sorry, could not resist it. Isn't that the point where people start mumbling Wayland under their breath? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 12:35:32PM +0100, Alan Cox wrote: 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 That's http://keithp.com/~keithp/talks/ Nice pictures. I also like how they demonstrate anti-aliased fonts are unusable at small sizes. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 11:31:18AM +0100, Alan Cox wrote: If any of the words I have used are too long please ask for help. In-ter-fwhat? Oh, fuck it, I'll go get a beer instead. Seriously, let's go back to that sentence again: Please download one of the latest releases in order to get an API-stable version of cairo. A reasoning one can have, and that's the one I would have, is: You have to download the latest release if you want to have the correct API = the API wasn't stable until very recently = there can't be that many applications using it if it was moving all the time = there can't have been much testing by real applications at that point 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. Looking around the website, there is no information I can find w.r.t real world use, stability or even speed and acceleration. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 02:05:51PM +0100, Alan Cox wrote: Each to their own, I know which I find easier to read and I know what extensive studies say people prefer as well. To each their own indeed. 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. Oh yeah, I'm careful with that. Not of course that anti-aliased fonts are really an X issue anyway - it a client side matter... 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? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 02:25:14PM +0100, Alan Cox wrote: = 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 If the cairo website gives a list of noticeable applications using the library, it's *very* well hidden. Remember the context: Thomas wanted to know how standard cairo is considered to be and went to the website for the information. What he found there made him think, erroneously or not, that it's nowhere near stability yet. And Behdad flamed him for that. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 09:31:01AM -0400, Jim Gettys wrote: If you look at our paper here: http://keithp.com/~keithp/talks/usenix2003/ You'll discover that the font metadata turned out to be as large as the glyphs actually used. And client side fonts with server caching therefore turns out to be a wash as far as bits transferred in practice, while avoiding a huge number of round trips to get font metadata (which was always inadequate), and *horrible* for application performance at starup. At least in theory you do not need more than one round trip per used font to get font metadata. Bulk-sending the list of supported characters and associated metrics in one message for caching in the client makes sense. Sending the list of existing fonts is costly but otoh fc-list :'s result is 20 times smaller than xlsfonts's. So the X11 core font design is fundamentally a mistake, which we fixed. Someday somehow I'll try to do some tests to check whether that's really true with a better optimized protocol, because right now everything that uses xft over a ssh tunnel is an horrible pain in the ass, while stuck-in-the-past applications like xemacs are way, way more responsive. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 12:55:09PM -0700, Corbin Simpson wrote: 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. You could say the exact same thing of pixmaps. After all, an implementation systematically answering BadAlloc to XCreatePixmap would be perfectly compliant. And there would be people here to say you shouldn't be using pixmaps anyway, you should use textures, *duh*. 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? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 09:28:47PM +0100, Alan Cox wrote: 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. Hence the pleasure that is composite. Backing store was mostly a mistake at the time of introduction (as opposed to save unders which are a least reasonably resource bounded). I actually meant save unders, which is what has been dropped. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 10:37:27PM +0200, Stephane Marchesin wrote: I never saw any of the people who complain here submit a single patch for their issues, yet they are very quick to complain for every change they don't like. Since you don't submit patches, that means one of three things: lazyness, incompetence, or a big honking design issue from your parents. So, which one is it ? There are reasons why I haven't yet participated in the xorg development, but somehow I suspect you're not interested. I *am* interested by the answer to my question, but you don't seem open-minded enough to realize it. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 10:15:44PM +0100, Alan Cox wrote: 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. That would be something interesting to add to fvwm2. You know if there's decent docs about that (what an appropriate thread name) if it's once again source-diving territory? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 11:47:28PM +0200, Nicolas Mailhot wrote: 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 chances of cairo not being deployed on a current system, or going away in the next 5 years, are pretty slight. While it seems highly probably that something called cairo will still exist in 5 years, whether it will be in any way compatible with current's cairo seems on the other hand highly improbable. Outside of the kernel compatibility seems to be considered unimportant nowadays. Add to that explicit measures against shared libraries and you end up with a very short lifetime for both source and binaries. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, Apr 09, 2009 at 12:20:04AM +0200, Olivier Galibert wrote: On Wed, Apr 08, 2009 at 11:47:28PM +0200, Nicolas Mailhot wrote: 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 chances of cairo not being deployed on a current system, or going away in the next 5 years, are pretty slight. While it seems highly probably that something called cairo will still exist in 5 years, whether it will be in any way compatible with current's cairo seems on the other hand highly improbable. Outside of the kernel compatibility seems to be considered unimportant nowadays. Add to that explicit measures against shared libraries and you end up with a very short lifetime for both source and binaries. That shared was supposed to be static, obviously. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, Apr 08, 2009 at 06:32:09PM -0400, Behdad Esfahbod wrote: This may as well be called joke of the year. Funny, I thought my only 4-years-old xmms-1.2.11 didn't compile with gtk+-2.14.7. Please, do tell me what I do wrong? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
On Wed, Apr 08, 2009 at 07:00:02PM -0400, Patrick O'Donnell wrote: Speaking of which -- the applications I'm maintaining are wedded to using a writable color map, which has always been PseudoColor, which, as you point out, pretty much means 8-bit. I've been toying with expanding the apps' repertoire to accepting a DirectColor visual, but I've noticed that not a lot of servers actually offer one. Would I be wasting my time adding in the necessary support for DirectColor? (Supporting TrueColor, alas, would be a royal pain, given the design of the apps.) You would be. On the other hand, are you sure supporting DirectColor is any easier than TrueColor? The hard part, supported 255 color numbers, seems to be identical, and the 3 per-color palettes don't allow for much in terms of color animation. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Nice theory. Kinda breaks down when you find out that pango_font_metrics_get_approximate_char_width answers 0 on such a subtitution. Pretending that fontconfig/pango is bug-free is just out there. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X12 [wasRe: Zoom Support]
On Thu, Dec 18, 2008 at 06:02:33PM +0100, Nicolas Mailhot wrote: Layout and language are closely related. Basically for a globalized user that types in multiple languages, you have two situations : 1. If his current layout is sufficient for the other language, he will perform a language shift but keep the layout 2. Otherwise he will perform a simultaneous language+layout shift So both are dynamic properties that have similar change triggers and will probably be controlled by the same desktop bit of code (and similarly most apps which will want the status of one of them will also want the status of the other) I'm a globalized user that types in 4 languages or so. I have one common layout for all of them, which is a US qwerty with Multi_key and Kanji keys added. In my experience language choice for input is never at the whole desktop level but at the window or even more often logical subwindow level (file in xemacs, tab in firefox for wikis...). I expect such a language change to stay fixed in the logical subwindow context I do it in. I don't want a switch to english in my grant proposal edition window acts on the mail writing I'm doing with the french colleagues I'm communicating with about it. OTOH, if I was doing layout switches, I suspect I'd hate having it change with the focus. Keyboard layout is semantically linked with the keyboard, so moving the mouse (focus-follow-mouse) and possibly clicking in a window has nothing to do with the keyboard, so shouldn't change the layout (except if what you click on is a change kb layout icon/button obviously). I really think that in terms of mental model, layout changes and input language changes usually don't have the same scope, and the X server and X protocol are at the wrong level for the language changes but at the correct level for keyboard layout changes (under client-side control obviously). OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Modeline autoadjusting problem
On Thu, Dec 18, 2008 at 03:47:23PM -0500, Marc Ferland wrote: Seems like the modeline is adjusted by the driver _even_ if I specified the LVDSFixedMode false option. I really don't know what to do next... How can I force my modeline to the driver? You can't. Looking at the code, there is no way to tell the system you know what you're doing. -mode_fixup is called unconditionally, and i830_lvds_mode_fixup has no toggle to switch itself off. That mode fixup function takes lvds_fixed_mode as gospel, and seems to do part of the chipset programming, so you can't just disable it anyway. Strange. lvds_fixed_mode itself can only come from bios or ddc, not config from what I can see. It's weird there isn't a generic high level way to tell X not to trust the roms and trust the config instead, when it comes to modelines, dpi, things like that. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: As usual, people who care about something are free to maintain it in good shape, since this is how free software works. What is there to maintain, exactly? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: BTW now that almost all the X userspace has been converted to use fontconfig and modern TrueType/OpenType fonts, I expect the level of attention fonts in legacy bitmap format receive to drop sharply, which will ultimately lead to problems kernel console-side. And, as usual, the ones of us that hate antialiased fonts at small sizes can go fuck themselves? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 02:05:24PM +0100, Nicolas Mailhot wrote: Le Lun 1 décembre 2008 13:44, Olivier Galibert a écrit : On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: As usual, people who care about something are free to maintain it in good shape, since this is how free software works. 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. Environment changes can be changes in encoding standards (unicode is still evolving and even low-level hardware stuff such as USB identifiers uses unicode), The bdf fonts use unicode. changes in font formats (use the same format as everyone else if you want to tap in the common maintenance pool), You plan to change bdf/pcf? changes in hardware capabilities (hardware pixel density is not a physical constant and any change there invalidates the existing pool of bitmap fonts). Bitmaps don't change. A 12pt bitmap font at 100dpi is a 8pt font at 150dpi and a 6pt at 200dpi. If you think there's nothing to maintain don't complain if maintenance is not done and things break in a few years. Fonts require maintenance just like every other part of the software stack. Looking at the git changelog for adobe-100dpi you're way overstating the number of changes. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
