After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 558586 - handling of keyboard under darwin (quartz)
handling of keyboard under darwin (quartz)
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.14.x
Other All
: Normal normal
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-10-30 20:14 UTC by Arnaud Charlet
Modified: 2008-11-12 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch against 2.12.11 (4.17 KB, patch)
2008-10-30 20:17 UTC, Arnaud Charlet
none Details | Review
new patch against trunk (2.58 KB, patch)
2008-11-03 11:41 UTC, Arnaud Charlet
none Details | Review
Another approach (1.74 KB, patch)
2008-11-10 15:05 UTC, Richard Hult
none Details | Review

Description Arnaud Charlet 2008-10-30 20:14:50 UTC
Please describe the problem:
As discussed on gtk-devel-list,
The current code in gdk/quartz/gdkkeys-quartz.c uses a deprecated (since 10.5)
API to handle keyboard layout on darwin, which is not available to x86-64
applications.

Here is an initial patch that uses the new TIS API.
A better patch would probably be to conditionalize the old code and keep
support for 10.4 this way.


Steps to reproduce:
Building Gtk+ with quartz on 10.5 with x86-64 (gcc -m64) will exhibit
the crash whenever you hit a key.

Actual results:
crash

Expected results:
key insert :-)

Does this happen every time?
yes on x86-64 darwin

Other information:
I'll file the patch as an attachmenet as soon as I get the number
Comment 1 Arnaud Charlet 2008-10-30 20:17:35 UTC
Created attachment 121687 [details] [review]
patch against 2.12.11

patch against 2.12.11. Can probably be applied out of the box on 2.14, let me
know if not.
Comment 2 Richard Hult 2008-11-03 10:12:21 UTC
If someone wants to work on getting this in, the plan is to use something like

#if MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_4
 new code...
# else
 old code...
#endif


Comment 3 Arnaud Charlet 2008-11-03 11:41:21 UTC
Created attachment 121858 [details] [review]
new patch against trunk

Here is a new patch against svn trunk, with support for older mac os versions based on the macro you suggested.

Let me know if you need anything else.

Arno
Comment 4 Richard Hult 2008-11-05 19:56:04 UTC
It looks ok, thanks! Have you tried on 10.4 (or using -mmacosx-version-min=10.4 or so)?

I assume you have been able to build everything up to gtk+ with -arch x86_64? I'm a bit surprised because there are other things that should have issues (pango and glib for example).
Comment 5 Arnaud Charlet 2008-11-05 20:12:41 UTC
I haven't tried with -mmacosx-version-min=10.4, if you or someone else
could try that'd be great, otherwise I can give it a try (I just have too many things to do at the moment!).

I could build everything with x86-64 with the following versions:

    glib-2.18.2       
    atk-1.24.0          
    cairo-1.8.0
    pango-1.22.2        
    gtk+-2.12.11
    pixman-0.12.0

and I'm working on upgrading to Gtk+ 2.14.4 and cairo 1.8.2 very soon now.

I had no particular troubles with glib 2.18.2 nor pango 1.22.2 (although we do
have some tricks, see below).
I did have a trouble with cairo 1.8.0 because cairo-quartz-font.c references
FMGetATSFontRefFromFont which is not defined on my system, so I had to add
the right definition.

Things are tricky though, and we have a quite complex build script for
Gtk+ that we've refined for all the platforms we build Gtk+ for
(which includes windows, solaris, linux, darwin, and in the past hpux, tru64, irix), that's quite a challenge...

Anyway, there are some strange issues on darwin, in particular wrt to
setting (or not) DYLD_LIBRARY_PATH. We also need to patch libtool a little,
make use of some LDFLAGS on some modules (such as -no-undefined -bind_at_load).

Getting libiconv to build and using the newly built version instead of the system version is also quite a challenge...

Arno
Comment 6 Richard Hult 2008-11-05 20:42:14 UTC
I can try to build against 10.4, don't worry about that.

The issues I've run into are libjpeg (and some other modules) ends up as 32 bit no matter what I do, glib fails with this:

var/folders/zt/ztNMqFM6H58gwwmtvGN9Ok+++TI/-Tmp-//ccRMj5p8.s:814:Incorrect register `%rdx' used with `l' suffix

Pango should fail since it uses ATSU(I) which is not supposed to be available in 64-bit, GTK+ uses some more APIs that are not supposed to be in 64-bit.
Comment 7 Richard Hult 2008-11-06 15:36:37 UTC
Committed to trunk, and tested with 10.4. Thanks again!
Comment 8 Arnaud Charlet 2008-11-06 15:41:13 UTC
Great, thanks!

