Menu
▾
▴
freeglut-developer
|
From: John T. <nu...@me...> - 2011-03-11 00:04:26
|
I just used the game-mode for the first time ever, and noticed that it doesn't work ... :) I don't know for how long it has been broken, or if it's broken on all GNU/Linux systems, but I found a problem with the way ifdefs where used to detect the availability of the XF86VidMode extension. The defines tested are actually not defined in the xf86vidmode.h header file (which was included in freeglut_internal.h), but rather on another file called xf86vmproto.h. I guess that's a recent (?) X.org change that broke our code. I fixed that by conditionally including that file as well, if autoconf detects its presence. That's not the interesting bit though. The interesting bit is that we're still using the XF86VidMode extension for mode-switching, which has long been deprecated in favour of the more recent, and more capable XRandR extension. So, gamemode-fix.patch (attached) fixes the XF86VidMode issue and implements mode switching with XR&R as well. Basically it first tries to use XR&R and if that fails it falls back to XF86VidMode. Another issue I noticed while hacking on this, is that if the user forgets to call glutLeaveGameMode() before exiting (as I surely did in my test program :), then the X server is never returned to the original video mode. Obviously this is a user error, but still I think it's nice to clean up properly regardless. gamemode-atexit.patch (attached) handles that by registering a simple cleanup function with atexit() if glutEnterGameMode is called. Finally when I got the recent source through svn to start hacking, it wouldn't compile because the build system expected to find a demo called Error which wasn't there. I glanced through the visual studio project file in the same directory and it doesn't include that demo program so I guess that somebody recently removed it but forgot to update the autoconf/automake files. Here's a patch that does that: missing-demo-error.patch (attached). -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
From: John T. <nu...@me...> - 2011-03-11 08:48:49
Attachments:
diederick-fixed.patch
|
Apparently I missed an earlier patch for the gamemode code by Diederick C. Niehorster, who was kind enough to send it over, to see how it meshes with my patches (see previous email in this thread). Diederick mentioned that he did mostly windows changes but also a couple of untested changes X11-side. In fact there is very little overlap between our patches, but his X11 changes have some minor mistakes which break the build. I attach his patch, modified to compile properly on UNIX/X11, and with a slight modification to work with my patches as well. The proper order to make everything work is first apply my patches from the previous email over the SVN head, and then apply this one on top of them. Cheers -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
From: Diederick C. N. <dc...@gm...> - 2011-03-11 09:14:36
|
Thanks John! I was hoping someone would test and fix my Linux patches ;) Glad they work together with very little trouble. Best, Dee On Fri, Mar 11, 2011 at 16:48, John Tsiombikas <nu...@me...> wrote: > Apparently I missed an earlier patch for the gamemode code by Diederick > C. Niehorster, who was kind enough to send it over, to see how it meshes > with my patches (see previous email in this thread). > > Diederick mentioned that he did mostly windows changes but also a couple > of untested changes X11-side. In fact there is very little overlap > between our patches, but his X11 changes have some minor mistakes which > break the build. > > I attach his patch, modified to compile properly on UNIX/X11, and with a > slight modification to work with my patches as well. The proper order to > make everything work is first apply my patches from the previous email > over the SVN head, and then apply this one on top of them. > > Cheers > > -- > John Tsiombikas > http://nuclear.mutantstargoat.com/ > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
|
From: Diederick C. N. <dc...@gm...> - 2011-03-14 15:38:21
Attachments:
gamemode-exit.patch
|
Hi John, I've been going over your patches as I'm planning to send John Fay a list of the outstanding patches to make his work easier (seeing he's very pressed for time). It'll be tomorrow that I'll finish that though... On Fri, Mar 11, 2011 at 08:04, John Tsiombikas <nu...@me...> wrote: > I just used the game-mode for the first time ever, and noticed that it > doesn't work ... :) > > I don't know for how long it has been broken, or if it's broken on all > GNU/Linux systems, but I found a problem with the way ifdefs where used > to detect the availability of the XF86VidMode extension. The defines > tested are actually not defined in the xf86vidmode.h header file (which > was included in freeglut_internal.h), but rather on another file called > xf86vmproto.h. I guess that's a recent (?) X.org change that broke our > code. I fixed that by conditionally including that file as well, if > autoconf detects its presence. If the only reason to include xf86vmproto.h header is so that specific preprocessor switch is defined, wouldn't a better fix then be to do condition compilation based on a different switch that is defined in xf86vidmode.h? (this is purely gathering from what you've written, not sure if its all true). That save an unnecessary include and one of those AC_CHECK_HEADERS lines. > That's not the interesting bit though. The interesting bit is that we're > still using the XF86VidMode extension for mode-switching, which has long > been deprecated in favour of the more recent, and more capable XRandR > extension. > > So, gamemode-fix.patch (attached) fixes the XF86VidMode issue and implements > mode switching with XR&R as well. Basically it first tries to use XR&R > and if that fails it falls back to XF86VidMode. Great! I guess the patch however no longer applies to the current trunk. Could you regenerate it and send it to the list/me? I'll them work on the other patches that are outstanding and make sure they apply cleanly on top of yours, before sending them to John Fay. Thanks! > Another issue I noticed while hacking on this, is that if the user > forgets to call glutLeaveGameMode() before exiting (as I surely did in > my test program :), then the X server is never returned to the original > video mode. Obviously this is a user error, but still I think it's nice > to clean up properly regardless. > > gamemode-atexit.patch (attached) handles that by registering a simple > cleanup function with atexit() if glutEnterGameMode is called. Instead of the atexit solution you proposed for resetting the display mode, I'm suggesting the attached patch, which feels less hackish (if you agree). Could you see if that works for you as well? Note that on windows it does not appear neccesary as windows apparently undoes any displaymode changes on executable exit, but its good to have this as normal clean-up behavior of FreeGLUT, good catch! Best, Dee |
|
From: John T. <nu...@me...> - 2011-03-14 21:58:15
|
On Mon, Mar 14, 2011 at 11:38:13PM +0800, Diederick C. Niehorster wrote: > On Fri, Mar 11, 2011 at 08:04, John Tsiombikas <nu...@me...> wrote: > > GNU/Linux systems, but I found a problem with the way ifdefs where used > > to detect the availability of the XF86VidMode extension. The defines > > tested are actually not defined in the xf86vidmode.h header file (which > > was included in freeglut_internal.h), but rather on another file called > > xf86vmproto.h. I guess that's a recent (?) X.org change that broke our > > code. I fixed that by conditionally including that file as well, if > > autoconf detects its presence. > > If the only reason to include xf86vmproto.h header is so that specific > preprocessor switch is defined, wouldn't a better fix then be to do > condition compilation based on a different switch that is defined in > xf86vidmode.h? (this is purely gathering from what you've written, not > sure if its all true). That save an unnecessary include and one of > those AC_CHECK_HEADERS lines. Indeed I thought it rather odd to use that particular define for the conditional code, I think the most reasonable check would involve something like HAVE_X11_EXTENSIONS_XF86VIDMODE_H which is defined by the configuration script. I just decided to make the least amount of changes just in case I'm missing something. Anyway I think you're right, I'll change that and submit a new patch. > > That's not the interesting bit though. The interesting bit is that we're > > still using the XF86VidMode extension for mode-switching, which has long > > been deprecated in favour of the more recent, and more capable XRandR > > extension. > > > > So, gamemode-fix.patch (attached) fixes the XF86VidMode issue and implements > > mode switching with XR&R as well. Basically it first tries to use XR&R > > and if that fails it falls back to XF86VidMode. > > Great! I guess the patch however no longer applies to the current > trunk. Could you regenerate it and send it to the list/me? I'll them > work on the other patches that are outstanding and make sure they > apply cleanly on top of yours, before sending them to John Fay. > Thanks! Yeah I guess I better fix that. Expect a new patch tomorrow. > > gamemode-atexit.patch (attached) handles that by registering a simple > > cleanup function with atexit() if glutEnterGameMode is called. > > Instead of the atexit solution you proposed for resetting the display > mode, I'm suggesting the attached patch, which feels less hackish (if > you agree). Could you see if that works for you as well? I suppose it should work, I'll try it tomorrow as well, and indeed I agree it's much preferable to do it this way. But *please* stop using C++ comments in C source code :) -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
From: Diederick C. N. <dc...@gm...> - 2011-03-15 01:07:32
|
On Tue, Mar 15, 2011 at 05:58, John Tsiombikas <nu...@me...> wrote: > But *please* stop using > C++ comments in C source code :) Ah sorry, I'll try to get a grip on that. I just read up on it: so // is not allowed, always use /* xxx */... :P Will try to remember that! VS allows it, so it might slip through sometimes... Best, Dee |
|
From: John T. <nu...@me...> - 2011-03-16 01:02:37
Attachments:
gamemode_final.patch
missing-demo-error.patch
|
On Mon, Mar 14, 2011 at 11:38:13PM +0800, Diederick C. Niehorster wrote: > Instead of the atexit solution you proposed for resetting the display > mode, I'm suggesting the attached patch, which feels less hackish (if > you agree). Could you see if that works for you as well? Not quite, if the app just calls exit(0) at some point, which if I'm not grossly mistaken it's still the most common way to exit a GLUT app considering that glutMainLoop never returns, then fgDeinitialize is never called, which means fgCloseWindow is never called, and thus glutLeaveGameMode is never called. If we are to handle that case atexit *must* be used at some point. I changed the code to call atexit in fgInitialize, to register the fgDeinitialize function. Then your modification works as advertised. SO... without further ado, here's the final gamemode patch (gamemode_final.patch), which does the following: - fixes XF86VidMode code to actually compile, without including any new headers, but checking for HAVE_X11_EXTENSIONS_XF86VIDMODE_H instead. - implements mode switching using XRandR, and only if not available falls back to XF86VidMode. - adds actual runtime checks for the support of all aforementioned X-extensions before trying to use them. The capabilities of the X server we happen to be connected to doesn't have anything to do with the availability of the necessary libraries client-side. Now I haven't actually tested this with an X server that doesn't support those extensions but I'll do it eventually... It should work though. - incorporates your patch for calling glutLeaveGameMode in fgCloseWindow, and my addition of registering fgDeinitialize as an atexit cleanup function in fgInitialize. With all of the above the build is still BROKEN on GNU/Linux since there's no "Error" demo program included in the svn! My earlier patch that removes that entry from the build files is still needed, so I also include it here for convenience (missing-demo-error.patch). Cheers. P.S. John: in case you still have other patches in your backlog, please apply these here first, I'm not going to go through them a third time. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
From: John F. <joh...@cy...> - 2011-03-16 03:42:12
|
It is done.
- John
On 3/15/2011 8:02 PM, John Tsiombikas wrote:
> On Mon, Mar 14, 2011 at 11:38:13PM +0800, Diederick C. Niehorster wrote:
>
>> Instead of the atexit solution you proposed for resetting the display
>> mode, I'm suggesting the attached patch, which feels less hackish (if
>> you agree). Could you see if that works for you as well?
>>
> Not quite, if the app just calls exit(0) at some point, which if I'm not
> grossly mistaken it's still the most common way to exit a GLUT app
> considering that glutMainLoop never returns, then fgDeinitialize is
> never called, which means fgCloseWindow is never called, and thus
> glutLeaveGameMode is never called. If we are to handle that case atexit
> *must* be used at some point. I changed the code to call atexit in
> fgInitialize, to register the fgDeinitialize function. Then your
> modification works as advertised.
>
> SO... without further ado, here's the final gamemode patch
> (gamemode_final.patch), which does the following:
> - fixes XF86VidMode code to actually compile, without including any new
> headers, but checking for HAVE_X11_EXTENSIONS_XF86VIDMODE_H instead.
> - implements mode switching using XRandR, and only if not available
> falls back to XF86VidMode.
> - adds actual runtime checks for the support of all aforementioned
> X-extensions before trying to use them. The capabilities of the X
> server we happen to be connected to doesn't have anything to do with
> the availability of the necessary libraries client-side. Now I haven't
> actually tested this with an X server that doesn't support those
> extensions but I'll do it eventually... It should work though.
> - incorporates your patch for calling glutLeaveGameMode in
> fgCloseWindow, and my addition of registering fgDeinitialize as an
> atexit cleanup function in fgInitialize.
>
> With all of the above the build is still BROKEN on GNU/Linux since
> there's no "Error" demo program included in the svn! My earlier patch
> that removes that entry from the build files is still needed, so I also
> include it here for convenience (missing-demo-error.patch).
>
> Cheers.
>
> P.S. John: in case you still have other patches in your backlog, please
> apply these here first, I'm not going to go through them a third time.
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Freeglut-developer mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>
|
|
From: Diederick C. N. <dc...@gm...> - 2011-03-16 06:07:49
|
Hi John,
Glad you could get these patches in. I have attached a bunch of
patches against the current HEAD (half hour old checkout now), some to
fix a few small issues with your application of my gamemode patches,
and some unrelated.
- gamemode-unspecified_windows.patch
A small problem appeared in applying the patch to fix game mode so
that it doesn't override unspecified displaymode settings. Putting
the if >0 checks makes FreeGLUT revert to its default values for
those unspecified parameters as I specifically intended the -1 to
end up in FreeGLUT's parse of what the user asks for.
- gamemode-unspecified_X11.patch
Fixing game mode in X11 so that it doesn't override unspecified
settings. This is taken from the version of my patch fixed by John
Tsiombikas, email Fri, Mar 11, 2011 at 16:48, it apparently wasn't
applied before.
- gamemode-testing_windows.patch
Per Diederick C. Niehorster, email Thu, Jan 27, 2011 at 13:59
Fixed that when testing if a gamemode is possible
(glutGameModeGet(GLUT_GAME_MODE_POSSIBLE)), the gamemode settings
you requested get overwritten with those of the current display
- vs2010_project_files.patch
Fixed problem in VS2010 project files where library files were
never copied to freeglut/lib if that folder doesn't already exist
- readme-win32.patch
Adding note on where to find the library files when compiling with
visual studio 2008 or 2010.
Best,
Dee
|
|
From: John F. <joh...@cy...> - 2011-03-17 02:56:18
|
OK, those are in.
- John
On 3/16/2011 1:06 AM, Diederick C. Niehorster wrote:
> Hi John,
>
> Glad you could get these patches in. I have attached a bunch of
> patches against the current HEAD (half hour old checkout now), some to
> fix a few small issues with your application of my gamemode patches,
> and some unrelated.
>
> - gamemode-unspecified_windows.patch
> A small problem appeared in applying the patch to fix game mode so
> that it doesn't override unspecified displaymode settings. Putting
> the if>0 checks makes FreeGLUT revert to its default values for
> those unspecified parameters as I specifically intended the -1 to
> end up in FreeGLUT's parse of what the user asks for.
>
> - gamemode-unspecified_X11.patch
> Fixing game mode in X11 so that it doesn't override unspecified
> settings. This is taken from the version of my patch fixed by John
> Tsiombikas, email Fri, Mar 11, 2011 at 16:48, it apparently wasn't
> applied before.
>
> - gamemode-testing_windows.patch
> Per Diederick C. Niehorster, email Thu, Jan 27, 2011 at 13:59
> Fixed that when testing if a gamemode is possible
> (glutGameModeGet(GLUT_GAME_MODE_POSSIBLE)), the gamemode settings
> you requested get overwritten with those of the current display
>
> - vs2010_project_files.patch
> Fixed problem in VS2010 project files where library files were
> never copied to freeglut/lib if that folder doesn't already exist
>
> - readme-win32.patch
> Adding note on where to find the library files when compiling with
> visual studio 2008 or 2010.
>
> Best,
> Dee
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Freeglut-developer mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>
|
|
From: Diederick C. N. <dc...@gm...> - 2011-03-17 04:06:41
Attachments:
gamemode.patch
one.patch
|
Hi John, Nice work, on the Windows end, all is tested to work well! I have two more patches that came up in testing. The attached one.patch modifies the one.c demo by both trying to enter an impossible mode and, afterwards a possible mode, to see how this is handled. It also uses glutGameModeGet(GLUT_GAME_MODE_ACTIVE) to test if gamemode was actually entered succesfully. The gamemode.patch file makes the error message on a failed mode switch a bit more informative. Best, Dee On Thu, Mar 17, 2011 at 10:56, John Fay <joh...@cy...> wrote: > OK, those are in. > > - John > > > On 3/16/2011 1:06 AM, Diederick C. Niehorster wrote: > > Hi John, > > Glad you could get these patches in. I have attached a bunch of > patches against the current HEAD (half hour old checkout now), some to > fix a few small issues with your application of my gamemode patches, > and some unrelated. > > - gamemode-unspecified_windows.patch > A small problem appeared in applying the patch to fix game mode so > that it doesn't override unspecified displaymode settings. Putting > the if >0 checks makes FreeGLUT revert to its default values for > those unspecified parameters as I specifically intended the -1 to > end up in FreeGLUT's parse of what the user asks for. > > - gamemode-unspecified_X11.patch > Fixing game mode in X11 so that it doesn't override unspecified > settings. This is taken from the version of my patch fixed by John > Tsiombikas, email Fri, Mar 11, 2011 at 16:48, it apparently wasn't > applied before. > > - gamemode-testing_windows.patch > Per Diederick C. Niehorster, email Thu, Jan 27, 2011 at 13:59 > Fixed that when testing if a gamemode is possible > (glutGameModeGet(GLUT_GAME_MODE_POSSIBLE)), the gamemode settings > you requested get overwritten with those of the current display > > - vs2010_project_files.patch > Fixed problem in VS2010 project files where library files were > never copied to freeglut/lib if that folder doesn't already exist > > - readme-win32.patch > Adding note on where to find the library files when compiling with > visual studio 2008 or 2010. > > Best, > Dee > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
|
From: Bill K. <bi...@ct...> - 2011-03-15 01:48:49
|
Diederick C. Niehorster wrote: > On Tue, Mar 15, 2011 at 05:58, John Tsiombikas <nu...@me...> wrote: > >> But *please* stop using >> C++ comments in C source code :) > > Ah sorry, I'll try to get a grip on that. I just read up on it: so // > is not allowed, always use /* xxx */... :P > Will try to remember that! VS allows it, so it might slip through sometimes... Single line // comments were added to the C language in the C99 standard. So, over a decade ago - but full compiler support for C99 is still rare. (As the saying goes, the great thing about standards is there are so many to choose from.) Regards, Bill |
|
From: John T. <nu...@me...> - 2011-03-16 01:07:22
|
On Mon, Mar 14, 2011 at 06:31:42PM -0700, Bill Kelly wrote: > Diederick C. Niehorster wrote: > > On Tue, Mar 15, 2011 at 05:58, John Tsiombikas <nu...@me...> wrote: > > > >> But *please* stop using > >> C++ comments in C source code :) > > > > Ah sorry, I'll try to get a grip on that. I just read up on it: so // > > is not allowed, always use /* xxx */... :P > > Will try to remember that! VS allows it, so it might slip through sometimes... > > Single line // comments were added to the C language > in the C99 standard. Indeed, but I think freeglut is supposed to be following the C89 standard, which is still the generally accepted "standard C" by most C programmers I know. Indeed my feelings about the whole affair is that C99 never happened. C is a small and, mostly, elegant language, feature creep does not suit it at all :) But personal feelings aside, as you said, most compilers (MSVC included) do not support C99 fully (or at all), so if one strives for universal compatibility C99 is not an option. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
From: Diederick C. N. <dc...@gm...> - 2011-03-16 06:43:22
|
Hi John,
On Wed, Mar 16, 2011 at 09:02, John Tsiombikas <nu...@me...> wrote:
> On Mon, Mar 14, 2011 at 11:38:13PM +0800, Diederick C. Niehorster wrote:
>> Instead of the atexit solution you proposed for resetting the display
>> mode, I'm suggesting the attached patch, which feels less hackish (if
>> you agree). Could you see if that works for you as well?
>
> Not quite, if the app just calls exit(0) at some point, which if I'm not
> grossly mistaken it's still the most common way to exit a GLUT app
> considering that glutMainLoop never returns, then fgDeinitialize is
> never called, which means fgCloseWindow is never called, and thus
> glutLeaveGameMode is never called. If we are to handle that case atexit
> *must* be used at some point. I changed the code to call atexit in
> fgInitialize, to register the fgDeinitialize function. Then your
> modification works as advertised.
>
> SO... without further ado, here's the final gamemode patch
> (gamemode_final.patch), which does the following:
> - fixes XF86VidMode code to actually compile, without including any new
> headers, but checking for HAVE_X11_EXTENSIONS_XF86VIDMODE_H instead.
> - implements mode switching using XRandR, and only if not available
> falls back to XF86VidMode.
> - adds actual runtime checks for the support of all aforementioned
> X-extensions before trying to use them. The capabilities of the X
> server we happen to be connected to doesn't have anything to do with
> the availability of the necessary libraries client-side. Now I haven't
> actually tested this with an X server that doesn't support those
> extensions but I'll do it eventually... It should work though.
> - incorporates your patch for calling glutLeaveGameMode in
> fgCloseWindow, and my addition of registering fgDeinitialize as an
> atexit cleanup function in fgInitialize.
That is a very nice solution to register fgDeinitialize atexit. It
works fine here as well :)
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?
- your current code only supports changing the resolution, not the
refresh rate through XRRConfigCurrentRate and
XRRSetScreenConfigAndRate
- A user might use glutGameModeString("@60") to request a change in
only the refresh rate. When the patches that I just sent to the list
are put in, this will work correctly on windows and X11 with XF86VMODE
(hopefully, still untested). in this case, the xsz and ysz inputs to
your function would be -1, meaning "use current", but from reading the
code I think that wouldn't work.Some code should be needed to change
any -1 into the value of the current display mode, as is done for
windows and XF86VMODE (when the patch I just sent is in).
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, which is
less work I guess? 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...
Best,
Dee
|
|
From: John T. <nu...@me...> - 2011-03-16 09:17:15
|
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. > - 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. > 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. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
|
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 |
|
From: John F. <joh...@cy...> - 2011-03-17 04:28:45
|
Done. On 3/16/2011 11:06 PM, Diederick C. Niehorster wrote: > Hi John, > > Nice work, on the Windows end, all is tested to work well! > > I have two more patches that came up in testing. > > The attached one.patch modifies the one.c demo by both trying to enter > an impossible mode and, afterwards a possible mode, to see how this is > handled. It also uses glutGameModeGet(GLUT_GAME_MODE_ACTIVE) to test > if gamemode was actually entered succesfully. > > The gamemode.patch file makes the error message on a failed mode > switch a bit more informative. > > Best, > Dee > > On Thu, Mar 17, 2011 at 10:56, John Fay<joh...@cy...> wrote: > >> OK, those are in. >> >> - John >> >> >> On 3/16/2011 1:06 AM, Diederick C. Niehorster wrote: >> >> Hi John, >> >> Glad you could get these patches in. I have attached a bunch of >> patches against the current HEAD (half hour old checkout now), some to >> fix a few small issues with your application of my gamemode patches, >> and some unrelated. >> >> - gamemode-unspecified_windows.patch >> A small problem appeared in applying the patch to fix game mode so >> that it doesn't override unspecified displaymode settings. Putting >> the if>0 checks makes FreeGLUT revert to its default values for >> those unspecified parameters as I specifically intended the -1 to >> end up in FreeGLUT's parse of what the user asks for. >> >> - gamemode-unspecified_X11.patch >> Fixing game mode in X11 so that it doesn't override unspecified >> settings. This is taken from the version of my patch fixed by John >> Tsiombikas, email Fri, Mar 11, 2011 at 16:48, it apparently wasn't >> applied before. >> >> - gamemode-testing_windows.patch >> Per Diederick C. Niehorster, email Thu, Jan 27, 2011 at 13:59 >> Fixed that when testing if a gamemode is possible >> (glutGameModeGet(GLUT_GAME_MODE_POSSIBLE)), the gamemode settings >> you requested get overwritten with those of the current display >> >> - vs2010_project_files.patch >> Fixed problem in VS2010 project files where library files were >> never copied to freeglut/lib if that folder doesn't already exist >> >> - readme-win32.patch >> Adding note on where to find the library files when compiling with >> visual studio 2008 or 2010. >> >> Best, >> Dee >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> >> >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> |
|
From: Diederick C. N. <dc...@gm...> - 2011-03-17 04:33:22
|
All works well, thanks John! Best, Dee On Thu, Mar 17, 2011 at 12:28, John Fay <joh...@cy...> wrote: > Done. > > On 3/16/2011 11:06 PM, Diederick C. Niehorster wrote: > > Hi John, > > Nice work, on the Windows end, all is tested to work well! > > I have two more patches that came up in testing. > > The attached one.patch modifies the one.c demo by both trying to enter > an impossible mode and, afterwards a possible mode, to see how this is > handled. It also uses glutGameModeGet(GLUT_GAME_MODE_ACTIVE) to test > if gamemode was actually entered succesfully. > > The gamemode.patch file makes the error message on a failed mode > switch a bit more informative. > > Best, > Dee > > On Thu, Mar 17, 2011 at 10:56, John Fay <joh...@cy...> wrote: > > > OK, those are in. > > - John > > > On 3/16/2011 1:06 AM, Diederick C. Niehorster wrote: > > Hi John, > > Glad you could get these patches in. I have attached a bunch of > patches against the current HEAD (half hour old checkout now), some to > fix a few small issues with your application of my gamemode patches, > and some unrelated. > > - gamemode-unspecified_windows.patch > A small problem appeared in applying the patch to fix game mode so > that it doesn't override unspecified displaymode settings. Putting > the if >0 checks makes FreeGLUT revert to its default values for > those unspecified parameters as I specifically intended the -1 to > end up in FreeGLUT's parse of what the user asks for. > > - gamemode-unspecified_X11.patch > Fixing game mode in X11 so that it doesn't override unspecified > settings. This is taken from the version of my patch fixed by John > Tsiombikas, email Fri, Mar 11, 2011 at 16:48, it apparently wasn't > applied before. > > - gamemode-testing_windows.patch > Per Diederick C. Niehorster, email Thu, Jan 27, 2011 at 13:59 > Fixed that when testing if a gamemode is possible > (glutGameModeGet(GLUT_GAME_MODE_POSSIBLE)), the gamemode settings > you requested get overwritten with those of the current display > > - vs2010_project_files.patch > Fixed problem in VS2010 project files where library files were > never copied to freeglut/lib if that folder doesn't already exist > > - readme-win32.patch > Adding note on where to find the library files when compiling with > visual studio 2008 or 2010. > > Best, > Dee > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
Thanks for helping keep SourceForge clean.
X