From: Diederick C. N. <dc...@gm...> - 2011-03-16 10:02:34
|
Hi John, On Wed, Mar 16, 2011 at 17:17, John Tsiombikas <nu...@me...> wrote: > On Wed, Mar 16, 2011 at 02:43:16PM +0800, Diederick C. Niehorster wrote: >> Some more things I was thinking about as I went through the current >> code (revision 898 with your patches applied). >> - currently using XRANDR or XF86VMODE code is not mutually exclusive. >> code patterns is: >> # ifdef HAVE_X11_EXTENSIONS_XRANDR_H >> # endif >> # ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H >> # endif >> Now, I again don't know about linux, but is it possible both are >> available on a system? And if so, wouldn't the code of both then be >> executed? I suppose that would be a problem? > > Not only possible, but pretty much certain. At least if Xrandr is there, > XF86VidMode is almost certainly there too, unless they decide to remove > support for it in the future. It is generally considered deprecated but > there's no reason to remove it and break old apps I guess. > > To add a bit of history, XF86VidMode was added by the XFree86 project > back in the 90s, to allow switching between a list of configured video > modes in /etc/X11/XF86Config. > > The biggest disadvantage is that the X server doesn't actually change > resolution, just the video mode, so the user can still pan around the > larger virtual desktop with the mouse. So the X.org developers, after > the fork from the XFree86 codebase, decided around the mid-00s (is that > what we'll call that decade? :) that they need a more flexible X server > that can add/remove monitors and allow resizing and rotating of the X > desktop on the fly, and so they added the XRandR (resize-and-rotate) > extension. > > So no, they're not mutually exclusive, and please correct me if I'm > wrong but I think that they can't both succeed at the same time, I > aranged the code so that it falls back to XF86VidMode only if XRandR > fails or is not present. Remember presence of the extension is > determined at runtime with the WhateverQueryExtension calls, not by the > ifdefs. The ifdefs merely allow the code to compile on a system that > doesn't have the proper libraries for these extensions installed. > Generally speaking on an old system without Xrandr support one wouldn't > expect to find the library and headers lying around. But compiling there > would produce a "crippled" freeglut that can't use Xrandr even if the > app connects to an X server that does support it. Thanks for the overview and detailed explanation of how things developed, I always enjoy such stories :) I see indeed how you arranged the code indeed. fghRememberState will return if XRandR is present and the current display mode is successfully queried. For fghChangeDisplayMode and fghRestoreState I am not sure however. It might be that the resize fails using xrandr_resize though fghRememberState previously succeeded using XRandR. In that case, the code will continue by trying the XF86VidMode extensions. Can those be mixed like that safely? Maybe it is best to set a flag at init time (in fghInitialize or the first time that fghRememberState is called) which based on XRRQueryExtension and XF86VidModeQueryExtension determines which to use. >> - your current code only supports changing the resolution, not the >> refresh rate through XRRConfigCurrentRate and >> XRRSetScreenConfigAndRate > > True, and I apologise, I'll fix that soon. I was under the impression > that XRandR doesn't allow refresh rate changes, but I see now that this > feature was added in XRandR v1.1. I'll fix the code to query the > extension version and use it conditionally. Thanks! >> I understand if you don't want to mess with this more, and wouldn't >> mind to hack it in and send the patch to you for testing, >> >> In any case, better wait till John has been able to put in the patchs >> I just sent, or you won't get the -1's to begin with... > > No no, I will :) > I'll make a patch after the rest of your patches go into the svn. Hehe, you're getting sick of changing my C++ style comments ;) Its more fun of course to hack it yourself than to fix my mess! Best, Dee |