We will see if we run into other 64 bits issues, although we haven't encountered
issues with pango/atsui so far, which is surprising.

Arno
Comment 9 Leandro Pereira 2008-11-08 12:11:08 UTC
GTK+ still crashes here. I'm on 10.5.5 on a white Macbook, all updates applied, built GTK+ from trunk with jhbuild yesterday (checked the patched file, changes are there).

All GTK+ programs I've tried aborts with the following messages:

Gdk-ERROR **: cannot get keyboard layout data
aborting...
Trace/BPT trap

Grepping the Makefiles for "m64" did not reveal a single hit; maybe this is the problem?
Comment 10 Richard Hult 2008-11-10 11:43:16 UTC
(In reply to comment #9)
> GTK+ still crashes here. I'm on 10.5.5 on a white Macbook, all updates applied,
> built GTK+ from trunk with jhbuild yesterday (checked the patched file, changes
> are there).

Is your issue really related to 64-bit and/or this bug report? The patch here only moves to a new API that exists in the 64-bit frameworks when building on 10.5, i.e. it has nothing to do with fixing 32-bit issues.

I think I need some background, like do you get this with unpatched trunk and building with 32-bit, what keyboard layout do you have?

> Grepping the Makefiles for "m64" did not reveal a single hit; maybe this is the
> problem?

No, we are not hardcoding GTK+ to build in 64 bit, that is something the user needs to control (e.g. by setting CFLAGS to "-arch x86_64" or so.
Comment 11 Leandro Pereira 2008-11-10 13:11:25 UTC
(In reply to comment #10)
> Is your issue really related to 64-bit and/or this bug report? The patch here
> only moves to a new API that exists in the 64-bit frameworks when building on
> 10.5, i.e. it has nothing to do with fixing 32-bit issues.

Using GTK+ from SVN, revision 21761 (prior to the patch included on this report being applied), I get no crashes. I've built it by using the default jhbuild settings, so it is being built as 32-bit.

> I think I need some background, like do you get this with unpatched trunk and
> building with 32-bit, what keyboard layout do you have?

I am using a third party keyboard layout ("U.S. International" [1], needed to type in Portuguese using a standard US keyboard). This keyboard layout works OK with GTK+ up to r21761, so I guess it's not the culprit. By the way, I've not tested with a stock keyboard layout and the latest trunk, but I can do so if needed.

[1] http://www.brockerhoff.net/usi/
Comment 12 Richard Hult 2008-11-10 13:14:18 UTC
Ah, thanks, that makes it more clear (it was the "still crashes" that consfused me).

I'll try to install that layout and see what happens.
Comment 13 Richard Hult 2008-11-10 13:58:15 UTC
OK, doing some investigation, it seems that the new input API in 10.5 doesn't work with non-xml keyboard layouts. Apple is recommending third party layouts to convert to xml using the tool klkchrtoxml which is included in:

http://developer.apple.com/textfonts/download/

Maybe you could report this to the author of the layout you are using? In the meantime we can look at adding a fallback using the old deprecated API as long as we're not building in 64-bit.

Comment 14 Richard Hult 2008-11-10 14:17:53 UTC
Reopen until fallback code has been fixed.
Comment 15 Richard Hult 2008-11-10 14:33:04 UTC
Oh, interestingly enough it seems that the latest version of the keylayout already is xml. Could you make sure you have the latest one and test again please? Just to make sure this isn't a different problem.

Comment 16 Richard Hult 2008-11-10 15:05:30 UTC
Created attachment 122328 [details] [review]
Another approach

This is a bit more strict approach, that only uses the new API when building for 64-bit. Arnaud, maybe you could check if that still works for you?

This way we still handle the old layout fallback that needs to old API, when building with 32-bit, keeping away from regressions.
Comment 17 Richard Hult 2008-11-10 15:06:05 UTC
Oh, and it would be great if you could try too, Leandro.
Comment 18 Arnaud Charlet 2008-11-10 15:30:06 UTC
Patch looks reasonable to me.

Arno
Comment 19 Leandro Pereira 2008-11-10 15:53:40 UTC
With the latest trunk (SVN rev. 21775) and the US International keyboard layout version 1.2 (I was with 1.1), GTK+ is working again.

I'll try later today with this new patch and the older version.
Comment 20 Richard Hult 2008-11-12 12:57:01 UTC
I've committed the updated patch. Please let me know if you run into more issues.