X11: Hotkeys aren't working when first defined keymap is not latin-one compatible #47228

New Issue

Loïc Faure-Lacroix · 2016-01-24T07:31:35+01:00

2016-01-24 07:31:35 +01:00

System Information
Linux localhost 4.1.12-gentoo #1 SMP Fri Jan 8 14:24:27 ICT 2016 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux intel HD4000

Blender Version
Broken: 2.72b and 2.76b http://data.gpo.zugaina.org/nightmare/media-gfx/blender/blender-2.76b.ebuild

Short description of error

Blender doesn't handle any keypress except of numbers, arrows, space, tab, shift, ctrl, alt, -, =, and a few others. Didn't try everything but no letters actually work.

When trying to set a key in the configuration, I see two strange behaviour.

If I press a letter, it doesn't do anything, but if I move my cursor at the same time, it sets the keybinding to In-between move as a Mouse event. If I open the advanced dialog, and try to set a letter from their, it set it backs to what it was before the "press a key". I can set the event to a number but if I press a letter it just reset the field to what it was. In the simple form, it doesn't reset anything, it doesn't react in any way.

Simple dialog behaviour:
press a letter: nothing
press an other letter: nothing,
press a number: select the pressed number

Advanced dialog:
Press a letter: select what it was before
Click on the box again:
Press a number: select the number pressed

The other strange thing is that when I run blender from the command line with debug all, whenever I press letters it logs the following in my terminal:

  wm_event_add_ghostevent Send double click

I feel that letters are handled as mouse events. Any idea how to fix this or where to check. It could be a config problem. I have this problem for a couple of months and no version of blender is working. That said, typing in a text box works and letters are handled as letters as expected. It's just not working for shortcuts containing letters.

**System Information** Linux localhost 4.1.12-gentoo #1 SMP Fri Jan 8 14:24:27 ICT 2016 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux intel HD4000 **Blender Version** Broken: 2.72b and 2.76b http://data.gpo.zugaina.org/nightmare/media-gfx/blender/blender-2.76b.ebuild **Short description of error** Blender doesn't handle any keypress except of numbers, arrows, space, tab, shift, ctrl, alt, -, =, and a few others. Didn't try everything but no letters actually work. When trying to set a key in the configuration, I see two strange behaviour. If I press a letter, it doesn't do anything, but if I move my cursor at the same time, it sets the keybinding to In-between move as a Mouse event. If I open the advanced dialog, and try to set a letter from their, it set it backs to what it was before the "press a key". I can set the event to a number but if I press a letter it just reset the field to what it was. In the simple form, it doesn't reset anything, it doesn't react in any way. Simple dialog behaviour: press a letter: nothing press an other letter: nothing, press a number: select the pressed number Advanced dialog: Press a letter: select what it was before Click on the box again: Press a number: select the number pressed The other strange thing is that when I run blender from the command line with debug all, whenever I press letters it logs the following in my terminal: ``` wm_event_add_ghostevent Send double click ``` I feel that letters are handled as mouse events. Any idea how to fix this or where to check. It could be a config problem. I have this problem for a couple of months and no version of blender is working. That said, typing in a text box works and letters are handled as letters as expected. It's just not working for shortcuts containing letters.

Loïc Faure-Lacroix commented

2016-01-24 07:31:35 +01:00

Changed status to: 'Open'

Loïc Faure-Lacroix commented

2016-01-24 07:31:35 +01:00

Added subscriber: @llacroix

Bastien Montagne commented

2016-01-24 11:31:51 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2016-01-24 11:31:51 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2016-01-24 11:31:51 +01:00

Bastien Montagne self-assigned this 2016-01-24 11:31:51 +01:00

Bastien Montagne commented

2016-01-24 11:31:51 +01:00

I’m sorry, but this is somehow specific to your system, you must be using some weird configuration of keyboard handling. Debugging this would require a direct access to the system (or a precise way to reproduce the issue)… Archiving for now, unless some way to reproduce it is given to us we cannot do anything.

Loïc Faure-Lacroix commented

2016-01-24 14:40:51 +01:00

I understand quite well, my keyboard configuration has nothing special as far as I know. I'm using Gnome3 but nothing custom. Even if you can't do anything, I can do something. I'd just need some pointer to know where to look for. I can report anything necessary.

Most of what I wrote proves that the keyboard is being detected. It is mostly working except for the letters. That's what's strange. I would expect it to work 100% or not working 100%.

If someone has any idea which dependencies are required for the keyboard or events. It could be a good start to know if all dependencies are present. If I have to have my hand into the code, it's also not a problem. Just don't close or archive that bug report as it's not going to help me in anyway to fix that Issue.

I understand quite well, my keyboard configuration has nothing special as far as I know. I'm using Gnome3 but nothing custom. Even if you can't do anything, I can do something. I'd just need some pointer to know where to look for. I can report anything necessary. Most of what I wrote proves that the keyboard is being detected. It is mostly working except for the letters. That's what's strange. I would expect it to work 100% or not working 100%. If someone has any idea which dependencies are required for the keyboard or events. It could be a good start to know if all dependencies are present. If I have to have my hand into the code, it's also not a problem. Just don't close or archive that bug report as it's not going to help me in anyway to fix that Issue.

Loïc Faure-Lacroix commented

2016-01-24 14:48:13 +01:00

As far as I know, the bug doesn't seem to be version dependent. All version I installed on my current system had the same behaviour. Chances are that the bug is related to GHOST. While searching around, I read that there is a system in blender that detect the platform and handle events accordingly for each platform. My guess is that this is a place where it could break.

