Bug 971577 - glutGetModifiers() always returns 0 in mouse callback
glutGetModifiers() always returns 0 in mouse callback
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: freeglut (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-06 16:28 EDT by caracalbjd
Modified: 2015-05-04 06:32 EDT (History)
2 users (show)

See Also:
Fixed In Version: freeglut-2.8.1-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-24 08:47:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to be used in rpm spec after all other patches (2.46 KB, patch)
2013-06-06 16:28 EDT, caracalbjd
no flags Details | Diff
small program compiled cc -o tst t.c -lglut (1.34 KB, text/plain)
2013-06-10 15:01 EDT, caracalbjd
no flags Details
updated test program (1.46 KB, text/x-csrc)
2015-05-01 15:29 EDT, jan p. springer
no flags Details

  None (edit)
Description caracalbjd 2013-06-06 16:28:19 EDT
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:
Comment 1 Tomas Smetana 2013-06-10 03:14:01 EDT
Thanks for reporting.  I'll take a look.
Comment 2 Tomas Smetana 2013-06-10 05:48:01 EDT
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.
Comment 3 Tomas Smetana 2013-06-10 08:10:21 EDT
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?
Comment 4 caracalbjd 2013-06-10 12:31:51 EDT
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.
Comment 5 caracalbjd 2013-06-10 15:01:32 EDT
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.
Comment 6 Tomas Smetana 2013-06-11 06:25:39 EDT
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.
Comment 7 Tomas Smetana 2013-06-11 07:07:15 EDT
Good to add -- I'm testing with the modified version of the "CallbackMaker" demo from the freeglut sources.
Comment 8 Fedora End Of Life 2013-12-21 10:32:54 EST
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.
Comment 9 Tomas Smetana 2014-01-24 08:47:04 EST
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.
Comment 10 jan p. springer 2015-05-01 15:17:30 EDT
on fedora 21 w/ freeglut-2.8.1-5 this is still not working. any plans to upgrade to freeglut-3.0?
Comment 11 jan p. springer 2015-05-01 15:25:24 EDT
appologies. just compiled the test program under f21 and it works. seems like my problem's somewhere else.
Comment 12 jan p. springer 2015-05-01 15:29:05 EDT
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
Comment 13 Tomas Smetana 2015-05-04 06:32:41 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.