Created attachment 757894 [details] patch to be used in rpm spec after all other patches Description of problem: glutGetModifiers() stopped working when I upgraded from FC14 to FC18. This seems to be a bug in freeglut. It gets the correct state of the modifiers but pushes an event on the X stack without the modifiers so they're lost. I patched my local freeglut to fix this. It looks like the upstream freeglut has been refactored and this may no longer be an issue but I'm putting this patch here for others. Version-Release number of selected component (if applicable): freeglut-2.8.0-7 How reproducible: Very easy Steps to Reproduce: 1.Compile program that checks glutGetModifiers() in a mouse button callback 2.See that all modifiers are lost 3. Actual results: glutGetModifiers() always returns 0 Expected results: glutGetModifiers() should return state indicating CTRL?SHIFT?ALT etc. Additional info:
Thanks for reporting. I'll take a look.
I don't have any F-18 box at hand so I did a quick dirty test: recompiled the F-18 package on my RHEL-6 workstation and so far the glutGetModifiers() seem to be working OK.
Same with a freshly updated F-18: freeglut-devel-2.8.0-7.fc18.x86_64 and the glutGetModifiers() is returning the bit mask as expected. Do you have a reproducer for this bug?
I have a function connected to mouse with glutMouseFunc(myfunc) in myfunc() it does the following: myfunc() { if(state == GLUT_DOWN) { switch(button) { case GLUT_LEFT_BUTTON: if (glutGetModifiers() == GLUT_ACTIVE_CTRL) { doctrlfunc(); break; } else if (glutGetModifiers() == GLUT_ACTIVE_SHIFT) { doshiftfunc(); break; } dobuttonfunc(); This worked in FC14 but stopped working in FC18. I put in an old fashioned printf of glutGetModifiers() and it was always 0. I grabbed the debug rpm for freeglut and saw that myfunc() is called with the event that is put back on the X event queue in fgHandleExtensionEvents the XI_ButtonPress case. In that code it builds a ButtonPress event to put back on the event queue. When that event is processed in freeglut_main.c glutMainLoopEvent it tries to set the modifier info from the event state but in the previously mentioned function fgHandleExtensionEvents the state was only set with the button not the modifier stuff so the modifier is lost. That's what I changed with my patch I also decided that the modifier should come from the event->modsa.effective since according to the X docs includes the state of all of the modifier buttons including caps lock etc. Hope this helps.
Created attachment 759335 [details] small program compiled cc -o tst t.c -lglut This simple test opens a window and prints "got button" to the console where it was started from if you press the left mouse button while the mouse pointer is in that window. It also prints "got shift" or "got ctrl" if those buttons are pressed. This works on FC14 or FC18 with my patch but not with the standard freeglut-2.8.0-7 that installs with FC18.
Ah... I misread the bugreport... My apologies. You're right. The glutGetModifiers() doesn't work with mouse buttons (i tested only keyboard...). And things look strange also on Rawhide with freeglut-2.8.1 where I seem to get only some modifiers (no Alt) for some mouse buttons. I will build a test package with your patch and try it out. Sorry again for the confusion -- I must be more careful.
Good to add -- I'm testing with the modified version of the "CallbackMaker" demo from the freeglut sources.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This looks to be working quite well now with F-19 and F-20 freeglut-2.8.1-3. I'm not sure what has changed but I suspect the Xorg might have played some role too.
on fedora 21 w/ freeglut-2.8.1-5 this is still not working. any plans to upgrade to freeglut-3.0?
appologies. just compiled the test program under f21 and it works. seems like my problem's somewhere else.
Created attachment 1021020 [details] updated test program slightly updated version of the test program. changes: - prints the actual value of glutGetModifiers - GLUT_ACTIVE_* are masks so we AND them and try to see if any (not just one) is present
(In reply to jan p. springer from comment #10) > on fedora 21 w/ freeglut-2.8.1-5 this is still not working. any plans to > upgrade to freeglut-3.0? No plans to upgrade freeglut in the stable Fedora releases: it's already present in Rawhide (future F23) though. This was an odd bug -- I think the problem described in this report was not really in freeglut itself since (IIRC) the behaviour was inconsistent between Fedora releases.