It's not clear how GHOST detect the OS but it could be possible that gentoo isn't defining things like most "binary distributions". Without any hints, the detection could fallback to anything... But I'm here to find out.

As far as I know, the bug doesn't seem to be version dependent. All version I installed on my current system had the same behaviour. Chances are that the bug is related to GHOST. While searching around, I read that there is a system in blender that detect the platform and handle events accordingly for each platform. My guess is that this is a place where it could break. It's not clear how GHOST detect the OS but it could be possible that gentoo isn't defining things like most "binary distributions". Without any hints, the detection could fallback to anything... But I'm here to find out.

Bastien Montagne commented

2016-01-24 14:54:58 +01:00

If ghost where detecting your OS as windows or OSX one, believe me you would not even see Blender at all!

Issue here is, this tracker is to fix bugs in Blender, not to make user support. We cannot spend hours trying to remotely guess what can goes wrong on a specific system to finally find whether it is actually a Blender bug, or some other issue - we have to get quick evidence it’s a blender bug, with easy way to reproduce it. Looks like you already found running Blender with --debug-all option (you could use only -d --debug-events --debug-wm set of options here to reduce the noise, btw), beyond that it’s up to you to understand why your keybord does not generates proper GHOST events.

You seems to be using some third-part builds too, please always check official Blender releases (and the latest build from our buildbot) too before reporting a bug.

If ghost where detecting your OS as windows or OSX one, believe me you would not even see Blender at all! Issue here is, this tracker is to fix bugs in Blender, not to make user support. We cannot spend hours trying to remotely guess what can goes wrong on a specific system to finally find whether it is actually a Blender bug, or some other issue - we have to get quick evidence it’s a blender bug, with easy way to reproduce it. Looks like you already found running Blender with `--debug-all` option (you could use only `-d --debug-events --debug-wm` set of options here to reduce the noise, btw), beyond that it’s up to you to understand why your keybord does not generates proper GHOST events. You seems to be using some third-part builds too, please always check official Blender releases (and the latest build from [our buildbot](https://builder.blender.org/download)) too before reporting a bug.

Loïc Faure-Lacroix commented

2016-01-24 17:13:20 +01:00

I'll check with the buildbot build

Loïc Faure-Lacroix commented

2016-01-24 17:28:35 +01:00

Same thing with the build from buildbot or download page from blender. I could try an older release though later tomorrow.

Loïc Faure-Lacroix commented

2016-01-25 12:04:19 +01:00

Ok, I got it. I found the bug,it might be possible to reproduce. Blender seems to be using the first keyboard layout available on the computer instead of using the current keyboard layout.

My computer has Russian as first keyboard layout and even if I switch between one keyboard layout to an other, it will not work until I move my Canadian keyboard layout first in the list. There isn't even a need to connect/disconnect from the session to take effect.

Blender doesn't use the current layout but the first one in the list.

Ok, I got it. I found the bug,it might be possible to reproduce. Blender seems to be using the first keyboard layout available on the computer instead of using the current keyboard layout. My computer has Russian as first keyboard layout and even if I switch between one keyboard layout to an other, it will not work until I move my Canadian keyboard layout first in the list. There isn't even a need to connect/disconnect from the session to take effect. Blender doesn't use the current layout but the first one in the list.

Bastien Montagne commented

2016-01-25 14:29:19 +01:00

Changed status from 'Archived' to: 'Open'

Bastien Montagne reopened this issue

2016-01-25 14:29:19 +01:00

Bastien Montagne commented

2016-01-25 14:29:19 +01:00

Yep, good catch, thanks for investigating!

Can confirm that here, looks like XLookupKeysym() only always use first defined keymap, while XLookupString() uses correct active one... Rather odd, but for now will just use the later instead of former one.

Yep, good catch, thanks for investigating! Can confirm that here, looks like `XLookupKeysym()` only always use first defined keymap, while `XLookupString()` uses correct active one... Rather odd, but for now will just use the later instead of former one.

Bastien Montagne changed title from ~~Hotkeys aren't working~~ to X11: Hotkeys aren't working when first defined keymap is not latin-one compatible

2016-01-25 14:30:17 +01:00

Loïc Faure-Lacroix commented

2016-01-25 15:47:54 +01:00

Yes, that said, I don't see why it wouldn't be possible to set keys to a keyboard other than latin. This of course would make some custom layout impossible to use on non-latin keyboards but would allow other people to use their own russian/chineese layouts for example.

Bastien Montagne commented

2016-01-25 16:14:32 +01:00

Using other keys would mean a complete change in our shortcut system, which is based on defines and not actual 'letter value'. Also, please keep in mind we have to handle at least three different OSs here, so we need some level of abstraction. Currently, supporting non-latin keymaps would basically mean adding hundreds (if not thousands) of new defines and RNA enum items, I do not think we'd want that. Other solution would be a way for users to define their own custom mapping between 'native' chars and 'Blender' (latin) ones (for shortcuts only), but that’d be also rather involved change. :/

blender-admin commented

2016-01-28 14:57:33 +01:00

This issue was referenced by 12c71508c2

This issue was referenced by 12c71508c2d7b719cc5cd0bf5ed79123aa38e52d

Bastien Montagne commented

2016-01-28 15:02:06 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2016-01-28 15:02:06 +01:00

Loïc Faure-Lacroix commented

2016-01-28 15:38:37 +01:00

Cool

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

X11: Hotkeys aren't working when first defined keymap is not latin-one compatible #47228