Red Hat Bugzilla – Bug 192086
PATCH: (proper) fullscreen support
Last modified: 2007-11-30 17:11:33 EST
Hi, I've been busy the last 2 days packaging tuxkart which uses plib. During this packaging I've found both a bug and a missing feature in plib, wich are both fixed by the attached patch: -The bug is that plib (pw) creates a resizable window, but that tuxkart expects the window to always be the size it has specified iow it expects a non resizable window. Now one could concider this a bug in tuxkart, but its not uncommon for games to be written to a hardcoded resolution and not written for a resizable window. Besides making the window non resizable is much easier then fixing tuxkart. To fix this I've added a new function: void pwSetResizable ( bool enable ) ; The default behaviour is still to create a resizable window because I didn't want to break the api and/or change any defautl behaviour. -The missing feature is the fact that plib doesn't have fullscreen support, atleast not really: * Its possible to create a fullscreen window by passing -1 for width and height and disabling the border. But I've tried this (6 months ago or so) and there were issues (If I remember correctly the panel was on top of the window). * Besides the issues their is the problem that in that case your desktop size gets used and the application thus cannot specify the size it wants (see above). Also the desktop size usually is a rather high resoltution which peformance wise is not ideal for 3D games. * Last but not least with the current "fullscreen" code its not possible to switch between fullscreen <-> window easily. * The attached patch uses XF86VidMode to switch to the requested resolution instead of always using the desktopsize and it allows easy fullscreen <-> window switching: void pwSetFullscreen () ; void pwSetWindowed () ; void pwToggleFullscreen () ; * Notice that I've choosen not to reuse the border flag for the new fullscreen support, so that the behaviour of plib is 100% identical for apps who do not use these new functions. If an app wants to use the new fullscreen code it must call pwSetFullscreen () after pwInit (). * Some apps don't want to show a cursor when fullscreen, whereas a hidden cursor in windowed mode is annoying. Thus I've added a new function which allows an app to specify seperate cursors for fullscreen and windowed mode: void pwSetCursorEx ( int wm, int fs ) ; Phew, long story. Well thats it I hope you like it! I will also send the patch upstream for intergration there. I can understand if you're a bit worried this patch may break other stuff *, so I would like to offer to co-maintain plib with yopu. If you agree I'll ad myself to the initial CC field of owners.list so that I get copied on any plib bugs. (If you want I'm even in for taking plib completly over). * although the normal code path without using the new functions is hardly changed, so that really shouldn't happen. p.s. I've also noticed that plib currently creates .a files. For easy pushing of bugfixes to plib without having to recompile plib I would like to see plib providing (properly versioned) .so files. Will yuo accept a patch for this?
Created attachment 129324 [details] Patch as described
I've completed packaging tuxkart so you can now use tuxkart to test out the patch, the review request is bug 192119 .
One last important note which I forgot: you need to add -DXF86VIDMODE to the CXXFLAGS when compiling plib with this patch, so the new configure line should become: %configure CXXFLAGS="%{optflags} -fPIC -DXF86VIDMODE"
I don't want to be rude and I know we are all volunteers, but: ping?
Oops, sorry for not replying earlier! I really appreciate all your work, and know how well you contribute upstream to projects you make changes to, so I'm really all for you taking over maintainership of plib (and plib16 if you want) in Extras :-) Just let me know if/when you make incompatible changes or have it provide a shared library at last so that I can patch/rebuild the packages I maintain that use it (only torcs from the top of my head). What do you think?
Sounds like a plan shall I edit owners.list and put me in as owner then? I'll take a look at making a proper .so's out of plib and once I'm ready with that I'll let you know. Have you had contact with upstream lately, I haven't had a response to my patch from upstream yet? About plib 1.6 I didn't do a complete check but 1.8 mostly seems api compatible with 1.6 wouldn't it be better to fix 1.6 using packages to compile against 1.8, send patches upstream and just drop 1.6? If you can point me to any packages using 1.6 I can take a stab at moving them to 1.8 (as time permits).
Yes, it's the plan : You can change owners.list :-) As for plib 1.6 vs. 1.8, I thought the changes were major since configure checks are quite strict on one vs. the other, and I even thought that important changes went in between point releases since plib builds only as a static library by default... I really have no objections in seeing that change, go for it!
Ok, Ive made myself owner of plib and added you into the initial-CC field. I've added myself into the initial-CC field for plib16. I'm waiting with releasing a plib with this patch untill I've also got an .so patch ready. Reassigning to me in the mean time.
Okay, I've finished writing .so support for plib into the spec file. The solution isn't pretty by besides that it should work fine. I've concidered adding proper shared lib support to the autoxxx files in plib. But upstream currently isn't interested so my current solution will do fine and is probably easier to maintain seperate from upstream too. I've comitted this to devel and requested a build. I think its best to lett this sit in devel for a while before making the same changes to FC-5 and FC-4 .
Matthias, Adding you to the CC (should have done that when assigning to me) a new version with the fullscreen support and creating .so files is in -devel now, can you rebuild and test your packages against this I would like to push it for FC-4 and FC-5 too. See above comments for more details on the .so file stuff.