Page MenuHome

Alt (and ctrl) keys remain active after switching to Blender app
Closed, InvalidPublicTO DO


System Information
CentOs 6.5, Intel Graphic Chip

Blender Version
2.70a f93bc76

Short description of error
If I switch to another application and come back to blender, 3d view is not responding.

Exact steps for others to reproduce the error
Cant reproduce the error, but if I work in Editmode (not tested in other modes), switch to Firefox, come back to Blenders Editmode - I cant select anything and ctrl-tab shortcut also dont work. BUT If I resize the Blender-Window (doubleclick on the window bar), Blender is back and I can continue working. Maybe it is a bug of my old graphic card. I will continue to ensure.

Event Timeline

Sergey Sharybin (sergey) lowered the priority of this task from 90 to 30.May 12 2014, 3:06 PM

Please try using blender-softwaregl from the official release archive in order to eliminate opengl errors and see whether it makes a difference for you.

This is likely a driver/hardware issue. Could you please test this with the blender-softwaregl script? (should be next to the blender binary in official builds, or release/bin/ in the sources).

Other than that there is not much we can do about this, if we can't even reproduce it.

Of course. Tested it 5min with software-gl and the same result. 3D View (Objectmode or Editmode) is not responding except the 3d-manipulator. All other workareas like timeline or properties work as expected.

I will try it on another computer with a "real" graphic card.

What is the size of your GPU memory? If the memory is less than 512M and it becomes full maybe you get a very slow Blender which seems like not responding. However I don't know what happens with software GL in this case.

Bastien Montagne (mont29) raised the priority of this task from 30 to Normal.May 24 2014, 4:12 PM

For what’s worth, I also experience that kind of stuff (switching off Blender, then back, mouse overring (higlight) works, but neither mouse clicks nor keyboard strokes). Debian Wheezy 64, AMD HD5730 (free driver xorg-video-radeon 7.3, 1GB of mem).

I never took the time to dig it, but I doubt it’s GPU driver issue (already had it when using official driver), would rather suspect some strange stuff going on in Ghost layer? Will try to investigate.

Ok, using debug build and debug even options, shows that when Blender does not react to mouse clicks, it’s because… click events are sent as MMB clicks!!!

next step: dig in ghost.

Oh, actually, think I found the culprit :P

Ghost itself generates the right event (just checked it). But I’m on a laptop, so enabled the 'emulate MMB' option (using… alt-LMB - and we do use ctrl-alt to switch to other app).

So it’s yet another 'modifier key issue' bug! Indeed, checked:

  • When mouse does not click, ctrl is up, and event is 'translated' as MMB (hence alt is up too).
  • Just hitting alt key is enough to fix the issue (and ctrl too, btw).

So it’s an issue very similar to T40317, but on linux this time… :/

Bastien Montagne (mont29) renamed this task from Blender sometimes does not respond when I switch back to it to Alt (and ctrl) keys remain active after switching to Blender app.May 24 2014, 4:45 PM

So, final for today, sometimes wm gets a 'keydown' Ghost event on alt just after it's resumed. Obviously, it then sets its internal 'state' alt modifier on - but never get a matching 'keyup' Ghost event…

I don’t know from where this alt press comes from (if I had to guess, I would say it’s the one from alt-press when we switched away from Blender, that remains somehow stuck in event queue and is then handled when focused back - and yet, its time value is after the one of the 'WindowActivate' one), and I don’t really know how to get rid of it.

My best idea currently would be to always double check modifiers key events (or modifiers states) with query_qual() calls, but I’d bet it could break in other cases then (like alt being missed in very quick alt-something, because of delay between event happening and event being handled). Or fix this mess in Ghost itself, but does not seems simple either. Maybe there is some way to 'purge' system events when we lose focus, so that old pending ones don’t get sent once focus is back? But that could break other things maybe?

Campbell, you did some work in this are recently, maybe you have better ideas?

If the user changes the input focus while pressing the modifier, I'm not sure you will get the press or the release event. The best is to use the state of the modifiers provided with the events. If you query the actual state from the OS maybe it is not the same as the state was when the event happened. If the keyboard or mouse event contains the modifier information, it is the best to use that. For example in X11, XButtonEvent, XKeyEvent and even XMotionEvent also contains the state of the modifier keys in the 'state' variable of the structure.

Hi, i'm new here and sorry about my bad language. I don't know is this related to this bug (or fixed already), but i noticed that blender 3d window freezes up in ubuntu 14.04 and blender 2.70.5 when system language is finland (finnish / latin) and when using alt-key (alt+e extrude and alt+tab switching). When i change keyboard layout to english blender starts respond keyboard input normally. I tested this in 2.70.5 / 2014/5/17, 2.70.5 / 2014/5/19, 2.70.5 / 2014/5/26 dated builds.

Checked this and I cant redo the bug. Can someone list exact steps to redo the problem?

A side effect. The mouse wheel works on unfocused windows too. Start two instances of Blender in Linux side by side. First map the ctrl-wheel and wheel events to something distinctive. Like zoom and pan for the 3D view. Press the Ctrl button and use the mouse wheel on both windows without changing the input focus. You will see that the focused window gets ctrl-wheel events but the unfocused gets wheel only.

@Fazekas Laszlo (totoro) this sounds like a different issue (though it might be related), probably better to make a new report.

@Campbell Barton (campbellbarton) :

  1. Start Blender, default scene.
  2. alt-tab to another app (OS file browser e.g.).
  3. alt-tab back into Blender.

This does not happen always (not even often, actually, about once every ten times for me), so you have to repeat 2 & 3 several times until LMB click in Blender fails. I have the feeling the responsiveness of Blender has no influence here (i.e. it happens in both basic startup scene and heavy scene), however I suspect to rapidity of the alt-tab combo to do have some influence (the quicker the alt-tab, the more probable LMB fails - i.e. an ALT_DOWN event to be generated by ghost).

Just like to add that it happened to me, too, a couple of times on Win7, but as it's not reproducable, I didn't post a report. I can't reproduce it just by Alt+Tab. I was working inside Blender when it happened. So, only info for now is it's not limited to Linux.

Hello, i record video of my blender ubuntu keyboard problems mentioned earlier.
Video is found here at the moment..
Video explains the problem best.

@Bastien Montagne (mont29): I disagree, if you are using the keyup/keydown events to handle the modifier keys state, the mouse wheel is exactly the same problem. There are modifier flags in the keyboard/mouse events for a reason.

Only the keyboard focus window gets the keyup/keydown events and if the user change the focus to another application (or even not, ie. mouse wheel or motion events), this information, just like the state of other keys is missing. But other keys and mouse buttons usually trigger actions with keyup or keydown so this is not a problem.

In Linux (X11) the modifier flags are directly in the event messages.

In Windows it's not there but you can check the state of the modifier keys with GetKeyState() when you received the message. I'm not a Windows expert so maybe there is a better way.

In OSX you can get the modifier keys from the event with GetEventParameter().

Talked a bit with Campbell, we’ll probably have to rework a bit ghost/WM events handling. Right now, WM gets ghost events, and when keydown/up of modifiers keys like alt or ctrl, it caches this state in WM data. This indeed sounds complicated, and gives often issues esp. when focus changes, etc. Would make much more sense to handle modifiers keys at Ghost level (as you said, @Fazekas Laszlo (totoro)).

Main issue here will probably be that we’ll have to sync between several devs, since it will be platform-specific code. Will move to TODO anyway, this is not fixable in a few lines of code.

Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Jul 20 2014, 3:43 PM

Closing the report itself, no need to keep it open (added a TODO item about it).